This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: GDB Documentation and Request for Help
On Fri, Mar 30, 2007 at 11:26:39AM -0700, Michael Eager wrote:
> Jim Blandy wrote:
> >If you post here, I think people would be happy to explain what's
> >current and what isn't. I'll watch for your messages.
> Thanks. I think that my questions are not very specific and
> it would be better to go through the Target Arch chapter
> and mark it up.
> But here goes: what did FRAME_INIT_SAVED get replaced by?
It got replaced by an entirely demand driven system. There's only two
entry points: this_id and prev_register. Every registered unwinder
provides both.
> Or, the much more general question: when the target hits a
> breakpoint, where are the registers read and how does the
> current frame get initialized with a frame pointer? (I've
> stepped thru normal_stop, and I know it must be somewhere
> nearby, but I've not found it.)
The old model required explicitly setting up the frame, but nowadays
that isn't true. What happens is that the frame cache is cleared by a
call to reinit_frame_cache. The next time someone says
get_current_frame (), they get two things:
- A sentinel frame at "level -1". This has no particularly useful
ID, and a prev_register method that reads from the current
register cache.
- An all new frame at level 0. This doesn't have an unwinder yet;
it's just a shell.
When you ask for a register belonging to the current frame, frame.c
goes up to the next frame (the sentinel frame) and uses its
prev_register method. When you ask for the current frame's ID, or
for something below it, then frame.c finds a registered unwinder that
knows how to handle that frame.
Usually this_id and prev_register share a common cache, and the first
time either of them is called they call a cache initialization
function which does whatever necessary. For instance, parsing the
prologue, or reading DWARF unwind tables.
(Of course, doing less work up front is OK too and that's something I
plan to look into - along with better caching. The whole
infrastructure is designed to be lightweight, but it isn't always.)
--
Daniel Jacobowitz
CodeSourcery