This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: RFC: Mark outer frames
- From: Joel Brobecker <brobecker at adacore dot com>
- To: gdb-patches at sourceware dot org
- Date: Thu, 3 Sep 2009 15:52:19 -0700
- Subject: Re: RFC: Mark outer frames
- References: <20090828213237.GA9175@caradoc.them.org>
> This patch was originally for an entirely different problem, namely,
> the dreaded "Value is not active" error. What happens with that is
> that we connect to some target, and we're in the middle of its startup
> code before there's a stack frame. No unwinder thinks we have a way
> out of this frame, so nothing returns a valid this_id. So the frame
> id is null_frame_id - which is overloaded to mean 'unknown id' and
> 'no frame at all'. The value checks are using it one way and the
> unwinder is using it the other.
I just started looking at PR/9786:
info frame: generates an error when remote debugging
Basically, on x86:
(gdb) target rem :4444
Remote debugging using :4444
0xb7f6d840 in _start () from /lib/ld-linux.so.2
(gdb) info frame
Stack level 0, frame at 0x0:
eip = 0xb7f6d840 in _start; saved eip
/[...]/findvar.c:304: internal-error: value_of_register_lazy: Assertion `frame_id_p (get_frame_id (frame))' failed.
This is the same issue as above, I believe, and your patch fixes
the issue too. After applying it, I get:
(gdb) info frame
Stack level 0, frame at 0x0:
eip = 0xb7f6d840 in _start; saved eip 0xb7f6d840
Outermost frame: unwinder did not report frame ID
Arglist at unknown address.
Locals at unknown address, Previous frame's sp in esp
So, should we apply you patch? (we don't have time for much else
except trying to see if we could plug that particular hole with
a temporary, localized, patch...
--
Joel