This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: dlmopen and core dumps
- From: Pedro Alves <palves at redhat dot com>
- To: Roland McGrath <roland at hack dot frob dot com>
- Cc: "Carlos O'Donell" <carlos at systemhalted dot org>, libc-alpha at sourceware dot org, gbenson at redhat dot com
- Date: Thu, 03 Jan 2013 18:23:41 +0000
- Subject: Re: dlmopen and core dumps
- References: <20121105132108.GA4305@redhat.com> <CAE2sS1j8pNMhgunxNHvCofR-TuiJYk9HVTWk5OYz0MQN2_GuDg@mail.gmail.com> <20121213214047.4D5652C0BF@topped-with-meat.com> <50CB55A5.2020007@redhat.com> <20121218001440.4E8042C092@topped-with-meat.com>
Sorry for the delay. I had been on vacation these past weeks.
On 12/18/2012 12:14 AM, Roland McGrath wrote:
>> In the case of in-process code that needs to do introspection,
>> dl_iterate_phdr also misses the other namespaces, right?
>
> Yes. Which is to say, it always reports about the namespace containing
> the caller of dl_iterate_phdr.
>
>> If going the external-file route, I'd much rather glibc provided a
>> declarative file, that describes where to find things, in a
>> non-procedural way. That could then be consumed by GDB in python, GDB
>> native code, or whatever else wants to get at the info.
>
> I'd like that too. I was hoping for such a thing to be an option for the
> pretty-printers too years ago now, before the Python method was chosen by
> the GDB camp. As there is today no such general declarative facility
> available to drive GDB, complaining about some application or library not
> using it is a non sequitur.
Any solution we come up with will need coding in GDB _and_ in gdbserver,
along with other debuggers, even if going the Python way. So, no, it's not.
> The options available today are GDB's Python
> support and hard-coded knowledge of data structure layouts in GDB.
The latter isn't really a problem, as long as a structure is considered
ABI and hence doesn't change layout incompatibly.
--
Pedro Alves