How does the dynamic loader (libdl) hook in to gdb?

[dufault at hda.com]

> On Jan 20, 2020, at 17:37 , Chris Johns <chrisj at rtems.org> wrote:
> 
> Hi Peter,
> 
> Happy new year.
> 
> On 17/1/20 9:01 am, Peter Dufault wrote:
>> I'm trying to hook the SLAC / Til Straumann PowerPC remote debugger stub in to what's loaded by "libdl" via "dlopen()".  *I know* this should be integrated into "libdebugger", and I do keep my eye on that, but I need to keep what is working working and working well.
>> 
>> The "libdl" code has support for GDB both finding out when shared libraries are loaded and resolving the new symbols in "rtl-debugger.c".  It's based on NetBSD and Android.  I don't know how to get this code to kick in.
> 
> You need a patch for GDB that enables the needed functionality in an RTEMS build
> of GDB. Have a look at the 2013 GSoC project's work ...
> 
> https://lists.rtems.org/pipermail/devel/2013-September/004644.html
> 
> The patch was never merged into gdb and as GDB has changed to C++ I doubt it
> will apply cleanly so it needs to be reworked and submitted.

I am trying to avoid changing GDB.  I think I have, but I need a little more time to verify it and add the last few hooks.  I don't have access to my work-in-progress when at HDA (it will be available for merge) but roughly:
- I've modified the SLAC debugger stub to support "qXfer:libraries:read:annex:offset,length" in order to read back what SVR4 style libraries are loaded.  This expects an exact ordered list of certain sections (without names) returned in XML.
- I've modified "libdl" to generate a report of the sections that GDB expects to receive in response the that query.  It's almost what is present to support the special RTEMS target stub, but you've collapsed the number of sections reported.  The stub needs to report sections such as (something like) ".rdonly-rela" in addition to ".rdonly" (sorry, not looking at the code).  This was straight-forward.
- After loading a library I can do "info sharedlibrary" in "gdb" and it will request the loaded libraries from the stub and then I can access the symbols.
- The final step will be to do sort of what GDB does for in-process run-time-linker support: Add a special GDB-stub-only breakpoint that GDB doesn't know about in the "_rtld_debug_state()" function that "libdl" calls whenever it loads or unloads a library.  The SLAC stub will then send an asynchronous stop message to GDB that the libraries have changed, and GDB will read back the info using the "qXfer:libraries" command.  Yes, I added GDB non-stop support to the SLAC remote debugger, and it works well.  I had to do that because the SLAC stub already supported a custom non-stop mode and I didn't want a regression.  All of this, once tested more, will be available or if someone really wants it I'll send it right now.

(...)

>  Also I am not sure what happens
> with the extra sections that have been added since this work was done, for
> example on the PowerPC the small data allocations. You would need to chase down
> what happens here.

I think this will work unchanged with the approach I'm using.  However, the small data allocations for PowerPC definitely have a bug associated with how much space is allocated that ends up trashing the heap. This has nothing to do with reading back the symbols, it's a "libdl" bug that I plan to document.  I tried to characterize it (without a debugger working well after loading new items) but gave up and compiled the application with "-mno-sdata".  I plan to get back to that as time permits once GDB is working properly with the loaded libraries.  I think it does not allocate enough space for where it loads items, "malloc walk" will detect the corruption but I deferred debugging it for now.

A final point about debugging "libdl": the heap allocation lock in "libdl" makes it tough to debug using a network debugger since at least the old network stack uses the heap.  It took me a little while to figure that out.

Peter
-----------------
Peter Dufault
HD Associates, Inc.      Software and System Engineering

This email is delivered through the public internet using protocols subject to interception and tampering.