> : I *thought* that shared libraries had their own data segments, loaded
> : at the same time as the library's text segment; certainly SunOS ones
> : do.  Under this paradigm, no space is allocated in the executable for
> : things like sys_errlist[]; it all comes from the library.  (Of course,

The arrangements made by ld(1) for references to shared library data
from ordinary (i.e. non-pic) object files, are mandated by the fact
that the executable image's segments have absolute load addresses.
Hence, instructions that refer to a data location have their address
operands completely resolved. At least, that's the goal; ld.so will
fixup still fixup any relocations that remain in the text segments,
but at the cost of making the underlying pages unshareable with other
processes.

So, we have two conflicting goals: we wish to use shared library data
content at _run time_, while we also want to know the address of
that data _now_.

The compromise implemented is this: ld notes the symbol name and the
size of the data item (both of which can be found in the shared library's
symbol table) and allocates space for it in the executable's BSS
segment. It also emits a relocation record instructing ld.so to lookup
the symbol in the shared library at run-time and to copy the contents to
the location reserved for it.

Note that references to such data from the shared library code itself
is also redirected to the copy, if one was made. Thus, if a program
has induced a copy of `sys_errlist[]', the libc routine strerror()
will also reference that copy. Otherwise, strerror() will just use
the sys_errlist[] within its own data segment (or in this case, its
text segment). This is particularly important for STD{IN,OUT,ERR},
or any other data that gets modified.


SunOS 4.x takes a different approach and stuffs all exported data into
an accompanying archive (`.sa') file, causing all referenced data to
be copied into the executable's data segment.

-pk