Browse Prior Art Database

Creating Slop for Instrumentation Code in a Large Object File Disclosure Number: IPCOM000241022D
Publication Date: 2015-Mar-20
Document File: 4 page(s) / 55K

Publishing Venue

The Prior Art Database


Disclosed is a method to avoid moving any user code during instrumentation. The novel solution is a method to examine each routine in the object files and score it based on it suitability to move.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 27% of the total text.

Page 01 of 4

Creating Slop for Instrumentation Code in a Large Object File

When overlaying instructions with an unconditional branch, occasionally the process can encounter an object file too large for a relative or absolute branch instruction to reach the end of the object. Overlaying multiple instructions is not a desirable option; therefore, using a branch-to-address-in-register is not an option because it requires more than a single instruction. It is then necessary to create space within the object file for the tailers by identifying routines that can be moved with minimum patching .


An existing software product for runtime analysis allows dynamic verification, a process by which a program discovers errors that occur when the program runs. Static verification or static code analysis, by contrast, involves detecting errors in the source code

without ever compiling or running it, just by discovering logical inconsistencies. Dynamic verification is done at runtime.

When a program is linked with the runtime analysis software, the verification code is automatically inserted into the executable. This is done by parsing and adding to the object code (including system libraries) through the object code insertion process. Thus, if a memory error occurs, then the runtime verification code identifies it and the program prints out the exact location of the error , the memory address involved, and other relevant information.

The errors that the runtime analysis software discovers include array bounds reads and writes, trying to access unallocated memory, freeing unallocated memory (usually due to freeing the same memory for the second time), as well as memory leaks (allocated memory with no pointer reference). Most of these errors are not fatal and often go undetected when running the program, except by observing that something is wrong due to incorrect program behavior. Hence, the runtime analysis software helps by detecting these errors and telling the programmer exactly where the errors occur. Because the runtime analysis software

works by instrumenting all the object code, it detects errors that occur inside of third party or operating system libraries. These errors are often caused by the programmer passing incorrect arguments to the library calls, or by misunderstandings about the protocols for freeing data structures used by the libraries.

Instrumentation Background

Processing object code and inserting additional instructions also incurs problems. As compilers become more sophisticated, parsing object code becomes less reliable. At build time, the runtime analysis software identifies executable instructions by starting at the entry points of the object and following the instructions through the routines . For one operating system (OS), the runtime analysis software inserts extra code directly into the object file before each memory load and store , and at subroutine entry and exit. In the process, it moves the locations of branch ta...