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

[David Mosberger]

>>>>> 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).

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).

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?

        --david