wnp@killer.Dallas.TX.US (Wolf Paul) (04/21/89)
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? Wolf -- Wolf N. Paul * 3387 Sam Rayburn Run * Carrollton TX 75007 * (214) 306-9101 UUCP: killer!wnp ESL: 62832882 DOMAIN: wnp@killer.dallas.tx.us TLX: 910-380-0585 EES PLANO UD
kevin@kosman.UUCP (Kevin O'Gorman) (04/22/89)
In article <7901@killer.Dallas.TX.US> wnp@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.