Re: Remote protocol problems after 2009 Oct 20

[Michael Snyder <msnyder@vmware.com>]

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 <http://gnu.org/licenses/gpl.html>
>>     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:
>>     <http://www.gnu.org/software/gdb/bugs/>...
>>     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.   ;-)