enoft Manual

TNS/E Native Object Files
eNOFT Manual—527507-005
A-11
Summary of the Contents of an Object File
Object RTDU Sections
An object RTDU, which is part of the SQL/MP implementation, can be placed into a
program by a tool named SQLCOMP. The object RTDU is represented by three
sections.
.shstrtab Section
This is a string space that is pointed at from the ELF section headers. It is
required.
ELF Section Headers
These contain header information to describe everything in the object file, except
for the ELF header, the program headers, the section headers themselves, and
possibly unused space within the object file.
A general principle behind the loadfile design is that the sections up through .dynstr2
are expected to be small, and it can therefore be more efficient to have them all near
the front. That is the reason that the .dynstr2 section was invented, that is, to
segregate out the strings needed by other small sections near the front of the file.
Another general principle is that, after all the things that are “small”, all the things that
might need to be resident come next. More specifically, the .restext section needs to
be resident (by definition), and if it is present then some other sections also need to be
resident, and some don’t. All the other things that would also need to be resident are
placed before the .restext section, so that the .restext section (if present) marks the
end of the portion of the text segment that needs to be resident.
Note 1:
The way NSK arranges all the relocation table entries of a loadfile into sections named
rela.dyn and rela.gblzd is not the standard way to do it for IPF, at least as followed by
both Intel and HP.
In the Intel and HP implementations there is a different relocation table section for each
of the sections of the loadfile that have relocation sites, which can include the .got
section, .IA_64.pltoff section, and various user data sections. Each of these relocation
tables has its own section header. In effect, that means that the relocation sites are
sorted according to their locations, or at least according to which sections they are in.
But then, most of these relocation table sections are placed consecutively in memory,
with no rounding up of the space between them, so that you can think of them as one
relocation table section, and that is what it looks like when you find them via the same
entries in the .dynamic section that we use to find the dynamic relocation table. The
exception to this in the Intel and HP implementations is the relocation table section for
the .IA_64.pltoff section, which is found via an additional group of .dynamic section
entries.
Instead of following this approach, the NSK implementation is based on the strategy
used by SGI. Namely, relocation table entries are sorted by the target symbol. So,
they could not be segregated by section as is done by Intel and HP.