This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: dlmopen and core dumps


On 12/13/2012 09:40 PM, Roland McGrath wrote:
>> Is that because r_debug->r_map won't contain anything not in the
>> initial namespace?
> 
> Yes.
> 
>> What do core dumps have to do with this? Isn't it the same problem in
>> a live process?
> 
> As Gary said, the sdt probes recently added give a mechanism for a debugger
> to catch loading events in any namespace.  It's not just core dumps that
> have the lack, but also attaching to an existing process after a secondary
> namespace has already had objects loaded.

Yes.

In the case of in-process code that needs to do introspection,
dl_iterate_phdr also misses the other namespaces, right?

> Nowadays, we have an entirely different and IMHO much better option for
> this sort of thing.  I've said before that I want to see GDB abandon
> using libthread_db in favor of this approach too.  That is, the same
> approach GDB now supports for application-specific pretty-printing:
> Python code to run in GDB that comes with the application.  Just as
> libstdc++ now comes with Python code to pretty-print STL data
> structures, libc can come with Python code to interpret its internal
> ld.so and libpthread data structures.  That code can know all manner of
> internals about the implementation, because it goes with the debuggee
> code rather than with the debugger code.

There are other debuggers and tools besides GDB.  GDB itself is using
Python 2 today, Python 3 support has just been added, and who knows what

scripting languages will it support going forward.
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.

(Looking through my crystal ball, I'm going to guess people at some point
will want to stuff this new file into a section in libc's binary to it
always easily available, which makes me kind of go full circle and think
that's all not really much different from just looking for r_debug)

-- 
Pedro Alves


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]