Unix PC ".lib" section (Was Re: UNIXpc per-process VM limit)

[Mike "Ford" Ditto]

In article <1006 at umbc3.UMD.EDU> alex at umbc3.UMD.EDU (Alex S. Crain) writes:
>	The .lib section is an illusion, because its always empty in loaded
>code (code that has no relocateable symbols). I would guess that its purpose
>is to provide shared-library linking information for *relocateable* object
>files, although I haven't tested this out.

That's close... the .lib section is always empty, and the only
information it carries is simply by its presence.  When the kernel
exec's a file (maps it into memory) it checks whether it has a ".lib"
section.  If the .lib section is there, then the kernel also maps in
the file "/lib/shlib".  The Unix PC shared library feature is a
primitive version of what was eventually put into SysV release 3.  In
SVR3, the .lib section contains the name of the shared library to use;
the Unix PC has the name "/lib/shlib" hard-coded into the kernel, so
the contents of the .lib section are never looked at.

>					    This would be neccessay though,
>because if you linked an object file into shlib, and then linked it to another
>object that used the same library call, you would have to make sure that they
>both used shlib, even if the second link was done without explicitly linking
>to the library.

I think making a relocatable file with /lib/shlib.ifile already linked
in would be a very strange thing to do.  It would probably work though,
because ld would put all the shlib symbols in the file.  Then you could
link that to another file(s) and get a non-relocatable executable.

>	I haven't seen a .lib that contained anything yet (except a header
>and a segment of length 0), so I don't know whats in it. If the above is even
>close to correct, though, then .lib could in fact be stripped out without
>a problem, after the file has fully linked.

No, if the .lib section isn't there, the program will have no access to
the shlib memory at 0x300000, and it will get a bus error very quickly.

>					     You would also have to modify the
>file header to reflect the missing section header, and since there isn't an 
>easy way to do that (editing object code is sooooo icky), I didn't try.

I just tried it, it's easy with Emacs.  I just renamed the .lib section
and it still worked.  I had to delete the section (actually just change
filehdr.f_nscns from 4 to 3) to make it fail.  Now the program gets
"Memory fault - core dumped" just because that one byte is changed.
So, evidently, the kernel just looks at the number of sections to
decide whether to use the shared library or not.

>	The reason that you can move everything around without a problem
>is that the shared library is effectively in its own segment. All references
>into shlib must use absolute addresses, or offset from the segment address,
>because there can be no relative addressing accross segments.

What are you talking about?  There are no segments on the 68000.
Perhaps you mean sections (as in text section, data section, etc.)?
The shared library is not in any of the sections that are in the a.out
file.  It is in the text, data, and bss sections of /lib/shlib, which
appear at a constant place in the address space of a process which was
run from an executable file with a .lib section.  /lib/shlib.ifile
tells the linker where those constant places are so it can have your
program call them.  /lib/shlib.ifile is also where the ".lib" section
comes from (line 14).

					-=] Ford [=-

"Once there were parking lots,		(In Real Life:  Mike Ditto)
now it's a peaceful oasis.		ford%kenobi at crash.CTS.COM
This was a Pizza Hut,			...!sdcsvax!crash!kenobi!ford
now it's all covered with daisies." -- Talking Heads