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

Andrew Cagney
2004-03-10T22:21:41Z

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