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

[Carlos O'Donell via Libc-alpha <libc-alpha@sourceware.org>]

On 9/16/20 12:18 PM, Daniel Walker (danielwa) wrote:
> 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.

In gdbserver I see that it's using DT_DEBUG exclusively to find _r_debug.

in gdb/solib-svr4.c:

 798   /* Find DT_DEBUG.  */
 799   if (scan_dyntag (DT_DEBUG, exec_bfd, &dyn_ptr, NULL)
 800       || scan_dyntag_auxv (DT_DEBUG, &dyn_ptr, NULL))
 801     return dyn_ptr;
 802 
 803   /* This may be a static executable.  Look for the symbol
 804      conventionally named _r_debug, as a last resort.  */
 805   msymbol = lookup_minimal_symbol ("_r_debug", NULL, symfile_objfile);
 806   if (msymbol.minsym != NULL)
 807     return BMSYMBOL_VALUE_ADDRESS (msymbol);

This code makes the most sense to me.

You look for DT_DEBUG otherwise lookup _r_debug (which is _r_debug@@GLIBC_2.2.5 on x86_64).

I would say that finding _r_debug_dlmopen would require lookup up the
symbol, not as a last resort, but as a definition of the API.

You will always have .dynsym with a definition for _r_debug_dlmopen.
 
> 2) Add another dynamic linker entry to go along with DT_DEBUG like
> DT_DEBUG_DLMOPEN.

This is one way which avoids hard coding _r_debug_dlmopen and instead
puts it into a DT_* tag, but requires we add a new tag.

I have no strong opinion here. Having the tag avoids going through
the symbol lookup, so it could have good value.

In gdbserver/linux-low.cc we have get_r_debug which doesn't do anything
but looking at DT_DEBUG. This would need changing to to lookup
_r_debug_dlmopen in that area, or DT_DEBUG_DLMOPEN.

However, looking at my i686/x86_64 system I don't see DT_DEBUG being
set so I don't know how this works with gdbserver? I could have sworn
we were using DT_DEBUG on x86... if we don't then we should fix that,
but that's another bug.

-- 
Cheers,
Carlos.