[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gcl-devel] Re: function addresses and ld.so

From: Camm Maguire
Subject: Re: [Gcl-devel] Re: function addresses and ld.so
Date: 14 Aug 2003 19:26:09 -0400
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

Greetings, and thanks again for your help.

David Mosberger <address@hidden> writes:

> >>>>> On 14 Aug 2003 10:08:08 -0400, Camm Maguire <address@hidden> said:
>   Camm> Greetings, and thanks for your very helpful reply!  David
>   Camm> Mosberger <address@hidden> writes:
>   >> >>>>> On Tue, 12 Aug 2003 18:24:47 -0400, Camm Maguire
>   >> <address@hidden> 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                                            address@hidden
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]