Re: [RFC PATCH 0/3] implement dlmopen hooks for gdb

["Daniel Walker \(danielwa\) via Libc-alpha" <libc-alpha@sourceware.org>]

On Thu, Jul 23, 2020 at 05:20:23PM -0400, Carlos O'Donell wrote:
> On 7/23/20 2:40 PM, Daniel Walker (danielwa) wrote:
> > On Fri, Jun 26, 2020 at 05:17:17PM -0400, Carlos O'Donell wrote:
> >> On 6/26/20 3:32 PM, Daniel Walker via Libc-alpha wrote:
> >>> Cisco System, Inc. has a need to have dlmopen support in gdb, which
> >>> required glibc changes. I think it was known when glibc implemented
> >>> dlmopen that gdb would not work with it.
> >>>
> >>> Since 2015 Cisco has had these patches in our inventor to fix issues in
> >>> glibc which prevented this type of gdb usage.
> >>>
> >>> This RFC is mainly to get guidance on this implementation. We have some
> >>> individuals who have signed the copyright assignment for glibc, and we
> >>> will submit these (or different patches) formally thru those channels if
> >>> no one has issues with the implementation.
> >>>
> >>> Also included in this are a couple of fixes which went along with the
> >>> original implementation.
> >>>
> >>> Please provide any comments you might have.
> >>>
> >>> Conan C Huang (3):
> >>>   Segfault when dlopen with RTLD_GLOBAL in dlmopened library
> >>>   glibc: dlopen RTLD_NOLOAD optimization
> >>>   add r_debug multiple namespaces support
> >>>
> >>>  elf/dl-close.c |  7 ++++++-
> >>>  elf/dl-debug.c | 13 ++++++++++---
> >>>  elf/dl-open.c  |  8 +++++++-
> >>>  elf/link.h     |  4 ++++
> >>>  4 files changed, 27 insertions(+), 5 deletions(-)
> >>>
> >>
> >> Thanks for looking at this. It is something the community would
> >> absolutely like to see. I'll comment quickly to provide direction.
> >>
> >> Florian Weimer, Pedro Alves, and I were talking about this as
> >> recently as April where we tried to agree to just adding a
> >> _r_debug_dlmopen with a new ABI for the debugger to use.
> >>
> > 
> > 
> > Here's another RFC I suppose. It's basic code I've only compile tested. It's
> > based on the comments, and the threads you provided. It just abstracts out the
> > next link into another structure. Let me know if this is in the ballpark of the
> > discussions.
> 
> I only looked over this briefly, but I think it's on the right track.
> 
> The point is to use *another* data symbol for the debugger to use to access
> the link maps. Then the debugger can look for that and try to use that to
> access a list of maps.
> 
> Your next step would be to export the symbol via Versions at the current
> symbol node GLIBC_2.32 (soon to be GLIBC_2.33).
> 
> The harder part will be the debugger changes because you have to look for
> _r_debug_dlmopen in preference to _r_debug, and they are different layouts,
> and once you find _r_debug_dlmopen you have to be able to maintain the
> lookup scope of the namespace you're in within the debugger.
> 


The second structure seems to work except making it available to GDB. I would
guess there are suggestions for this from you or this list.

A couple ideas,

1) GDB does pointer arithmetic off the r_debug DT_DEBUG value to find the
r_debug_dlmopen structure. Add a linker script into glibc to force the two
structures arrangement in memory, or use a section tag.

2) Add another dynamic linker entry to go along with DT_DEBUG like
DT_DEBUG_DLMOPEN.


Any other ideas for this ?

Thanks,
Daniel