Remote protocol problems after 2009 Oct 20
Michael Snyder
msnyder@vmware.com
Tue Nov 24 21:50:00 GMT 2009
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. ;-)
More information about the Gdb
mailing list