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