Re: GDB Documentation and Request for Help

[Daniel Jacobowitz <drow@false.org>]

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