Re: NULL selected/current frame; Was: [patch/rfc] Add frame_read_signed/unsigned_register(); convert h8300 to print_registers_info()

[Daniel Jacobowitz <drow@mvista.com>]

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