dlmopen and core dumps

[Jan Kratochvil]

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