This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: dlmopen and core dumps
- From: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- To: Pedro Alves <palves at redhat dot com>
- Cc: "Carlos O'Donell" <carlos at systemhalted dot org>, Roland McGrath <roland at hack dot frob dot com>, libc-alpha at sourceware dot org, gbenson at redhat dot com
- Date: Thu, 3 Jan 2013 19:38:04 +0100
- 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><CAE2sS1gnk0vCgWFpmxQVLfcNOGYU3SRXU-ZtpfBU4JFZoPo2tw@mail.gmail.com><50CB6100.7070100@redhat.com><CAE2sS1iRo8_Z1zCkGN==cU0b=-zy_4o1GpTxk02Rpq+QoFhVNw@mail.gmail.com><20121219180552.GA19512@host2.jankratochvil.net><50D20572.70002@systemhalted.org><50E5CD5D.9030100@redhat.com>
On Thu, 03 Jan 2013 19:26:37 +0100, Pedro Alves wrote:
> On 12/19/2012 06:20 PM, Carlos O'Donell wrote:
> > (3) Investigate a DWARF based declarative solution.
>
> I can split this in (at least) two variants:
>
> - always somehow provide debug info for _r_debug. IOW, the structure's fields
> and semantics would be known to the debugger, but the specific layout of the
> fields in memory would be described by the debug info, in the usual way. Walking
> the list would mean following the next pointer, as today.
>
> - somehow provide to a debugger DWARF expressions for:
>
> "Get me the address of the first entry in the DSO list."
> "Get me the value of a property XXX of this DSO".
> "I have this DSO entry. Get me the next entry."
>
> Is any of this really necessary? To me, the latter is appealing iff there
> are real plans of changing the loader's structures, _and_ removing
> _r_debug. But not if we're stuck with _r_debug forever. The former doesn't
> appear to bring that much value in compared to hard coding field offsets.
If we consider extending _r_debug the new interface could provide a single
(dynamically allocated) memory block with info about all the libraries incl.
their names, so that GDB can read it by single /proc/PID/mem read instead of
the current zillions of PTRACE_PEEKDATA of all the data scattered around.
(In the case the incremental fetch is not applicable in that moment.)
Just an idea what the new interface - if ever implemented - should support.
Jan