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

[Andrew Cagney <cagney@gnu.org>]

> BTW, I think the NORMAL_FRAME check is wrong too:
> 
>     {
>       int i;
>       stuff (i);
> ->  }
> 
> get signal

Er, hold on.  The intent of address-in-block is:

/* An address (not necessarily alligned to an instruction boundary)
    that falls within THIS frame's code block.

    When a function call is the last statement in a block, the return
    address for the call may land at the start of the next block.
    Similarly, if a no-return function call is the last statement in
    the function, the return address may end up pointing beyond the
    function, and possibly at the start of the next function.

    These methods make an allowance for this.  For call frames, this
    function returns the frame's PC-1 which "should" be an address in
    the frame's block.  */

and:

   /* If THIS frame is not inner most (i.e., NEXT isn't the sentinel),
      and NEXT is `normal' (i.e., not a sigtramp, dummy, ....) THIS
      frame's PC ends up pointing at the instruction fallowing the
      "call".  Adjust that PC value so that it falls on the call
      instruction (which, hopefully, falls within THIS frame's code
      block.  So far it's proved to be a very good approximation.  See
      get_frame_type for why ->type can't be used.  */

It's not possible to construct my senario:

>daniel:
 >> 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?

The only way to get a PC pointing at the first instruction of a function 
is for that function to have been interrupted just as that first 
instruction was about to be executed -- thats the very case where the 
existing address_in_block correctly leaves the PC as is.

In the example in question:

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

the existing code correctly puts the PC at the instruction about to 
destroy the prologue.

> 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 :)

Andrew