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

[Daniel Jacobowitz <drow@false.org>]

On Wed, Mar 10, 2004 at 12:09:10PM -0500, Andrew Cagney wrote:
> >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.

Hmm, you're right and that matches GCC behavior - for inner scopes!
Takes a lot out of my argument.

> 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

It would be nice to be able to query i at this point, since it
hasn't been clobbered.  I think the consensus is that we can't.

> >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.

I dunno.  But the problem here appears to be that there is a lexical
block which ends before the epilogue, containing the local variables.
Unlike the inner scope blocks, this one ends before they are destroyed.
Maybe that's a bug after all.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer