Adding to the shared library -- how??

[Kevin O'Gorman]

In article <7901 at killer.Dallas.TX.US> wnp at killer.Dallas.TX.US (Wolf Paul) writes:
>Is there a way to add additional routines to the shared library on a
>UNIX-PC/3b1 (3.5 software)?
>
>"file shlib" identifies shlib as a "mc68k executables (shared demand paged)" --
>is it actually an a.out file? How is the shlib.ifile built, and if it really
>is an a.out file, how does one force the order in which the routines appear
>in the a.out file?

Yes, it's an a.out file.  I did some hacking a while ago in an attempt to
build it out of the libraries that we already get with the machine.  I gave
up for reasons I'll explain in a bit, but it is not impossible.

The routines can appear in any order at all, but there's a little bit of
trickery called a "jump table" at the beginning of the section that contains
the machine instructions.  This jump table is the reason that code for the
3b1 has been binary compatible from 2.0 to 3.51, even when using the shared
libraries.

Take a look at shlib.ifile, and the values that appear in it.  You will see
that the ones that come after _tbase increase by exactly 6 for each entry
point.  The length of a long-form absolute jump instruction on the mc68000
is also 6, which is no coincidence at all.  This jump table is just a simple
piece of assembler code with a list of jump instructions to each of the
library routines which one wishes to have included in the shared library.
The libraries themselves are loaded after, and can appear in any order.

Your programs use the absolute entry points provided in the ifile, and you
pay the price of an extra jump instruction when using the shared library, but
you get in return the assurance that the address of the entry point will
not change from release to release.

You can figure out how shlib.ifile works, and how to make your own shared
library with ld(1) by reading the loader section in that "other" big book
that comes with the development set.  There used to be a couple of bugs
in the examples, mostly having to do with number bases, but the general
scheme is correct.  You will have to hand-craft your own ifile to force
the memory assignments to the shared-library memory segments.  This will
be VERY different from shlib.ifile, which is for programs that _use_ the
shared library.

When I tried to make my own shared library, I wanted to make the thing,
then do a binary compare with the "real" shared library, massage things,
and proceed until I had an exact match.  I was doing okay, and was fiddling
with the order of library inclusion, when I discovered that a VERY big
routine (something to do with forms, I think) was quite different between
the shared library and the "normal" libraries.  At that time, I did not
have a disassembler other than my own eyes and brain, and the routine is
just so huge that I decided to give up.  I was not going to take the
crash-and-burn approach to finding out if AT&T had just fumbled a bit and
the library would work anyway.  It might have.

Anyway, the project is not at all impossible, and it appears that there's
still some room in the memory map for a bigger shared library, so someone
else may have better ideas about how to proceed.