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 <[EMAIL PROTECTED]> writes: > >>>>> On Tue, 12 Aug 2003 18:24:47 -0400, Camm Maguire <[EMAIL PROTECTED]> > >>>>> 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 > [EMAIL PROTECTED] > http://mail.gnu.org/mailman/listinfo/gcl-devel > > > -- Camm Maguire [EMAIL PROTECTED] ========================================================================== "The earth is but one country, and mankind its citizens." -- Baha'u'llah
