f78
Sections and Relocation
Contents|Index|Previous|Next
Sections and Relocation
The following documentation discusses sections, object files, addressing and
relocation.
ld Sections
as Internal Sections
Sub-Sections
bss Section
A section is a range of addresses, with no gaps; all data in those addresses is treated the same for some particular purpose. For example
there may be a read-only section.
The linker
ld reads many object files (partial programs) and combines their contents to
form a runnable program. When as emits an object file, the partial program is assumed to start at address 0. ld assigns the final addresses for the partial program, so that different
partial programs do not overlap. This is actually an oversimplification, but it
suffices to explain how as uses sections.
ld moves blocks of bytes of your program to their run-time addresses. These
blocks slide to their run-time addresses as rigid units; their length does not
change and neither does the order of bytes within them. Such a rigid unit is called
a section. Assigning run-time addresses to sections is called relocation. It includes the task of adjusting mentions of object-file addresses so they
refer to the proper run-time addresses. For the H8/300 and H8/500, and for the Hitachi SH, as pads sections if needed to ensure they end
on a word (sixteen bit) boundary.
An object file written by
as has at least three sections, any of which may be empty. These are named text, data and bss sections.
When it generates COFF output,
as can also generate whatever other named sections you specify using the .section directive (see .section name,
ffb
subsection ). If you do not use any directives that place output in the .text or .data sections, these sections still exist, but are empty.
When
as generates SOM or ELF output for the HPPA, as can also generate whatever other named sections you specify using the .space and .subspace directives.
See HP9000 Series 800 Assembly Language Reference Manual (HP 92432-90001) for
details on the
.space and .subspace assembler directives.
Additionally,
as uses different names for the standard text, data, and bss sections when
generating SOM output. Program text is placed into the $CODE$ section, data into $DATA$, and BSS into $BSS$.
Within the object file, the text section starts at address
0, the data section follows, and the bss section follows the data section.
When generating either SOM or ELF output files on the HPPA, the text section
starts at address
0, the data section at address 0x4000000, and the bss section follows the data section.
To let
ld know which data changes when the sections are relocated, and how to change
that data, as also writes to the object file details of the relocation needed. To perform
relocation, each time an address in the object file is mentioned, ld must know the following criteria.
Where in the object file is the beginning of this reference to an address?
How long (in bytes) is this reference?
Which section does the address refer to? What is the numeric value of (
address)-<
ffb
/FONT>(start-address of section)?
Is the reference to an address “Program-Counter relative”?
In fact, every address
as ever uses is expressed as the following.
(section) + (offset into section).
Further, most expressions as computes have this section-relative nature. (For some object formats, such as
SOM for the HPPA, some expressions are symbol-relative instead.) In this
manual we use the notation {secname N} to mean “offset N into section secname.”
Apart from text, data and bss sections you need to know about the absolute section. When
ld mixes partial programs, addresses in the absolute section remain unchanged.
For example, address {absolute 0} is “relocated” to run-time address 0 by ld. Although the linker never arranges two partial programs’ data sections with
overlapping addresses after linking, by definition their absolute sections must overlap. Address {absolute 239} in one part of a program is always the same address when the program is
running as address {absolute 239} in any other part of the program.
The idea of sections is extended to the undefined section. Any address whose section is unknown at assembly time is by
definition rendered
{undefined U}– where U is filled in later. Since numbers are always defined, the only way to
generate an undefined address is to mention an undefined symbol. A reference to a
named common block would be such a symbol: its value is unknown at assembly time so
it has section undefined.
By analogy the word section is used to describe groups of sections in the linked program.
ld puts all partial programs’ text sections in contiguous addresses in the
linked program. It is customary to refer to the text section of a program, meaning
all the addresses of all partial programs’ text sections. Likewise for data and bss sections. Some sections are manipulated by ld; others are invented for use of as and have no meaning except during assembly.
0