This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: NULL selected/current frame; Was: [patch/rfc] Add frame_read_signed/unsigned_register(); convert h8300 to print_registers_info()
On Wed, Oct 23, 2002 at 12:47:57PM -0400, Andrew Cagney wrote:
>
> >> void
> >>+frame_read_unsigned_register (struct frame_info *frame, int regnum,
> >>+ ULONGEST *val)
> >>+{
> >>+ frame_unwind_unsigned_register (get_next_frame (frame), regnum, val);
> >>+}
> >
> >
> >So, the register belonging to this frame.
>
> Yes. The old roughly equivalent function was get_saved_register.
>
> >That means the register
> >which would be in the hardware registers if this frame were current,
> >right?
>
> To be pedantic, no. A frame's registers are ALWAYS found by unwinding
> get_next_frame(FRAME). It just so happens that registers unwound from
> get_next_frame(current_frame) come from the register cache.
>
> The difference is subtle but important. current_frame isn't the special
> case, get_next_frame(current_frame) is. Unfortunatly much of the GDB
> code treated ``current_frame'' as special creating unnecessary
> complexity and ongoing confusion. Per generic_unwind_get_saved_register():
>
> /* Reached the the bottom (youngest, inner most) of the frame chain
> (youngest, inner most) frame, go direct to the hardware register
> cache (do not pass go, do not try to cache the value, ...). The
> unwound value would have been cached in frame->next but that
> doesn't exist. This doesn't matter as the hardware register
> cache is stopping any unnecessary accesses to the target. */
>
> /* NOTE: cagney/2002-04-14: It would be nice if, instead of a
> special case, there was always an inner frame dedicated to the
> hardware registers. Unfortunatly, there is too much unwind code
> around that looks up/down the frame chain while making the
> assumption that each frame level is using the same unwind code. */
>
> >Should we allow NULL to imply the current frame?
>
> Definitly no :-)
>
> There is a bit of dogma here - there is always a frame. The above
> should not be called with NULL. Code that calls this checks that
> selected_frame != NULL. I'll add a ``gdb_assert (frame != NULL)'' and a
> comment to that effect.
>
> As for get_next_frame(FRAME), if that returns NULL, we've fallen off the
> inner most frame and should get the register value from the register
> cache. (Oh, while get_next_frame(current_frame) will always return
> NULL, there may come a time when current_frame->next does not :-).
OK, I see where you're going, vis some of the comments about a "frame"
for the hardware registers. I can buy that. I like these new
functions...
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer