This is the mail archive of the
mailing list for the GDB project.
Re: time to workaround libc/13097 in fsf gdb?
- From: Pedro Alves <palves at redhat dot com>
- To: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- Cc: Doug Evans <xdje42 at gmail dot com>, "gdb-patches at sourceware dot org" <gdb-patches at sourceware dot org>
- Date: Tue, 23 Sep 2014 13:05:03 +0100
- Subject: Re: time to workaround libc/13097 in fsf gdb?
- Authentication-results: sourceware.org; auth=none
- References: <20140922183505 dot GA21660 at host2 dot jankratochvil dot net>
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
- 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
a) somehow hand over the vdso from one target_so_ops to the
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.