> On Jan 20, 2020, at 17:37 , Chris Johns <chr...@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.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
