fde-glibc.c bug

[Jakub Jelinek <jakub at redhat dot com>]

Moving to more appropriate mailing lists.

For wider audience, here is the problem description:

There is a bug in gcc/config/ia64/fde-glibc.c:
      ret = find_fde_for_dso ((Elf64_Addr)pc, (Elf64_Ehdr *)map->l_addr,
                                                            ^^^^^^^^^^^
                              segment_base, gp);
this will work only as long as the shared library in question has first
PT_LOAD segment's p_vaddr == 0.
E.g. with ELF prelinking this is almost never true though, so what you really
want is map->l_map_start (map->l_addr will be almost always 0) or even
better map->l_phdr/map->l_phnum pair.
Unfortunately,
map->l_map_start is not at beginning of (struct link_map *), not even in the
public part of struct link_map, and before l_map_start is a bunch of
elements
which change over the time (l_info grows from time to time, l_searchlist and
l_symbolic_searchlist recently shrunk, similarly with l_phdr/l_phnum.
l_addr is not the address of ElfW(Ehdr) though, it is the difference between
library's virtual addresses and where it was mapped to.
Comment above l_map_start mentions the difference:
    /* Start and finish of memory map for this object.  l_map_start
       need not be the same as l_addr.  */
    ElfW(Addr) l_map_start, l_map_end;

On Mon, Jul 02, 2001 at 03:05:43PM -0700, Ulrich Drepper wrote:
> Jakub Jelinek <jakub@redhat.com> writes:
> 
> > So do you prefer exporting something like l_ehdr which will be a pointer to
> > ElfW(Ehdr) wherever it is, or what else do you suggest for fde-glibc.c?
> 
> I haven't looked at the problem and won't do it.  Not my job.  I'll
> not accept any additional exposure of existing data structures and no
> new global variables.

Ok, in that case I guess the only remaining solution is to do what
fde-glibc.c does inside of glibc, so that glibc internals don't have to be
exposed, because I don't think fde-glibc.c can find the ELF headers of
shared libraries just from the link_map exported portion.
This would have major advantages IMHO (like __ia64_app_header can be gone
and with little kernel work it will work just fine even for static programs
dlopening other libraries).
The drawback would be that _Unwind_FindTableEntry interface would need to be
exposed (as _Unwind_FindTableEntry would be provided by glibc, the rest of 
the unwinding stuff would be provided by libgcc_s.so.1.

I said above little kernel work, what I had in mind is binfmt_elf.c setting
up full aux vector instead of just filling AT_HWCAP/AT_PLATFORM/AT_NULL
(well, AT_PHDR/AT_PHNUM/AT_PHENT would be enough). Then _dl_aux_init
could just record static binary's phdr/phnum (fde-glibc.c actually wants
Elf64_Phdr, access to Elf64_Ehdr is not necessary) and
_Unwind_FindTableEntry implementation could use that later on.

	Jakub