Re: [RFA 4/4 take 2] Improved linker-debugger interface

[Gary Benson <gbenson@redhat.com>]

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/