To: scuffer@hups.apana.org.au Cc: From: "Joel N. Weber II" <devnull@gnu.ai.mit.edu> Date: Sun, 13 Jul 1997 02:05:07 -0400 Newsgroups: linux.dev.8086 Date: Sun, 13 Jul 1997 15:43:48 +1000 (EST) From: David Murn <scuffer@hups.apana.org.au> X-Sender: scuffer@grunge.hpy.hell One idea, which might be a bit stupid, but anyway.. No, I don't think it is stupid. If we have a segment set aside, somewhere in memory. After the kernel starts up, it loads libc into that segment. When a program needs a function, say it needs 'open()', it can find the offset of that code, being in the libc segment. Jump to that code, and then return. It's a nice simple long jump. You can probably do it in such a way that the code in the functions can change without recompiling every program linked against libc. The part that makes it hard is that libc really ought to be able to get some space for its global variables in the DS that the program used. I suppose having hte space allocated at run time might work, if you pass a start address to the library entry point, although it makes access to library globals slow. Let me know if the above is incoherent. Or, another idea I had, if, as we load the program in, we load the functions we want from the libs. So when the kernel loads a program in, say if it sees some opcode there then it'll expect some sortof pointer of where to load the function code from the library. It would be easier to load the whole library, I think. That explaination isn't quite clear.
From Unofficial Linux-8086 Mailing List Archive (ULMLA)
Maintained by Robert
Robert's Mailing List Archive Page
Archive created with babymail