Re: [patch/rfc] Add a sentinel frame

[Andrew Cagney <ac131313@redhat.com>]

> Oh, but you're misunderstanding.  There's more than one frame in there. 
> The call stack in glibc looks like:
>   _start
>   calls __libc_start_main
>   calls main

Nope, that assumes glibc.  Remember, i debugged this using the d10v.

> _start is written in assembly; it generally doesn't have a frame worth
> talking about.  Even if we want to show __libc_start_main, we can't
> safely backtrace into _start.  That's what the inside_entry_file
> (frame_pc_unwind (fi)) is for.

Why not?  If someone wants to do that, why should we stand in their way :-)

> Now, if we want to do this anyway, that's different.  But it's a
> change, not a redundancy.

The entire get_prev_frame is change.  It should only affect targets 
converted to the new code though (if it wasn't for this sentinel edge 
condition).

> The missing test I mentioned above inside_entry_func, not
> inside_entry_file.  Where'd that go?

Left until something that does need it surfaces.

>> As things progress, and more targets switch to the new code, the tests 
>> in get_prev_frame will most likely evolve.  However, I don't know that 
>> we want to be adding tests without hard evidence that they are needed :-/
>> 
>> Having said that, sanity checks that the frame didn't go backwards:
>> 	!frame_id_inner (frame_id, get_frame_id (next_frame))?
> 
> 
> Yes.
> 
> 
>> and that they changed:
>> 	!frame_id_eq (frame_id, get_frame_id (next_frame))?
> 
> 
> Can we do that?  Hmm, we probably can.  A frame ID has a PC in it and a
> stack pointer, and if neither has changed we're probably stuck in a
> rut.

legacy_get_prev_frame() contains exactly that test.

Andrew