This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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
_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.
Now, if we want to do this anyway, that's different. But it's a change, not a redundancy.
The missing test I mentioned above inside_entry_func, not inside_entry_file. Where'd that go?
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.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |