Re: RFC: Mark outer frames

[Joel Brobecker <brobecker@adacore.com>]

> 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