Firmware execution profiling and inspection

Abstract

The present application relates to firmware execution profiling and verification. An example method for generating an execution profile of a firmware module includes: receiving an execution trace of a firmware module including a plurality of executable instructions, wherein the execution trace includes a plurality of execution trace records, wherein each of the plurality of execution trace records indicates successful execution of an executable instruction identified by a program counter PC value; retrieving a first execution trace record of the plurality of execution trace records, wherein the first execution trace record includes a first PC value; identifying a first executable instruction referenced by the first PC value; identifying a firmware function containing the first executable instruction; incrementing a loop count of the firmware function by a loop number associated with the first executable instruction; and generating an execution profile of the firmware module using the loop count.

Description

Technical Field

[0001] The present disclosure relates generally to computer systems and, more particularly, to firmware execution profiling and inspection. Background Art

[0002] A memory subsystem may include one or more memory devices that store data. The memory devices may be, for example, non-volatile memory devices and volatile memory devices. In general, a host system may utilize a memory subsystem to store data at the memory devices and retrieve data from the memory devices. Summary of the invention

[0003] One aspect of the present disclosure relates to a method, which includes: receiving, by a processing device, an execution trace of a firmware module including multiple executable instructions, wherein the execution trace includes multiple execution trace records, wherein each execution trace record in the multiple execution trace records indicates the successful execution of the executable instruction identified by a program counter PC value; retrieving a first execution trace record in the multiple execution trace records, wherein the first execution trace record includes a first PC value; identifying a first executable instruction referenced by the first PC value; identifying a firmware function containing the first executable instruction; incrementing a loop count of the firmware function by a loop number associated with the first executable instruction; and using the loop count to generate an execution profile of the firmware module.

[0004] Another aspect of the present disclosure relates to a system, comprising: a memory; and a processing device coupled to the memory, the processing device being configured to perform operations, comprising: receiving an execution trace of a firmware module comprising a plurality of executable instructions, wherein the execution trace comprises a plurality of execution trace records, wherein each of the plurality of execution trace records indicates successful execution of an executable instruction identified by a program counter PC value; retrieving a first execution trace record of the plurality of execution trace records, wherein the first execution trace record comprises a first PC value; identifying a firmware function containing a first executable instruction referenced by the first PC value; incrementing a loop count of the firmware function by a number of loops associated with the first executable instruction; and generating an execution profile of the firmware module comprising source code lines associated with the first executable instruction, the first PC value, and the loop count.

[0005] Yet another aspect of the present disclosure relates to a non-transitory computer-readable storage medium comprising executable instructions, which, when executed by a processing device, causes the processing device to perform operations, the operations comprising: receiving an execution trace of a firmware module comprising a plurality of executable instructions, wherein the execution trace comprises a plurality of execution trace records, wherein each of the plurality of execution trace records indicates successful execution of an executable instruction identified by a program counter PC value; retrieving a first execution trace record of the plurality of execution trace records, wherein the first execution trace record comprises a first PC value; identifying a first executable instruction referenced by the first PC value; identifying a firmware function containing the first executable instruction; incrementing a loop count of the firmware function by a loop number associated with the first executable instruction; and generating an execution profile of the firmware module using the loop count. BRIEF DESCRIPTION OF THE DRAWINGS

[0006] The present disclosure will be more fully understood from the detailed description given below and the accompanying drawings of various embodiments of the present disclosure.

[0007] Figure 1 An example computer system incorporating a memory subsystem according to an embodiment of the present disclosure is shown.

[0008] Figure 2 An example execution profile generated by a firmware execution profiler operating in accordance with an embodiment of the present disclosure is schematically illustrated.

[0009] Figure 3 Another example execution profile generated by a firmware execution profiler operating according to an embodiment of the present disclosure is schematically illustrated.

[0010] Figure 4 is an example UML diagram illustrating a firmware execution flow enhanced by execution profile data generated by a firmware execution profiler operating in accordance with an embodiment of the present disclosure.

[0011] Figure 5 is a flow chart of an example method 500 of generating a firmware execution profile according to an embodiment of the present disclosure.

[0012] Figure 6 is a block diagram of an example computer system in which embodiments of the present disclosure may operate. DETAILED DESCRIPTION

[0013] Aspects of the present disclosure are to perform profiling and inspection on firmware, such as firmware utilized by a memory subsystem. The memory subsystem may be a storage device, a memory module, or a mixture of a storage device and a memory module. Figure 1Examples of storage devices and memory modules are described. In general, a host system may utilize a memory subsystem that includes one or more components, such as memory devices. The host system may provide data for storage at the memory subsystem and may request retrieval of data from the memory subsystem.

[0014] The memory device may be a non-volatile memory device, which is a package of one or more dies. The dies in the package may be assigned to one or more channels for communicating with the memory subsystem controller. The non-volatile memory device includes cells (i.e., electronic circuits storing information) grouped into pages to store data bits. One example of a non-volatile memory device is a NAND memory device. Figure 1 Other examples of non-volatile memory devices are described.

[0015] The memory subsystem controller may include one or more general or special purpose microcontrollers, special purpose logic circuits (e.g., field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), etc.), and / or other suitable processors that run executable firmware modules that manage the memory devices and facilitate their interaction with the host. The firmware may be initially developed using one or more suitable programming languages, such as assembly language or C / C++. Although general or special purpose integrated development environments (IDEs) running on personal computers or other computing devices may be used for firmware development and perform limited debugging tasks, such IDEs are generally not suitable for firmware profiling and performance verification because they cannot adequately simulate timing or instruction execution, thread synchronization, and / or other aspects that may be important for profiling and performance verification.

[0016] Aspects of the present disclosure address the above and other deficiencies by providing a firmware execution profile analyzer that generates an execution profile with single-cycle accuracy. The firmware execution profile analyzer can be implemented by one or more software modules running on a general-purpose computer system (e.g., a personal computer, a notebook computer, a tablet computer, a smart phone) or any other suitable computer system. A firmware execution profile analyzer operating according to one or more aspects of the present disclosure can receive and process execution traces generated by a firmware execution environment (e.g., a debugger). The firmware execution profile analyzer can process execution traces and generate various execution profiles and execution profile summaries, which can be used for performance verification and testing, as described in more detail below herein.

[0017] Figure 1 An example computer system 100 is shown that includes a memory subsystem 110 that includes a controller that runs various firmware modules for managing one or more volatile memory devices (e.g., memory device 140), one or more non-volatile memory devices (e.g., memory device 130), or a combination of such memory devices.

[0018] The memory subsystem 110 may be a storage device, a memory module, or a mixture of storage devices and memory modules. Examples of storage devices include solid-state drives (SSDs), flash drives, universal serial bus (USB) flash drives, embedded multimedia controller (eMMC) drives, universal flash storage (UFS) drives, secure digital (SD) cards, and hard disk drives (HDDs). Examples of memory modules include dual in-line memory modules (DIMMs), small outline DIMMs (SO-DIMMs), and various types of non-volatile dual in-line memory modules (NVDIMMs).

[0019] Computer system 100 may be a computing device such as a desktop computer, a laptop computer, a network server, a mobile device, a vehicle (e.g., an airplane, a drone, a train, a car, or other transportation), an Internet of Things (IoT) enabled device, an embedded computer (e.g., a computer included in a vehicle, industrial equipment, or a networked commercial device), or such computing device that includes a memory and a processing device (e.g., a processor).

[0020] Computer system 100 may include a host system 120 coupled to one or more memory subsystems 110. In some embodiments, host system 120 is coupled to memory subsystems 110 of different types. Figure 1 An example of a host system 120 coupled to one memory subsystem 110 is shown. As used herein, "coupled to" or "coupled with" generally refers to a connection between components, which can be an indirect communication connection or a direct communication connection (e.g., without intervening components), whether wired or wireless, including connections such as electrical connections, optical connections, magnetic connections, etc.

[0021] The host system 120 may include a processor chipset and a software stack executed by the processor chipset. The processor chipset may include one or more cores, one or more cache memories, a memory controller (e.g., an NVDIMM controller), and a storage protocol controller (e.g., a PCIe controller, a SATA controller). The host system 120 uses the memory subsystem 110, for example, to write data to the memory subsystem 110 and read data from the memory subsystem 110.

[0022] The host system 120 may be coupled to the memory subsystem 110 via a physical host interface. Examples of the physical host interface include, but are not limited to, a Serial Advanced Technology Attachment (SATA) interface, a Peripheral Component Interconnect Express (PCIe) interface, a Universal Serial Bus (USB) interface, a Fibre Channel, a Serial Attached SCSI (SAS), a Double Data Rate (DDR) memory bus, a Small Computer System Interface (SCSI), a Dual In-line Memory Module (DIMM) interface (e.g., a DIMM socket interface supporting Double Data Rate (DDR)), an Open NAND Flash Interface (ONFI), Double Data Rate (DDR), Low Power Double Data Rate (LPDDR), etc. The physical host interface may be used to transfer data between the host system 120 and the memory subsystem 110. When the memory subsystem 110 is coupled to the host system 120 through a PCIe interface, the host system 120 may further utilize an NVM Express (NVMe) interface to access components such as the memory device 130. The physical host interface may provide an interface to pass control, address, data, and other signals between the memory subsystem 110 and the host system 120. Figure 1 Memory subsystem 110 is shown as an example. In general, host system 120 can access multiple memory subsystems via the same communication connection, multiple separate communication connections, and / or a combination of communication connections.

[0023] Memory devices 130, 140 may include any combination of different types of non-volatile memory devices and / or volatile memory devices. Volatile memory devices such as memory device 140 may be, but are not limited to, random access memory (RAM), such as dynamic random access memory (DRAM) and synchronous dynamic random access memory (SDRAM).

[0024] Some examples of non-volatile memory devices (e.g., memory device 130) include "NAND" type flash memory and write-in-place memory, such as a three-dimensional cross-point ("3D cross-point") memory device, which is a cross-point array of non-volatile memory cells. The cross-point array of non-volatile memory can be combined with a stackable cross-grid data access array to perform bit storage based on changes in body resistance. In addition, in contrast to many block flash-based memories, cross-point non-volatile memories can perform write-in-place operations, where non-volatile memory cells can be programmed without pre-erasing the non-volatile memory cells. NAND-type flash memory includes, for example, two-dimensional NAND (2D NAND) and three-dimensional NAND (3D NAND).

[0025] Each of the memory devices 130 may include one or more memory cell arrays. One type of memory cell, such as a single-level cell (SLC), may store one bit per cell. Other types of memory cells, such as multi-level cells (MLC), three-level cells (TLC), and four-level cells (QLC) may store multiple bits per cell. In some embodiments, each of the memory devices 130 may include one or more memory cell arrays, such as SLC, MLC, TLC, QLC, or any combination of these. In some embodiments, a particular memory device may include an SLC portion of memory cells, as well as an MLC portion, a TLC portion, or a QLC portion. The memory cells of the memory device 130 may be grouped into pages, which may refer to a logical unit of a memory device for storing data. For some types of memory (e.g., NAND), pages may be grouped to form blocks.

[0026] Although nonvolatile memory components such as a 3D cross-point nonvolatile memory cell array and NAND-type flash memory (e.g., 2D NAND, 3D NAND) are described, the memory device 130 may be based on any other type of nonvolatile memory, such as read-only memory (ROM), phase-change memory (PCM), magnetic random access memory (MRAM), spin transfer torque (STT)-MRAM, conductive bridging RAM (CBRAM), resistive random access memory (RRAM), oxide-based RRAM (OxRAM), "NOR" (NOR) flash memory, and electrically erasable programmable read-only memory (EEPROM).

[0027] The memory subsystem controller 115 (for simplicity, controller 115) can communicate with the memory device 130 to perform operations, such as reading data, writing data, or erasing data at the memory device 130, as well as other such operations. The memory subsystem controller 115 can include hardware, such as one or more integrated circuits and / or discrete components, buffer memory, or a combination thereof. The hardware can include digital circuits with dedicated (i.e., hard-coded) logic to perform the operations described herein. The memory subsystem controller 115 can be a microcontroller, a dedicated logic circuit (e.g., a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), etc.), or other suitable processor.

[0028] The memory subsystem controller 115 may include a processor 117 (e.g., a processing device) configured to execute firmware instructions 118 stored in a local memory 119. In the example shown, the local memory 119 of the memory subsystem controller 115 includes an embedded memory configured to store instructions for executing various processes, operations, logic flows, and routines that control the operation of the memory subsystem 110, including handling communications between the memory subsystem 110 and the host system 120. In some embodiments, the firmware instructions may be stored on one or more memory devices 130, 140.

[0029] In some embodiments, local memory 119 may include memory registers that store memory pointers, fetched data, etc. Local memory 119 may also include read-only memory (ROM) for storing microcode. Figure 1 The example memory subsystem 110 in FIG. 1 has been shown as including a memory subsystem controller 115, but in another embodiment of the present disclosure, the memory subsystem 110 does not include a memory subsystem controller 115, but may rely on external control (e.g., provided by an external host or by a processor or controller separate from the memory subsystem).

[0030] In general, the memory subsystem controller 115 may receive commands or operations from the host system 120, and may convert the commands or operations into instructions or appropriate commands to achieve the desired access to the memory device 130. The memory subsystem controller 115 may be responsible for other operations, such as wear leveling operations, garbage collection operations, error detection and error correction code (ECC) operations, encryption operations, cache operations, and address translation between logical addresses (e.g., logical block addresses (LBA), name space) and physical addresses (e.g., physical block addresses) associated with the memory device 130. The memory subsystem controller 115 may also include a host interface circuit system to communicate with the host system 120 via a physical host interface. The host interface circuit system may convert commands received from the host system into command instructions to access the memory device 130, and convert responses associated with the memory device 130 into information for the host system 120.

[0031] The memory subsystem 110 may also include additional circuitry or components not shown. In some embodiments, the memory subsystem 110 may include a cache memory or buffer (e.g., DRAM) and address circuitry (e.g., row decoder and column decoder) that may receive addresses from the memory subsystem controller 115 and decode the addresses to access the memory device 130.

[0032] In some embodiments, the memory device 130 includes a local media controller 135 that operates in conjunction with the memory subsystem controller 115 to perform operations on one or more memory cells of the memory device 130. An external controller (e.g., the memory subsystem controller 115) may externally manage the memory device 130 (e.g., perform media management operations on the memory device 130). In some embodiments, the memory device 130 is a managed memory device, which is a raw memory device combined with a local controller (e.g., the local controller 135) to perform media management within the same memory device package. An example of a managed memory device is a managed NAND (MNAND) device.

[0033] As mentioned herein above, a firmware module contains a set of executable instructions that are intended to be executed by the memory subsystem controller 115 and / or one or more local media controllers 135. Firmware execution profiling and verification may involve running one or more firmware modules in an execution environment (e.g., a debugger) that is capable of generating at least one substantially time-stamped execution trace. An example execution trace may include multiple execution trace records, such that each execution trace record maps a program counter (PC) value to a timestamp corresponding to the execution of a machine instruction identified by the PC value, thereby indicating successful execution of the instruction. "Program counter" herein shall refer to a special register of a processor. During program execution, the PC stores the address of the currently executing instruction or the address of the next instruction to be executed by the processor, depending on the processor architecture and instruction set.

[0034] A firmware execution profiler operating in accordance with one or more aspects of the present disclosure receives and processes execution traces generated by a firmware execution environment (e.g., a Joint Test Action Group (JTAG) debugger or any other suitable debugger). Based on the received firmware execution traces, the firmware execution profiler can generate various execution profiles and execution profile summaries that can be used for firmware performance testing and verification.

[0035] In some embodiments, a firmware execution profiler may generate an execution profile, such as Figure 2 Shown schematically. Figure 2 Each entry of an example execution profile of may include a PC value 210; an identifier (e.g., a symbolic name) 220 of a function whose range includes the executable instructions identified by the PC value; a timestamp 230, and a counter of executable instructions within the current function call 240. A "function" herein shall refer to a set of executable instructions having at least one entry point and at least one return instruction for returning execution flow control to a caller (e.g., a calling function).

[0036] In some embodiments, the firmware execution profiler may further generate an execution profile, such as Figure 3For each executable function, Figure 3 An example execution profile of includes its identifier (e.g., symbolic name) 310, the total number of processor cycles 320 spent executing the function, the number of times the function was called 330, and the aggregate (e.g., averaged over multiple function calls) number of processor cycles spent executing the function 340.

[0037] In an illustrative example, the firmware execution profiler may map each execution trace record (which, as mentioned herein above, includes a PC value and a corresponding timestamp) to a corresponding source code line. In an illustrative example, the source code may be provided by an assembly listing, each line of which corresponds to a single executable machine instruction. The assembly listing may show the offset (relative address) of each executable machine instruction relative to the beginning of the executable module, which may be used by the firmware execution profiler to identify the assembly listing line corresponding to the particular executable instruction referenced by the execution trace.

[0038] Thus, the firmware execution profiler may utilize the PC value of the execution trace to map each executable instruction referenced by the execution trace to a corresponding source code line. In an illustrative example, the firmware execution profiler may calculate, for each execution trace record, an offset (relative address) of the corresponding executable instruction relative to the beginning of the firmware loadable module. The relative address may be calculated by subtracting the absolute address identifying the entry point at which the firmware module has been loaded for execution from the PC value supplied by the execution trace record. Since the assembly listing uses relative addresses, the calculated relative address will therefore identify the source code line corresponding to the machine instruction referenced by the execution trace record.

[0039] The firmware execution profiler may further utilize the calculated relative address to identify a function whose range includes the machine instruction referenced by the execution trace record. In an illustrative example, the firmware execution profiler may traverse a list of functions sorted according to their respective relative start addresses until a function whose address range (i.e., a relative address range from the start address of the function until the end address of the function) includes the calculated relative address is identified.

[0040] Once a function is identified, the firmware execution profiler may accordingly increment a counter of the number of calls to the function (if the instruction referenced by the current execution trace record is the entry point to the function) or increment the number of processing cycles spent executing the current function call. In some embodiments, the firmware execution profiler may render the generated execution profile via a graphical user interface (GUI).

[0041] The execution profile may then be compared to the intended execution flow, for example, by comparing a target number of calls and / or execution cycle counts for each function with a corresponding actual number of calls and / or actual execution cycle counts. In some embodiments, the firmware execution profiler may identify functions for which actual performance parameters (e.g., actual number of function calls and / or actual execution cycle counts) differ from the target parameters by more than certain thresholds. In some embodiments, the firmware execution profiler may generate and render one or more GUI screens that highlight functions and / or individual commands for which performance issues (e.g., deviations of actual performance parameters from corresponding target performance parameters) have been identified.

[0042] Figure 4 FIG. 4 is an example UML diagram 400 illustrating a firmware execution flow enhanced by execution profile data generated by a firmware execution profile analyzer operating in accordance with an embodiment of the present disclosure. Figure 4 Schematically shown, the firmware execution flow shows a sequence of function calls 410A through 410N, and the number of cycles taken to execute each function.

[0043] Figure 5 5 is a flow chart of an example method 500 for generating a firmware execution profile according to an embodiment of the present disclosure. The method 500 may be performed by processing logic, which may include hardware (e.g., a processing device, a circuit system, a dedicated logic, a programmable logic, a microcode, hardware of a device, an integrated circuit, etc.), software (e.g., instructions running or executed on a processing device), or a combination thereof. In some embodiments, the method 500 is performed by a computer system (e.g., Figure 6 The computer system 600 of the embodiment of the present invention is executed. Although shown in a specific sequence or order, unless otherwise specified, the order of operations can be modified. Therefore, it should be understood that the embodiments shown are only examples, and the operations shown can be performed in different orders, and some operations can be performed in parallel. In addition, in some embodiments, one or more operations can be omitted. Therefore, not all the operations shown are required in every embodiment, and other process flows are possible.

[0044] At operation 510, a processing device implementing the method receives an execution trace of a firmware module. The execution trace may include execution trace records ordered based on the execution flow of corresponding executable instructions. Each execution trace record maps a program counter (PC) value to a timestamp corresponding to the execution of the instruction identified by the PC, as described in more detail above herein.

[0045] At operation 520, the processing device implementing the method initializes an execution trace pointer TracePtr, a call counter array CallCount[], a cycle counter array CycleCount[], and a function identifier variable CurFunctionID. The execution trace pointer TracePtr is used to store the index of the execution trace record currently being processed. The call counter array CallCount[] is used to store the number of calls to the function identified by the array index. The cycle count array CycleCount[] is used to store the number of cycles spent executing the function identified by the array index. The CurFunctionID variable is used to store the identifier of the function currently being processed (i.e., the function whose scope includes the executable instructions referenced by the current execution trace record).

[0046] At operation 530 , the processing device retrieves the next execution trace record of the execution trace of the firmware module (ie, the record identified by the execution trace pointer).

[0047] At operation 540, the processing device identifies the executable instructions and source code lines corresponding to the PC values ​​specified by the execution trace record. In the illustrative example, the processing device calculates the difference between the PC values ​​specified by the execution trace record and the PC values ​​corresponding to the entry point of the firmware module currently being profiled (e.g., the first trace record), and then identifies the source code lines whose offsets relative to the entry point of the firmware module match the calculated relative addresses, as described in more detail herein above.

[0048] At operation 550, the processing device identifies the function containing the identified executable instruction. In the illustrative example, the process traverses the list of functions sorted according to their respective relative start addresses until a function is identified whose address range (i.e., the relative address range from the start address of the function to the end address of the function) includes the calculated relative address.

[0049] In response to determining at operation 560 that the identifier of the function matches the stored function identifier CurFunctionID (ie, the current executable instruction and the immediately preceding executable instruction belong to the same function), processing continues at operation 580 ; otherwise, the method branches to operation 570 .

[0050] At operation 570 , which is performed in response to determining at operation 560 that the current executable instruction and the immediately preceding executable instruction belong to the same function, the processing device increments the cycle count of the function currently being processed by the number of cycles taken to execute the current executable instruction. Processing continues at operation 590 .

[0051] At operation 580 (which is performed in response to determining at operation 560 that a new function is now being processed), the processing device updates the function identifier variable CurFunctionID with the identifier (e.g., a symbolic name) of the function identified at operation 550; increments the call count of the function identified at operation 550; and resets the loop count of the function identified at operation 550.

[0052] At operation 590 , the processing device increments the execution track pointer track Ptr.

[0053] In response to determining at operation 595 that the execution trace contains more trace records, the method loops back to operation 530 ; otherwise, processing continues at block 598 .

[0054] At block 598, the processing device generates an execution profile for the firmware module. The execution profile generated in an illustrative example may include a separate text line corresponding to each executable instruction. The line may include a PC value, an identifier (e.g., a symbolic name) of a function whose range includes the executable instruction identified by the PC value, a timestamp, and a counter of cycles within the current function call. In another illustrative example, for each executable function, the generated execution profile may include its identifier (e.g., a symbolic name), the total number of processor cycles spent executing the function, the number of times the function was called, and the aggregate (e.g., averaged over multiple function calls) number of processor cycles spent executing the function, as described in more detail herein above. The generated execution profile may be stored in a file, displayed via a graphical user interface (GUI), and / or transmitted to a remote computer system via a network.

[0055] Figure 6 An example machine of a computer system 600 is shown within which a set of instructions for causing the machine to perform any one or more of the methodologies discussed herein may be executed. In some embodiments, the computer system 600 may be connected (e.g., networked) to other machines in a LAN, an intranet, an extranet, and / or the Internet. The machine may operate in the capacity of a server or a client machine in a client-server network environment as a peer machine in a peer-to-peer (or distributed) network environment or as a server or a client machine in a cloud computing infrastructure or environment.

[0056] The machine may be a personal computer (PC), a tablet PC, a set-top box (STB), a personal digital assistant (PDA), a cellular phone, a network appliance, a server, a network router, a switch or a bridge, a digital or non-digital circuit system, or any machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be performed by the machine. In addition, while a single machine is described, the term "machine" should also be construed to include any collection of machines that individually or collectively execute one (or more) sets of instructions to perform any one or more of the methodologies discussed herein.

[0057] The example computer system 600 includes a processing device 602, a main memory 604 (e.g., read-only memory (ROM), flash memory, dynamic random access memory (DRAM), such as synchronous DRAM (SDRAM) or Rambus DRAM (RDRAM)), etc.), a static memory 606 (e.g., flash memory, static random access memory (SRAM), etc.), and a data storage system 618, which communicate with each other via a bus 630.

[0058] The processing device 602 represents one or more general-purpose processing devices, such as a microprocessor, a central processing unit, or the like. More specifically, the processing device may be a complex instruction set computing (CISC) microprocessor, a reduced instruction set computing (RISC) microprocessor, a very long instruction word (VLIW) microprocessor, or a processor that implements other instruction sets, or a processor that implements a combination of instruction sets. The processing device 602 may also be one or more special-purpose processing devices, such as an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA), a digital signal processor (DSP), a network processor, etc. The processing device 602 is configured to execute instructions 626 for implementing the operations and steps discussed herein. The computer system 600 may further include a network interface device 608 to communicate via a network 620.

[0059] The data storage system 618 may include a machine-readable storage medium 624 (also referred to as a computer-readable medium) on which is stored one or more sets of instructions 626 or software embodying any one or more of the methodologies or functions described herein. The instructions 626 may also reside, completely or at least partially, within the main memory 604 and / or within the processing device 602 during execution thereof by the computer system 600, the main memory 604 and the processing device 602 also constituting machine-readable storage media. The machine-readable storage medium 624, the data storage system 618, and / or the main memory 604 may correspond to Figure 1 Memory subsystem 110.

[0060] In one embodiment, instructions 626 include instructions implementing the functionality of the firmware execution profiler described herein, including the example method 500 of generating a firmware execution profile. Although the machine-readable storage medium 624 is shown as a single medium in the example embodiment, the term "machine-readable storage medium" should be considered to include a single medium or multiple media storing one or more sets of instructions. The term "machine-readable storage medium" should also be considered to include any medium capable of storing or encoding a set of instructions for execution by a machine and causing the machine to perform any one or more of the methods of the present disclosure. Therefore, the term "machine-readable storage medium" should be considered to include, but not limited to, solid-state memory, optical media, and magnetic media.

[0061] Some portions of the previous detailed description have been presented with respect to algorithms and symbolic representations of operations on data bits within a computer memory. These algorithmic descriptions and representations are the means by which those skilled in the art of data processing can most effectively communicate the substance of their work to other persons skilled in the art. An algorithm is here and generally considered to be a self-consistent sequence of operations that produces a desired result. An operation is an operation that requires physical control of a physical quantity. These quantities are usually, but not necessarily, in the form of electrical or magnetic signals that can be stored, combined, compared, and otherwise manipulated. Sometimes, primarily for general reasons, it has proven convenient to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like.

[0062] It should be borne in mind, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. The present disclosure may refer to the actions and processes of a computer system or similar electronic computing device that manipulates and transforms data represented as physical (electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system's memories or registers or other such information storage systems.

[0063] The present disclosure also relates to an apparatus for performing the operations described herein. This apparatus may be specially constructed for the intended purpose, or it may comprise a general purpose computer selectively activated or reconfigured by a computer program stored in the computer. Such a computer program may be stored in a computer-readable storage medium, such as, but not limited to, any type of disk (including floppy disks, optical disks, CD-ROMs, and magnetic optical disks), a read-only memory (ROM), a random access memory (RAM), an EPROM, an EEPROM, a magnetic card or an optical card, or any type of medium suitable for storing electronic instructions, each coupled to a computer system bus.

[0064] The algorithms and displays presented herein are not inherently related to any particular computer or other device. Various general purpose systems may be used with programs according to the teachings herein, or it may prove convenient to construct more specialized devices to perform the methods. The structures of a variety of these systems will be presented as set forth in the description below. In addition, the present disclosure is not described with reference to any particular programming language. It will be appreciated that a variety of programming languages ​​may be used to implement the teachings of the present disclosure as described herein.

[0065] The present disclosure may be provided as a computer program product or software, which may include a machine-readable medium having stored thereon instructions that can be used to program a computer system (or other electronic device) to perform a process according to the present disclosure. A machine-readable medium includes any mechanism for storing information in a form readable by a machine (e.g., a computer). In some embodiments, a machine-readable (e.g., computer-readable) medium includes a machine (e.g., computer) readable storage medium, such as a read-only memory ("ROM"), a random access memory ("RAM"), a magnetic disk storage medium, an optical storage medium, a flash memory component, etc.

[0066] In the foregoing description, embodiments of the present disclosure have been described with reference to specific example embodiments thereof. It should be apparent that various modifications may be made to the present disclosure without departing from the broader spirit and scope of embodiments of the present disclosure as set forth in the appended claims. Accordingly, the description and drawings should be viewed in an illustrative rather than a restrictive sense.

Claims

1. A computer-operated method comprising: Receiving, by a processing device, an execution trace of a firmware module including a plurality of executable instructions, wherein the execution trace includes a plurality of execution trace records, wherein each execution trace record of the plurality of execution trace records indicates successful execution of an executable instruction identified by a program counter PC value; Retrieving a first execution trace record from among the plurality of execution trace records, wherein the first execution trace record includes a first PC value; identifying a first executable instruction referenced by the first PC value; identifying a firmware function containing the first executable instruction; incrementing a loop count of the firmware function by a loop number associated with the first executable instruction; as well as Using the cycle count, an execution profile of the firmware module is generated. 2 . The method of claim 1 , wherein each of the plurality of execution trace records further comprises a timestamp. The method according to claim 1 , wherein the plurality of execution trace records are sorted based on execution flows of the plurality of executable instructions. The method according to claim 1 , wherein the execution trace is generated by an execution environment running the firmware module.

5. The method according to claim 1, further comprising: In response to determining that the identifier of the firmware function does not match the stored function identifier, a call count associated with the firmware function is incremented.

6. The method of claim 1, wherein generating the execution profile further comprises: Text is generated that includes source code lines associated with the first executable instruction, the first PC value, and the loop count.

7. The method according to claim 1, further comprising: The execution profile is caused to be rendered by a graphical user interface (GUI).

8. The method of claim 1 , wherein identifying the first executable instruction referenced by the first PC value further comprises: calculating a relative address by subtracting a second PC value corresponding to an entry point of the firmware module from the first PC value; as well as The source code line identified by the relative address is identified.

9. The method of claim 8, wherein identifying the firmware function further comprises: The list of functions sorted by relative start address is traversed until a function is identified that has an address range that includes the relative address.

10. A computer system comprising: Memory; as well as A processing device coupled to the memory, the processing device being configured to perform operations comprising: receiving an execution trace of a firmware module including a plurality of executable instructions, wherein the execution trace includes a plurality of execution trace records, wherein each execution trace record of the plurality of execution trace records indicates successful execution of an executable instruction identified by a program counter PC value; Retrieving a first execution trace record from among the plurality of execution trace records, wherein the first execution trace record includes a first PC value; identifying a firmware function containing a first executable instruction referenced by the first PC value; incrementing a loop count of the firmware function by a loop number associated with the first executable instruction; and An execution profile of the firmware module is generated that includes source code lines associated with the first executable instruction, the first PC value, and the loop count. 11 . The computer system of claim 10 , wherein the plurality of execution trace records are sorted based on execution flows of the plurality of executable instructions.

12. The computer system of claim 10, wherein the instructions further comprise: In response to determining that the identifier of the firmware function does not match the stored function identifier, a call count associated with the firmware function is incremented.

13. The computer system of claim 10, wherein the instructions further comprise: The execution profile is caused to be rendered by a graphical user interface (GUI).

14. The computer system of claim 10, wherein identifying the first executable instruction to which the first PC value refers further comprises: calculating a relative address by subtracting a second PC value corresponding to an entry point of the firmware module from the first PC value; as well as The source code line identified by the relative address is identified.

15. The computer system of claim 14, wherein identifying the firmware function further comprises: The list of functions sorted by relative start address is traversed until a function is identified that has an address range that includes the relative address.

16. A non-transitory computer-readable storage medium comprising executable instructions that, when executed by a processing device, cause the processing device to perform operations comprising: receiving an execution trace of a firmware module including a plurality of executable instructions, wherein the execution trace includes a plurality of execution trace records, wherein each execution trace record of the plurality of execution trace records indicates successful execution of an executable instruction identified by a program counter PC value; Retrieving a first execution trace record from among the plurality of execution trace records, wherein the first execution trace record includes a first PC value; identifying a first executable instruction referenced by the first PC value; identifying a firmware function containing the first executable instruction; incrementing a loop count of the firmware function by a loop number associated with the first executable instruction; as well as Using the cycle count, an execution profile of the firmware module is generated. 17 . The non-transitory computer-readable storage medium of claim 16 , wherein the plurality of execution trace records are sorted based on an execution flow of the plurality of executable instructions.

18. The non-transitory computer-readable storage medium of claim 16, wherein the operations further comprise: In response to determining that the identifier of the firmware function does not match the stored function identifier, a call count associated with the firmware function is incremented.

19. The non-transitory computer-readable storage medium of claim 16, wherein identifying the first executable instruction to which the first PC value refers further comprises: calculating a relative address by subtracting a second PC value corresponding to an entry point of the firmware module from the first PC value; as well as The source code line identified by the relative address is identified.

20. The non-transitory computer-readable storage medium of claim 19, wherein identifying the firmware function further comprises: The list of functions sorted by relative start address is traversed until a function is identified that has an address range that includes the relative address.

Images