Greetings, and thank you for your helpful example! In fact, GCL uses a mechanism like this for user compiled lisp functions, known as its 'faslink' mechanism. Each call to an external function from within a compiled lisp function refers at first to a static stub, which then invokes a routine call_or_link to redirect the function pointer to the real address for subsequent calls. These addresses are stored in an array in such a manner that the user can redirect the function pointer back to the stub by setting a lisp variable use-faslinks to nil.
Your proposal below appears to have promise, but I think it would need a mechanism like the above to redirect the pointers back to the stub before unexec. The reason for this is that it appears to be common lisp usage to make incremental changes to an image, dump, and reload the next day. I won't be able to guarantee the lack of function call before unexec, therefore. Still, this should be doable. I have a few questions: 1) My understanding is that it is critical to declare the stub static, and therefore it needs to be defined in the same file housing the pointer. 2) What if some other variable in a different file defines a different pointer and assigns its value to this pointer, e.g. double (*ptr1_sqrt)(double)=ptr_sqrt; , and saves this pointer into an unexeced .data section? Don't I have the same problem? (In a separate posting, I've clarified that my problem is not in referring to symbols in external shared libs such as sqrt, but in referring to addresses in my .text section from variables unexeced into the .data section. The only difference I can see in the proposal you suggest below from what we do now is that the symbol referred to in the .text by the variable in the .data would be a variable, instead of a function per se. Would this step around the function descriptor behavior?) 3) What is the problem with variadics? GCL, being a rather old program before the era of prototypes, still casts function pointers to ((object)(*)()) in places. While not the cleanest, it does currently seem to handle variadics properly across the 11 Debian architectures. 4) Can you elaborate on your idea of having the stub _be_ the PLT stub? GCL already has quite a few low level machine specific routines, so if its not too difficult, GCL might be able to provide its own portable interface. Take care, "Zack Weinberg" <[EMAIL PROTECTED]> writes: > Richard Henderson <[EMAIL PROTECTED]> writes: > > > On Wed, Aug 13, 2003 at 04:35:36PM -0700, David Mosberger wrote: > >> Wouldn't, e.g., LD_PRELOADing something break this assumption? > > > > Yes. Or, indeed, just recompiling the library could result > > in different PLT offsets within the DSO, even on x86. > > > > This behaviour is completely broken. It'll never work reliably. > > A tactic that _will_ work is to mimic ld.so's PLT stubs. I'll use > sqrt() as an example: > > extern double sqrt(double); > static double stub_sqrt(double); > > // this is the value that gets written to the unexec file > double (*ptr_sqrt)(double) = stub_sqrt; > > double stub_sqrt(double x) > { > ptr_sqrt = sqrt; > return ptr_sqrt(x); > } > > Generate one of these stubs for every function you care about, and > bob's your uncle. Just make sure that none of the stubs get called > before the unexec file is written out. > > Unfortunately this won't work for variadic functions. > > There is no portable way that I know of to make the stub _be_ the PLT > stub, which is kind of a shame, as it would be (marginally) more > efficient and would work for variadics. > > zw > > > _______________________________________________ > Gcl-devel mailing list > [EMAIL PROTECTED] > http://mail.gnu.org/mailman/listinfo/gcl-devel > > > -- Camm Maguire [EMAIL PROTECTED] ========================================================================== "The earth is but one country, and mankind its citizens." -- Baha'u'llah