Re: [patch/rfc] Add a sentinel frame

Andrew Cagney
2003-02-19T21:21:08Z

> 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