Re: [Gcl-devel] Re: function addresses and ld.so
Greetings! I have a few ideas on robustification/fixing/repair of
this GCL calling convention, on which I would greatly appreciate any
advice:
1) statically link on function descriptor platforms -- not a fix by
any means, but should stabilize things quickly. (I.e. if the
executable is statically linked, then surely nothing can go wrong,
right?)
2) PLT stub mimicing
3) Do a poor man's relocation on startup. Save some address in .text
and .data in a variable unexeced into the .data, and check the
actual value on startup vs. the saved value. Add a single fixed
offset to the function pointers accordingly. Will this work?
4) Most ambitiously/foolishly, write reloc records into the executable
when unexecing, and let ld.so do the magic.
Advice appreciated,
David Mosberger <davidm@napali.hpl.hp.com> writes:
> >>>>> On Tue, 12 Aug 2003 18:24:47 -0400, Camm Maguire <camm@enhanced.com> said:
>
> Camm> GCL stores addresses of its functions in data structures
> Camm> allocated in the normal way in its .data section. It then
> Camm> runs an unexec routine which saves the memory image including
> Camm> these addresses to a file.
>
> Isn't this a dangerous thing to do even on non-function-descriptor
> architectures? If I understand you right, GCL depends on the loader
> mapping the shared objects on subsequent executions at the exact same
> location as during the original execution. Wouldn't, e.g.,
> LD_PRELOADing something break this assumption?
>
> --david
>
>
> _______________________________________________
> Gcl-devel mailing list
> Gcl-devel@gnu.org
> http://mail.gnu.org/mailman/listinfo/gcl-devel
>
>
>
--
Camm Maguire camm@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
Reply to: