Re: time to workaround libc/13097 in fsf gdb?

[Pedro Alves <palves@redhat.com>]

On 09/22/2014 07:35 PM, Jan Kratochvil wrote:
> Clarifying it does not fulfill this your suggestion:
> 
> On Fri, 12 Sep 2014 14:14:36 +0200, Pedro Alves wrote:
> # I was more inclined to leave the vdso in the shared library list
> # though, like ldd does, than filtering it out.
> 
> But I understand it was more a suggestion than requirement for patch acceptance.
> IMO it was request for an unrelated feature.

I don't think of it as unrelated (your original patch did that even, after all),
but also not required for acceptance.

An important goal of review and maintenance IMO is checking whether we're
taking steps in the right direction.  I hadn't identified the issues
with solib-svr4.c vs symfile-mem.c and DSO lifetimes at that point.

As I said, I've investigated this further now.  I now believe
that we're still a couple steps away from being able to list the vdso
without causing other issues.  In the patch'es commit log, I wrote:

"It would actually be nice if GDB also listed the vdso in the shared library
list, but there are some design considerations with that:

 - the vDSO is mapped by the kernel, not userspace, therefore we
   should load its symbols right from the process's start of life,
   even before glibc / the userspace loader sets up the initial DSO
   list.  The program might even be using a custom loader or no
   loader.

 - that kind of hints at that solib.c should handle retrieving shared
   library lists from more than one source, and that symfile-mem.c's
   loading of the vdso would be converted to load and relocate the
   vdso's bfd behind the target_so_ops interface.

 - and then, once glibc links in the vdso to its DSO list, we'd need
   to either:

    a) somehow hand over the vdso from one target_so_ops to the
      other
    b) or simply keep hiding glibc's entry.

And then b) seems the simplest."

IOW, I'm now convinced that making solib-svr4.c hide the vDSO is
_not_ a step backwards from making "info shared" list the vDSO.

I didn't like much the way the address matching was done though,
hence the new patch revision.

Thanks,
Pedro Alves