Re: [Gcl-devel] Re: function addresses and ld.so

[Camm Maguire]

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" <address@hidden> writes:

> Richard Henderson <address@hidden> 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
> address@hidden
> http://mail.gnu.org/mailman/listinfo/gcl-devel
> 
> 
> 

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah