>>> I *thought* that shared libraries had their own data segments,
>>> loaded at the same time as the library's text segment; [...]

> 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 [...]

It is?  When I ran nm -a -p on /usr/lib/libc.so.12.20, no symbols of
type S (or s) were listed.  Is this a change more recent than version
12.20 of libc?  (This was on a SPARC.)

Incidentally, nm (as of the approximately-1.3 source tree I have) can
print several symbol type letters that aren't documented in the
manpage.

Those aside...yes, that explains what's going on.  Given that half the
point of shared libraries is painless library upgrades, this seems at
least somewhat broken to me.  I'd be tempted to suggest turning
sys_errlist into "const char * const * const" instead of the current
"const char * const []", except that that doesn't fix the real problem,
it just papers over it in this case (and perhaps not even that; I
haven't thought about it much, precisely because it's not a real fix).

The best fix, I think, is to record in the executable the size ld
assumed for each object, and generate relocations telling ld.so where
the references to it are.  Then, if ld.so finds that the symbol size in
the library at run-time matches the size recorded at link-time, it
ignores those relocations and copies the data into the bss segment;
otherwise, it leaves the data in the shared library and relocates all
references to refer to it.  This always gets the semantics correct,
paying the penalty of not sharing text pages only when it can't be
avoided.  (Another penalty is some wasted bss space when a mismatch is
found; I don't consider this to be a problem.)

Of course, it would also mean someone would have to do it; the code
isn't going to write itself. :-(

> 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.

I'm fairly sure I've used .so libraries under SunOS with nontrivial
data segments and without generating .sa files, and they've at least
basically worked, so *something* right happens.  (Perhaps this just
made ld.so do more work and rendered a bunch of text pages
nonshareable....)

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B