This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Gcl-devel] Re: function addresses and

Greetings!  I have a few ideas on robustification/fixing/repair of
this GCL calling convention, on which I would greatly appreciate any

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,

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

Advice appreciated,

David Mosberger <> writes:

> >>>>> On Tue, 12 Aug 2003 18:24:47 -0400, Camm Maguire <> 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

Camm Maguire	
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]