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.