enoft Manual

TNS/E Native Object Files
eNOFT Manual—527507-005
A-12
The 32-Bit and 64-Bit Programming Models
NSK has also invented the .rela.gblzd section to handle globalized symbols in our
implementation of C++. Other implementations take different approaches, not just to
handle this specific feature of C++ but with regard to the issue of preemption in
general. This invention of the .rela.gblzd section again follows the same strategy for
NSK of segregating relocation table entries based on the target symbol, not based on
the address of the relocation site.
The reason that Intel and HP separate out the relocation table entries for the
.IA_64.pltoff section is related to the feature of “lazy evaluation”, which NSK does not
support (and which is not described in this appendix).
Note 2:
The .got is used to make indirect references to data, while the .IA_64.pltoff section is
used to make indirect references to procedures. Instead of these two names, the
names used by HP are more sensible, namely, .dlt (“data linkage table”) and .plt
(“procedure linkage table”), respectively. HP has a different name for the section of
import stubs, which NSK calls the .plt section.
Also, note that the .plt section of import stubs makes references to the .IA_64.pltoff
section of local function descriptors. That seems backwards, because you would think
that a section named pltoff would contain “offsets” into a section named plt.
The strange names that NSK uses are the ones found in the IPF standards
documents.
The 32-Bit and 64-Bit Programming Models
According to the IPF-Specific ABI Document there is a choice of two programming
models, named ILP32 and LP64. In the standard, this means two different things. On
the one hand, it tells something about your C compiler, namely, whether the sizes of
pointers and the predefined type long are 32-bits or 64-bits. On the other hand, it also
tells whether 32-bit or 64-bit addresses are stored in object files.
At the present time, the NSK C compiler supports the 32-bit model. In the future, NSK
will also support the 64-bit model. When we do that, it will not be possible for general
users to mix the two within the same loadfile, but it will be possible to mix different
types of loadfiles in the same process. Regardless of the data model supported by the
compiler, however, NSK always use the 64-bit format for object files. That allows us to
internally put 64-bit code into loadfiles that are otherwise 32-bit. When TNS/E object
files contain values that are 32-bit addresses, they correspond to the actual 64-bit
values supported by the underlying hardware via sign extension.
Code and Data Sections
This subsection discusses the "ordinary" code and data sections that come from
application source code, possibly with some things added by the compiler or linker.
Special types of data sections, such as the stack unwinding information, the .procinfo