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

[Andrew Cagney <cagney@gnu.org>]

> On Tue, Mar 09, 2004 at 10:05:29PM -0500, Daniel Jacobowitz wrote:
> 
>>> Think about this for a moment.  I'm going to give addresses so that I
>>> can be more precise.
>>> 
>>> 0x10 <stuff>: ret		stuff(int) { }
>>> 0x20 <main>: push		main() {
>>> 0x21 <main+1>: push			{
>>> 0x22 <main+2>: move arg1, i			stuff(i)
>>> 0x23 <main+3>: call stuff			  "
>>> 0x24 <main+4>: pop			}
>>> 0x25 <main+5>: pop		}
>>> 0x26 <main+6>: ret		"
>>> 
>>> The inner scope is probably <main+2> to <main+3> inclusive.

It is "pc in [<main+2>,<main+4>]"  -- only after executing the 
instuction at <main+4> is the inner most scope destroyed.

>>> 
>>> Suppose PC == 0x10.  We backtrace.  Look at main; saved PC is 0x24.  We
>>> want an address in the block.  We subtract 1.  OK, saved addr-in-block
>>> is 0x23.  'i' is in scope.

In your example there isn't a need to substract one -- the return 
address <main+4> is still inside the correct block (it does no harm though).

>>> Suppose PC == 0x24.  Shouldn't this be the same?  For the purposes of
>>> looking at local variables, aren't we still in the the block?

PC=24 (that "<main+4>)" edge case) is also in the correct block.

>>> Suppose PC was 0x24 and we got a signal.  Ditto.
>>> 
>>> Suppose PC == 0x20 and we get a signal.  Obviously we don't want to
>>> change the behavior of this.

Now consider this example:

 >>> 10 0x10 <stuff>: ret		stuff(int) { }
 >>> 11 0x20 <main>: push		main() {
 >>> 12 0x21 <main+1>: push			{
 >>> 13 0x22 <main+2>: move arg1, i			stuff(i)
 >>> 14 0x23 <main+3>: call stuff			  "
 >>> 15                  			}
 >>> 16 0x25 <main+5>: pop  2; ret	}

Note how that closing brace @15 doesn't have code associated with it. 
Its possible to breakpoint @14 or @16 only.  Consequently:

- the return address will be @16 and is _out_ of scope
hence "@16 - 1" is needed to find the correct block when doing a backtrace

- once returned from stuff(), the pc is clearly @16 which, to the user, 
will visibly reflect the departure from the inner scope

> BTW, my proposed replacement is woefully inaccurate, which I should
> have realized before posting.  I do not have a good solution to this
> problem without actually turning back time :)

I'm wondering what the 3.4 wierdness MichaelC's refering to is.

Andrew