This is the mail archive of the
mailing list for the GCC project.
Re: [Gcl-devel] Re: function addresses and ld.so
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
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.
"Zack Weinberg" <firstname.lastname@example.org> writes:
> Richard Henderson <email@example.com> 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.
> Gcl-devel mailing list
Camm Maguire firstname.lastname@example.org
"The earth is but one country, and mankind its citizens." -- Baha'u'llah