This is the mail archive of the
mailing list for the GCC project.
Re: [Gcl-devel] Re: function addresses and ld.so
>>>>> On 14 Aug 2003 10:08:08 -0400, Camm Maguire <firstname.lastname@example.org> said:
Camm> Greetings, and thanks for your very helpful reply! David
Camm> Mosberger <email@example.com> writes:
>> >>>>> On Tue, 12 Aug 2003 18:24:47 -0400, Camm Maguire
>> <firstname.lastname@example.org> 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
- 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
- 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
Hmmh, none of these look terribly attractive to me. Richard, what do