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

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

On 9/22/20 2:17 PM, Andreas Schwab wrote:
> On Sep 22 2020, Carlos O'Donell via Libc-alpha wrote:
> 
>> Yes, absolutely, I agree completely, for it to be useful the semantics
>> have to be:
>>
>> - If you detect a given symbol foo@GLIBC_DEBUG, then the feature is
>>   present and has the semantics you expect.
>>
>> - If you want new semantics then you need to make a foo2@GLIBC_DEBUG
>>   with the new semantics.
>>
>> What are the runtime semantics of the symbol? How do you access it?
> 
> Isn't that the same situation as libthread_db?

Yes, but coupled to libc.so, and doesn't require finding and loading
another matching library.

Taking that direction would mean creating a symbol in libthread_db.
In this particular case the symbol would provide the address of
the new structure that you could walk that contains the namespace
lists (that themselves contain linkmap lists).

In my opinion we should be heading towards the complete removal of
libthread_db from glibc because as an interface it requires that
the debugger load a library from a potentially untrusted filesystem
(or container) and execute code in order to debug the process.

I would rather see data-driven approaches where foo@GLIBC_DEBUG is
a data symbol and exposes a structure that can be walked to gather
information about the inferior.

It is also difficult if not impossible for a kernel-side agent to
run target code from libthread_db to resolve the result.

Keeping the symbol in libc.so avoids any debugger having to
locate the matching libthread_db, which is not always in the same
place as the library.

In summary:
- Use data symbols.
- Avoid needing to run code to resolve result.
- Keeps interface matched and in libc.so.

-- 
Cheers,
Carlos.