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, and thanks again for your help.

David Mosberger <> writes:

> >>>>> On 14 Aug 2003 10:08:08 -0400, Camm Maguire <> said:
>   Camm> Greetings, and thanks for your very helpful reply!  David
>   Camm> 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?
>   Camm> The code does not depend on shared library mappings being
>   Camm> identical, but only the .text, .data, and perhaps .bss
>   Camm> mappings of the executable itself being identical across
>   Camm> multiple executions.
> Ah, thanks for explaining that.  So the problem is the following:
>  - There is a function FOO whose address is stored in variable BAR and
>    both FOO and BAR are part of the executable (i.e., there is not
>    reference across shared object/executable boundaries).

This is correct.

> On ia64, the function descriptor necessary for FOO will be
> materialized at runtime (by the runtime loader) and hence there is no
> guarantee that the descriptor's address will be the same from run to
> run.  Specifically, in glibc, the root problem seems to come from
> sysdeps/generic/dl-fptr.c:make_fptr_table() calling mmap() to allocate
> memory for the descriptor table.
> So, I think the issue you're seeing occurs only on platforms where the
> function descriptors are materialized by the runtime loader (I think
> only ia64 is doing that at the moment).

This is consistent with what I am seeing.

> If this analysis is correct, I suspect there are multiple ways to fix
> the problem:
>  - One possibility might be to have the link editor reserve the
>    necessary space so that make_fptr_table() can map this reserved
>    space, rather than allocating anonymous memory via mmap().
>    Downside: requires changed to both the link-editor and the runtime
>    loader and I'm not sure how the runtime loader would locate the
>    reserved-space section.
>  - Another possibility might be to change make_fptr_table() to use
>    sbrk() instead of mmap() when it allocates the descriptor table for
>    the main program.  Downside: I'm not sure it's safe for the runtime
>    loader to change the process' break-value.
>  - A third possibility might be to materialize function pointers for
>    the executable program at link time (rather than at load time).  I
>    think the ELF symbol resolution rules would allow that, but I'm not
>    sure whether it would be easy to make these descriptors visible to
>    shared objects.
> Hmmh, none of these look terribly attractive to me.  Richard, what do
> you think?

I take it you feel that this indicates a problem needing a fix with
ldso on ia64.  Is there a workaround in GCL until such time as this
fix is in place, short of static linking?

Take care,

> 	--david

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]