Source: {"pile_set_name": "USPTO Backgrounds"}

Over recent years, the computing community developed a strong set of tools and methods used to analyze and monitor run-time behavior of a program. Performance analysis tools include, for example, basis tools which allow for mapping of periodically taken snapshots during a program's execution to the program's source (e.g. sampling applications) and more complex tools which allow a broader range of program analysis (e.g. code instrumentation applications). Measurements such as basic-block coverage and function invocation counting can be accurately made using code instrumentation. One specific type of code instrumentation is referred to as dynamic binary instrumentation. Dynamic binary instrumentation allows program instructions to be changed on-the-fly. Additionally, dynamic binary instrumentation, as opposed to static instrumentation, is performed at run-time of a program and only instruments those parts of an executable that are actually executed. This minimizes the overhead imposed by the instrumentation process itself. Furthermore, performance analysis tools based on dynamic binary instrumentation require no special preparation of an executable such as, for example, a modified build or link process.
Unfortunately the benefits of conventional performance analysis tools are not available to all types of programs and functions. Specifically, conventional performance analysis tools will not work properly with inlined functions. As an explanation, many programming languages offer support for “inlining” functions. That is, many programming languages such as, for example, C++, allow the compiler to generate machine code for a function call such that the code from the function body gets directly inserted into the place where the call was made. The now inlined function causes the size of the text program to increase but removes the overhead of the function call. From the point of view of the programmer, there is some ambiguity as to whether a particular function has been inlined or not. For example, even if the programmer specifies in the source code that a certain function be inlined, that does not necessarily mean that the particular function will ultimately be inlined in the binary executable by the compiler. This ambiguity exists because there are certain cases where the compiler decides, on its own, not to inline a function even though the programmer has specified for the function to be inlined. Because conventional performance analysis tools correlate to the binary executable and the regular functions therein as opposed to the source code, and because conventional performance analysis tools do not take into account inlined function information, inlined functions can not be properly analyzed using existing performance analysis tools.
Thus, a need has arisen for a method and system for examining an inlined function using a performance analysis tool.