Re: [Gcl-devel] Re: function addresses and ld.so
Camm Maguire <camm@enhanced.com> writes:
> 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.
Yes, you would need such a mechanism.
> 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.
No. The property of the stub, that makes this all work, is that it's
in the GCL base executable, not a shared library. Since the
executable is loaded at a fixed address, you can safely save a pointer
into the executable's .text segment in a dump file.
There do exist platforms where the executable is _not_ loaded at a
fixed address -- there you have more problems.
>
> 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.
My expectation is that that should just work. As such, your problem
is not what I thought it was, and my advice is probably no good.
Function descriptors can't be avoided on the platforms that use them,
nor should you even try. Are you perhaps casting between object and
function pointers?
> 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.
Only that (without resorting to assembly language) there is no way to
call the real function from the stub if the real function is variadic.
> 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.
This is kind of vague, but consider the possibility of having your
Lisp memory image be structured in such a way that the unexec
operation can generate an ELF shared object. References from the
compiled code in that object to functions in the executable or system
shared libraries would then go via the PLT just as if it were compiled
code generated by a traditional batch compiler. That _should_ make
the entire problem vanish.
zw
Reply to: