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]

Re: [patch/rfc] Add a sentinel frame



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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]