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

[Camm Maguire <camm at enhanced dot com>]

Greetings, and thanks again for your help.

David Mosberger <davidm@napali.hpl.hp.com> writes:

> >>>>> On 14 Aug 2003 10:08:08 -0400, Camm Maguire <camm@enhanced.com> said:
> 
>   Camm> Greetings, and thanks for your very helpful reply!  David
>   Camm> 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?
> 
>   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			     			camm@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah