This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [RFC/RFA] gdb.cp/classes.exp: Don't try to print local variable out of scope
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