Re: [RFC/RFA] gdb.cp/classes.exp: Don't try to print local variable out of scope

[Daniel Jacobowitz <drow@false.org>]

On Tue, Mar 09, 2004 at 05:32:12PM -0500, Andrew Cagney wrote:
> >>Yes, the inner "i" should be in scope.  That line, which hasn't yet been 
> >>>executed, will destory the inner block.  I think that is covered by the 
> >>>GCC-O0 rule?
> >
> >
> >If that's right, it sounds like we should be using the address-in-block
> >hack to figure out what local variables are in scope for the top
> >frame.  But that runs the risk of, for instance, moving us back into a
> >preceeding function.
> 
> Er, that sounds like a theoretical address-in-block bug?  The value 
> returned should be floored by (as in can't be less than) the function 
> start.  Can you think of an edge case that makes this real?

Right now, frame_unwind_address_in_block returns PC for any frame,
whose next frame is a normal frame, other than the innermost.  If
you're here:

    {
      int i;
      stuff (i);
->  }

and you want to use something like the address-in-block hack to claim
to be inside the scope of i, that means you need to apply it to the
innermost frame.  If you apply it to the innermost frame, you might end
up applying it when we're at the beginning of a function, which is just
wrong.

BTW, I think the NORMAL_FRAME check is wrong too:

    {
      int i;
      stuff (i);
->  }

get signal

Use the sigtramp saved PC unmodified, and it leaves you in the right
function - but that doesn't mean it leaves you in the right block!

Maybe something like (considering recent discussion about
get_frame_func):

/* Return an address of that falls within the frame's code block.  */

CORE_ADDR
get_frame_address_in_block (struct frame_info *this_frame)
{ 
  /* A draft address.  */
  CORE_ADDR pc = get_frame_pc (this_frame);
  CORE_ADDR func = get_frame_func (this_frame);

  if (pc != func)
    pc--;

  return pc;
}

Note that this doesn't work for functions with discontiguous address
ranges, which GCC will soon be generating; but neither does anything
else in GDB, so we can tackle that with a fixme :)

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer