From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6251 invoked by alias); 28 Sep 2012 10:51:57 -0000 Received: (qmail 6243 invoked by uid 22791); 28 Sep 2012 10:51:56 -0000 X-SWARE-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED X-Spam-Check-By: sourceware.org Received: from gbenson.demon.co.uk (HELO gbenson.demon.co.uk) (80.177.220.214) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 28 Sep 2012 10:51:48 +0000 Date: Fri, 28 Sep 2012 10:51:00 -0000 From: Gary Benson To: Jan Kratochvil Cc: gdb-patches@sourceware.org Subject: Re: [RFA 4/4 take 2] Improved linker-debugger interface Message-ID: <20120928105145.GA3465@redhat.com> Mail-Followup-To: Jan Kratochvil , gdb-patches@sourceware.org References: <20120719110518.GE16185@redhat.com> <20120815172346.GA5696@host2.jankratochvil.net> <20120919094933.GA3023@redhat.com> <20120919111422.GA17988@host2.jankratochvil.net> <20120919150622.GA7647@redhat.com> <20120919151255.GA5436@host2.jankratochvil.net> <20120921123555.GA6449@redhat.com> <20120921144543.GA23658@host2.jankratochvil.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120921144543.GA23658@host2.jankratochvil.net> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2012-09/txt/msg00677.txt.bz2 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 > 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 although that is > an add-on optional feature. The major reason for implementing > 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/