wilber@alice.UUCP (07/04/88)
Is there any way to add new object files to the shared library? Presumably
they'd have to be appended at the end so as not to destroy the offsets to the
existing modules. Can it be done? How?
Bob Wilber UUCP: {allegra, mtune, ihnp4}!gauss!wilber
ARPA: wilber@research.att.comkevin@kosman.UUCP (Kevin O'Gorman) (07/06/88)
In article <8021@alice.UUCP> wilber@alice.UUCP writes: >Is there any way to add new object files to the shared library? Presumably >they'd have to be appended at the end so as not to destroy the offsets to the >existing modules. Can it be done? How? > >Bob Wilber UUCP: {allegra, mtune, ihnp4}!gauss!wilber > ARPA: wilber@research.att.com Well, I did some hacking on this problem just last week, and I gave up. I was going to try to see if I could duplicate /lib/shlib with the materials at hand. In prinicple it seemed worth trying. I ran into a few small routines just after the jump table that were different: brk(), sbrk() and a couple of things I didn't recognize. Then, it looked like everything else had been loaded from a library. Hoping that the libraries used were the ones we have, I had a go. I got an output that had about the same size as /lib/shlib, with the right addresses and all. Then I tried comparing the address maps to see where the differences might be. Unfortunately, it turns out that the Tam library is the next one that was linked into shlib, and form() is different. I have no idea what is different, and form() is so big I was not about to hack it, and I didn't have the courage to just go ahead and build the library and hope for the best. There are two possible ways to work on this problem. You could try to duplicate /lib/shlib as I did, and hope that the pieces where /lib/shlib is different from the non-shared libraries is just a mistake in software control (possible, given other things I've seen), or you could get really risky and decompile the stuff in violation of who knows what. The other idea involves the link editor. /lib/shlib is just a common object file, presumably output by ld(1). It has been stripped, so you cannot link to its symbols, but I wonder if you could link other stuff to it? I don't know what happens when you pass an address-bound object as input to ld. I wasn't ready to try that, either, because I had had my heart set on being able to extend the jump table. This is not really possible as things stand. You would have to have your own jump table, located after all the present library, with uncertain address assignments. It would be a kludge, but if you could build it, it could work.