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

[Andrew Pinski]

On Wednesday, Aug 13, 2003, at 20:11 US/Eastern, Zack Weinberg wrote:

> 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.

Apple uses this exact technic in mach-o (and works with prebinding) but 
with an asm function to "bootstrap" the c function.
The stub is only called once after setting the lazy-pointer which 
points to the real function.
The mach-o stuff to do this is in the cc tools project of Darwin.


Thanks,
Andrew Pinski