dlmopen and core dumps

[Pedro Alves]

On 01/03/2013 06:38 PM, Jan Kratochvil wrote:
> 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.

You mean a single /proc/PID/mem instead of the zillions of /proc/PID/mem
accesses / syscalls, I think.  PTRACE_PEEKDATA is a red herring here.
The whole list is seldom read - usually only on attach or on explicit refresh.
During run time, with stap probes, the debugger will be reading one entry at a
time, when a DSO is loaded/unloaded.  You'd have to consider also how to update that
block around DSO loads/unloads, most specially unloads (due to the resulting hole).
It seems to me that having the loader manage this block if bound to
penalizing/slowing normal operation over debugging.  It may not be that simple.

> 
> (In the case the incremental fetch is not applicable in that moment.)
> 
> Just an idea what the new interface - if ever implemented - should support.

-- 
Pedro Alves