Relocation Table
A PE file needs only based relocations. The linker resolves all the relative relocations, assuming that the file will get loaded at the preferred base address. For example, if a function foo has the RVA as 0x100 and the preferred base address is 0x400000, the linker resolves the call to foo as a call to address 0x400100. At run time, if the file is loaded at the preferred base address of 0x400000, then no relocation needs to be preformed. If, for some reason, the file cannot be loaded at the base address of 0x400000, the loader needs to patch the call. If the loader manages to load the file at a base address of 0x600000, it needs to change the call address to 0x600100. In general, it needs to add the difference of 0x200000 to all the to-be-patched locations. This process is called as the based relocation. The list of the to-be-patched locations, also called as fixups, is maintained in the relocation table that is generally present in the .reloc section and is pointed to by the data directory entry at the IMAGE_DIRECTORY_ENTRY_BASERELOC index. The relocation table is nothing but a series of relocation blocks, each representing the fixups for a 4K page. Each relocation block has a header followed by the relocation entries for the corresponding page. The relocation block format is defined as the IMAGE_BASE_RELOCATION structure in the WINNT.H file, and it has following fields:
| VirtualAddress | RVA of the page to be patched. |
| SizeOfBlock | Total size of the relocation block, including the header and the relocation entries. |
Each relocation entry is a 16-bit word. The higher 4 bits indicate the type of relocation, and the lower 12 bits are the offset of the fixup location within the 4K page. The address-to-patched is calculated by adding the base address for loading, the RVA of the page to be patched, and the 12-bit offset within the page. The relocation types are defined in the WINNT.H file–only two of them are used on Intel machines:
| IMAGE_REL_BASED_ABSOLUTE | The relocation is skipped. This type can be used to pad a relocation block so that the next block starts at a 4-byte boundary. |
| IMAGE_REL_BASED_HIGHLOW | The relocation adds the base-address difference to the 32-bit double word at the location denoted by the 12-bit offset. |
Debug Directory
The operating system is not concerned with the debug information present in a PE file. The debugging tools access the debug information in a PE file. There are various debugging tools, which expect the debug information in different formats. The corresponding compilers/linkers also store the debug information in different formats. The PE format allows the debug information to be stored in different formats, such as COFF, Frame Pointer Omission (FPO), CodeView (CV4), and so on. A single file may contain debug information in more than one format. The debug directory pointed to by the IMAGE_DIRECTORY_ENTRY_DEBUG entry in the data directory is an array of debug directory entries, one for each debug information format. The IMAGE_DEBUG_DIRECTORY structure in the WINNT.H file represents the format of a debug directory entry.
| Characteristics | Currently unused. Set to 0. |
| TimeDateStamp | Date and time when the debug data was created. |
| MajorVersion, MinorVersion | Version of the debug data format. |
| Type | Type of the debug data format. |
| SizeOfData | Size of the debug data. |
| AddressOfRawData | RVA of the debug data. |
| PointerToRawData | Within file offset to the debug data. |
Of the different debug information formats, three are frequently encountered in PE files. The first one is the format used by the popular CodeView debugger. This format is defined in the CV4 specification. The FPO format is used to describe nonstandard stack frames. Not all the files in a PE file need have an FPO format debug entry. The functions without one are assumed to have a normal stack frame. The third important format is COFF, which is the native debug information format for PE files. The PE header itself points to the COFF symbol table. The COFF debug information consists of symbols and line numbers.
Thread Local Storage
The threads executing in a process share the same global data space. Sometimes, it may be required that each thread has some storage local to itself. For example, say a variable i needs to be local for each thread.
In such a case, each thread gets a private copy of i. Whenever a particular thread is running, its own private copy of i should be automatically activated. This is achieved in Windows NT using the Thread Local Storage (TLS) mechanism. Let’s see how it works.
Do not confuse the local data of a thread with the local variables that are created on stack. Each thread has a separate stack and local variables that are created and destroyed separately for each thread as the stack grows and shrinks. In this section, the phrase local data means global variables that have a separate copy for each thread.
The operating system maintains a structure called as the Thread Environment Block (TEB) for every thread running in the system. The FS segment register is always set such that the address FS:0 points to the TEB of the thread being executed. The TEB contains a pointer to the TLS array. The TLS array is an array of 4-byte DWORDs. Similar to the TEB, a separate TLS array is present for each thread. A thread can store its local data in the TLS array. Generally, programs store pointers to local data in some slot in the TLS array. The slot allocation for the TLS array is controlled by the API functions TlsAlloc() and TlsFree(). The Win32 API also provides functions to set and get the value at a particular index in the TLS array.
It is cumbersome to access the thread-specific data using the API functions. An easier way is to use the __declspec(thread) specification while declaring global variables that need to have a private copy for each thread. All such variables are gathered by the compiler/linker, and a single TLS array index is automatically allotted to this bunch of data. The TLS array entry at this index contains the pointer to a local data buffer that stores all these variables. These variables are accessed as any other normal variable in the program. Whenever such a variable is accessed, the compiler takes care to generate the code to access the TLS array entry and the data at a proper offset within the local data buffer.
This discussion is bit off the track. However, it is necessary before discussing the IMAGE_DIRECTORY_ENTRY_TLS data directory entry. The TLS directory structure is defined as IMAGE_TLS_DIRECTORY in the WINNT.H. Let’s have a look at this structure and see how it fits in the TLS mechanism.
| StartAddressOfRawData | Each time a new thread is created, the operating system allocates a new local data buffer for the thread and initializes the buffer with the data that is pointed to by this field. Note that this address is not an RVA, but it is a proper virtual address that has a relocation entry in the .reloc section. |
| EndAddressOfRawData | Virtual address of the end of the initialization data. The rest of the local data buffer is filled with zeros. |
| AddressOfIndex | Address in the data section where the loader should store the automatically allotted TLS index. The code accessing TLS variables accesses the index from this location. |
| AddressOfCallBacks | Pointer to a null-terminated array of TLS callback functions. Each function in this array is called whenever a new thread is created. These functions can perform additional initialization (for example, calling constructors) for the TLS data. The TLS callback has the same parameters as the DLL entry-point function. |
| SizeOfZeroFill | Size of the local data that is to be initialized to zero. The total size of the local data is (EndAddressOfRawData StartAddressOfRawData) + SizeOfZeroFill. |
| Characteristics | Reserved. |
|
Page: 1, 2, 3, 4, 5, 6 |
next page  |
|
|
|
|
Windows IT Pro
Register
