Subject: Re: RRS Relocation Entry
To: John F. Woods <jfw@ksr.com>
From: Paul Kranenburg <pk@cs.few.eur.nl>
List: current-users
Date: 02/26/1994 17:46:06
>
> (2) What does the complaint from ld mean? What is an RRS Relocation Entry,
> and why is it so noteworthy?
>
When linking against shared libraries, ld arranges for ld.so to finish the
relocation jobs for symbols that are actually defined in those shared
libraries. Only at run-time the actual load addresses of the shared library
are known. To avoid scribbling into a the text segment of program as a result
of such run-time relocations (eg. to update the address portion of a `call'
instruction) the linker diverts the call to an entry in a jumptable of which
it does know the address (because it's built into the program at link time).
Run-time relocation now consists of updating the entry in the jump table
in stead of the location of the original call instruction.
The problem is that jump tables can only be used for function calls; they
are no use for accessing data that happens to reside in the text segment,
such as string constants or other data declared `const' which the compiler
stashes in the text segment. To help in discriminating true function calls
from data with the N_TEXT attribute the compiler emits .type directives
that specify the nature of the symbol it pertains to. The linker uses
this information to decide whether or not a jump table slot should allocated
for the relocation request at hand. If ld does not have positive information
that a particular relocation is in fact a function call to a shared library
resident function, it does not allocated a jump slot and emits a run-time
relocation for the address in text segment in stead. If this happens, you'll
see this (by now notorious) warning message.
-pk
------------------------------------------------------------------------------