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: Jan Kratochvil <jan dot kratochvil 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, 03 Jan 2013 18:56:07 +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> <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> <20130103183804.GA19398@host2.jankratochvil.net>
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