Some of these relocations are available for ECOFF, but mostly only for ELF. They are modeled after the relocation format introduced in Digital Unix 4.0, but there are additions.
The format is `!tag' or `!tag!number' where tag is the name of the relocation. In some cases number is used to relate specific instructions.
The relocation is placed at the end of the instruction like so:
ldah $0,a($29) !gprelhigh lda $0,a($0) !gprellow ldq $1,b($29) !literal!100 ldl $2,0($1) !lituse_base!100
ldqinstruction to load the address of a symbol from the GOT.
A sequence number N is optional, and if present is used to pair
lituse relocations with this
literal relocation. The
lituse relocations are used by the linker to optimize the code
based on the final location of the symbol.
Note that these optimizations are dependent on the data flow of the
program. Therefore, if any
lituse is paired with a
literal relocation, then all uses of the register set by
literal instruction must also be marked with
relocations. This is because the original
may be deleted or transformed into another instruction.
Also note that there may be a one-to-many relationship between
lituse, but not a many-to-one. That is, if
there are two code paths that load up the same address and feed the
value to a single use, then the use may not use a
ldl) to indicate that the literal is used for an address load. The offset field of the instruction must be zero. During relaxation, the code may be altered to use a gp-relative load.
jsr) to indicate that the literal is used for a call. During relaxation, the code may be altered to use a direct branch (e.g.
lituse_jsr, but also that this call cannot be vectored through a PLT entry. This is useful for functions with special calling conventions which do not allow the normal call-clobbered registers to be clobbered.
extbl) to indicate that only the low 3 bits of the address are relevant. During relaxation, the code may be altered to use an immediate instead of a register shift.
ldqinstruction may not be altered or deleted. This is useful in conjunction with
lituse_jsrto test whether a weak symbol is defined.
ldq $27,foo($29) !literal!1 beq $27,is_undef !lituse_addr!1 jsr $26,($27),foo !lituse_jsr!1
__tls_get_addrused to compute the address of the thread-local storage variable whose descriptor was loaded with
__tls_get_addrused to compute the address of the base of the thread-local storage block for the current module. The descriptor for the module must have been loaded with
ldato load the GP from the current address, a-la the
ldgpmacro. The source register for the
ldahinstruction must contain the address of the
ldahinstruction. There must be exactly one
ldainstruction paired with the
ldahinstruction, though it may appear anywhere in the instruction stream. The immediate operands must be zero.
bsr $26,foo ldah $29,0($26) !gpdisp!1 lda $29,0($29) !gpdisp!1
ldahinstruction to add the high 16 bits of a 32-bit displacement from the GP.
$27or perform a standard GP load in the first two instructions via the
ldainstruction to load the address of a TLS descriptor for a symbol in the GOT.
The sequence number N is optional, and if present it used to
pair the descriptor load with both the
literal loading the
address of the
__tls_get_addr function and the
marking the call to that function.
For proper relaxation, both the
lituse relocations must be in the same extended basic block.
That is, the relocation with the lowest address must be executed
first at runtime.
ldainstruction to load the address of a TLS descriptor for the current module in the GOT.
Similar in other respects to
ldqinstruction to load the offset of the TLS symbol within its module's thread-local storage block. Also known as the dynamic thread pointer offset or dtp-relative offset.
gprelrelocations except they compute dtp-relative offsets.
ldqinstruction to load the offset of the TLS symbol from the thread pointer. Also known as the tp-relative offset.
gprelrelocations except they compute tp-relative offsets.