This is the mail archive of the
gdb-patches@sourceware.cygnus.com
mailing list for the GDB project.
Re: patch to make 'until location' work better
- To: msnyder@cygnus.com (Michael Snyder)
- Subject: Re: patch to make 'until location' work better
- From: toddpw@wrs.com (Todd Whitesel)
- Date: Tue, 11 May 1999 17:44:26 -0700 (PDT)
- Cc: toddpw@wrs.com (Todd Whitesel), gdb-patches@sourceware.cygnus.com (GDB Patches), shebs@cygnus.com
Ugh, this is embarrassing, it appears the bug was fixed in 4.18, in a totally
different place from where I fixed it. Since I wasn't expecting that, I didn't
check to be sure it wasn't already fixed. Our local sources are still mostly
4.17 era, and my solaris native reference 4.17 exhibits the bug also.
> OK. Could you tell me what the specific complaint was, then?
Sure, that's easy. Use 'until location' to run to a point that is not in the
function associated with selected_frame, but will be executed before the
selected_frame returns.
The .orig code sets the frame of the 'location' breakpoint to selected_frame,
but this only makes sense if 'location' can be hit with its current_frame
equal to selected_frame. If 'location' is not even in that function, then the
frames will never be equal when the breakpoint is actually hit, and the bpstat
logic was quietly resuming past the breakpoint as if the breakpoint weren't
really set. Next'ing through factorial() or any other recursive function tends
to need this machinery.
void a()
{
puts("hi");
}
void main()
{
a();
}
b main
run
until a
The program exits instead of stopping at a().
> And if possible, how to reproduce it?
Drop back to GDB 4.17. I've now checked my reference 4.18, and the last tar
snapshot I had downloaded, and they both seem to have this bug fixed. Perhaps
they are doing the same check as my patch, only later, when the breakpoint is
hit instead of when it is created ??
--
Todd Whitesel
toddpw @ wrs.com