From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12452 invoked by alias); 24 Nov 2009 19:15:31 -0000 Received: (qmail 12442 invoked by uid 22791); 24 Nov 2009 19:15:30 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from smtp-outbound-1.vmware.com (HELO smtp-outbound-1.vmware.com) (65.115.85.69) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 24 Nov 2009 19:15:25 +0000 Received: from mailhost4.vmware.com (mailhost4.vmware.com [10.16.67.124]) by smtp-outbound-1.vmware.com (Postfix) with ESMTP id 24B0649018; Tue, 24 Nov 2009 11:15:24 -0800 (PST) Received: from [10.20.94.141] (msnyder-server.eng.vmware.com [10.20.94.141]) by mailhost4.vmware.com (Postfix) with ESMTP id 18666C9A1B; Tue, 24 Nov 2009 11:15:24 -0800 (PST) Message-ID: <4B0C2FE0.6050909@vmware.com> Date: Tue, 24 Nov 2009 21:50:00 -0000 From: Michael Snyder User-Agent: Thunderbird 1.5.0.12 (X11/20090624) MIME-Version: 1.0 To: Michael Snyder CC: Julian Smith , "gdb@sources.redhat.com" Subject: Re: Remote protocol problems after 2009 Oct 20 References: <20091124085529.96068b00.jsmith@undo-software.com> <4B0C2E95.1040303@vmware.com> In-Reply-To: <4B0C2E95.1040303@vmware.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2009-11/txt/msg00182.txt.bz2 Michael Snyder wrote: > Julian Smith wrote: >> Hello >> >> I'm working on UndoDB's support for running as a remote target, >> controlled by gdb-7's remote protocol commands, including the new >> reverse commands bc and bs. >> >> Things were working fine, but a rather large commit to gdb on 2009 Oct >> 19 (the diff is 10,000 lines long) seems to have changed something and >> UndoDB no longer works, even for simple running forwards. > > Bummer! > >> The symptom is that gdb doesn't step off of an internal (i.e. not set >> by the user) breakpoint in _dl_debug_state after starting the inferior >> but instead returns to the user. Here's the output (for gdb built from >> source dated 2009 oct 20, but the same thing happens with a gdb from a >> few days ago): >> >> GNU gdb (GDB) 7.0.50.20091019-cvs >> Copyright (C) 2009 Free Software Foundation, Inc. >> License GPLv3+: GNU GPL version 3 or later >> This is free software: you are free to change and redistribute it. >> There is NO WARRANTY, to the extent permitted by law. Type "show copying" >> and "show warranty" for details. >> This GDB was configured as "i686-pc-linux-gnu". >> For bug reporting instructions, please see: >> ... >> Reading symbols from test/_yabs/test16,cpu=i686,debug,gcc=4.3.4,os=Linux,osv=2.6.30-1-686.exe...done. >> 0xb7fc3850 in ?? () from /lib/ld-linux.so.2 >> (gdb) break main >> Breakpoint 1 at 0x8048465: file test16.c, line 13. >> (gdb) run > > OK first question -- is there any compelling reason why you > are using "run" here? With the remote target, once you are > connected, you usually want to use only "continue", not "run". > > Not saying that's the problem, but it would be nice to > take it out of the picture. > > Oh, I see from further down that you are using target > "extended-remote". Fine, that does support the "run" > command. Still, I would be interested in finding out what > happens if you used plain "target remote" and no "run". > > >> The program being debugged has been started already. >> Start it from the beginning? (y or n) y >> Starting program: test/_yabs/test16,cpu=i686,debug,gcc=4.3.4,os=Linux,osv=2.6.30-1-686.exe >> 0xb7fa7b51 in _dl_debug_state () from /lib/ld-linux.so.2 >> (gdb) >> >> With earlier builds of gdb, gdb steps off the breakpoint at >> _dl_debug_state and continues the inferior until it hits the breakpoint >> at main(). > > If you continue again from here, what happens? > > Hitting this breakpoint repeatedly is expected -- and is > not necessarily an indication that you are not making progress. > Have you tried something like "continue 100"? > > Also if you "set verbose on", you should get a shared library > message every time this breakpoint is hit. That could also give > you an indication as to whether the program is making progress. > > >> I'm running gdb with the following startup script: >> >> set remote hardware-breakpoint-limit -1 >> set remote hardware-breakpoint-packet off >> set remote software-breakpoint-packet on >> target extended-remote localhost:3000 >> >> If anyone has any ideas what might be wrong, or where to look for more >> information, i'd be very grateful. >> >> Here's the protocol log, with a few diagnostics from the UndoDB remote >> server: > > These logs are helpful, but also a little confusing due to linux > auto-randomization: the program is loading at a different base address > each time you run it. Thus the PC looks different each time even though > it is probably the same. Could you re-run the experiment with auto > randomization turned off? > > What I can tell so far is that the sequence of events up until > the "run" seems the same, and that the next thing that happens > is a stop at what is *probably* _dl_debug_state. After that > they diverge, and it would be easier to compare if we could > take the address randomization out of the picture. "set disable-randomization on", by the way. ;-)