Data Sections | Inside Microsoft .NET IL Assembler

Data Sections

The data section (.sdata) of an image file generated by the ILAsm compiler is a read/write section. It contains data constants, the v-table, the unmanaged export table, and the thread local storage directory structure. The data declared as thread-specific is located in a different section, the .tls section.

Data Constants

The term data constants might be a little misleading. Located in a read/write section, data constants can certainly be overwritten, so technically they can hardly be called “constants.” The term, however, refers to the usage of the data rather than to the nature of the data. Data constants represent the mappings of the static fields and usually contain data initializing the mapped fields. (Chapter 1 described the peculiarities of this field mapping; see “Mapped Fields.”)

Field mapping is a convenient way to initialize the static fields with ANSI strings, blobs, or structures. An alternative way to initialize the static fields—and a more orthodox way in terms of the common language runtime—is to do it explicitly in class constructors, as discussed in the section “Constructors vs. Data Constants” in Chapter 8, “Fields and Data Constants.” But this alternative is much more tedious, so no one can really blame the managed compilers for resorting to field mapping for initialization. The MC++ compiler maps all the global fields, whether they will be initialized or not.

Mapping static fields to data has its caveats. Fields mapped to the data section are, on the one hand, out of reach of runtime controlling mechanisms such as type control and garbage collection and, on the other hand, wide open to unrestricted access and modification. This causes the loader to prevent certain field types from being mapped; types of mapped fields might contain no references to objects, vectors, or arrays, nor to any nonpublic substructures. No such problems arise if a class constructor is used for static field initialization. Philosophically speaking, this is only natural: throughout the history of humanity, deviations from orthodoxy, however tempting, have always brought some unpleasant complications.

V-Table

The v-table consists of entries, and each entry consists of one or more slots. The v-table fixups we have already discussed earlier in the section “VTableFixups Field” specify the number and width (4 or 8 bytes) of slots in each entry. Each slot contains a metadata token of the respective method, which at execution time is replaced with the address of the method itself or the address of a marshaling thunk representing the method. Because these fixups are performed at execution time, the v-table of a managed PE file must be located in a read/write section. The ILAsm compiler puts the v-table in the .sdata section, together with other data.

V-tables of unmanaged image files are completely defined at link time and need base relocation fixups only, performed by the OS loader. Because no changes are made to v-tables at execution time, unmanaged image files carry their v-tables in read-only sections.

Unmanaged Export Table

The unmanaged export table in an unmanaged image file occupies a separate section named .edata. In image files generated by the ILAsm compiler, the unmanaged export table resides in the .sdata section, together with the v-table it references.

The unmanaged export table contains information about symbols that other (unmanaged) image files can access through dynamic linking. The unmanaged export table is not a single table but rather a contiguous set of five tables: the Export Directory table, the Export Address table, the Name Pointer table, the Ordinal table, and the Export Name table.

The unmanaged export information starts with the Export Directory table, which describes the rest of the export information. It is a table with only one element, containing the locations and sizes of other export tables. The structure of the sole row of the Export Directory table is defined in Winnt.h as follows:

typedef struct _IMAGE_EXPORT_DIRECTORY {     DWORD   Characteristics;     DWORD   TimeDateStamp;     WORD    MajorVersion;     WORD    MinorVersion;     DWORD   Name;     DWORD   Base;     DWORD   NumberOfFunctions;     DWORD   NumberOfNames;     DWORD   AddressOfFunctions;     DWORD   AddressOfNames;     DWORD   AddressOfNameOrdinals; } IMAGE_EXPORT_DIRECTORY, *PIMAGE_EXPORT_DIRECTORY;

Briefly, the fields of IMAGE_EXPORT_DIRECTORY are the following:

Characteristics Reserved. This field should be set to 0.
TimeDateStamp The time and date the export data was generated.
MajorVersion The major version number. This field and the MinorVersion field are for information only; the ILAsm compiler does not set them.
MinorVersion The minor version number.
Name The RVA of the ANSI string containing the name of the exporting module.
Base The ordinal base (usually 1). This is the starting ordinal number for exports in the image file.
NumberOfFunctions The number of entries in the Export Address table.
NumberOfNames Number of entries in the Export Name table.
AddressOfFunctions The RVA of the Export Address table.
AddressOfNames The RVA of the Export Name table.
AddressOfNameOrdinals The RVA of the Name Pointer table.

The Export Address table contains the RVAs of exported entry points. The export ordinal of an entry point is defined as its zero-based index within the Export Address table plus the ordinal base (the value of the Base field of IMAGE_EXPORT_DIRECTORY structure).

In a managed file, the Export Address table contains the RVAs not of the exported entry points (methods) themselves but rather of unmanaged export stubs representing these entry points. (See “Text Section” earlier in this chapter.) Export stubs, in turn, contain references to respective v-table slots.

An RVA in an Export Address table can be a so-called forwarder RVA, identifying a re-exported entry point—that is, an entry point this module imports from another module and exports as its own. In such a case, the RVA points to an ANSI string containing the import name. The import name might be a DLL name and the name of the imported entry (SomeDLL.someFunc) or a DLL name and the imported entry’s ordinal in this DLL (SomeDLL.#12).

Because the ILAsm compiler does not allow re-export, the entries in an Export Address table of an image file generated by this compiler always represent the RVAs of unmanaged export stubs.

The Name Pointer table contains RVAs of the export names from the Export Name table. These RVAs are lexically ordered to facilitate binary searches of the entry points by name.

The Ordinal table contains 2-byte indexes to the Export Address table. The Name Pointer table and the Ordinal table form two parallel arrays and operate as one intermediate lookup table, rearranging the entries so that they are lexically ordered by name.

The Export Name table contains zero-terminated ANSI strings representing the export names of the methods exported by the module. The export names might differ from the names under which the methods were declared in the module. An exported method might have no exported name at all if it is being exported by ordinal only. In this case, its ordinal is not included in the Ordinal table. The ILAsm compiler does not allow unnamed exports.

Chapter 15 examines unmanaged export information and the details of exposing managed methods as unmanaged exports.

Thread Local Storage

ILAsm and MC++ allow you to define data constants belonging to thread local storage and to map static fields to these data constants. TLS is a special storage class in which a data object is not a stack variable but is nevertheless local to each separate thread. Consequently, each thread can maintain a different value for such a variable.

The TLS data is described in the TLS directory, which the ILAsm compiler puts in the .sdata section. The structure of the TLS directory for 32-bit image files is defined in Winnt.h as follows:

typedef struct _IMAGE_TLS_DIRECTORY32 {     DWORD   StartAddressOfRawData;     DWORD   EndAddressOfRawData;     PDWORD  AddressOfIndex;     PIMAGE_TLS_CALLBACK *AddressOfCallBacks;     DWORD   SizeOfZeroFill;     DWORD   Characteristics; } IMAGE_TLS_DIRECTORY32;

The fields of this structure can be described as follows:

StartAddressOfRawData The starting virtual address (not an RVA) of the TLS data constants. The TLS data constants plus uninitialized TLS data together form the TLS template. The operating system makes a copy of the TLS template every time a thread is created, thus providing each thread with its “personal” data constants and field mapping.
EndAddressOfRawData The ending VA of the TLS data constants. The rest of the TLS data (if any) is filled with zeros. Because the ILAsm compiler allows no uninitialized TLS data, presuming that TLS data constants represent the whole TLS template, nothing is left for the zero fill.
AddressOfIndex The VA of the 4-byte TLS index, located in the ordinary data section. The ILAsm compiler puts the TLS index in the .sdata section, immediately after the TLS directory structure and the callback function pointer array terminator.
AddressOfCallBacks The VA of an array of TLS callback function pointers. Because the array is null-terminated, this field points to 4 bytes set to 0 if no callback functions are supported. The ILAsm compiler does not support TLS callback functions, so the entire array of TLS callback function pointers consists of zero terminator. This zero terminator immediately follows the TLS directory structure in the .sdata section.
SizeOfZeroFill The size of the uninitialized part of the TLS template, filled with zeros when a copy of the TLS template is being made. The ILAsm compiler sets this field to 0.
Characteristics Reserved. This field should be set to 0.

Because the StartAddressOfRawData, EndAddressOfRawData, AddressOfIndex, and AddressOfCallBacks fields hold VAs rather than RVAs, base relocations must be defined for them in the .reloc section.

The RVA and size of the TLS directory structure are stored in the tenth data directory (TLS) of the PE header. TLS data constants, which form the TLS template, are stored in the .tls section of the image file.