How Intel Pin Works

The Pin JIT compiler re-compiles and instruments small chunks of binary code imme- diately before executing them. The modied instructions are stored in a software code cache. It allows code regions to be generated once and reused for the remainder of program execution later on, in order to reduce the cost of recompilation. The overhead introduced by the compilation is highly dependent on the application and workload [24]. Figure 2.6 shows a basic structure of the Pin software architecture. It consists of three main processes, launcher process, server process and instrumented process. The launcher process creates the other two processes, injects the Pin modules and instru- mented code into the instrumented process, then it waits for the process to terminate. The server process provides services for managing symbol information, injecting Pin or communicating with the instrumented process via shared memory. The instrumented process includes the Pin Virtual Machine Manager (VMM) (pinvm.dll), the user dened Pin tool library, and the application executable and libraries. The VMM performs as a

2.5 Intel Pin Process Launcher PIN.exe Server Process Create Process (DBGHELP.DLL)

Debug Symbol Server

Create Process

PinTool Library Application

Code and Data

PIN Virtual Machine Monitor (PINVM.DLL) System call Dispatcher Emulator Dispatcher Thread Event Code Cache NTDLL.DLL KERNEL32.DLL Windows Kernel

Figure 2.6: Overview of program execution with an Intel Pin tool on Windows system call emulator, event and thread dispatcher, and also as JIT compiler. It is the engine of the entire instrumented process. After Pin takes over control of the application, the VMM coordinates its execution. Then the JIT compiler instruments the code and passes it to the dispatcher, which launches the execution. The compiled code is stored in the code cache. The Pin tool contains the instrumentation and analysis routines. It is a plug-in and linked with the Pin library, which allows it to communicate with the Pin VMM.

In order to gain control of execution and then instrument the application, the Pin VMM uses the injection procedure to be loaded into the address space of the application. The injection is desirable to be performed as early as possible when Pin executable is launched, so that the Pin tools can observe the execution of guest application. The application process is created in suspended state and is attached to by Pin via Win32 debugger APIs. When the system kernel nished initializing the process, the debugger then detaches from the debugged process. The context of the application is stored and the instruction pointer is modied to load the VMM boot routine. After the VMM is fully initialized, it loads the Pin tool. Principally, this is the earliest time to load the tool library, as the initialization of the kernel libraries is not possible to be instrumented. For system calls, such as I/O access and new process creation, Pin is able to handle them on behalf of the application. It rst detects when the application is about to execute a system call, then instruments immediately after the system call instructions,

and nally execute the call with precisely constructed register state of the application. The reason of instrumenting extra code for executing system calls, is because the kernel may cause the application to continue after the system call. This ensures that Pin always has control of the execution.

Exceptions are synchronous events, which are delivered immediately from the system kernel when detected by hardware or generated by software. Windows provides the so- called Structured Exception Handling (SEH) [34] mechanism to handle exceptions, and this can also be used by applications to capture exceptions. The further information of exceptions then can be analyzed and appropriate exception handlers can be specied by the application. This makes it possible for Pin to intercepts exceptions and insert instrumented code at the entry of the original exception routine. However, it is necessary to distinguish exceptions from the application and internal Pin. The Pin dispatcher checks the exception origin to accomplish this. As the inserted instructions from Pin are ensured to not fault into the code cache, the only source of the exceptions is from the application. The JIT compiler guarantees that the same exceptions are raised in the instrumented applications under the same conditions as the original instructions.

The overhead introduced by instrumenting with Pin is dependent on the application and the Pin tool. In the VMM, time is spent on processing the system events like system calls, exceptions, and Asynchronous Procedure Call (APC)s, invoking the JIT compiler, and management of the code cache. Internally, time is also spent on executing the application or its instrumentation by code cache and translating the application and inserting instrumentation by the JIT compiler. On the other hand, the interaction with the operation system has also overhead, especially on Windows [52], that shows a higher overhead from system calls than exceptions, APCs and callbacks.