Execution control with cross-level trace mapping

Abstract

The described technology facilitates execution control during the replay of the program behavior being tracked. Cross-level mapping associates the source code, intermediate representation, and native instructions in the trace. The trace includes a record of the native code instructions executed by the program managed by the runtime. The trace does not include any execution instance at the runtime. Breakpoints are set to align the trace location with the source code expression or statement, and skip garbage collection and other code that is unlikely to be of interest to the developer. The real-time debugging environment is adapted to support reverse execution based on the trace. The execution controller in the debugger or other tools can control the replay execution of the trace using breakpoint ranges, cross-level mapping, backward stepping exit support, and other items. Aspects of familiar compilers or familiar runtimes can be reused for innovative execution control that replays previously generated native code, which is contrary to their established purpose of generating native code.

Description

Technical Field

[0001] Embodiments of the present disclosure relate to execution control with cross-level trace mapping. Background Art

[0002] Computer software is often complex. Part of the complexity may come from the nature of the work that the program is designed to perform, such as tracking a large number of real-world items or ongoing transactions over hours or longer, coordinating activities with other complex software, controlling complex hardware, and so on. Complexity also arises in almost any real-world use of software, because many details are introduced and should be managed correctly to instruct computer hardware how to perform real-world work, which is much less precise when originally described in English or another natural language. That is, the conversion from a high-level description to a low-level implementation executable by a computer system inevitably introduces complexity. Even programming language source code that is more precise than natural language is still at a relatively high level and is therefore vague and open to various understandings and implementations. The source code is converted into low-level instructions that are directly executable by computational hardware, and many details are introduced and choices are made during the conversion.

[0003] Complexity introduces the possibility of programming errors (also called "defects", bugs) that are usually not often recognized. The process of identifying the cause of the defect and attempting to modify the program to remedy or remove the effect of the defect is called "debugging". Specialized software tools that assist in debugging are called "debuggers". The program being debugged is called a "debugee".

[0004] Debugging may be the easiest when the developer can arbitrarily run the debug object slowly or at full speed, or arbitrarily suspend the execution of the debug object, and can check all the state information of the debug object at any time during the execution of the debug object. This is referred to as "real-time process debugging". However, such full access to the debug object is usually unavailable. For example, the debug object may be production software, and the production software cannot be debugged in real time without violating the service agreement or damaging the reputation, security or financial status of the interested party. If the real-time process debug object is suspended for a few seconds at a time when the developer checks the variable value, checks which functions are called using which parameter values, views the source code, considers the possible explanation of the defect, and designs the test that may help to identify, remedy or eliminate the defect, it may cause unacceptable harm.

[0005] Therefore, sometimes state information is recorded when the debug object is executed so that it can be checked later without substantially pausing the execution of the debug object. Creating such a record may slow down the speed of the debug object, but the record can provide useful information without compromising production performance goals like real-time debugging. For example, the debug object can be suspended for a long enough time to create a memory dump that copies some or all memory values ​​associated with the debugger to disk at a specific point in time. Some aspects of the execution of the debug object can also be recorded in the execution trace. In the case where the debug object is not a real-time process, some debuggers support the use of such tracing to replay the execution of the debug object being tracked. With some debuggers, the debug object execution can be replayed forward or reverse, thereby allowing "time travel", "reverse" or "historical" debugging.

[0006] However, because execution traces may contain less information than is sometimes available during live process debugging, and because execution traces record state information at a low level, technical challenges arise when a debugger or other software tool attempts to control replayed execution (i.e., execution based on a recorded trace). Depending on the implementation, execution control operations that developers are familiar with and often use during live debugging may not be very accurate when attempted during trace-based replay, or may not be available at all.

[0007] Therefore, advances in using low-level execution tracing to efficiently and accurately achieve high-level execution control through debuggers or other replay or logging tools can help improve the information available to developers or automated performance monitoring tools. Therefore, such advances will tend to improve the functionality of computer systems by supporting accurate understanding of computer system behavior and by supporting mitigation or elimination of computer system defects. Summary of the invention

[0008] Some of the techniques described herein relate to technical activities for mapping between locations in the source code of a program and corresponding locations in a trace of the execution of the program, thereby improving the accuracy of execution control in trace-based debugging. Some teachings relate to a specific breakpoint setting procedure that sets one or more breakpoints at locations aligned with source code expressions or statements. Technical mechanisms for adapting a real-time debugging environment to support reverse execution based on tracing are described. In response to the challenges of replaying the execution of a debug object forward or in reverse or forward and in reverse based on execution tracing, specific technical tools and techniques are described herein. Other technical activities related to the teachings herein will also become clear to those skilled in the art.

[0009] Some embodiments described herein use or provide a trace replay execution control capability that uses a processor, memory, traces recorded during execution of a program using a runtime, program source code, mappings between source code and its intermediate representation and traces, and an execution controller in a debugger or other tool. The runtime contains support code that provides dynamic compilation or memory garbage collection services as the traced program is executed and the trace is captured. The trace may include a record of native code instructions executed by the program. The trace may include a record of data accessed during execution of the program while the debug object is being executed. The trace may include one or more memory dumps or snapshots. The trace may be stored in one or more files or portions of non-volatile or volatile memory. The execution controller is configured to control the replay execution of the trace in response to a request from a tool. During replay, the source code is associated with the traced native code instructions or other trace entries through source intermediate mappings and intermediate native mappings using breakpoints that are set to help align the grouped native instructions with their corresponding source code items.

[0010] Some embodiments described herein use or perform computer-implemented trace-replay execution control. The traced managed program is identified. A managed program (also referred to as a "runtime management" program) is a program configured to be executed in conjunction with a call to a runtime. The traced managed program is a program that is traced or configured to be traced. A trace-replay execution control request is received in a software tool. Based on the trace-replay execution control request, a mapping is performed between the source code of the traced managed program and an intermediate representation of the source code, and another mapping is performed between the intermediate representation and the trace. The trace does not include any execution instance at runtime. The traced replay can be controlled by, for example, simulating the trace activity in a direction and amount corresponding to the trace-replay execution control request (e.g., one step forward, or repeating the entire routine by stepping over it), or by setting a breakpoint at the trace location, or by performing both of the above.

[0011] The examples given are merely illustrative. This Summary is neither intended to identify key features or essential features of the claimed subject matter nor to limit the scope of the claimed subject matter. Instead, this Summary is provided to introduce some technical concepts in a simplified form, which will be further described in the Detailed Description below. The invention is defined by the claims, and in the event of a conflict between this Summary and the claims, the claims shall prevail. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] A more detailed description will be given with reference to the accompanying drawings. These drawings illustrate selected aspects only and therefore cannot fully determine the coverage or scope. Although the dashed lines indicate that some items are optional, any item recited in the claims or any item considered by a person skilled in the art to be non-optional for embodying the claims should be understood to be present in some form in an embodiment of the claims.

[0013] Figure 1 is a block diagram illustrating a computer system and also illustrating configured storage media;

[0014] Figure 2 is a block diagram illustrating aspects of real-time process debugging;

[0015] Figure 3 is a block diagram illustrating aspects of debugging based on a copy of memory made at a single specific point in time;

[0016] Figure 4 is a block diagram illustrating aspects of an example architecture for trace-based debugging, including primary requests and responses between a debugger and a replay adapter;

[0017] Figure 5 is a block diagram showing various memory locations that may be referenced during debugging or in tracing;

[0018] Figure 6 is a block diagram illustrating a machine level request that may seek information from an execution trace or exert execution control during replay of the execution trace;

[0019] Figure 7 is a block diagram illustrating a response to a machine level request;

[0020] Figure 8 is a block diagram illustrating an example trace-replay execution control system;

[0021] Fig. 9 is a block diagram illustrating some trace replay execution control operations;

[0022] Fig.10 is a block diagram illustrating some aspects of thread tracking data;

[0023] Fig.11 is a block diagram illustrating some aspects of one or more intermediate representations;

[0024] Fig.12 is a block diagram illustrating some aspects of a real-time process debugging environment adapted to use tracing to support reverse execution debugging;

[0025] Fig.13 is a flowchart illustrating an example trace replay execution control method; and

[0026] Fig.14 is a flow chart further illustrating some trace replay execution control methods. DETAILED DESCRIPTION

[0027] Overview

[0028] Debugging in a production cloud environment presents serious technical challenges. For example, suppose a particular request R to an online shopping cart does not work. How can a developer debug the processing of request R without slowing down the processing of all other requests and minimizing the slowdown in the processing of request R? To find the defect, the developer uses information about what is happening inside the code, such as a way to view the values ​​of variables at one or more points of interest during the processing of request R.

[0029] The debugging innovation based on tracing discussed here helps to overcome technical difficulties that traditional methods cannot solve. For example, many traditional debuggers and debugging methods allow developers to set a halt breakpoint to obtain information about the value of a variable. A halt breakpoint is an instruction to suspend execution, so that the developer has time to examine the memory contents at a given point in the process and consider possible explanations for the observations. However, in a production environment, a halt breakpoint may suspend the processing of a large number of requests, or cause the request to fail completely (e.g., time out), or cause the execution to take a different execution path, whichever is undesirable. Even if only a single thread is paused, it may result in an undesirable abandonment of the request and produce unpredictable side effects that hinder debugging, or reduce performance, or both.

[0030] Some familiar debugging methods involve adding print statements at specific points in the code to print the value of a specific variable, or adding other code, for example, to test the value of a variable to see if it is the value the developer expected at that point in the code. However, these methods may require recompiling and redeploying the code, which is undesirable in a production environment, especially if recompiling and redeploying are to be done multiple times as part of an iterative debugging process to find and fix a single defect.

[0031] Developers can inject operations into request processing code at execution time to make copies of some or all of the memory related to the request. The copy can include a "snapshot" 304 (an in-memory copy of a process that shares memory allocation pages with the original process via copy-on-write) or a "dump" file 302 (a serialized copy of the process) or both. Some traditional debuggers can read dump files or snapshots and, given appropriate metadata, present memory contents in a specific format that shows variable values ​​converted from binary to an informative structure including variable names and displays variable values ​​based on the corresponding data types of the variables. However, dumping memory to a file takes a lot of time, which not only slows down request R, but also slows down the processing of all requests in the example scenario. Although taking a snapshot is much faster than creating a dump file, this may require a lot of attempts by the developer to find a useful point in the process to obtain a memory snapshot that reveals the defect, and the snapshot takes up space in RAM. In order to view the memory at another point in time other than execution time captured in the dump file or snapshot, another memory copy can be created.

[0032] In order to view the memory at any point in time in real time, real-time processes are used. In many modern computing systems, such as Figure 2 As shown in the example in , in addition to relying on the operating system, the real-time debugging object 202 also includes a runtime 204. The runtime 204 provides garbage collection or dynamic code compilation (i.e., JIT compilation or compilation of intermediate language code), or both. Garbage collection can utilize object reachability analysis, object reference counting, or other strategies. Some configurations include an interpreted runtime 204, and those skilled in the art will recognize that the teachings herein can be applied to perform execution control on the interpreted runtime by overlaying the interpreter's view onto the native trace and using breakpoints within the interpreter itself. Additionally, some runtimes (e.g., The runtime) does not always JIT compile its IL representation (which is called "bytecode" in Java terminology). Instead, the runtime may choose to interpret the bytecode for less frequently used functions. In this case, execution control can be performed by the runtime code itself, and the native code to internal runtime data structures to IL to source code can be mapped. The mapping of native code to internal runtime data structures to IL can be considered an example of intermediate native mapping 812, and the mapping of IL to source code can be considered an example of source intermediate mapping 810.

[0033] Unlike processes that lack a runtime, which can be directly controlled by the debugger by inserting breakpoints, processes that rely on the runtime cannot be directly controlled by the debugger 200 because their runtime is effectively hidden from the debugger memory items 206, such as memory locations, memory contents, and instruction pointers. In order to show the developer what is in memory during debugging, the debugger sends a main request 214 to the runtime asking for current memory values, the runtime sends these values ​​in a main response 216 to the debugger, and the debugger displays the values ​​it receives in a reply message in some user interface 210.

[0034] As a specific example of the shortcomings of the previous approach, consider a runtime 204 implemented as a virtual machine that executes an intermediate language (IL). IL code cannot be easily debugged using a traditional native code debugger because the debugger will be used to debug the virtual machine / runtime, not the IL code.

[0035] Runtime also controls the execution of real-time debug objects. Traditional debuggers for IL or languages ​​compiled to IL work by establishing a communication channel between the debugger and the runtime inside the debug object. The runtime in the debug object performs most of the work required for providing debugging experience. In one example, in order to set a breakpoint at the intermediate language (IL) instruction in method Foo at offset 28, a message is sent to the runtime, requiring it to set a breakpoint at Foo offset 28. Then, the thread in the runtime will receive the message, convert Foo IL offset 28 to a machine instruction residing at memory address 0x4567123512395, and then write a breakpoint instruction at this location. Similarly, in order to perform familiar execution control operations, such as stepping, stepping into, stepping out and stepping skipping, the debugger sends a main request 214 requesting the operation to the runtime, the runtime 204 performs the operation and sends the updated state to the debugger in the main response 216, and the debugger displays the result indicated in the reply message in a certain user interface 210.

[0036] The user interface 210 graphically displays to the user a representation of the debugger's debuggee program state. Some examples of program state are a list of threads, the next line of source code to be executed on each thread, a call stack for each thread, a set of variables in each frame of the call stack, the values ​​of these variables, etc. The user interface may include windows that display local data of a routine, variables being watched and their values, source code, an expression evaluator, and other information about the live debuggee 202.

[0037] In some implementations, the runtime conversion portion of the debugger 200 is responsible for converting between low-level concepts (such as memory cells and registers) and runtime abstractions. Examples of runtime abstractions include a list of threads, one or more call stacks for each thread, and the IL instructions to be executed next. Note that the call stack at the abstract runtime layer is not necessarily the same as the call stack at the abstract source code level, for example, the call stack of a virtual machine does not necessarily match the virtual call stack of the IL code being executed in the virtual machine.

[0038] It is possible to create an execution trace 418 of a process. The trace can then be replayed using a simulation of the computer system 102. Sometimes, the traced process is written in source code 212, a high-level language that requires a real-time debug object 202 to be executed by the runtime 204. The trace itself can be difficult to debug because the trace data reflects the view at a low level (e.g., the runtime or the just-in-time compiled code or both), rather than the high-level language in which the program was written. Some tracing technologies do not provide a high-level view of the process that the user 104 may prefer. Most high-level runtimes require the runtime itself to provide information about the program running in its framework. Therefore, conventional debugging may require that the process be executed within the runtime, which is not an option when debugging is based on tracing rather than real-time processes.

[0039] Like any other process, the runtime can be traced. However, debugging software other than the runtime is more common than debugging the runtime. Tracing a process can include or exclude tracing some or all code that is part of the runtime itself.

[0040] This functionality does not apply to trace files that do not have a currently executing runtime. In order to control the execution of a real-time process that is executing code that depends on the runtime 204, the debugger can send a message to the runtime requesting an operation, such as "step" or "run", and the runtime then performs the operation on behalf of the debugger.

[0041] The debugger's ability to send messages to the runtime to perform actions on behalf of the debugger does not apply to trace files that do not have a currently executing runtime. Dump files 302 and snapshots 304 are similar to traces in that the runtime is not available. A runtime can be represented as a dump or snapshot or trace, but it is not executing and therefore cannot be called in the traditional way.

[0042] Nevertheless, it is possible to make the trace file 420 part of the debugging environment. Some trace-based debugging embodiments discussed herein extend the power of debugging so that a debugger can replay execution from a trace file, starting at one or more points in execution time selected by the developer, and then move forward or backward in the traced execution by increments selected by the developer. One approach is to insert a replay layer between the trace and a high-level language debugger. The replay layer understands the execution control messages at runtime, allowing high-level control of the traced process.

[0043] In some cases, a developer may use a "time travel" debugger to control execution replay to run forward in execution time or backward in execution time when replaying a recorded trace 418, thereby taking advantage of the debugger's ability to present program state information such as instruction pointer(s) and memory in a useful high-level (e.g., named and data type-based) variable presentation form, not only for snapshots as before, but now for continuous replay of segments of execution time recorded during code execution. Debugging may be made more efficient by aligning grouped trace data with corresponding source code structures (such as expressions and statements). Memory values ​​captured in the trace may be inspected by the developer at multiple points in a high-level presentation based on the low-level data recorded in the trace file.

[0044] As the trace is replayed, the included replay layer can be used to control the debuggee state. So adapted, the debugger 200 can apply a runtime (high-level) view of the process trace that has been recorded as a machine-level operation. For purposes of this application only, a "machine-level" operation is an operation specified at a machine-specific level. In general, "native" and "machine-level" are used interchangeably herein with respect to instructions or code.

[0045] Some may view some of the embodiments described herein in a broader context. For example, concepts such as controlling execution, recording execution, and replaying recorded execution may be considered relevant to specific embodiments. However, it is not in accordance with the availability of a broad context that exclusive rights to abstract concepts are sought herein; they are not. Rather, the present disclosure is focused on providing appropriate specific embodiments whose technical effects fully or partially solve specific technical problems, such as how to automatically associate high-level control requests with machine-level traces, and other problems addressed herein. Other media, systems, and methods involving controlling execution, recording execution, or replaying recorded execution are not within the scope of the present invention. Therefore, with a proper understanding of the present disclosure, ambiguity, mere abstraction, lack of technical characterization, and the attendant proof problems are also avoided.

[0046] Technical features

[0047] The technical features of the embodiments described herein will be apparent to those of ordinary skill in the art, and will also be apparent to various dedicated readers in a variety of ways. Some embodiments address technical activities rooted in computing technology and improve the functionality of computing systems by helping to debug these systems, thereby improving the system's uptime, system accuracy, and power utilization relative to the computational results produced. For example, some embodiments provide system debuggability functionality that helps reduce the amount of time spent by developers locating defect descriptions while debugging by allowing replay execution to move backward to a desired point rather than restarting from the beginning of execution and moving forward to that point. Some embodiments improve the debuggability of the system by accurately aligning trace data with corresponding source code statements. Some embodiments provide additional debugging functionality in the system, such as functionality for setting a breakpoint address range instead of setting a breakpoint on one address at a time.

[0048] Some embodiments include technical components, such as computing hardware, that interact with software in ways that go beyond typical interactions within a general-purpose computer. For example, in addition to general interactions (such as general memory allocation, general memory reads and writes, general instruction execution, and certain I / O), some embodiments described herein implement backward stepping out of playback operations as disclosed herein.

[0049] Some embodiments provide technical effects including more efficient use of debugging time, reduced re-tracing to obtain additional trace data, and improved debugger functionality for defect causality exploration.

[0050] Some embodiments include technical adaptations. Some embodiments include a replay layer adapter that accepts requests formatted for the runtime, i.e., in a message format compatible with familiar debugger runtime communications, and responds to these requests in a format that can be used by the runtime during real-time debugging. In some embodiments, the replay adapter provides an interface that hides the differences between real-time process debugging, dump-based debugging, and time travel tracing-based debugging. Some embodiments include mappings between source code, intermediate representation(s), and trace data.

[0051] Other advantages of the technical features based on the teachings will also be apparent to those skilled in the art from the description provided.

[0052] Acronyms and Abbreviations

[0053] Some acronyms and abbreviations are defined below. Other abbreviations may be defined elsewhere herein or may be understood by those skilled in the art without any definition.

[0054] ALU: Arithmetic and Logic Unit

[0055] API: Application Programming Interface

[0056] BIOS: Basic Input / Output System

[0057] CD: Compact Disc

[0058] CPU: Central Processing Unit

[0059] DAC: Data Access Component

[0060] DVD: Digital Versatile Disc or Digital Video Disc

[0061] FPGA: Field Programmable Gate Array

[0062] FPU: Floating Point Processing Unit

[0063] GPU: Graphics Processing Unit

[0064] GUI: Graphical User Interface

[0065] IDE: Integrated Development Environment, sometimes called "Interactive Development Environment"

[0066] IL: Intermediate Language

[0067] OS: Operating System

[0068] RAM: Random Access Memory

[0069] ROM: Read Only Memory

[0070] Additional terms

[0071] Reference is made herein to exemplary embodiments such as those shown in the accompanying drawings, and specific language is used herein to describe them. However, changes and further modifications of the features shown herein of the present disclosure and additional technical applications of the abstract principles illustrated by the specific embodiments herein that may occur to those skilled in the relevant art and that have the present disclosure should be considered within the scope of the claims.

[0072] The meanings of the terms are declared in this disclosure, so these statements should be carefully noted when reading the claims. Specific examples are given, but those skilled in the relevant art will understand that other examples may also fall within the meaning of the terms used and fall within the scope of one or more claims. The terms here do not necessarily have the same meaning as they are in general use (especially in non-technical use), in the use of a specific industry, or in a specific dictionary or dictionary. Figure numerals can be used with various wordings to help show the breadth of the terms. Omitting a figure numeral from a given text does not necessarily mean that the text does not discuss the content of the figure. The inventor claims and exercises his right to compile his own dictionary. Quoted terms are explicitly defined, but it is also possible to define terms implicitly without using quotation marks. Terms can be explicitly or implicitly defined in the "Detailed Description" and / or elsewhere in the application document.

[0073] As used herein, a "computer system" may include, for example, one or more servers, motherboards, processing nodes, laptops, tablets, personal computers (portable or non-portable), personal digital assistants, smart phones, smart watches, smart bracelets, cellular or mobile phones, other mobile devices with at least a processor and memory, video game systems, augmented reality systems, holographic projection systems, televisions, wearable computing systems, Internet of Things nodes, and / or other devices that provide one or more processors controlled at least in part by instructions. Instructions may take the form of firmware or other software in memory and / or dedicated circuit systems.

[0074] A "multithreaded" computer system is one that supports multiple threads of execution. The term "thread" should be understood to include any sequence of instructions that can be executed or scheduled (and possibly synchronized), and may also be referred to as, for example, a "procedure" or a "coroutine." Threads may run in parallel, sequentially, or in a combination of parallel execution (e.g., multiprocessing) and sequential execution (e.g., time-sliced).

[0075] A "processor" is a thread processing unit, such as a core in a simultaneous multithreading implementation. A processor comprises hardware. A given chip may house one or more processors. Processors may be general purpose or customized for specific uses, such as vector processing, graphics processing, signal processing, floating point arithmetic processing, encryption, I / O processing, etc.

[0076] The "kernel" includes the operating system, virtual machine monitor, virtual machines, BIOS code, and similar hardware interface software.

[0077] "Code" refers to processor instructions, data (including constants, variables, and data structures), or both. "Code" and "software" are used interchangeably herein. Executable code, interpreted code, and firmware are some examples of code. Code that is interpreted or compiled for execution is called "source code."

[0078] "Program" is used broadly herein to include applications, kernels, drivers, interrupt handlers, firmware, state machines, libraries, and other code written by a programmer (also called a developer) and / or automatically generated.

[0079] "Services" means consumable programs provided in a cloud computing environment or other network environment.

[0080] "Execution time point" refers to a specific execution point for a processing unit or thread, especially in relation to traced execution. References to "specific execution time" or "execution time t" etc. in this document are references to execution time points. For example, the execution time point can be implemented as a time code variable or time code value, or as a relative position in other records of traced or executed activities. An execution time point ta being "earlier than" or "later than" an execution time point tb means that the relative order of the two execution time points is determined. Similarly, a "younger" execution time point is an execution time point that is later than an "older" execution time point.

[0081] The information in a trace about the order of traced events may be incomplete. Thus, a trace may have enough information to determine that event A is earlier than event B, or that event D is later than event C. But the relative order of events may also be partially or completely uncertain with respect to the trace. A trace may show that event E does not follow event F, but this does not necessarily mean that E precedes event F; similarly, a trace may show that event K does not precede event J without the trace also showing that K follows J. A trace may also lack sufficient information to establish any order of two specific events relative to each other.

[0082] "Timecode" means a monotonically varying value that can be used to impose an order on at least some events in an execution trace. It is expected that timecodes are typically monotonically increasing values, but timecodes can also be implemented as monotonically decreasing values. Some examples of timecodes include instruction counters, clock times (a.k.a. clock ticks), and completely artificial (not register- or instruction-based) monotonic values. Depending on the trace, all, some, or no trace events may have corresponding associated timecodes. When timecodes exist, they may be unique, or they may simply be monotonic because some timecode values ​​repeat.

[0083] A "memory cell" refers to an addressable unit of memory. Some examples include a byte or word in RAM or ROM, a processor register, a cache line, and other addressable memory cells.

[0084] An "emulator" performs an "emulation" that provides the same functionality as the original hardware, but uses a different implementation or different hardware, or both. An example is a CPU emulator, which acts like a CPU and can be used to execute code just like the original CPU hardware, but has a different implementation than the original CPU, e.g., the emulator may run on completely different physical hardware.

[0085] As used herein, "comprising" allows for additional elements (ie, comprising means including) unless stated otherwise.

[0086] "Optimization" means improvement, not necessarily perfection. For example, a program or algorithm that has already been optimized can be further improved.

[0087] For example, "process" is sometimes used herein as a term in the field of computer science and in a technical sense covers computational resource users, i.e., coroutines, threads, tasks, interrupt handlers, application processes, kernel processes, procedures, and object methods. "Process" is also used herein as a term in patent law, for example, when describing a process claim relative to a system claim or an article (configured storage medium) claim. Similarly, "method" is sometimes used herein as a technical term in the field of computer science (a "routine") and as a term in the field of patent law ("process"). Those skilled in the art will understand the meaning intended to be used in a particular case, and will also understand that a given claimed process or method (in the patent law sense) can sometimes be implemented using one or more processes or methods (in the computer science sense).

[0088] In contrast to no automation, "automatically" means utilizing automation (e.g., general-purpose computing hardware configured by software for the specific operations and technical effects discussed herein). In particular, the steps performed "automatically" are not performed manually on paper or in a person's mind, although they may be initiated by a person or guided interactively by a person. The automated steps are performed by a machine in order to obtain one or more technical effects that would not be achievable without utilizing the technical interactions so provided.

[0089] The technician understands that the technical effect is the presumed purpose of the technical embodiment. For example, in one embodiment, calculations are involved, and some calculations can also be performed without a technical component (e.g., by paper and pencil, or even as a mental step), and this fact does not eliminate the existence of the technical effect or change the specific and technical nature of the embodiment. Operations such as searching for trace data at a sufficiently fast speed to allow replay within one or two orders of magnitude of the original execution speed, and calculations for grouping the native instructions of the trace and aligning the instruction groups with the corresponding source code items should be understood in this article as: in addition to its inherent digital nature, it is also necessary and provides speed and accuracy that human thinking steps cannot obtain (human thinking cannot be directly connected to trace files or other digital storage to retrieve necessary trace data). This is well understood by those skilled in the art, but others may sometimes benefit from being informed or reminded of the fact. Unless otherwise stated, contrary to a simple thought experiment, the embodiment is assumed to be able to operate on a large scale in a production environment or in a test laboratory in a production environment.

[0090] "Computationally" also means that a computing device (at least a processor plus memory) is being used, and excludes results obtained by human thought alone or by human action alone. For example, as understood herein, arithmetic performed with paper and pencil is not computationally performed arithmetic. Computational results are faster, more extensive, deeper, more accurate, more consistent, more comprehensive, and / or provide technical effects beyond the scope of human performance. A "computational step" is a step that is performed computationally. Neither "automatically" nor "computationally" necessarily means "immediately." "Computationally" and "automatically" are used interchangeably herein.

[0091] "Actively" means without direct request from the user. In fact, the user may not even be aware that an active step of an embodiment is possible until the results of the step have been presented to the user. Unless otherwise stated, any computational and / or automatic steps described herein may also be performed actively.

[0092] Throughout this document, the optional "(s)" is used to indicate the presence of one or more of the indicated feature. For example, "processor(s)" means "one or more processors" or equivalently "at least one processor."

[0093] For purposes of U.S. law and practice, use of the word "step" herein, in the claims or elsewhere, is not intended to invoke means-plus-function, step-plus-function, or 35 U.S.C. 112(f) requirements. Any presumption to such effect is hereby expressly rebutted.

[0094] For purposes of U.S. law and practice, unless claims use the phrase “means for,” they are not intended to invoke a means-plus-function interpretation. Claim language that is intended to be interpreted as means-plus-function language, if any, will expressly recite that intent through the use of the phrase “means for.” When a means-plus-function interpretation is employed, whether through the use of “means for” and / or through a court’s legal interpretation of the claim language, the means enumerated in the specification for a given noun or a given verb should be understood to be linked to the claim language and are linked hereto by any of the following: appearing in the same box in a block diagram of the accompanying drawings, being represented by the same or similar name, being represented by the same figure number. For example, if a “zac widget” is recited in a claim limitation, and that claim limitation is subject to a means-plus-function interpretation, then all structure identified anywhere in the specification where “zac widget” is mentioned, or bound together by any figure number assigned to the zac widget, at least in any block, paragraph, or example, should be considered part of the structure identified in the zac widget application and help define the set of equivalents for the zac widget structure.

[0095] Throughout this document, unless otherwise explicitly stated, any reference to a step in a process assumes that the step may be performed directly by the party of interest, and / or indirectly by a party through an intervening mechanism and / or intervening entity, and still be within the scope of the step. That is, unless directly performed is explicitly stated, the step need not be performed directly by the party of interest. For example, steps such as align, clear, compile, continue, control, debug, simulate, encounter, exceed, execute, obtain, group, identify, map, execute, receive, record, replay, request, respond, send, set, specify, step (and variations such as step into, step out, step skip), terminate, track (and align, aligned, clear, cleared, etc.), etc., involving actions performed by the party of interest with respect to a destination or other subject matter, may involve intervening actions performed by some other party, such as forwarding, copying, uploading, downloading, encoding, decoding, compressing, decompressing, encrypting, decrypting, authenticating, calling, etc., but should still be understood to be performed directly by the party of interest.

[0096] Whenever reference is made to data or instructions, it should be understood that these items configure computer-readable memory and / or computer-readable storage media, for example, to transform it into a specific article, as opposed to simply existing on paper, in one's mind, as energy alone, or as a signal propagating on a wire. For purposes of U.S. patent protection, memory or other computer-readable storage media are not propagating signals, carrier waves, or mere energy outside the scope of patentable subject matter, as interpreted by the U.S. Patent and Trademark Office (USPTO) in re Nuijten. In the United States, no claim covers the signal itself, and any claim interpretation asserting the contrary is unreasonable. Unless expressly stated otherwise in a claim issued outside the United States, the claim does not cover the signal itself.

[0097] Furthermore, despite explicit provisions to the contrary elsewhere herein, the distinct distinction between (a) computer-readable storage media and computer-readable memory and (b) transmission media (also known as signal media or energy only) should be understood. Transmission media are propagating signals or carrier wave computer-readable media or energy only. In contrast, computer-readable storage media and computer-readable memory are not propagating signals or carrier wave computer-readable media. Unless otherwise expressly stated in the claims, "computer-readable medium" means computer-readable storage media, not propagating signals per se, nor energy only.

[0098] The "embodiments" herein are examples. The term "embodiments" is not interchangeable with the "invention." The embodiments may freely share or borrow aspects to create some other embodiments (as long as the result is operable), even if the resulting combination of aspects is not explicitly described herein itself. It is not necessary for a person skilled in the art to explicitly describe every permissible combination, which is contrary to the policy of recognizing that patent specifications are written for those skilled in the art. Formal combinatorial calculations and informal intuition about the number of possible combinations resulting from even a small number of combinable features will show that there are a large number of aspect combinations of the aspects described herein. Therefore, requiring an explicit recitation of each combination runs counter to the policy of requiring concise patent specifications and requiring the reader to have knowledge in the relevant technical field.

[0099] Reference numerals list

[0100] The following list is provided for the convenience and support of the drawings and as part of the specification text, which describes the innovation by reference to multiple items. Nevertheless, items not listed here may still be part of a given embodiment. In order to make the text clearer and easier to read, given reference numerals are cited near some (but not all) referenced items in the text. The same reference numerals may be used to refer to different examples or different instances of a given item. The list of reference numerals is:

[0101] 100: Operating environment, also known as computing environment

[0102] 102: Computer system, also known as computing system or computing system

[0103] 104: User

[0104] 106: Peripheral devices

[0105] 108: Usually the Internet

[0106] 110: Processor

[0107] 112: Computer-readable storage media, such as RAM, hard disk

[0108] 114: Removably configurable computer readable storage medium

[0109] 116: Instructions executable by a processor; may be on removable media or in other memory (volatile or nonvolatile or both)

[0110] 118: Data

[0111] 120: (multiple) kernels, e.g., (multiple) operating systems, BIOS, device drivers

[0112] 122: Tools, such as antivirus software, profilers, debuggers, editors, compilers, interpreters, security penetration testers, fuzzers, automated performance monitoring tools, etc.; can be adapted to use the execution control taught herein

[0113] 124: Applications, such as word processors, web browsers, spreadsheets

[0114] 126: Display

[0115] 128: computing hardware, not otherwise associated with reference numerals 106, 108, 110, 112, 114

[0116] 200: debugger, also refers to debugging activities

[0117] 202: Real-time debugging of the target program or process

[0118] 204: Runtime, for example, Common Language Runtime, Virtual Machine, or other virtual machine that dynamically translates code for execution (a trademark of Oracle Corporation)

[0119] 206: Memory items, such as application or system data structures

[0120] 208: Data Access Components of the Debugger

[0121] 210: Debugger User Interface

[0122] 212: Source code, related information such as metadata and symbol tables

[0123] 214: Primary request from a debugger for a debuggee information source, such as a live debuggee or dump file reader software or snapshot reader software or trace file reader software

[0124] 216: Response to a main request seeking information from a debuggee information source or state change; also called a "main response", as in a response at the abstract level of the main request, rather than as in the first or initial or foremost response

[0125] 218: Statements in source code; may be explicitly delimited, for example, by semicolons or parentheses, braces, or brackets, or implicitly by spaces or end-of-line

[0126] 220: An expression in source code; syntactically defined by the programming language used; may be an assignment to a function call, an assignment to an object member, a routine call, or another combination of constants, variables, operators, and routines that produces a result value or side effects

[0127] 302: Dump file, also called memory dump; may include additional information such as indexes or metadata

[0128] 304: Storage snapshot; may include additional information such as indexes or metadata

[0129] 402: Debug object execution control code in a debugger, e.g., for requesting or simulating execution control of a debug object, such as stepping through a debug object, setting breakpoints, executing a debug object until a breakpoint is reached, etc.

[0130] 404: Cross-level mapping in a debugger or other tool, for example, between source code and intermediate representation or between intermediate representation and trace data

[0131] 406: Replay component, which uses the trace file to simulate the execution of the debug object; the trace replay component 406, alone or in conjunction with other execution controllers 402, 408 (depending on the implementation), uses the trace to simulate the execution of the original process and allows viewing of CPU state and memory units over time; in some embodiments, the simulation can be performed forward or backward

[0132] 408: Replay adapter for the replay component, which allows the replay component to send requests and receive responses, which are also used during debugging of the real-time process; in the trace file debugging scenario, the replay layer (i.e., the replay component plus the replay adapter) receives and responds to primary requests from the debugger, which can be received and responded to by the runtime in the real-time process debugging scenario, and the replay adapter can also make secondary requests for trace files

[0133] 410: Replay adapter interface; configured to communicate with the debugger

[0134] 414: secondary request for trace from replay adapter, where "secondary" indicates a lower level of abstraction than the primary request 214; the secondary request may be a machine-level request, which may be implemented as a communication to a trace file reader, or may be implemented internally within the replay adapter (e.g., as a function call)

[0135] 416: Response to a machine-level request seeking information from the trace; also called a "secondary response", as in a response at the abstract level of the secondary request, rather than as in a second response; may be implemented as a communication from a trace file reader, or may be implemented internally within a replay adapter (e.g., as a function result or data structure update)

[0136] 418: Execution trace; despite Figure 4 The dashed lines in 418 show that individual items may be included or omitted from a given trace, but it is assumed herein that the trace is not empty and is therefore shown with solid lines on the box for what is generally trace data 454; 418 may also refer to the activity of creating a trace, which is sometimes also referred to as "tracing" or "recording".

[0137] 420: Trace file containing execution trace data; may include machine-level trace data, i.e., data recording execution activity at the native machine code level

[0138] 422: Accurate tracking data in tracking

[0139] 424: A time code in a trace that identifies a particular execution time point in the execution of the traced code; may be linked to or embedded in other data within the trace, e.g., in trace data that explicitly states an execution time point associated with a stated operation at a stated memory address involving stated data values; the time code may be implemented, e.g., as clock ticks or an instruction counter; some traces may contain a unique time code for each recorded operation, but time codes may also be repeated or omitted in some trace data

[0140] 428: Gaps in timecodes in a trace, used to explicitly or implicitly indicate points in execution time where tracing is not performed (e.g., ranges when tracing is disabled for a thread or processing unit). This can include any gaps where adjacent timecodes differ by more than a default or specified increment (usually 1), e.g., a gap between 4 and 300 for the timecode sequence 2,3,4,300,301,302, and a gap between 1000 and 2000 for the timecode sequence 250,500,750,1000,2000,2250,2500.

[0141] 430: Indexes into the data in the trace file, such as reverse lookup data structures for quickly identifying trace attributes, memory life index information, and other searchable lists of locations in the trace data that may be of particular interest

[0142] 432: Keyframes in tracking data; for example, may be present at fixed intervals in the tracking data to permit playback to jump to a tracking playback at (or near) a keyframe more quickly.

[0143] 434: Executed code, e.g., opcodes and parameters of the debuggee's machine-level code executed by the processor while the debuggee is running and being traced

[0144] 436: Stack activity that occurs while the debuggee is running and being traced, such as stack growth, stack shrinkage, and the execution time at which the activity occurs

[0145] 438: data stream; may correspond to a single thread or a group of threads, may correspond to a processor unit (e.g., a processor core); may correspond to all cores in a given processor socket; may be annotated with metadata to aid replay

[0146] 440: Processor core activity that occurs while the debuggee is running and being traced, such as the opcodes and parameters of the instructions executed by the core

[0147] 442: Processor socket activity that occurred while the debuggee was running and being traced, for example, the opcodes and parameters of instructions executed by any core located in a given processor socket

[0148] 444: Thread activity that occurs while the debuggee is running and being traced, e.g., instructions executed while the thread is running, memory unit accesses made while the thread is running, and associated metadata such as thread ID and timecode

[0149] 446: Register activity that occurs while the debuggee is running and being traced, for example, what value is read from which register at what time code, and what value is written to which register at what time code

[0150] 448: memory address

[0151] 450: instruction opcode

[0152] 452: Data value

[0153] 454: Generally, it is tracking data

[0154] 456: Tuple, i.e., two or more items of trace data that are associated in a trace, representing the same operation during the execution of the trace; for example, a memory read operation or a memory write operation may be recorded on a single line in the trace as a tuple that contains or otherwise associates together the opcode (e.g., read or write), the address (e.g., a RAM address or a register ID), and the data value that has been read or written

[0155] 458: Tracking Entry

[0156] 502: Memory unit, such as a byte or word in RAM or ROM, a processor register, a cache line, or other addressable memory unit

[0157] 504: stack, e.g., a portion of memory into which state information is pushed when a routine is entered and then popped as control returns from the routine to the code that called the routine; usually distinguished from heap memory

[0158] 506: stack base address, which defines the starting point from which the stack is allocated in contiguous memory; the stack is assumed to grow in a known direction using the allocation of stack memory in the system, which may be an upward direction in a given system (i.e., addresses increase as items are pushed onto the stack), but in another system it may also be downward (i.e., addresses decrease as items are pushed onto the stack); the term "growing" herein refers to in the direction of stack growth on the system in question, while "shrinking" refers to in the opposite direction

[0159] 508: Stack frame, i.e., allocation record, which is allocated on the stack when a routine is called; typically contains a return address, which identifies the location in the code where execution will resume when the routine returns; may also contain values ​​passed as parameters to the routine when it was called, or the addresses of such parameter values

[0160] 510: Heap memory allocated and freed as objects are constructed and released; in some cases, the heap may be automatically garbage collected, identifying and marking free memory that holds objects that are no longer reachable during real-time execution of the process; in other cases, memory allocated from the heap requires a separate explicit call to free the allocated memory.

[0161] 512: Object

[0162] 514: Cache memory; for example, it can be in RAM working memory or on the processor chip

[0163] 516: Registers in the processor core

[0164] 518: Object property; a named value that is part of an object; can be a function, in which case the property is often called a method; also refers to the function that implements an object property; a function is a routine that returns a value

[0165] 520: ROM (read-only memory); usually nonvolatile

[0166] 522: Non-volatile memory other than onboard ROM, such as removable flash memory, magnetic or optical disk storage, tape storage, etc.

[0167] 524: RAM (random access memory); usually volatile

[0168] 526: Local memory, e.g., memory that is local to a stated or implicit context, such as being local to a routine during its execution and then released, or being local to a thread

[0169] 528: Global memory, e.g., memory that is global to a stated or implicit context, such as global to a set of multiple routines during the execution of any of them, or global to a set of threads

[0170] 530: Characteristics of the memory that increase or decrease the likelihood that an entity external to the thread will change the value stored in the memory cell, e.g., whether the memory cell is write-protected with respect to other threads, whether it is in shared memory (such as memory that is global with respect to multiple threads)

[0171] 602: Memory unit specification, e.g., address in ROM or RAM or cache, or register ID, or another item that specifies a memory unit by distinguishing it from other memory units to permit access (read or write, or reasonable attempt to read or write) to the memory unit; multiple memory units may also be specified, e.g., as a range of addresses

[0172] 604: Register ID, e.g., register name, or index into register array

[0173] 606: Address range, i.e., a set of adjacent addresses identifying a set of corresponding consecutive memory cells; as an example, a range may be specified as a pair of addresses (high address and low address); as another example, a range may be specified as a base address and a count of consecutive cells based on the base address

[0174] 608: Specification of one or more execution time points, for example, as a specific time code or a range of time codes; a range may be specified as a pair of time codes (a start time code and an end time code), or as a base time code and a count of time code increments, such as a number of clock ticks or a number of instructions

[0175] 610: Instruction count, which can be used as a time code; it can be an absolute count from the beginning of the process execution, or a relative count such as when the thread resumes execution

[0176] 612: System clock value, for example, in milliseconds or CPU cycles

[0177] 614: Execution time range specification, i.e., data specifying a range of execution time points; for example, may be implemented as a pair of time codes (start and end) or as a base time code and a count of time code increments based on the base time code

[0178] 616: Execution time

[0179] 618: Perform control operations, such as stepping forward, stepping backward, going to a specified location, setting or clearing breakpoints, etc.

[0180] 620: Identifier of an execution control operation; for a step or continue operation, it refers to or includes a direction (i.e., forward or backward; "reverse" and "backward" are used interchangeably herein) and also refers to or includes an increment size (e.g., one step, step over a routine, or continue until a breakpoint is encountered)

[0181] 702: Data value derived from trace data

[0182] 704: Instruction pointer, which identifies a specific instruction or execution time point in the trace data; this is the reference location for moving forward or backward in replay execution; "backward" means towards younger and younger execution time points, and "forward" means towards older and older execution time points

[0183] 706: Status code indicating the result of the request, for example, the execution control operation is successful, the execution control operation is initiated (for asynchronous control), and the execution control operation fails.

[0184] 800: Tracking and replaying execution control system

[0185] 802: The process of the program being tracked; may include one or more threads

[0186] 804: Thread

[0187] 806: Request from user for a tool to perform a control operation

[0188] 808: Program metadata or tool metadata, i.e. data not specifically numbered elsewhere but still discussed here

[0189] 810: Source intermediate mapping, i.e., mapping between source code or (multiple) source code items and one or more intermediate representations of the source code or (multiple) source code items; mapping 810 is an example of cross-level mapping 404

[0190] 812: Intermediate native mapping, i.e., mapping between one or more intermediate representations and native instructions or other trace data; mapping 812 is an example of cross-level mapping 404

[0191] 814: Record of native instructions 116 in trace; may include, for example, accurate trace data 422, execution code 434, tuple 456, or generally trace data 454

[0192] 816: JIT (Just-in-time) compiler

[0193] 818: A call to a routine or other call, for example, to transfer control to an exception handler or interrupt handler

[0194] 820: Return address, i.e., the execution point or instruction where execution will continue after calling 818

[0195] 822: A set of trace data, such as native instructions, corresponding to a particular source code statement S or source code expression E; for example, this may include a record of the execution of instructions that were all generated by compiling the source code statement S or source code expression E, but not generated from the compilation of source code statements and source code expressions adjacent to S or E

[0196] 824: edge instructions of group 822; each group typically has two edges - if the instructions are ordered, one edge is the youngest instruction in the group and the other edge is the oldest instruction in the group; regardless of whether all instructions in a group of instructions are ordered relative to each other, an instruction X of a group of instructions G in a trace is on an edge of G when instruction X satisfies at least one of the following conditions: X is the first instruction of G encountered during forward execution of the trace ("first forward edge"), X is the last instruction of G encountered during forward execution of the trace ("last forward edge"), X is the first instruction of G encountered during backward execution of the trace ("first backward edge"), or X is the last instruction of G encountered during backward execution of the trace ("last backward edge")

[0197] 826: Intermediate representation, e.g., low-level code such as intermediate language code, or an abstract syntax tree, or a symbol table

[0198] 828: Breakpoint

[0199] 830: Breakpoint range

[0200] 902: A forward step operation, also called "forward step" or "step" (when the default or only direction is forward), is a forward step over a source code statement.

[0201] 904: A forward step into operation, also called "forward step into" or "step into" (default or only when direction is forward), is a forward step into a routine so that the next statement to be executed is the first statement of the body of the routine.

[0202] 906: A forward step skip operation, also called "forward step skip" or "step skip" (default or only when direction is forward), is to step forward into and through a routine so that the next statement to be executed is the first statement after the call to the routine.

[0203] 908: A forward step exit operation, also called "forward step exit" or "step exit" (default or only when direction is forward), is to step forward through the remainder of the current routine so that the next statement to be executed is the first statement after the calling routine.

[0204] 910: Continue forward operation, also called "continue" or "run" when the default or only direction is forward, means to continue forward execution until a breakpoint is encountered or the process terminates

[0205] 912: A backward stepping operation, also called "backward stepping", refers to stepping backwards over a source code statement.

[0206] 914: A backward step into operation, also called "backward step into", refers to stepping backward into a routine so that the next statement to be executed in reverse is the last statement of the body of the routine.

[0207] 916: A backward step skip operation, also called a "backward step skip", refers to stepping backward into and through a routine so that the next statement to be executed in reverse is the first statement before the calling routine.

[0208] 918: A backward step exit operation, also called "backward step exit", refers to stepping backwards through the remainder of the current routine so that the next statement to be executed in reverse is the first statement before the calling routine.

[0209] 920: Continue backward operation, also known as "continue backward" or "run backward" or "run reverse", means to continue executing backward until a breakpoint is encountered or the beginning of the process is reached

[0210] Some implementations may use different definitions for operations 902-920, such as by executing more or fewer instructions or by using different names.

[0211] 922: Set a breakpoint range, which specifies that execution should be paused when any address or execution time point in the specified range of multiple addresses or execution time points is encountered

[0212] 924: Set breakpoint

[0213] 1004: thread ID

[0214] 1006: thread status, for example, created, runnable, running, suspended, blocked, terminated

[0215] 1008: Thread code, that is, the code that is executed or can be executed when the thread runs

[0216] 1010: Thread memory, e.g., memory that is local to a thread, or memory that is global to a thread and accessed by the thread as the thread executes

[0217] 1102: Symbol table

[0218] 1104: Identifiers used in source code

[0219] 1106: Data type

[0220] 1108: Abstract Data Tree

[0221] 1110: Intermediate language, for example, Microsoft Common Intermediate Language, Bytecode (a trademark of Oracle Corporation), Register Transfer Language, Parrot Intermediate Representation, Standard Portable Intermediate Representation, IR Intermediate Language (trademark of LLVM Foundation, Inc.) etc.

[0222] 1112: Intermediate language code

[0223] 1300: Example trace replay execution control method, and flowchart illustrating the above method

[0224] 1302: Identification Program

[0225] 1304: Receive execution control request

[0226] 1306: Using the mapping between source code and intermediate representation

[0227] 1308: Using the mapping between intermediate representation and trace

[0228] 1310: Control the reply, e.g. by executing forward or backward or setting parameters on such execution (direction, increment)

[0229] 1312: Execute the traced instructions during replay, for example, by emulation or by converting the operations specified in the trace to control of the replay of native instructions (not necessarily all of those in the trace)

[0230] 1314: Set a breakpoint or breakpoint range; includes 922 or 924 or both

[0231] 1316: Send response to execution control request

[0232] 1318: Aligning a set of traced instructions with a source code statement or expression, e.g., by executing until the edge of the set before pausing at a breakpoint

[0233] 1400: Flowchart

[0234] 1402: This identifies a backward step exit request

[0235] 1404: Set a breakpoint at the execution location immediately before the indicated location; location A is "immediately before" location B in a trace when A is encountered before B during forward execution of the trace and there are at most five traced native code instructions between A and B.

[0236] 1406: Set a breakpoint at the edge of a set of instructions corresponding to a specific source code statement or expression

[0237] 1408: Set a breakpoint range that covers (and in some implementations matches) the range of addresses specified to receive dynamically compiled ("jitted") code

[0238] 1410: Set a breakpoint to step over the specified runtime routine

[0239] 1412: An instruction was encountered during original or replayed execution

[0240] 1414: Exceeded hardware constraint on maximum number of simultaneously monitored breakpoints

[0241] 1416: Avoid terminating the program

[0242] 1418: Terminate program

[0243] 1420: Controlling the original or replayed execution at a high level, for example by specifying the execution of source code statements or expressions to be executed

[0244] 1422: Execution (original or replay) of a process, thread, or program

[0245] 1424: Get the user's selection of a source code statement or expression

[0246] 1426: User selection of source code statement or expression

[0247] 1428: Debugging a process, thread, or program

[0248] 1430: Forward execution of a process, thread, or program

[0249] 1432: Execution of a process, thread, or program backwards

[0250] 1434: Set a large breakpoint range; a breakpoint range is "large" when it covers at least one thousand consecutive addresses or instructions in the trace

[0251] 1436: Large breakpoint range

[0252] 1438: Recording trace data from a live process

[0253] 1440: Group the traced instructions, i.e., create or specify group 822

[0254] 1442: Clear breakpoint or breakpoint range

[0255] Operating Environment

[0256] refer to Figure 1, an operating environment 100 for one embodiment includes at least one computer system 102. Computer system 102 may or may not be a multiprocessor computer system. The operating environment may include one or more machines in a given computer system, which may be clustered in a cloud, client-server networked, and / or peer-to-peer networked. An individual machine is a computer system, as is a group of cooperating machines. A given computer system 102 may be configured, for example, for end users with applications, for administrators, as a server, as a distributed processing node, and / or in other ways.

[0257] Human users 104 can interact with computer system 102 via typed text, touch, voice, movement, computer vision, gestures, and / or other forms of I / O using displays, keyboards, and other peripherals 106. Screen 126 can be a removable peripheral 106, or can be an integral part of system 102. A user interface can support interaction between an embodiment and one or more human users. A user interface can include a command line interface, a graphical user interface (GUI), a natural user interface (NUI), a voice command interface, and / or other user interface (UI) presentations, which can be presented as different options or can be integrated.

[0258] System administrators, network administrators, software developers, engineers, and end users are all specific types of users 104. Automated agents, scripts, playback software, etc. that represent one or more people may also be users 104. Storage devices and / or network devices may be considered peripheral devices in some embodiments and may be considered part of system 102 in some other embodiments, depending on their separability from processor 110. For example, Figure 1 Other computer systems not shown may interact with computer system 102 or with another system embodiment in a technical manner using one or more connections to network 108 via a network interface device.

[0259] Each computer system 102 includes at least one processor 110. As with other suitable systems, the computer system 102 also includes one or more computer-readable storage media 112. The media 112 can be of different physical types. The media 112 can be volatile memory, non-volatile memory, local fixed media, removable media, magnetic media, optical media, solid-state media, and / or other types of physical persistent storage media (as opposed to only propagating media signals). Specifically, when inserted or otherwise installed, a configured medium 114 such as a portable (i.e., external) hard drive, CD, DVD, memory stick, or other removable non-volatile storage medium can functionally become a technical part of the computer system, making its content accessible for interaction with the processor 110 and use by the processor 110. Removably configured media 114 is an example of a computer-readable storage medium 112. Some other examples of computer-readable storage media 112 include built-in RAM, ROM, hard disk, and other memory storage devices that are not readily removable by the user 104. For purposes of compliance with current US patent requirements, under any claim pending or issued in the US, neither the computer-readable medium, computer-readable storage medium, nor the computer-readable memory is a signal per se, or merely energy.

[0260] For example, the medium 114 is configured with binary instructions 116 executable by the processor 110; "executable" is used in a broad sense herein to include machine code, interpretable code, byte code, and / or code running on a virtual machine. The medium 114 is also configured with data 118, which is created, modified, referenced, and / or otherwise used for technical effect by the execution of the instructions 116. The instructions 116 and data 118 configure the memory or other storage medium 114 in which they reside; when the memory or other computer-readable storage medium is a functional part of a given computer system, the instructions 116 and data 118 also configure the computer system. In some embodiments, a portion of the data 118 represents real-world items, such as product characteristics, inventory, physical measurements, settings, images, readings, targets, volumes, etc. Such data may also be converted through backup, restore, submission, abort, reformat, and / or other technical operations.

[0261] Although an embodiment may be described as being implemented by software instructions executed by one or more processors in a computing device (e.g., a general-purpose computer, server, or cluster), this description does not represent an exhaustive list of all possible embodiments. Those skilled in the art will appreciate that the same or similar functions may also be implemented directly in hardware logic in whole or in part to provide the same or similar technical effects. Alternatively, or in addition to software implementations, the technical functionality described herein may be at least partially performed by one or more hardware logic components. For example, and without excluding other implementations, an embodiment may include hardware processors 110, 128, such as field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), application specific standard products (ASSPs), system on chip components (SOCs), complex programmable logic devices (CPLDs), and similar components. For example, the components of an embodiment may be grouped into interactive functional modules based on their inputs, outputs, and / or their technical effects.

[0262] In addition to the processor 110 (e.g., CPU, ALU, FPU and / or GPU), memory / storage medium 112 and display 126, the operating environment may also include other hardware 128, such as batteries, buses, power supplies, wired and wireless network interface cards. The terms "screen" and "display" are used interchangeably herein. The display 126 may include one or more touch screens, a screen that responds to input from a pen or tablet computer, or a screen that is only used for output. In some embodiments, peripheral devices 106 such as human user I / O devices (screens, keyboards, mice, tablet computers, microphones, speakers, motion sensors, etc.) will be in operable communication with one or more processors 110 and memory. The software process may be a user 104.

[0263] In some embodiments, the system includes multiple computers connected by a network 108. The networking interface device may use components such as a packet-switched network interface card, a wireless transceiver, or a telephone network interface (e.g., which may be present in a given computer system) to provide access to the network 108. However, an embodiment may also transmit technical data and / or technical instructions via direct memory access, removable non-volatile media, or other information storage retrieval and / or transmission methods.

[0264] Those skilled in the art will appreciate that the foregoing aspects and other aspects presented herein in the context of an "operating environment" may form part of a given embodiment. The headings of this document are not intended to strictly categorize features into embodiment and non-embodiment feature sets.

[0265] One or more items are shown in dashed form or listed in parentheses in the figures to emphasize that they are not necessarily part of the operating environment shown or part of all embodiments, but can interoperate with items in the operating environment or some embodiments discussed herein. In any figure or any embodiment, items that are not dashed or in parentheses are not necessarily required. In particular, Figure 1 is provided for convenience; Figure 1 The inclusion of an item does not imply that the item or the described use of the item was known prior to the present invention.

[0266] Debugging environment

[0267] Figure 2 A real-time process debugging environment is shown, which is an example of an operating environment 100. The debugger 200 includes various components, many of which are not shown here because many are well known. A primary use of execution control as taught herein may be in environments where real-time process debugging is not feasible or at least not desired. Nevertheless, real-time process debugging is shown for context and because it can be combined with trace-based debugging utilizing execution control as taught herein.

[0268] Debugger 200 may be a conventional debugger, or may be adapted to perform execution control as taught herein. The debugger shown includes a data access component 208 (DAC). In this real-time debugging 1428 environment, DAC 208 communicates with runtime 204 of real-time debug object 202 to obtain memory items 206 by using a primary request 214 to the runtime and a primary response 216 from the runtime. The debugger then updates its user interface 210 accordingly. The user interface presents state information at a relatively high level (e.g., in terms of artifacts defined in source code 212). However, those skilled in the art will appreciate that execution control as taught herein does not require DAC 208 or other adapters.

[0269] Figure 3 A dump debug environment is shown, which is another example of operating environment 100. Debugger 200 uses its data access component 208 or functionally similar code to read memory contents and other state information at a particular point in the execution of the debuggee from dump file 302 or snapshot 304 or both.

[0270] Figure 44. A trace-based debugging environment is shown, which is another example of an operating environment 100. The debugger 200 shown is used in conjunction with or includes (because the scope of the debugger may be defined, for example, by a given developer to include a replay adapter 408) a technical adaptation that permits the debugger to interact with the trace 418 more or less as the debugger is interacting with the runtime. For example, in this example, the same format may be used to Figure 2 1428. However, trace-based debugging 1428 may provide developers with less flexibility than real-time process debugging because variables and other memory contents accessible through the runtime are not necessarily readable from the trace. The granularity of execution control using familiar trace-based debuggers may also be greater than that obtainable through the teachings provided herein. Finer granularity may provide better control during debugging, which may speed up defect location identification and understanding of defects.

[0271] Trace-based debugging with appropriate execution control 402 code, replay component 406, and mapping 404 between trace data and source code 212 can support reverse execution 1422 in the form of reverse replay of the traced execution. In contrast, in just-in-time debugging, the debuggee is typically not executed in reverse.

[0272] The replay adapter 408 is shown to include an interface 410 with a debugger, which in this example presents an API to the debugger that matches at least a subset of the API presented to a conventional debugger by the runtime 204 to support real-time process debugging 1428. Other implementations are also possible. Figure 4408, in some implementations, some or all of the replay adapters may be considered part of the debugger 200 because the debugger is an adapted debugger 200 that includes code that utilizes one or more cross-level mappings 404. For example, one variation implements the main request 214 and the main response 216 and the interface 410 as function calls, returns, and interfaces within the debugger, as opposed to using external messages. In some variations, the debugger includes and utilizes the cross-level mapping 404, and there is no separate replay adapter 408. The debugger DAC 208 may be used to map the address 448 to the high-level object 512. The debugger cross-level mapping 404 and its associated code (i.e., one or more of the execution controller 402, the replay component 406, and the replay adapter 408) may be used to map the source code statement 218 or expression 220 or both to a specific native instruction 434 or native instruction group 822. In some embodiments, similar to dump debugging, DAC 208 has internal knowledge of the runtime and can read runtime data structures to determine where the JIT original code is located for a given set of IL instructions. The machine architecture on which the debuggee is running can be significantly different from the machine architecture on which the debugger is running, but the DAC can be designed to read the runtime data structures and handle the hardware / runtime differences.

[0273] Figure 4 The communication between the replay component 406 and the trace 418 is shown in the form of machine-level requests 414 and responses 416. This is one possible implementation, which can use a trace reader (not shown) to receive and respond to the requests, as an example. However, in another implementation, the machine-level requests 414 and responses 416 are in the form of function calls within the replay adapter 408, including functions that read from the trace 418 and pass back their caller information found in the trace, so that the replay component can maintain current state information, such as which position in the trace 418 is identified by the current instruction pointer 704.

[0274] As shown, trace 418 may be stored in one or more files 420, and may include various types of trace data, as well as metadata that supports or defines searches on the trace data. Some or all of trace 418 may also reside in RAM. Some examples of trace data include bit-accurate trace data 422, such as a copy of low-level instructions and their operands (also called "native instructions"), a time code 424 that can be used to order trace data items relative to each other, a memory snapshot 304 or dump file 302, an index 430 into the raw trace data, key frames 432 inserted into the raw trace data at specified intervals, a copy of code 434 executed 1422 by the debuggee during the trace, stack activity 436, data streams 438 read or written by the debuggee while tracing, processor activity on a per-core 440 or per-socket (multiple cores) 442 basis, thread activity 444 while tracing, register reads and writes 446 while tracing, a tuple 456 associating a memory address 448 with an instruction 450 and one or more values ​​452 and optionally also with a time code 424, and other 454 reads or writes or values ​​or opcodes captured in the trace. In some embodiments, an instance of any of items 216, 422, 434, 436, 438, 440, 442, 444, 446, 456 qualifies as a trace "entry" 458. In some, any minimal portion of trace data 454 that by itself represents a state change of the program being traced qualifies as a trace "entry" 458. The absence of some data in the trace can also be considered state information, such as a gap 428 in the time code sequence.

[0275] Figure 5 Various memories 112 are shown that may be tracked and therefore subject to changes in value or allocation state as performed by the execution of native instructions under control of execution 1422 in accordance with the teachings herein. Examples of memory units 502 shown include a stack 504 (including data such as its base address 506 and the allocated stack frame 508), heap contents 510 such as objects 512, or metadata such as garbage collection data, caches 514, processor registers 516, object members such as attributes 518, addressable units in ROM 520 or RAM 524, removable or third level memory 522, local memory 526, and global memory 528. A memory unit may have one or more characteristics 530 that increase or decrease the accessibility of the memory unit, for example, the memory may be in kernel space, may be shared, may be DMA capable, and so forth.

[0276] Figure 6The contents of a machine level request 414 are shown. As described above, these requests can be implemented using communication data structures, or they can be implemented as parameters to a routine. Some examples of the contents in a machine level request 414 are a memory unit specification 602 and a specification 608 of one or more execution time points 616. The memory unit 502 can be specified as, for example, a single address 448, a range of addresses 606, or a register name 604. The time code 424 can be specified as, for example, an instruction count 610 or a system clock value 612, and the specification can be for a single specific execution time point 616 (a point during a trace, or a specific native instruction) or a range of execution times 614 (i.e., a span or period or interval of execution 1422 time during a trace, or a group of consecutive native instructions).

[0277] Figure 7 The contents of the machine-level request response 416 are shown. As described above, these request responses can be implemented using communication data structures, or they can be implemented as function return values ​​or side effects of routines. Some examples of the contents in the machine-level request response 416 are: the value 702 for one or more memory cells specified in the corresponding request 414; an instruction pointer 704 indicating which instruction will be executed next (or which instruction has just completed execution 1422); and a status code 706, which contains, for example, flags associated with the instruction, or an error, or a condition (such as an end-of-file). Each thread can have a corresponding instruction pointer 704.

[0278] Some trace-replay execution control systems

[0279] Figure 8 A trace-replay execution control system 800 is shown, each of which is a system 102 configured according to the execution teachings provided herein. If the execution control system operates in a real-time debugging environment, it includes a debug object program 124 with a callable runtime 204. Although debugging is used as an example, execution control can also be performed as taught in other contexts herein, for example, for performance analysis or software health monitoring. The debug object or other replayed program includes one or more processes 802, each of which can include one or more threads 804. It will be appreciated by those skilled in the art that the terms "process" and "thread" are used in different ways, such as sometimes as synonyms for each other and sometimes with different meanings. In either case, the execution control teachings provided herein can be applied, because in either of the two meanings of "process" and "thread", the process 802 and the thread 804 have corresponding source code 212 and corresponding traced instructions 434.

[0280] Regardless of whether the replay execution is performed in a real-time debugging environment, the state information of the program being replayed is maintained and updated as the replay execution "proceeds." In this sense, proceeding includes forward execution, backward execution, or both. The state information includes, for example, one or more instruction pointer values ​​indicating the execution time point(s) in trace 418, and the tracked program variable value changes captured in trace 418. To indicate the presence of state information, a block for process(es) 802 is provided in the Figure 8 The state information is shown as solid lines rather than dashed lines inside the debuggee program 124 box. However, those skilled in the art will recognize that the state information may also be maintained inside the execution controller 402 or at one or more other locations in the system 800.

[0281] Execution controller 402 itself includes software executed using processor 110 and memory 112. Tracked program 124 is other software having source code 212 and metadata 808. Execution controller 402 uses source intermediate mapping 810 to map between source code 212 and intermediate representation 826 of the source code. Execution controller 402 also uses intermediate native mapping 812 to map between intermediate representation 826 and trace 418 (including record 814 of native instructions collected from the trace). These mappings 810, 812 are collectively referred to herein as "cross-level mappings". Note that a given embodiment may include one or more cross-level mappings 404, for example, source-to-intermediate and intermediate-to-native functionality may be integrated into a single source-to-native mapping 404.

[0282] In some cases, such as in the case of .NET languages, a source-to-IL mapping 810 is created by a compiler. However, runtimes 204 exist that can directly execute the source language; an example of this is (Trademark of Oracle America Corporation). In this case, the runtime itself compiles the language into an intermediate format and creates a source-to-IL mapping at the same time. In the case of managed languages ​​like .NET languages, the high-level language compiler does not perform the IL-native mapping; instead, the JIT compiler in the runtime 204 does so. Compilers that compile to native code also do not perform the IL-native mapping. In fact, if such a compiler has any form of IL, it is likely an implementation detail of the compiler. In some embodiments, execution control utilizes the IL-native mapping 812 generated by the runtime.

[0283] Some implementations obtain the generated IL from tracing native instructions. For example, some implementations work by emulating a CPU and use native instructions to replay the trace. In some cases, IL alone is not enough information to recreate the native instructions. In some, the native instructions themselves are not enough to implement IL stepping or IL breakpoints. In addition, a mapping between native instructions and IL instructions is used. Some embodiments use mappings without relying on native instructions (which may not even exist in the trace) to implement a debugger that supports stepping through IL code using a trace replayer that does not rely on understanding native instructions. Such an implementation can track the instruction pointer through the range provided in the mapping or through any continuous or non-continuous collection of specified items.

[0284] Supplement on cross-level mapping

[0285] To further illustrate the cross-level mapping 404, consider the following example: some source code 212, a portion of some corresponding intermediate language code used as intermediate representation 826, and a portion of some native instructions. Due to the patent office's restrictions on the inclusion of computer code in patent documents, and because showing a portion is sufficient to illustrate the mapping 404 in the context of the other information provided herein and the knowledge of a person of ordinary skill in the art, only portions of the intermediate language code and native instructions are shown here.

[0286] Original C# source code:

[0287]

[0288] Sample source to IL mapping. This sample is manually generated. The actual implementation is usually not human readable. That is, the source to IL mapping will usually be implemented in binary format rather than text format. Nevertheless, the following material illustrates the source to IL mapping functionality to those skilled in the art. The mapping is not a one-to-one mapping, and some parts of the source code line end up in different locations in the IL code. For a single source program, there are many correctly generated IL transformations.

[0289]

[0290]

[0291]

[0292] Sample IL to native mapping. As with the source to IL mapping, this is generated by hand, and the implementation will exist as a data structure, such as in the runtime. For a single generated IL, there are many correctly generated native code transformations. Because the JIT compiler may have the added complexity of processor-specific optimizations, and because debugging 1428 of a program using trace may not be executed on the same processor type (i.e., different optimizations will be applied), one cannot simply run the JIT on the IL and ensure the same results as if it were run during the generation of the trace 418. In this example, the IL begins with "IL_", and the native is represented as<memory address><hexadecimal representation of native code><assembly mnemonic> .

[0293]

[0294]

[0295] Typically, there is a kernel 120 and in Figure 8 Kernel 120 is explicitly shown in , to help prevent confusion between runtime 204 and kernel 120. The cross-level mapping and execution control described herein assumes that the runtime is present when execution is traced to create trace 418 in most, if not all, configurations.

[0296] Additional Aspects of System 800 and Related Systems

[0297] Some embodiments of the system 800 include a JIT compiler 816 for dynamically compiling code of the traced program 124. Some aspects of execution control address challenges created by JIT compilation, for example by supporting breakpoint ranges 830, which allow breakpoints to be encountered even if native code that spans the location of the breakpoint has not yet been generated by the compilation, as long as the address range that will contain the generated code is known. For example, a breakpoint range 830 can be specified as a range 606 or 614, while an individual breakpoint 828 is specified as a specific single location in the trace 418.

[0298] Continue to refer Figure 8 , some embodiments of system 800 include a return address 820 for call 818. The return address 820 may be used, for example, when performing a reverse step-out execution control operation that steps out of a calling routine in reverse execution.

[0299] Some embodiments improve the accuracy of execution control by providing a more precise correspondence between source code statements or expressions and the instructions that implement them. For example, some familiar methods of tracing playback step into the middle of the instructions that are tracked corresponding to a given source code statement 218 or expression 220, which may cause confusion. Some embodiments described herein positively define a group 822 of tracked instructions corresponding to a given source code statement 218 or expression 220 (e.g., generated by compilation to implement). Then, the execution controller sets the instruction pointer to the position at the edge 824 of the group 822, rather than somewhere in the middle as before. Which edge 824 is selected can depend on whether the execution is forward replay or backward replay, for example, the first forward edge is selected for forward replay, and the first backward edge is selected for backward replay. Alternatively, the same edge can always be used regardless of the replay direction, for example, the instruction pointer is always set at the first forward edge.

[0300] Fig. 9 Several execution control operations 618 are shown. For example, a control operation request 806 is presented to the debugger 200 or other tool 122 by a user through the user interface 210. The execution controller 402 converts the control operation request 806 into a change in the state of the process 802. The operations shown include step forward 902, step forward into 904, step forward skip 906, step forward exit 908, continue forward 910, step backward 912, step backward into 914, step backward skip 916, step backward exit 918, continue backward 920, set breakpoint range 922, and set breakpoint 924. In these operation names, "forward" means forward execution replay, and "backward" means backward execution replay.

[0301] Various stepping operations 902-920 can be implemented so that from the perspective of the developer, operate in a similar or identical manner to familiar similar or identically named operations. However, for example, internally, they can be implemented by being used to place innovations that align source code with tracking using cross-level mapping 404, instruction groups 822, and specific breakpoints. Continue operations 910, 920 can also be implemented so that from the perspective of the developer, operate in a similar or identical manner to familiar continue operations, and internally, they utilize cross-level mapping 404 or instruction groups 822 or both. Set breakpoint operation 924 can also be implemented so that from the perspective of the developer, operate in a similar or identical manner to familiar operations that set breakpoints with the developer, and internally, it utilizes cross-level mapping 404 or instruction groups 822 or both.

[0302] Fig.10Thread 804 activity information 444 is shown that may be captured in a given trace 418. Thread identifier 1004, thread state indication 1006, executable code 1008 for the thread, and memory unit 502 state information 1010 such as thread local variables and their identifiers are shown.

[0303] Fig.11 Some examples of intermediate representations 826 are shown. The examples shown include a symbol table 1102 that associates source code identifiers 1104 (variable names, function names, object member and method names, etc.) with data types 1106 (e.g., integers, floating points, strings, Booleans, and user-defined types). Another example is an abstract syntax tree 1108. Some other examples include code 1112 written in one or more intermediate languages ​​1110. More generally, some embodiments use an intermediate representation 826 that shares the structure of, or even a copy of, an intermediate representation created by a compiler. However, the intermediate representation 826 is placed in the context of an execution controller that is opposite to the context of the compiler. Moreover, the intermediate representation 826 is used for trace replay of the execution trace 418 of previously generated code, rather than being used to generate the code in the first place.

[0304] The technician will recognize that a given source code 212 can potentially be used to generate many different versions of the corresponding IL. However, only one of these versions will be used in the program, and the symbol information issued by the compiler will correspond to the issued IL. The debugger can be designed to only load the corresponding symbol information, so there will be only one mapping. In some systems, multiple versions of the native code for a given routine can be included in the runtime, for example, the optimized production version and the non-optimized version of the native code for debugging can all exist, or the multi-layer JIT functionality can provide multiple versions of the native code in the memory. In such a multi-native version system, replay can still be completed. For example, when a breakpoint is set, it can be set in all existing versions of the native code. Some embodiments use the native code and IL code generated by JIT, which are obtained from or via tracking 418. Some embodiments also use corresponding symbol information for source / IL mapping, which may or may not be included in the same tracking file 420.

[0305] Fig.12 yes Figure 2 A variation of . Fig.12In an environment of , both real-time debugging and replay execution are supported. Replay is supported by a rolling trace 418, which records the forward execution of the real-time debug object in real time while the debug object executes according to the prompts of the debugger 200. For efficiency, only a pair of buffers, for example, are used to track the latest instructions. The trace 418 is written to one buffer until it is full, then written to the other buffer until it is full, then written back to the first buffer (overwriting the earlier trace), and so on. Alternatively, instead of a rolling window, all execution activity during the debugging 1428 session can be traced. As another alternative, previously recorded traces 418 can be accessed during a real-time debugging session.

[0306] Some additional system examples

[0307] Examples are provided herein to help illustrate various aspects of the technology, but the examples given in this document do not describe all possible embodiments. The embodiments are not limited to the specific implementations, arrangements, displays, features, methods, or scenarios provided herein. A given embodiment may include, for example, additional or different technical features, mechanisms, sequences, or data structures, and may otherwise depart from the examples provided herein.

[0308] refer to Figure 1-Figure 2 , some embodiments use or provide a trace-replay execution control system 800. The system includes a processor 110, a memory 112 in operable communication with the processor, and a trace 418 recorded during execution of a program 124 in conjunction with a runtime 204 and a kernel 120. The trace includes a record 814 of native code instructions 116 executed in at least one thread 804 of the program. There is also source code 212 for at least a portion of the program.

[0309] The system 800 also includes a source intermediate map 810 that maps between source code and an intermediate representation 826 of the source code, and an intermediate native map 812 that maps between the intermediate representation 826 and the trace 418 .

[0310] System 800 also includes execution controller 402 in software tool 122. Execution controller is configured to control replay execution of trace 418 when executed with a processor in response to request 806. In replay execution, source code is associated with trace native code instructions or other trace entries through source intermediate mappings and intermediate native mappings.

[0311] In some embodiments, execution controller 402 is configured to convert requests for at least the following operations 618 into corresponding executions of trace native code instructions: forward execution step into 904 operation, forward execution step out 908 operation, and forward execution step skip 906 operation.

[0312] In some embodiments, execution controller 402 is configured to convert requests for at least the following operations 618 into corresponding executions of traced native code instructions: backward execution step into 914 operation, backward execution step out 918 operation, and backward execution step skip 916 operation.

[0313] In some embodiments, the execution controller 402 is configured to convert a request for at least the following operations 618 into corresponding executions of traced native code instructions: continuing forward execution 910 in the trace until any location in the breakpoint range 830 is reached, and continuing backward execution 920 in the trace until a location in the breakpoint range is reached.

[0314] In some embodiments, system 800 is configured to step into a portion of source code that has not yet been compiled into native code instructions during replay execution.

[0315] In some embodiments, the intermediate representation 826 includes at least one of: a symbol table 1102 that associates at least two identifiers 1104 used in the source code with a data type 1106, an abstract syntax tree 1108 derived from at least a portion of the source code, or a conversion 1112 of at least a portion of the source code 212 into an intermediate language 1110.

[0316] In some embodiments, trace 418 does not include any execution instance of runtime 204, and trace 418 is not configured to invoke trace to execute any code specific to the runtime.

[0317] In some embodiments, system 800 includes a real-time debug object 202 having a program 124 of a callable instance at runtime. In some embodiments, a trace 418 is recorded from a real-time process and the system is configured to replay the execution of the trace.

[0318] In some embodiments, the system 800 is configured to skip replaying execution of a portion of the trace 418 because the execution controller 402 moves the replay execution from a first execution time point in the trace to a second execution time point in the trace, and the system does not execute traced native code instructions or other trace entries that would have been executed by continuing execution from the first location to the second location.

[0319] Those skilled in the art will appreciate that some other systems are also within the scope of the teachings presented here. In particular, some other systems can perform cross-level mapping 404, use breakpoint ranges 830, and implement other teachings provided herein, while departing from the specific examples described herein. Systems or devices that use any of the execution control teachings taught herein are within the present disclosure, regardless of whether they are in the specific examples provided.

[0320] Some method examples

[0321] Fig.13 An execution control method 1300 is shown, which is an example of a method performed or assisted by an execution controller 402, a cross-level mapping 404, or other items discussed herein. The example method includes identifying 1302 a tracked managed program as a tracked managed program. Identifying a program as tracked is simple; if a program is being tracked, or has been tracked before, then the program is a tracked program. To some extent, it is more about identifying a program as managed because it is managed when the program relies on the runtime 204 for real-time execution and the runtime 204 can provide different services in different implementations. In many cases, the runtime 204 provides automatic management of heap memory through garbage collection based on reachability analysis or reference counting or other mechanisms. However, what is more interesting in this application is the use of the runtime 204 to execute intermediate language code 1112. In some runtimes, the conversion from source to native instructions is not modularized into a source to intermediate language stage, followed by an intermediate language to native code stage. For example, some The platform directly executes source code (a trademark of Oracle Corporation of America). For purposes of this application only, a "managed" program is a program that relies on the runtime 204 to generate native instructions. Managed programs may or may not also be subject to garbage collection by the runtime.

[0322] The illustrated method 1300 also includes receiving 1304 a request for a trace replay execution control operation. The request may be a request 806 directly from a user through a user interface, or a request 214 to a trace execution controller 402, 406, or 408 from a debugger.

[0323] The method 1300 shown also includes a mapping 1306 from source code to intermediate representation and a mapping 1308 from intermediate representation to native code. This can be done in two stages as indicated, or in some other embodiments, can be done in a single combined stage from source code to native instructions. However, unlike the compilation itself, whether in two stages or in one stage, the mappings 1306, 1308 are not for generating code for execution, but rather for associating source code locations with locations in a trace of previously generated and executed instructions.

[0324] Some implementations map 1306 from source code to an intermediate representation by using a symbol file that contains a hash value, checksum, or other identifier of the IL that corresponds to the source. If the identifiers correspond, the debugger will load the symbol file. The symbol file also contains identifiers for each source file used to compile the IL. Before the debugger is about to load a source file and map the IL code to the source, it will verify the identifiers of the source file using the identifiers contained in the symbol file.

[0325] When the IL is just-in-time compiled (JIT), some implementations use a mapping generated by the runtime to map 1308 from the IL to native code. In some implementations, the runtime may not guarantee to retain backward compatibility about how the JIT will occur, so the JIT process can be freely changed at any time. In such an implementation, the debugger may not be able to make assumptions about what the native code output by the JIT process will contain. Therefore, the debugger can require the runtime to provide a mapping between native code and IL.

[0326] Some variations of the illustrated method 1300 include aligning 1318 groups of native instructions with source code statements or expressions from which the native instructions were generated by compilation.

[0327] The method 1300 shown includes controlling 1310 replay, that is, completing "execution control". An example of control 1310 is executing 1312 native instructions or other trace entries corresponding to stepping, stepping into, stepping skipping, stepping out or continuing operations, thereby changing the state of process 802. Another example of control 1310 is setting 1314 individual breakpoints or breakpoint ranges. Those skilled in the art will recognize that performing stepping, stepping into, stepping skipping, or stepping out operations involves setting breakpoints, but breakpoints can also be set without executing native instructions or other trace entries, for example, when preparing for continuing operations. In some embodiments, the code itself is not modified to set breakpoints in tracing. The technician will recognize that the processor can set execution breakpoints via instructions (e.g., int3 in some Intel architectures) or via hardware breakpoints (registers that say which address to monitor). In some embodiments, the trace replay execution control system 800 provides similar capabilities. Some implementations do not modify the code flow and support an arbitrarily large number of breakpoints.

[0328] Finally, the illustrated method 1300 includes sending 1316 a response to the request, such as response 416 or another message or data structure containing instruction pointer 704 or status code 706 .

[0329] Fig.14Some additional execution control steps that may be performed in some embodiments are shown. Some familiar debuggers do not support the step backwards exit operation 918. However, some embodiments identify 1402 a request for the step backwards exit operation 918 and implement the operation as taught herein.

[0330] The debugger may implement some commonly familiar breakpoint operations, i.e., operations for setting 1314 breakpoints. However, some embodiments set 1314, 1404 breakpoints immediately before the indicated location. Some embodiments set 1314, 1406 breakpoints at instruction group edges 824. Some embodiments set 1314, 1408 breakpoint ranges 830, for example, on address ranges designated for receiving just-in-time compiled code (code generated by a JIT compiler). In particular, some embodiments set 1434, 1314, 1408 large breakpoint ranges 1436, 830. Some embodiments set 1314, 1410 breakpoints as part of implementing a step-bypass operation to step-bypass runtime routines that may not be of much interest to the developer. For example, such runtime routines may perform garbage collection, JIT compilation, anti-malware or other security checks, or runtime 204 housekeeping functions. Fig.14 Other steps shown are discussed elsewhere in this document or are included for completeness, for example, not only can breakpoints be set, but also 1442 breakpoints can be cleared.

[0331] Unless otherwise noted, the technical methods shown in the accompanying drawings or otherwise disclosed will be automatically executed by, for example, system 800. In the scope of the action involving a human administrator or other human beings, the method can also be partially automatically and partially manually executed, for example, a person can select 1426 source code statements or expressions, and then use the tool 122 user interface to request stepping operations or breakpoint operations. However, it is not considered that the method as an innovation is completely manual. In a given embodiment, zero or more example steps of the method can be repeated, possibly with different parameters or data to be operated. The steps in an embodiment can also be performed in a different order from that shown in the figure. Steps can be performed sequentially, in a partially overlapping manner or completely in parallel. The order of executing steps during a given method can change from the execution of one method to the execution of another method. If the method performed is operable and meets at least one claim, the steps can also be omitted, combined, renamed, regrouped, or otherwise deviate from the flow shown.

[0332] Some embodiments use or provide a computer-implemented method for tracing a replay execution control method. An example method includes identifying 1302 a managed program being traced, i.e., a program that is configured to execute in conjunction with a call to a runtime and is configured to be traced. The example also includes receiving 1304 a trace replay execution control request in a software tool running on a computing system. Based on the trace replay execution control request, the example method automatically maps 1306 between source code of the traced managed program and an intermediate representation of the source code, and automatically maps 1308 between the intermediate representation and a trace 418. The trace includes a record of native code instructions that are traced when the traced managed program is executed. The trace 418 does not include any execution instances at the runtime. The example method also executes 1312 trace native code instructions corresponding to the trace replay execution control request, thereby replaying a portion of the trace.

[0333] In some embodiments, the trace replay execution control request identification 1402 performs a step-out operation backward to step out of the routine, and the method includes setting 1314, 1404 breakpoints on the traced native code instructions, which have a position immediately before the position of the return address of the call to the routine. For the purpose of the method, when 1412A is encountered before B during the forward execution of the trace and there are at most five traced native code instructions between A and B, position A is "immediately before" position B in the trace. For the purpose of the method, when performing source-level debugging, alignment 1318 can associate the instruction group edge 824 with the most recently executed source file line number, statement or expression executed before calling the current function. Some embodiments set a breakpoint at the call location of the routine, for example, some embodiments set a breakpoint at the call location of the current function.

[0334] Typically, the source code includes statements 218 and expressions 220. In some embodiments, the method includes setting 1406, 1314 a breakpoint on a traced native code instruction 116, the breakpoint being on an edge 824 of a group 822 that includes all traced native code instructions, all traced native code instructions being mapped by the method to a given statement or a given expression in the source code. In some implementations, the group includes only all traced native code instructions, and may also include other instructions.

[0335] In some embodiments, the received trace replay execution control request 806, 214, 414 names, identifies, or otherwise invokes replay performance based on one of: performing a forward step skip 906 operation to step forward through a routine; performing a backward step skip 916 operation to step backward through a routine; performing a forward step enter 904 operation to step forward into a routine; or performing a backward step enter 914 operation to step backward into a routine.

[0336] In some cases, the received trace replay execution control request 806, 214, 414 names, identifies, or otherwise invokes a replay capability to step into a user code routine according to a forward execution step into 904 operation, and the replay execution of the user code routine includes the replay execution of at least one call 818 to a runtime 204 routine, and the call to the runtime routine has no corresponding call statement or call expression in the source code. In this context, some embodiments include at least one of the following: setting 1408 a breakpoint range that specifies the entire memory range designated to receive the dynamically compiled code, or setting 1410 a breakpoint to perform a step over operation on the call to the runtime routine.

[0337] In some embodiments, the forward stepping into step 904 operation is performed as follows. The debugger 200 configured according to the teachings herein maps 1306 the source line range to the intermediate language range, and maps 1308 the intermediate language range to the native range. The debugger then performs this step using low-level primitives; this can be done using instruction-level single-stepping or breakpoints. When a call 818 instruction is encountered, the debugger determines whether the target is a high-level source step that represents stepping into at the source level, or a detail of the runtime implementation that should not be stepped into because it is not clearly indicated in the source code. For example, this determination can be completed by querying the runtime or by searching the source code for the name of the calling routine. If the call is for a different high-level (shown in the source code) routine, the debugger queries the runtime 204 (e.g., via DAC 208) to determine whether the calling routine has been JIT compiled. If the calling routine has been JIT compiled, the debugger uses instruction-level single-stepping into the call or by setting a breakpoint inside the target routine to step into the call 904. If the calling routine has not been JIT compiled, the debugger will use DAC 208 or another mechanism to set a breakpoint on the JIT compiler or on the target address area written by the JIT compilation using (multiple) data breakpoints. The debugger allows the trace replay to run until the JIT compilation is completed. The debugger sets a breakpoint on the JIT compiled target and runs. This continues until the native instructions no longer fall within the native stepping range mapped from the initial action above, or the program exits. An exception is a special case that should fall on the target of a catch.

[0338] In some embodiments, the trace replay execution control request invokes at least one of the following operations: continue tracing replay execution forward 910 in trace until breakpoint 828 is reached; continue tracing replay execution forward 910 in trace until a location in breakpoint range 830 is reached; continue tracing replay execution backward 920 in trace until breakpoint 828 is reached; or continue tracing replay execution backward 920 in trace until a location in breakpoint range 830 is reached. Some embodiments also include other operations that may be invoked in the request, including, for example, one or more of the following: perform step into backward 914 operation; perform step out backward 918 operation; perform step skip backward 916 operation; perform step into forward 904 operation; perform step out forward 908 operation; perform step skip forward 906 operation. More generally, a given embodiment may be limited to any subset of the operations taught herein.

[0339] In some cases, the maximum number of breakpoints is constrained by a hardware breakpoint constraint that the processor can monitor at most N addresses at a time during execution of the traced managed program to create the trace 418. However, in some embodiments, the method sets 1314 more than N breakpoints during replayed execution of the trace, thereby exceeding 1414 the hardware breakpoint constraint.

[0340] Those skilled in the art will appreciate that other methods are also within the scope of the teachings presented here. In particular, other systems can perform cross-level mapping 404, use breakpoint ranges 830, and implement other teachings provided herein, while departing from the specific examples narrated herein. The methods of using any execution control teachings taught herein are within the present disclosure, regardless of whether they are in the specific examples provided.

[0341] Some examples of configured media

[0342] Some embodiments include a configured computer-readable storage medium 112. The medium 112 may include disks (magnetic, optical or otherwise), RAM, EEPROMS or other ROMs and / or other configurable memory, particularly including computer-readable media (which do more than just propagate signals or energy). The configured storage medium may be, in particular, a removable storage medium 114, such as a CD, DVD, or flash memory. General purpose memory (which may be removable or non-removable, and may be volatile or non-volatile) may be configured as an embodiment: items such as the execution controller 402, the replay adapter 408, the instruction group 822, the cross-level mapping 404, the machine level request 414 and response 416, and the breakpoint range 830 are used in the form of data 118 and instructions 116 read from the removable medium 114 and / or another source such as a network connection to form the configured medium. As disclosed herein, the configured medium 112 is capable of causing a computer system to perform technical processing steps for horizontal crossover (high level in the tool 122 to low level in the trace 418) replay execution control. Thus, the drawings help illustrate the configured storage medium embodiments and process embodiments, as well as system and process embodiments. In particular, Figure 4 , 13 Or 14 or any processing step otherwise taught herein may be used to help configure the storage medium to form a configured medium embodiment.

[0343] Some embodiments use or provide a computer-readable storage medium 112, 114 configured with code that, when executed by a computer processor 110, performs a trace replay execution control method. In this example, the trace replay execution control method includes receiving 1304 a trace replay execution control request in a software tool running on a computing system. The method includes mapping 1306 between source code of the managed program being traced and an intermediate representation of the source code, and mapping 1308 between the intermediate representation and a trace 418 based on the trace replay execution control request. The trace 418 includes a record of processor activity, such as native code instructions being traced when the managed program being traced is executed, because the trace does not include any execution instances at runtime. In this example, the trace replay execution control method also includes executing 1312 a trace native code instruction or other trace entry corresponding to the trace replay execution control request, or setting 1314 a breakpoint on the trace native code instruction, thereby controlling 1310 the replay of the trace.

[0344] Some embodiments operate in combination with a debugger 200, and in some of these cases, the traced managed program includes a real-time process and an execution runtime 204. The debugger 200 communicates with the execution runtime 204 of the traced managed program without 1416 terminating 1418 the traced managed program, and the method controls 1310 backward execution replay using the trace 418. That is, in this example, reverse debugging is intertwined with real-time process debugging.

[0345] Some embodiments perform one or two or three or all four of the following activities of particular interest. One particularly interesting activity is to control 1420 the execution of the runtime 204 at a high level using the machine level information in the trace 418. In this context, controlling "at a high level" means controlling (obtained 1424 from the user 104 via a user interface) based on user selections 1426 that specify identifiers or statements or expressions in the source code. In this context, "machine level" information refers to information specific to the processor architecture, such as a specific instruction set or a specific microarchitecture.

[0346] Another particularly interesting activity is debugging 200 both forward and backward execution of a live debug object 202, 802 of a managed program that is traced by the managed program.

[0347] Another particularly interesting activity is to step into the call shown in the source code at least in part by setting 1434 a large breakpoint range 1436. In this case, the breakpoint range is "large" when it covers at least one thousand consecutive addresses or instructions in the trace 418.

[0348] Another particularly interesting activity is tracing 418 trace data from a real-time process while debugging 200 a real-time debug object 202 of a traced managed program, and then performing reverse execution debugging of the real-time process using at least some of the recorded trace data.

[0349] Those skilled in the art will appreciate that other configurations of media embodiments are also within the teachings of the present invention. In particular, some other embodiments may include legal media configured with codes for performing cross-level mapping 404, using breakpoint ranges 830, and implementing other teachings provided herein when executed, while departing from the specific examples described herein. Media configured to perform methods using any execution control teachings taught herein are within the present disclosure, regardless of whether they are in the specific examples provided.

[0350] Example with JIT code

[0351] Assume that the source code includes a class similar to the one shown below in C#:

[0352]

[0353] If the language is C++, the developer would reasonably expect that the call to WiggleLeg() in Squid.Swim() can be compiled into the following form (similar to assembly code):

[0354] CALL 0x0c84fabd; 0x0c84fabd is the address of Squid::WiggleLeg()

[0355] In this case, 0x0c84fabd will begin the implementation of Squid::WiggleLeg(). But in the managed software executing in runtime 204, this is not the case. The code run by runtime 204 is compiled "just in time", aka "jit". If this is the first time Squid::WiggleLeg() is called, there will be no machine instruction 116 for Squid::WiggleLeg(). It has not been compiled yet. So, instead of having machine instructions implementing Squid::WiggleLeg(), 0x0c84fabd will have some instructions that look like this (in pseudocode):

[0356]

[0357] This bit of code is called "pre-pile". The compilation process is long and complicated, so usually, developers who try to analyze or debug applications by tracking and using tracking do not want to record the compilation process in detail. However, tracking 418 may record at least a portion of the pile, even if these tracked instructions may not arouse the interest of the person debugging the code. In real-time process debugging, this part of the code will usually be skipped at runtime. However, when debugging only from tracking 418, the runtime 204 of the debug object will not execute, so the pre-pile cannot be skipped. On the contrary, an embodiment can utilize the functionality of the out-of-process debugging utility that is usually used to read the data in the dump file 302, and the innovative tracking replay functionality that can be used together to find the address range of all JITTED codes at runtime. After receiving a request to step into a method call, an embodiment can temporarily set 1314 breakpoints on the JITTED code range, and virtually execute forward (that is, replay forward) until the first JITTED code range is read. Once read, the embodiment can remove the breakpoints. In this way, developers can skip all these "pile" codes that are not interested. Some embodiments also optimize this method by targeting the address range of the breakpoint to only the scope of Squid::WiggleLeg_implementation.

[0358] Some additional combinations and variations

[0359] Any of these combinations of code, data structures, logic, components, communications, and / or their functional equivalents may also be combined with any of the above systems and variations thereof. A process may include any of the steps described herein in any subset or combination or sequence that is operable. Each variation may occur alone or in combination with any other one or more other variations. Each variation may occur with any process, and each process may be combined with any one or more other processes. Each process or combination of processes (including variations) may be combined with any of the above media combinations and variations.

[0360] In some embodiments, the trace replay component uses source-IL mapping and IL-machine mapping to convert between trace file 420 locations (eg, indicated by time codes 424) and locations in source code 212 (eg, indicated as line numbers).

[0361] In some embodiments, a portion of the runtime functionality is provided in the trace playback component 406. However, the runtime is not Figure 2 Rather than mediating between the debugger, user code, and the operating system as in the real-time process of FIG. 4 , the runtime functionality mediates between the debugger and trace file(s) 420.

[0362] Some trace recording processes record only two types of data. One type of data recorded is the execution of code instructions 116, which may be executed in parallel on multiple threads. Another type of data recorded is a snapshot 304 of a particular block of memory taken at a discrete point in execution time, for example to capture a portion of a stack. However, other trace processes record different or additional types of data, such as Figure 4 As shown. In some cases, the trace contains an efficient representation of all recorded instructions and all of their inputs and outputs. The recording of trace 418 can be made efficient by relying on the determinism of the (multiple) processors 110 and recording primarily information that cannot be inferred based on that determinism and information that has already been recorded in trace 418. In some implementations, most of trace 418 is data, not the executed code instructions; such data is typically uncertain. The trace can be primarily seed data plus uncertain information. In some cases, only information that enters the cache of the (multiple) processors being traced is recorded in trace 418, for example, reading a value V into a processor cache is entered into the trace, but writing a value V from a processor's register to a memory location X is not necessarily entered into the trace. If a write to X makes a difference in the behavior of the program being traced, it is because at some point the written value is returned from X to the processor register, at which time, if tracing is still enabled, the entry in trace 418 can be realized.

[0363] The execution control of a high-level program from a process trace is described herein using examples, diagrams, definitions, and other descriptive material. A skilled artisan will recognize that a trace of a process can be created at the machine level using a variety of techniques, such as when running Microsoft Windows Event Tracing (ETW) or "Time Travel Tracing" for tracing on systems in an environment, Tracking on the environment's system (trademarks of Efficios and Linus Torvalds, respectively), Environment tracking (trademarks of Oracle America Corporation and X / Open, Inc., respectively), and other tracing techniques. The trace can then be replayed using emulation of the hardware. Sometimes the procedure is written in a high-level language that requires a runtime framework to actually execute the procedure. An example of this is a .NET application running in the Common Language Runtime (CLR). Moving forward or backward in a trace This, by itself, is not helpful to the developer of a high-level program because the view of the trace is that of the runtime or just-in-time compiled code rather than that of the high-level program. This document describes a method for mapping machine-level instructions in a trace to high-level operations in a program. This allows breakpoints to be set and reached as well as forward and reverse stepping in a high-level language.

[0364] The process of stepping through the code in a high-level runtime can be achieved by abstracting the complexity into three layers. At the lowest layer (layer 0) is the process trace 418. The trace contains enough information to allow simulation of the recorded process execution at the hardware level.

[0365] At Tier 1, a suitably configured system can apply some very basic hardware debugging support to replay a trace. This support can include: being able to play the procedure forward or backward, read procedure memory, read thread context (per thread), set hardware breakpoints, and single-step machine instructions per thread.

[0366] In layer 2, support is provided for mapping a range of machine instructions to a range of high-level virtual machine (VM) instructions or another code. The operations in layer 1 can be used to debug high-level code. In some configurations, the operations to be supported are run forward, run backward, set breakpoints, step into, step out, and step skip. In an example, details about the implementation of each operation are given below.

[0367] Regarding running forward and backward, in this example they are equivalent in the high level and machine level runtimes, so this is handled entirely in layer 1.

[0368] Regarding breakpoints, in this example, breakpoints are set by using a mapping defined in layer 2 to map high-level breakpoints to hardware breakpoints. When a hardware breakpoint is encountered, the implementation can use the mapping to map the hardware breakpoint back to a high-level breakpoint.

[0369] Regarding forward and reverse stepping out, by using the stack trace, the implementation can set a hardware breakpoint at the return address of the function. To implement reverse stepping out, the breakpoint is set on the instruction before the return address.

[0370] About forward and reverse stepping skip, can realize stepping skip by looking at the next instruction to be executed.Depending on the instruction, the implementation can use the 1st layer to either perform single stepping or set breakpoint and run until it is reached.The "call" instruction is an example of an instruction that needs a breakpoint.Most other instructions can use single stepping.Different from some familiar methods, this example debugger implementation can use the mapping in the 2nd layer to repeat the stepping operation until the instruction pointer or code execution time point is located at the appropriate stopping point in the high-level runtime.This inspires the discussion of instruction group 822 elsewhere in this article.

[0371] Regarding backward stepping into, to perform backward stepping into, the implementation uses the stepping operation defined in layer 1. If the machine has just returned from a call instruction, this use will return the execution time point to the return instruction of the previous call. If the machine has not just returned from a call, the machine will simply step back to the previous instruction. As with stepping over, the implementation can use the mapping in layer 2 to know when execution is at the stopping point, and may need to step multiple times to align the execution trace with the source code 1318.

[0372] About forward stepping into, in this implementation, forward stepping into is similar to reverse stepping into. However, if the high-level runtime needs to perform work that is not directly related to the high-level code being run, difficulties may arise. Some examples are real-time compilation, runtime housekeeping, and stepping operations that need to be solved by the runtime (transparent proxy in .NET is an example of this solution challenge). Any one or all of the following can be implemented to solve these difficulties. One option is to set a large breakpoint range for all codes compiled in real time when starting stepping into. If this breakpoint is encountered after stepping into, then the implementation can complete this step when arriving at the next stopping point. Another option is to implement logic in the stepping engine to fully understand the runtime, thereby knowing when to step over a call and when to step through a call, so that the implementation can stop stepping at the appropriate point in the high-level runtime.

[0373] In some embodiments, out-of-process execution control controls the execution of IL instructions by using, for example, functionality provided by replay component 406 and IL to address mapping 812. Functionality provided by replay component 406 or other execution controllers 402, 408 for execution control includes:

[0374] Get the status of all threads (register values)

[0375] Step forward or backward one instruction

[0376] Runs forward or backward until the instruction pointer reaches the specified address set.

[0377] The IL to address mapping exists in the memory image of the procedure or trace, and the replay layer can provide it to the out-of-procedure execution control debugger. One view is that this example includes converting IL-level debugging to machine-level debugging.

[0378] Some implementations support applying high-level execution control to the trace using source-to-IL mapping 810, IL-to-native mapping 812, native-style out-of-procedure execution control, and the ability to walk forward and backward in the trace 418, by stepping into individual instructions, or running forward and backward in the trace until a specific instruction address is reached.

[0379] Consider the example of real-time process debugging

[0380] As a further illustration of trace-based execution control, consider some of the ways in which a particular embodiment may be similar to or different from real-time debugging. Several components are referenced below, and those skilled in the art will understand their relationship to other examples provided herein, and in particular will understand that functionality may be grouped into different components for the sake of understanding or ease of implementation without departing from the execution control teachings provided herein. The system 800 components discussed in this example include:

[0381] User interface (UI). A user interface that graphically displays to the user a representation of the debugger's program state. Examples of program state are a list of threads, the next line of source code to be executed on each thread, a call stack for each thread, a collection of variables in each frame of the call stack, the values ​​of those variables, etc.

[0382] Source conversion. A source code conversion portion that is responsible for converting between runtime abstractions and source code level abstractions. For example, the CLR runtime uses IL instructions encoded in a binary file format to represent code, while C# source code has a syntax of text statements. As an example, this layer of the debugger can convert between the runtime abstraction layer (e.g., defined in the ECMA-335 standard, Common Language Architecture (CLI) 6th Edition (June 2012) or its subsequent version) and the C# abstraction layer (e.g., defined in C# Language Specification Version 5.0 or its subsequent version).

[0383] Runtime conversion.The runtime conversion part of the debugger is responsible for converting between low-level concepts (such as memory and registers) and runtime abstractions. Examples of runtime abstractions include a list of threads, a call stack for each thread, and the IL instructions to be executed next. Note that the call stack at the abstract runtime layer does not have to be the same as the call stack at the abstract source code level. In the case of real-time debugging only, in order to assist in completing some tasks, this layer uses an inter-process communication mechanism to request the runtime within the process being debugged to perform work. For example, in order to set a breakpoint at the IL instruction in method Foo at offset 28, this layer will send a message to the runtime to ask it to set a breakpoint at Foo at offset 28. Then, the thread within the runtime will receive the message, convert Foo IL offset 28 to a machine instruction residing at memory address 0x4567123512395, and then write a breakpoint instruction at this location. It is reasonable to regard the part of the runtime that serves those requests as also functionally located within this layer of the debugger, even if it is implemented in a different process.

[0384] Base. The low-level part of the debugger is responsible for using the kernel, or dump files, or traces to generate memory and registers to be read by the runtime translation part. For kernel processes, this is implemented in some environments through an API (such as ReadProcessMemory). For trace files, it supports parsing the file and establishing a mapping between time t and the set of memory and register contents recorded at that time.

[0385] With these components in mind, consider the case where a breakpoint is set and the program is executed forward until the breakpoint is reached. One view is that real-time process debugging generally involves the following actions.

[0386] Action 1. User interface. The user clicks the mouse on a displayed source code line to indicate where a breakpoint should be set.

[0387] Action 2. Source transformation. Source code lines are transformed into specific methods and IL instruction offsets.

[0388] Action 3. Runtime conversion. The message is sent to the runtime, and then within the runtime, the method + IL instruction offset is converted to a memory address. Then, the breakpoint opcode is written there.

[0389] Action 4. User interface. The user clicks a button in the UI, indicating that they want the process to run.

[0390] Action 5. Source transformation. Forwards the request to run.

[0391] Action 6. Runtime conversion. A message is sent to the runtime 204, requesting it to execute forward. Upon receiving the message, the runtime will execute forward and then reach the breakpoint at the specific memory address set earlier. The memory address of the breakpoint is converted back to a method and IL offset, and then a notification message is sent back to the debugger indicating that the breakpoint at the specific method / IL offset has been reached.

[0392] Action 7. Source conversion. The message that the breakpoint was reached is converted from the method and IL offset back to the source line, and a notification is continued to be sent to the UI that the breakpoint at that source line was reached.

[0393] Action 8. User Interface. The UI requests additional information about the new state of the process so that it can display current state information to the user, such as the current call stack for each thread.

[0394] Action 9. Source transformation. To provide the source abstraction of the call stack, the component first requests the runtime abstraction of the received call stack.

[0395] Action 10. Runtime Transformation. To provide a runtime abstraction of the call stack, the component first requests to receive the state of memory and registers.

[0396] Action 11. Basics. Determine the memory and registers at the current time.

[0397] Action 12. Runtime transformation: Using memory and registers, compute a runtime abstraction of the call stack.

[0398] Action 13. Source transformation: Using the runtime abstraction of the call stack, calculate the source code abstraction of the call stack.

[0399] Action 14. User Interface. Using the source code abstraction of the call stack, the UI can now display the current state of the debugged process to the user.

[0400] In some embodiments, when using trace actions 3, 6, and 11, it no longer operates in the same way. For actions 3 and 6, no process can receive messages to set breakpoints, to execute forward, or to send notifications back when breakpoints are reached. For action 11, no process can use the kernel API to query to determine memory or registers.

[0401] Therefore, in some embodiments, to implement action 3 above, the source conversion code requires the runtime conversion code to indicate which memory address X has the machine code for a given method + IL offset where a breakpoint should be set. This address X is saved for later use.

[0402] To implement the above-mentioned action 6, in some embodiments, the source conversion code directly instructs the low-level infrastructure of the debugger or (multiple) other tools to advance the trace to a new time t', t' being the next time point at which the machine instruction at address X will be simulated or emulated to execute. For action 6, an embodiment can use the same process commonly used in dump debugging to convert from IL offsets to process memory offsets. However, this embodiment uses the converted memory offsets to set virtual breakpoints inside the trace replay engine. When the replay engine reads the memory address during virtual execution, the virtual process (replay execution) will stop. Indeed, if the trace contains more than one version of the same function (via re-jitted), the runtime conversion may require the trace to provide multiple addresses to cover a single breakpoint. For different time ranges in the trace, the address can be a different address, or it can be the address of a runtime function (such as a jitting function) so that the runtime conversion can locate the location of the new re-compilation of the function.

[0403] To implement action 11 above, instead of reading from the real-time process, the trace 418 is read and the memory and registers corresponding to the time t' are provided.

[0404] Replay debugging scenario

[0405] By providing access to forward and backward execution when debugging, system 800 can enhance debugging efficiency.For example, some embodiments support the following debugging scenarios.

[0406] By way of context, technicians will realize that production debugging is difficult. Assume that a customer reports an issue on a website. How can a developer debug it? Some familiar approaches rely on information such as logs and dumps, which only provide point-in-time information. Therefore, if the issue does not reproduce or occur at a specific moment captured in a log or dump, the developer must try again to capture useful information at a different point in the execution, which means it takes longer to resolve the issue.

[0407] Imagine, instead, an environment that can tell developers exactly what is happening in their production applications, line by line. Using Microsoft Time Travel Debugging or other reverse execution replay embodiments allows team members to collect a high-fidelity record of application behavior. Developers can then run code in a commonly familiar environment such as Microsoft environment or other debugging or integrated development environment).

[0408] As a specific example, assume that there is a problem with the SmartHotels360 website; this is a demonstration website whose code is publicly available from Microsoft Corporation via the GitHub.com website. A developer at the company that runs the SmartHotels360 website gets a report from a user that a feature for BestHotels is no longer displaying data. However, it was previously working fine, and the problem has not been reproduced in the company's test or staging environment. A member of the operations team or engineering team has collected a log (trace 418) of the application while running the code that powers the failed feature. The trace 418 can be collected into a file 420 via a command line tool or by the cloud environment ( or another cloud environment) automatically triggers logging for a condition such as a method throwing more exceptions than expected.

[0409] The developer opens the debugger and loads the SmartHotels360 code and trace file 420. In the API that returns BestHotels, execution stops at the breakpoint on line 28. Now, even though this is a log file, in this example, the developer can use many familiar commands to navigate it using the debugger that the developer is generally familiar with. The developer wants to know what happens when the API is called. The developer steps over lines 28 and 29 and sees from the Locals window that bestHotels has zero items after stepping over line 29. If the debugger supports data tips, the developer can also view them, at least in this example.

[0410] Now, the developer has determined that the reason for the problem is in BestHotels () routine. Therefore, the developer wishes to investigate what happened in BestHotels (). With another debugging method, in order to look back and see what happened, the developer can click to continue, click breakpoint again, then step into the next BestHotels () call, although value, object and memory address may be different from the call that is partially debugged. Or, when the debugger state is difficult to reproduce, the developer can restart the application, and this may take a lot of time. But in this example, the environment supports time travel debugging. Therefore, the developer uses the reverse continue button (request to continue 920 operations backward) to rewind the application to the state of the previous breakpoint. A result of rewinding is that before the above-mentioned stepping is carried out, the local will be reset to the state before 28 rows. Now, by ensuring that all values, objects and memory addresses from the call that is partially debugged are identical, the developer can step and skip Load () routine and step into BestHotels ().

[0411] At this point, the developer decides to step through BestHotels() and delve into GetBestHotels(). Therefore, the developer wants to step past line 36 and then step into line 37. Assume that the developer accidentally presses the Step Over button multiple times. With time travel debugging, the developer can quickly go back and see what happened in GetBestHotels(). In fact, the developer can use the Backward Step Button (Request Backward Step Into 914 Operation), which will bring the execution into GetBestHotels() and play it backwards. The developer finds that at the end of GetBestHotels(), the value of the local variable bestHotels (corresponding to the count) is zero. Obviously, all levels have been filtered out.

[0412] Therefore, the developer decides to test the assumption by checking to see the ratings of all hotels. Remember, this trace is happening in production, so these values ​​are real values. The developer can use the debugger's immediate window to evaluate expressions, which can be achieved through the live debugging process. The developer evaluates the expression "AllHotels.Select(h=>h.rating)" in the debugger's immediate window and finds that rating is a floating point, while the code is checking for rating values ​​that are equal to integers 4 or 5. Data type mismatch, a mismatch between the shape of the data in production and the application expectations.

[0413] Now assume that the developer has completed the debugging just described and wants to discuss and show a colleague what happened in detail. The developer wants to start again at the beginning of the investigation and wants a way to quickly get back to a specific point of interest. Therefore, the developer sets a breakpoint at line 21 and then rewinds to that breakpoint. Replay will then allow the developer to reproduce the debugging steps again. If the developer wants to jump to the end, the developer can continue forward until the last breakpoint set by the developer.

[0414] In short, developers can quickly debug problems using a high-fidelity trace 418 of the application that captures what actually went wrong in production. With the power of a debugger adapted for replay as described herein, developers can debug using a familiar debugger user interface and can debug forward and backward, saving a significant amount of developer time.

[0415] in conclusion

[0416] Although particular embodiments are explicitly shown and described herein as processes, configured media, or systems, it should be understood that a discussion of one type of embodiment also generally extends to some other types of embodiments. Fig.13 and 14The process descriptions performed also help describe the configured media, and help describe the technical effects and operations of systems and fabrications similar to those discussed in conjunction with the other figures. Limitations from one embodiment must not necessarily be read into another embodiment. In particular, the processes are not necessarily limited to the data structures and arrangements presented when discussing systems or fabrications such as configured memories.

[0417] Those skilled in the art will appreciate that implementation details may be relevant to specific code, such as specific APIs, specific domains, and specific sample programs, and therefore may not necessarily appear in each embodiment. Those skilled in the art will also appreciate that program identifiers and some other terms used when discussing details are implementation-specific, and therefore may not necessarily be relevant to each embodiment. Nevertheless, although they are not necessarily required to exist here, such details may help some readers by providing context, and / or may illustrate some implementations of many possible implementations of the technology discussed herein.

[0418] Reference herein to an embodiment having some feature X and reference elsewhere herein to an embodiment having some feature Y does not exclude embodiments having both feature X and feature Y, unless such exclusion is expressly stated herein. All possible negative claim limitations are within the scope of the present disclosure, as any feature specified as part of one embodiment may be expressly deleted from some other embodiment even if no specific exclusion is given in any example herein. The term "embodiment" is used herein merely as a more convenient form of "process, system, article, configured computer-readable medium, and / or other example of the teachings herein applied in a manner consistent with applicable law." Thus, a given "embodiment" may include any combination of the features disclosed herein, as long as the embodiment is consistent with at least one claim.

[0419] In each embodiment, not every item shown in the figures must be presented. On the contrary, an embodiment may include items that are not explicitly shown in the figures. Although some possibilities are shown in the text and drawings by specific examples here, the embodiments may deviate from these examples. For example, specific technical effects or technical features of the examples may be omitted, renamed, grouped differently, repeated, instantiated differently in hardware and / or software, or be a mixture of effects or features that appear in two or more examples. In some embodiments, the functions shown at one location may also be provided at different locations; for example, those skilled in the art recognize that functional modules can be defined in various ways in a given implementation without having to ignore the required technical effects from a set of interactive modules that are considered as a whole.

[0420] Reference is made to the drawings throughout the text by reference numerals. Any apparent inconsistency in the wording associated with a given reference numeral in the drawings or text should be understood to simply expand the scope of the reference to that numeral. Even if the same reference numeral is used, different instances of a given reference numeral may refer to different embodiments. Similarly, a given reference numeral may refer to a different embodiment of the present invention.

[0421] can be used to refer to verbs, nouns, and / or corresponding instances of each, e.g., processor 110

[0422] The instructions may be processed 110 by executing the instructions.

[0423] As used herein, terms such as "a", "an" and "the" include one or more of the indicated items or steps. In particular, in the claims, reference to an item generally means that there is at least one such item, and reference to a step means at least one instance of performing the step.

[0424] Headings are for convenience only; information on a given topic may be found outside the section whose heading indicates that topic.

[0425] All claims and the abstract as filed are part of the specification.

[0426] Although exemplary embodiments have been shown in the drawings and described above, it is clear to those skilled in the art that various modifications may be made without departing from the principles and concepts set forth in the claims, and such modifications do not necessarily encompass the entire abstract concept. Although the subject matter is described in a language specific to structural features and / or program actions, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the specific technical features or actions described in the claims. Each means or aspect or technical effect identified in a given definition or example does not have to be presented or utilized in every embodiment. Instead, the specific features, actions, and effects described are disclosed as examples to be considered when implementing the claims.

[0427] To the maximum extent permitted by law, all changes that come within the general abstract concept and within the meaning and range of equivalency of the claims are intended to be embraced within their scope.

Claims

1. A tracking and replay execution control system, comprising: processor; a memory in operable communication with the processor; a trace recorded during execution of a program in conjunction with calls to a runtime and a kernel of the program, wherein the trace comprises trace entries comprising a record of activity of native code instructions executed in at least one thread of the program, wherein the activity of the native code instructions is traced while the program is executed, and wherein the trace does not include any execution instances of the runtime of the program; source code for at least a portion of the program; a source intermediate map that automatically maps between the source code of the at least a portion of the program and an intermediate representation of the source code of the at least a portion of the program; an intermediate native mapping that automatically maps between the intermediate representation of the source code of the at least a portion of the program and the trace; as well as An execution controller in a software tool, wherein the execution controller is configured to, when executed by the processor, control replay execution of the trace in response to receiving a trace replay execution control request, wherein the source code is associated with the trace entry via the source intermediate map and the intermediate native map.

2. The trace-replay execution control system of claim 1 , wherein the execution controller is further configured to convert a request for at least the following operations into a corresponding execution of the traced native code instructions: Perform a step-in operation forward; Perform a forward step exit operation; and Performs a forward step skip operation.

3. The trace-replay execution control system of claim 1 , wherein the execution controller is further configured to convert a request for at least the following operations into a corresponding execution of the traced native code instructions: Perform a step-in operation backwards; Perform a step-out operation backwards; and Performs a step skip operation backward.

4. The trace-replay execution control system of claim 1 , wherein the execution controller is further configured to convert requests for at least the following operations into corresponding executions of traced native code instructions: Continue execution forward in the trace until a position in the breakpoint range is reached, and Execution continues backwards in the trace until a position in the breakpoint range is reached.

5. The trace-replay execution control system of claim 1 , wherein the trace-replay execution control system is configured to step into a portion of the source code of the at least a portion of the program, the portion of the source code having not been compiled into native code instructions during the traced replay execution.

6. The trace-replay execution control system according to claim 1, wherein the intermediate representation of the source code of the at least a portion of the program comprises at least one of the following: a symbol table associating at least two identifiers used in the source code of the at least a portion of the program with data types; an abstract syntax tree derived from at least a portion of the source code of the at least a portion of the program; or conversion of at least a portion of the source code of the at least a portion of the program into an intermediate language.

7. The trace-replay execution control system of claim 1 , wherein the trace does not include any execution instances of the runtime of the program because the trace-replay execution control system is not configured to call the trace to execute any code specific to the runtime of the program.

8. The trace-replay execution control system according to claim 1 further includes a real-time process of the program having a callable instance of the program at runtime, wherein the trace is recorded from the real-time process of the program and the trace-replay execution control system is configured to replay the execution of the trace recorded from the real-time process of the program.

9. A trace-replay execution control system according to claim 1, wherein the trace-replay execution control system is configured to skip the replay execution of a portion of the trace because the execution controller moves the replay execution of the portion of the trace from a first execution time point of the trace to a second execution time point of the trace, and the trace-replay execution control system does not execute the traced native code instructions that would have been executed by continuing execution from the first execution time point of the trace to the second execution time point of the trace.

10. A tracking and replay execution control method, comprising: identifying a traced hypervisor, the traced hypervisor configured to execute in conjunction with calls to a runtime and a kernel of the traced hypervisor and configured to be traced during execution; receiving a trace-replay execution control request, wherein the trace-replay execution control request is received in a software tool running on a computing system; automatically mapping between source code of the tracked managed program and an intermediate representation of the source code of the tracked managed program and automatically mapping between the intermediate representation of the source code of the tracked managed program and a trace recorded during the execution of the tracked managed program based on receiving the trace replay execution control request, wherein the trace comprises a trace entry comprising: a record of activity of native code instructions executed by at least one processor in at least one thread of the tracked managed program, wherein the activity of the native code instructions is traced while the tracked managed program is executed, and wherein the trace does not include any execution instance of the runtime of the tracked managed program; as well as Traced native code instructions corresponding to the trace replay execution control request are executed, wherein the source code is associated with the trace entry via a source intermediate map and the intermediate native map, thereby replaying execution of a portion of the trace.

11. The trace replay execution control method of claim 10 , wherein the trace replay execution control request identifies a backward execution step exit operation to step exit a routine, and the trace replay execution control method further comprises setting a breakpoint on a traced native code instruction, the breakpoint having a position immediately before a position of a return address of a call to the routine, and wherein when A is encountered before B during forward execution of the trace and there are at most five traced native code instructions between A and B, position A is immediately before position B in the trace.

12. The trace-replay execution control method of claim 10 , wherein the source code of the traced managed program contains statements and expressions, wherein the trace-replay execution control method further comprises setting a breakpoint on a traced native code instruction, the breakpoint being on the edge of a set of all traced native code instructions, the all traced native code instructions being mapped by the trace-replay execution control method to a given statement or a given expression in the source code of the traced managed program, and wherein an instruction X in a set of instructions G in the trace satisfies at least one of the following conditions, X is on the edge of G: X is the first instruction of G encountered during forward execution of the trace; X is the last instruction of G encountered during forward execution of the trace; X is the first instruction of G encountered during backward execution of the trace; or X is the last instruction of G encountered during backward execution of the trace.

13. The trace replay execution control method according to claim 12, wherein the trace replay execution control request calls one of the following: Perform a forward step skip operation to step forward through the routine; Perform a step skip operation backward to step skip the routine backward; Perform a forward step entry operation to step forward into the routine; or Perform a step-into operation backward to step backward into the routine.

14. The trace replay execution control method according to claim 10, wherein the trace replay execution control request indicates a forward execution step-in operation to step into a user code routine, wherein the replay execution of the user code routine includes the replay execution of at least one call to a runtime routine, wherein the at least one call to the runtime routine has no corresponding call statement or call expression in the source code of the managed program being traced, and wherein the trace replay execution control method further comprises at least one of the following: Setting a breakpoint range that specifies the entire memory range designated to receive dynamically compiled code; or A breakpoint is set to step over the at least one call to the runtime routine.

15. The trace replay execution control method according to claim 10, wherein the trace replay execution control request calls at least one of the following operations: Continue tracing replay execution forward in the trace until a breakpoint is reached; continuing to trace replay execution forward in the trace until a position within the breakpoint range is reached; Continue tracing replay execution backwards in the trace until a breakpoint is reached; continuing to trace replay execution backward in the trace until a position within the breakpoint range is reached; Perform a step-in operation backwards; Perform a step-out operation backwards; Perform a step skip operation backwards; Perform a step-in operation forward; Perform a forward step exit operation; or Performs a forward step skip operation.

16. The trace-replay execution control method of claim 10 , wherein during the execution of the traced managed program, a maximum number of breakpoints is subject to a hardware breakpoint constraint that a processor can monitor at most N addresses at a time, and wherein the trace-replay execution control method further comprises setting more than N breakpoints during the replay execution of the portion of the trace, thereby exceeding the hardware breakpoint constraint.

17. A computer-readable storage medium storing data and instructions, which when executed by a processor in operable communication with a memory, perform a trace replay execution control method, the trace replay execution control method comprising: identifying a traced hypervisor, the traced hypervisor configured to execute in conjunction with calls to a runtime and a kernel of the traced hypervisor and configured to be traced during execution; receiving a trace-replay execution control request, wherein the trace-replay execution control request is received in a software tool running on a computing system; automatically mapping between source code of the tracked managed program and an intermediate representation of the source code of the tracked managed program and automatically mapping between the intermediate representation of the source code of the tracked managed program and a trace recorded during the execution of the tracked managed program based on receiving the trace replay execution control request, wherein the trace comprises a trace entry comprising: a record of activity of native code instructions executed by at least one processor in at least one thread of the tracked managed program, wherein the activity of the native code instructions is traced while the tracked managed program is executed, and wherein the trace does not include any execution instance of the runtime of the tracked managed program; as well as Executing a traced native code instruction corresponding to the trace replay execution control request or setting a breakpoint on a traced native code instruction, wherein the source code is associated with the trace entry through a source intermediate map and the intermediate native map, thereby controlling replay execution of the trace.

18. The computer-readable storage medium of claim 17, wherein the tracked managed program is combined with debugger code, including a real-time process and an execution runtime of the tracked managed program, and wherein the debugger code communicates with the execution runtime of the tracked managed program, and wherein the trace-replay execution control method further comprises using the trace control to perform backward replay without terminating the tracked managed program.

19. The computer-readable storage medium according to claim 17, wherein the trace-replay execution control method further comprises at least two of the following execution control activities: using machine level information in the trace to control at a high level execution of the runtime of the traced hypervisor, wherein controlling at a high level the execution of the runtime of the traced hypervisor refers to controlling based on user selections, the user selections specifying identifiers or statements or expressions in the source code of the traced hypervisor, and the machine level information in the trace refers to information specific to a processor architecture; debugging both forward and backward execution of the traced managed program's process; stepping into a call shown in the source code of the traced managed program at least in part by setting a large breakpoint range, wherein the breakpoint range is large when it covers at least one thousand consecutive addresses or instructions in the trace; When the trace includes at least two versions of the native code of a routine, mapping to a specific version of the native code of the routine; or While debugging the real-time process of the traced managed program, trace data from the real-time process is recorded, and then reverse execution debugging of the real-time process is performed using at least some of the recorded trace data.

20. The computer-readable storage medium according to claim 17, wherein the trace-replay execution control method further comprises at least three of the following execution control activities: using machine level information in the trace to control at a high level execution of the runtime of the traced hypervisor, wherein controlling at a high level the execution of the runtime of the traced hypervisor refers to controlling based on user selections, the user selections specifying identifiers or statements or expressions in the source code of the traced hypervisor, and the machine level information in the trace refers to information specific to a processor architecture; debugging both forward and backward execution of the traced managed program's process; stepping into a call shown in the source code of the traced managed program at least in part by setting a large breakpoint range, wherein the breakpoint range is large when it covers at least one thousand consecutive addresses or instructions in the trace; When the trace includes at least two versions of the native code of a routine, mapping to a specific version of the native code of the routine; or While debugging the real-time process of the traced managed program, trace data from the real-time process is recorded, and then reverse execution debugging of the real-time process is performed using at least some of the recorded trace data.

Images