System and method for automatically mapping source code to machine code

Abstract

Systems and methods for mapping a location in source code to a location in machine code are disclosed. An identifier of source code and an identifier of a first location of the source code are received. Based on the identifier of the first location, a marker is inserted in association with the source code. The source code is compiled into machine code. A second location associated with the marker is identified in the machine code. A third location is returned based on identifying the second location.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to and the benefit of U.S. Provisional Application No. 63 / 285,749, filed on December 3, 2021, entitled “Mechanism for Automatically Mapping Native Program Code C / C++ / PYTHON to EBPF Bytecode to Enable Setting Breakpoints for Debugging,” the entire contents of which are incorporated herein by reference. Technical Field

[0003] One or more aspects according to embodiments of the present disclosure relate to a debugging tool, and more particularly, to a tool for debugging bytecode instructions by setting breakpoints in corresponding source code. Background Art

[0004] Debugging is one of the many important functions of a processing unit (including a computational memory unit). Difficulties may arise when debugging machine code instructions because machine code can be more complex than source code. Furthermore, performing debugging of machine code instructions may require knowledge of the machine code, including its semantics.

[0005] The above information disclosed in this Background section is only for enhancement of understanding of the background of the disclosure and therefore it may contain information that does not constitute the prior art. Summary of the Invention

[0006] Embodiments of the present disclosure are directed to a method for mapping locations in source code to locations in machine code. According to the method, an identifier of source code and an identifier of a first location in the source code are received. Based on the identifier of the first location, a marker is inserted in association with the source code. The source code is compiled into machine code. A second location associated with the marker is identified in the machine code. Based on the identification of the second location, a third location is returned.

[0007] According to one embodiment, the identifier of the source code is the name of the source code, and the identifier of the first position of the source code is the line number of the source code.

[0008] According to one embodiment, the marker is a preset function call. The preset function call may be an exit function call.

[0009] According to one embodiment, compilation of the source code is stopped in response to the exit function call.

[0010] According to one embodiment, the machine code is extended Berkeley Packet Filter (eBPF) bytecode.

[0011] According to one embodiment, the second location is a line number of the machine code associated with the tag.

[0012] According to one embodiment, the third position is a line number above the line number of the machine code associated with the tag.

[0013] According to one embodiment, the source code is copied into a temporary source code file, wherein the markup is inserted into the temporary source code file, and compilation is performed on the temporary source code file.

[0014] Embodiments of the present disclosure are also directed to a system for mapping source code locations to machine code locations. The system includes a processor and a memory. The memory stores instructions that, when executed by the processor, cause the processor to: receive an identifier for source code and an identifier for a first location in the source code; insert a marker associated with the source code based on the identifier for the first location; compile the source code into machine code; identify a second location in the machine code associated with the marker; and return a third location based on identifying the second location.

[0015] As will be appreciated by those skilled in the art, embodiments of the present disclosure provide a mechanism for debugging machine code instructions by mapping the locations of the source code where one may want to insert breakpoints to the locations of the machine code. In this way, programmers can interact with the source code during debugging exercises using breakpoints, rather than attempting to debug the machine code directly.

[0016] These and other features, aspects and advantages of the embodiments of the present disclosure will be more fully understood when considered with reference to the following detailed description, appended claims and accompanying drawings.Of course, the actual scope of the invention is defined by the appended claims. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] Non-limiting and non-exhaustive embodiments of the present invention are described with reference to the following figures, wherein like reference numerals refer to like parts throughout the various figures unless otherwise specified.

[0018] Figure 1 is a block diagram of a system for automatically mapping source code to machine code according to one embodiment;

[0019] Figure 2 is a flowchart of a process for mapping locations in source code to locations in machine code according to one embodiment;

[0020] Figure 3 is a screenshot of exemplary temporary source code including markup according to one embodiment; and

[0021] Figure 4 is a flow diagram of a process executed by a debugger to debug machine code using breakpoints, according to one embodiment. DETAILED DESCRIPTION

[0022] Hereinafter, example embodiments will be described in more detail with reference to the accompanying drawings, in which the same reference numerals always refer to the same elements. However, the present disclosure can be implemented in a variety of different forms and should not be construed as being limited to the embodiments shown here. On the contrary, these embodiments are provided as examples so that the present disclosure will be thorough and complete and will fully convey the aspects and features of the present disclosure to those skilled in the art. Therefore, for those of ordinary skill in the art, processes, elements and techniques that are not necessary for a complete understanding of the aspects and features of the present disclosure may not be described. Unless otherwise stated, the same reference numerals represent the same elements in all drawings and written descriptions, and therefore, their descriptions will not be repeated. In addition, in the drawings, the relative sizes of elements, layers and regions may be exaggerated and / or simplified for clarity.

[0023] Inserting breakpoints in a computer program can be a useful debugging technique used by programmers. For example, a breakpoint can be inserted at a specific line in a program to pause the program's execution. During this pause, the programmer can examine the state of registers, memory, logs, files, and / or gain other knowledge about the program as it runs.

[0024] When the program being loaded and run is machine code instructions, such as extended Berkeley Packet Filter (eBPF) bytecode instructions, debugging the machine code can be difficult. For example, if attempting to debug using breakpoints, the programmer may need to understand the low-level machine code instructions, including their semantics, to know where to insert the breakpoints.

[0025] In general, embodiments of the present disclosure are directed to automatically mapping lines in high-level source code to locations in corresponding machine code. If the machine code is generated based on the source code (e.g., by a compiler that compiles the source code), the machine code may correspond to the source code. The mapping may be performed by a mapping tool that may be installed, for example, on a host device. The mapping tool may take as input the name of the source code program and the line number in the source code program (e.g., where a breakpoint is inserted).

[0026] In one embodiment, the tool makes a temporary copy of the source code program and inserts a preset high-level command, label, or marker (collectively, a marker) into the temporary copy at a position corresponding to the line number. The marker can be, for example, an exit function call that stops the execution of the temporary source code program and the generation of associated machine code when the source code is compiled. The marker can also be a label, a marker, or any other command or function that generates distinguishable code or effects in the machine code instructions.

[0027] In one embodiment, the mapping tool compiles the temporary source code program and generates low-level machine code (also referred to as bytecode) based on the temporary source code program. The bytecode can be stored in a temporary bytecode file. The mapping tool can search for the bytecode corresponding to the mark in the temporary bytecode file. In this regard, when the mark is an exit function call that suspends bytecode generation, the tool can identify the bytecode at the end of the temporary bytecode file as corresponding to the exit function call. In one embodiment, the tool returns the line number in the temporary bytecode file based on the bytecode of the positioning mark. For example, the line number returned may be the line number above the line where the bytecode of the mark is positioned. The programmer can use the returned line number to debug the original bytecode file. For example, the programmer can use the returned line number to insert a breakpoint at the line number.

[0028] Figure 1 is a block diagram of a system for automatically mapping source code to machine code according to one embodiment. The system may include a host computing device 100 coupled to a computing storage device 102 via a wired or wireless storage interface 104, the wired or wireless storage interface 104 including Ethernet, Fibre Channel, and / or other storage interfaces. The computing storage device 102 may be a state-driven storage device (SSD) having an embedded processor (such as a field programmable gate array (FPGA), an SSD controller, and / or a discrete coprocessor). In one embodiment, the storage interface 104 is a compute express link (CXL). In one embodiment, the host device 100 may transmit data to and receive data from the storage device 102 via the storage interface 104 using a storage interface protocol. The storage interface protocol may be, for example, a non-volatile memory express (NVMe) protocol or any other similar protocol.

[0029] In one embodiment, host 100 includes a processor 105 coupled to a memory 108. Processor 105 can be configured to run one or more software applications stored in host memory 108. One such application can be a mapping tool 106 for mapping locations (e.g., line numbers) in source code 112 to locations (e.g., line numbers) of corresponding machine code 110. Source code 112 can be generated by a programmer using a human-readable programming language such as C, C++, Python, etc. Machine code 110 can be, for example, eBPF bytecode, although embodiments are not limited thereto.

[0030] Mapping tool 106 can be used, for example, to debug machine code 110. For example, mapping tool 106 can receive as input the line number of source code 112 where a breakpoint is to be inserted, and the tool can return the corresponding line number of machine code 110 for inserting the breakpoint. By using high-level source code for debugging and inserting breakpoints, more natural and efficient debugging of machine code can be achieved.

[0031] In one embodiment, host 100 includes a device driver 111 configured to interface with storage device 102. In one embodiment, device driver 111 is implemented as software instructions stored in host memory 108 and executed by processor 105.

[0032] In one embodiment, the storage device 102 includes a host interface layer (HIL) 114 for interfacing between a device driver 111 of the host 100 and a device control subsystem 116. The device control subsystem 116 may include, but is not limited to, one or more processors 118 and one or more media interfaces 120. The one or more processors 118 may be configured to execute computer-readable instructions, including, for example, a debugger 122 for debugging the machine code 110. The machine code 110 may be loaded into the storage device 102. In one embodiment, the debugger 122 is configured to receive a location (e.g., a line number) of the machine code 110 provided by the mapping tool 106, and to insert a breakpoint based on the identified location (e.g., a line below the identified location). When the debugger 122 executes the machine code 110, the machine code may pause when a breakpoint is reached, and the register values ​​before the breakpoint may be output.

[0033] In one embodiment, one or more processors 118 may interact with NVM media 124 via media interface 120 to implement write or read operations. NVM media 124 may include one or more types of non-volatile memory, such as, for example, flash memory. In one embodiment, machine code 110 may be loaded onto NVM media 124 and retrieved by processor 118 via media interface 120 for execution. In some embodiments, storage device 102 may retrieve machine code 110 from an external source (e.g., a host or another device). The machine code may be stored in memory 126 or NVM media 124 for later retrieval.

[0034] In one embodiment, storage device 102 further includes internal memory 126 for short-term or temporary storage during operation of storage device 102. Internal memory 126 may include DRAM (dynamic random access memory), SRAM (static random access memory), and / or DTCM (data tightly coupled memory). For example, machine code 110 may be loaded from NVM media 124 into internal memory 126 for execution.

[0035] In some embodiments, the storage device 102 is within a chassis (not shown) that includes an Ethernet switch, a baseboard management controller (BMC), and a PCIe switch. The Ethernet switch can provide an Ethernet connection to the storage device 102 (e.g., a smart SSD) via a midplane, and the PCIe switch can provide a management interface to the storage device via a midplane. The BMC can program the storage device 102 according to instructions given by the system administrator. The BMC can manage the internal components of the chassis, including the Ethernet switch, the PCIe switch, and the storage device 102. The BMC can support PCIe and / or system management bus (SMBus) interfaces for system management. The BMC can configure the storage device 102 and program the Ethernet switch. In some embodiments, the Ethernet switch provides a network connection between the host 100 and the storage device 102 via a storage interface 104.

[0036] Figure 2 1 is a flow chart of a process for mapping a location in source code 112 to a location in machine code 110 according to one embodiment. The process begins, and at act 200, mapping tool 106 receives as input an identifier (e.g., a name) of source code 112 and a first location of the source code to be mapped to a machine code location. The input location can be a line number, although embodiments of the present disclosure are not limited thereto. In this regard, mapping tool 106 provides a graphical user interface (GUI) for receiving input, although embodiments are not limited thereto. For example, the input can also be received as command line parameters, etc.

[0037] In action 202, the source code is copied into a temporary source code file, although the embodiment is not limited thereto. For example, in one embodiment, the original source code is edited and the edits are undone after the mapping is performed.

[0038] In action 204, based on the line number of the input, a marker is inserted into the temporary source code (or the original source code, depending on the embodiment). In one embodiment, the marker is an exit function call that pauses the program execution. In some embodiments, the marker can be a unique label, mark, etc. provided by the source programming language. In embodiments where the marker is not an exit function call, multiple markers can be inserted to identify multiple locations that may want to be debugged. The markers may also be different based on the language in which the original source code was written. For example, a C code exit marker is syntactically different from a Python or Java exit marker. In one embodiment, the tool receives the marker to be used as input.

[0039] In action 206, the mapping tool 106 compiles the temporary source code and generates temporary machine code in response. In embodiments where the temporary source code includes an exit function call, compilation stops when the exit function call is reached, and no machine code is generated for any source code after the exit function call. In embodiments where a unique label or token is used as a marker, the entire temporary source code is compiled.

[0040] At act 208, the mapping tool 106 identifies a location in the temporary machine code associated with the marker (e.g., a location in the temporary machine code of a sequence of machine code instructions corresponding to an exit function call). In embodiments where an exit function call is used as a marker, compilation stops when the exit function call is reached. Thus, the last instruction(s) of the temporary machine code are the instruction(s) associated with the exit function call. In embodiments where a unique tag or token is used as a marker, the location of the marker in the temporary machine code can be identified by comparing the temporary machine code with machine code generated by compiling the original source code to obtain differences.

[0041] At block 210, the mapping tool 106 returns a mapped location based on the marked location. In one embodiment, the returned mapped location is a line number above the marked line number in the temporary machine code. The mapped location can be returned to, for example, a debugger 122 in the storage device 102 for inserting a breakpoint for debugging the machine code 110.

[0042] In act 212 , the mapping tool 106 deletes the temporary source code and machine code files because they are no longer needed.

[0043] Figure 3 is a screenshot of exemplary temporary source code 300 including markup 302 according to one embodiment. Figure 3 In the example of , the marker is an exit function call. In response to receiving the input line number "14", the mapping tool 106 may insert the marker at line 14 of the temporary source code 300

[0044] Machine code 304 (which may be similar to machine code 110) may be generated in response to compiling temporary source code 300. Figure 3 In the example shown in FIG, machine code instructions (lines 9-11) 306 are generated for function 308 in the temporary source code; machine code instructions (lines 12-14) 310 are generated for function 312 in the temporary source code; and machine code instructions (lines 15-17) 314 are generated for function 316 in the temporary source code. For the marker 302 inserted at line 14, the last two lines of machine code (lines 18-19) 318 correspond to the marker. In one embodiment, the mapping function returns line 17 (the line above the marker line 18) as the output line number mapped to input line number 14.

[0045] Figure 4 FIG1 is a flow diagram of a process executed by debugger 122 to debug machine code 110 using breakpoints, according to one embodiment. Debugger 122 may be invoked, for example, by mapping tool 106 in response to mapping input line numbers of source code 112 to corresponding line numbers in machine code 110. In this manner, a programmer may participate in the debugging process by interacting with high-level source code 112, rather than attempting to debug machine code 110 directly.

[0046] The process begins, and at block 400, the debugger 122 receives a machine code line number that maps to an input source code line number. Figure 3 In the example of , in response to receiving an input line number 14 of the source code, a machine code line number 17 is returned.

[0047] At block 402, the debugger 122 inserts a breakpoint (also called a trap) below the identified line number of the machine code. Figure 3 In the example, a breakpoint is inserted at machine code line number 18.

[0048] At block 404 , debugger 122 runs machine code 110 with the breakpoints inserted.

[0049] At block 406, the machine code hits a trap, and at block 408, the debugger 122 outputs the register values ​​at the line before the trap (e.g., the machine code instruction). For example, if the trap is inserted at line 18 of the machine code, the debugger 122 outputs the register values ​​at line 17. Figure 3 In the example, the register values ​​at line 17 are as follows:

[0050] 85 00 00 00 06 00 00 00call 6

[0051] In one embodiment, the register values ​​are provided to mapping tool 106 for display on a display device. By examining the output register values, a programmer can attempt to identify errors in machine code 110.

[0052] Depending on the number and type of traps / breakpoints inserted in the source code, the process may or may not terminate after outputting the register values ​​at block 408. In one embodiment, multiple traps / breakpoints are inserted into the source code. In such an embodiment, after hitting a first breakpoint and outputting the associated register values ​​at block 408, the process returns to block 404 (e.g., in response to a user command) to continue running the program until a second breakpoint is hit and its register values ​​are output. The process continues until there are no more breakpoints to be executed.

[0053] It should be understood that Figure 2 and Figure 4 The order of the steps of the processes in are not fixed, but may be modified, reordered, performed differently, performed sequentially, concurrently or simultaneously, or changed into any desired order, as recognized by those skilled in the art.

[0054] The term processor used herein may refer to one or more processors and / or one or more processing cores. One or more processors may be hosted in a single device or distributed across multiple devices (e.g., on a cloud system). Processors may include, for example, application-specific integrated circuits (ASICs), general-purpose or dedicated central processing units (CPUs), digital signal processors (DSPs), graphics processing units (GPUs), and programmable logic devices such as field programmable gate arrays (FPGAs). As used herein, in a processor, each function is performed either by hardware configured to (i.e., hardwired) perform the function, or by more general hardware (e.g., a CPU) configured to run instructions stored in a non-temporary storage medium (e.g., a memory). The processor may be manufactured on a single printed circuit board (PCB) or distributed across several interconnected PCBs. The processor may contain other processing circuits; for example, a processing circuit may include two processing circuits, an FPGA, and a CPU, interconnected on a PCB.

[0055] It should be understood that although the terms "first," "second," "third," etc. may be used herein to describe various elements, components, regions, layers, and / or portions, these elements, components, regions, layers, and / or portions should not be limited by these terms. These terms are only used to distinguish one element, component, region, layer, or portion from another element, component, region, layer, or portion. Thus, a first element, component, region, layer, or portion discussed herein may be referred to as a second element, component, region, layer, or portion without departing from the spirit and scope of the present inventive concept.

[0056] The terms used herein are merely for describing specific embodiments and are not intended to limit the concepts of the present invention. In addition, unless explicitly stated otherwise, the embodiments described herein are not mutually exclusive. The various aspects of the embodiments described herein may be combined in some implementations.

[0057] As used herein, the terms "substantially," "approximately," and similar terms are used as terms of approximation, rather than terms of degree, and are intended to account for the inherent variations in measurements or calculations that those skilled in the art would recognize.

[0058] As used herein, the singular forms "one" and "an" are also intended to include plural forms, unless the context clearly indicates otherwise. It will also be understood that the terms "including" and / or "comprising" when used in this specification specify the presence of stated features, integers, steps, operations, elements and / or components, but do not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components and / or their combinations. As used herein, the term "and / or" includes any and all combinations of one or more related listed items. When following a list of elements, expressions such as "at least one of" modify the entire list of elements without modifying the individual elements of the list. In addition, when describing an embodiment of the present invention's concept, "may" is used to refer to "one or more embodiments of the present disclosure." In addition, the term "exemplary" is intended to refer to an example or illustration. As used herein, the terms "using," "being in use," and "being used" can be considered to be synonymous with the terms "utilizing," "being utilized," and "being utilized," respectively.

[0059] Although exemplary embodiments of a system and method for automatically mapping source code to machine code have been specifically described and illustrated herein, numerous modifications and variations will be apparent to those skilled in the art. Therefore, it should be understood that a system and method for automatically mapping source code to machine code constructed in accordance with the principles of the present disclosure may be implemented in ways other than as specifically described herein. The present disclosure is further defined in the appended claims and their equivalents.

Claims

1. A method for mapping a location in source code to a location in machine code, the method comprising: compiling the first source code to generate a first machine code; receiving a first location of a first source code; inserting a marker into a first position of the first source code and generating a second source code; compiling the second source code to generate a second machine code; identifying a second location in the second machine code associated with the tag; and A breakpoint, different from the marker, is inserted into a third location of the first machine code based on the second location identified in the second machine code.

2. The method according to claim 1, further comprising: An identification of source code and an identifier of a first location of the source code are received, wherein the identification of the source code includes a name of the source code and the identifier of the first location of the source code includes a line number of the source code. The method according to claim 1 , wherein the marker is a preset function call. The method according to claim 3 , wherein the preset function call is an exit function call. The method of claim 4 , wherein compilation of the source code stops in response to exiting the function call.

6. The method of claim 1, wherein the machine code is Extended Berkeley Packet Filter (eBPF) bytecode. The method of claim 1 , wherein the second location is a line number of the machine code associated with the tag.

8. The method according to claim 1, further comprising: Run the first machine code; identifying a breakpoint based on the execution of the first machine code; as well as The recognition based on the breakpoint outputs a state associated with the execution of the machine code.

9. The method of claim 1, wherein the source code is copied into a temporary source code file, wherein the marker is inserted into the temporary source code file, and wherein the compiling is performed on the temporary source code file.

10. A system for mapping the location of source code to the location of machine code, the system comprising: processor; and a memory, wherein the memory stores instructions that, when executed by the processor, cause the processor to: compiling the first source code to generate a first machine code; receiving a first location of a first source code; inserting a marker into a first position of the first source code and generating a second source code; compiling the second source code to generate a second machine code; identifying a second location in the second machine code associated with the tag; and A breakpoint, different from the marker, is inserted into a third location of the first machine code based on the second location identified in the second machine code.

11. The system according to claim 10, wherein: The instructions further cause the processor to: An identification of source code and an identifier of a first location of the source code are received, wherein the identification of the source code includes a name of the source code and the identifier of the first location of the source code includes a line number of the source code. The system of claim 10 , wherein the marker is a preset function call. The system according to claim 12 , wherein the preset function call is an exit function call.

14. The system of claim 13, wherein the instructions that cause the processor to compile the source code further cause the processor to stop compiling the source code in response to an exit function call.

15. The system of claim 10, wherein the machine code is Extended Berkeley Packet Filter (eBPF) bytecode.

16. The system of claim 10, wherein the second location is a line number of the machine code associated with the tag.

17. The system according to claim 10, wherein: The instructions further cause the processor to: Run the first machine code; identifying a breakpoint based on the execution of the first machine code; and The recognition based on the breakpoint outputs a state associated with the execution of the machine code.

18. The system of claim 10, wherein the instructions further cause the processor to: The source code is copied into a temporary source code file, wherein the instructions causing the processor to insert the markup include instructions causing the processor to insert the markup into the temporary source code file, and the instructions causing the processor to compile include instructions causing the processor to compile the temporary source code file.

Images