This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFA 4/4 take 2] Improved linker-debugger interface
Jan Kratochvil wrote:
> On Fri, 21 Sep 2012 14:35:56 +0200, Gary Benson wrote:
> > I've also passed --with-expat to force the issue. I'm not seeing the
> > XML warning any more, but the tests are still using the probes code
> > and not the code from linux-low.c.
>
> The tests are using linux-low.c:
>
> ../gdb gdb.base/break-probes -ex 'target remote localhost:1234' -ex 'set stop-on-solib-events 1' -ex 'set debug remote 1' -ex c
> [...]
> Sending packet: $qXfer:libraries-svr4:read::0,fff#91...Packet received: l<library-list-svr4 version="1.0" main-lm="0x7ffff7ffe2a8"><library name="/lib64/ld-linux-x86-64.so.2" lm="0x7ffff7ffd998" l_addr="0x7ffff7ddc000" l_ld="0x7ffff7ffcdd8"/></library-list-svr4>
> SVR4:PASS
> Sending packet: $z0,7ffff7ddf702,1#00...Packet received: OK
> [...]
> Sending packet: $z0,7ffff7df0285,1#d2...Packet received: OK
> Stopped due to shared library event (no libraries added or removed)
> (gdb) _
>
> It has stopped on probe due to stop_on_solib_events == 1 but that is unrelated
> to how solib-svr4.c fetches the library list.
I'm seeing this too now. I think I assumed gdbserver would be
responsible for everything, but that's not the case; gdb sets the
breakpoints, so in this configuration it's stopping at the probes
breakpoints but using the old-style code in linux-low.c to fetch
the library list. This explains why the testcases see the probes
breakpoints, and why the check for PR 2328 doesn't segfault.
> I see the implementation for the linux-low.c side may not be so easy
> as I thought about before.
>
> GDB still needs to stop at the stap probes as it does but:
>
> * gdbserver needs to fetch probe arguments on its own. Therefore GDB client
> needs to compile the arguments into AX (agent-expression) and upload them
> to gdbserver. gdbserver then can do the incremental fetching of solist
> entries like solib-svr4.c with your patches does.
>
> * svr4_handle_solib_event should disable updating the local list of shared
> libraries as svr4_current_sos->svr4_current_sos_via_xfer_libraries will
> accomplish everything without needing svr4_handle_solib_event.
>
> * It could transfer only differences of <library-list-svr4> although that is
> an add-on optional feature. The major reason for implementing
> <library-list-svr4> was the high amount of pings over long latency links.
> The amound of transferred data over wire may not be such a concern.
> Although with your high-performance solib goals it may be also your goal.
>
> I had to clear it up for myself so I wrote it down, I hope I have it
> right.
Ah, I wondered if the stap code was in gdbserver, but apparently not.
dlmopen support requires the local cache that incremental updating
uses, because when you stop to update a namespace's so_list you can
only see the address of that namespace in the inferior. The other
namespace's so_lists are fetched from the cache, so either gdb or
gdbserver will have to maintain a cache somewhere. I'm tempted to
retain the cache in gdb, and have gdbserver send namespace updates.
I'm trying to understand the existing interface between gdb and
gdbserver. Does gdb request a library list and gdbserver send one,
or does gdbserver recognise the stop and send one, and gdb assumes
it's been sent one and try to read it?
Thanks,
Gary
--
http://gbenson.net/