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

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

[Michael Elizabeth Chastain]

  1 void foo ()
  2 {
  3   int i = 1;
  4   {
  5     int i = 2;
  6     bar(i);
  7   }
  8   bar (i);
  9 }

cv> Is line 7 still in the scope of the inner definition of variable `i'?
cv> Which `i' should be printed at that point?

My intuition says that the inner "i" is in scope at line 7.
That means my intutition is faulty.  :(

> I tested the whole gdb.cp testsuite on linux-x-sh with and without the
> patch and the only difference in the testsuite output where the tests
> directly affected by this change:

I still want to add a copyright notice to misc.cc, and then clone the
file, and then make the change only in classes.cc.  I think it's a bit
better for every test script to have a dedicated unique test program.

Michael C

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

[Andrew Cagney]

> 1 void foo ()
>   2 {
>   3   int i = 1;
>   4   {
>   5     int i = 2;
>   6     bar(i);
>   7   }
>   8   bar (i);
>   9 }
> 
> cv> Is line 7 still in the scope of the inner definition of variable `i'?
> cv> Which `i' should be printed at that point?
> 
> My intuition says that the inner "i" is in scope at line 7.

Yes, the inner "i" should be in scope.  That line, which hasn't yet been 
executed, will destory the inner block.  I think that is covered by the 
GCC-O0 rule?

Andrew

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

[Daniel Jacobowitz]

On Tue, Mar 09, 2004 at 03:38:04PM -0500, Andrew Cagney wrote:
> >1 void foo ()
> >  2 {
> >  3   int i = 1;
> >  4   {
> >  5     int i = 2;
> >  6     bar(i);
> >  7   }
> >  8   bar (i);
> >  9 }
> >
> >cv> Is line 7 still in the scope of the inner definition of variable `i'?
> >cv> Which `i' should be printed at that point?
> >
> >My intuition says that the inner "i" is in scope at line 7.
> 
> Yes, the inner "i" should be in scope.  That line, which hasn't yet been 
> executed, will destory the inner block.  I think that is covered by the 
> GCC-O0 rule?

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.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

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

[Andrew Cagney]

>>Yes, the inner "i" should be in scope.  That line, which hasn't yet been 
>>> executed, will destory the inner block.  I think that is covered by the 
>>> GCC-O0 rule?
> 
> 
> 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?

Andrew

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

[Daniel Jacobowitz]

On Tue, Mar 09, 2004 at 05:32:12PM -0500, Andrew Cagney wrote:
> >>Yes, the inner "i" should be in scope.  That line, which hasn't yet been 
> >>>executed, will destory the inner block.  I think that is covered by the 
> >>>GCC-O0 rule?
> >
> >
> >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?

Right now, frame_unwind_address_in_block returns PC for any frame,
whose next frame is a normal frame, other than the innermost.  If
you're here:

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

and you want to use something like the address-in-block hack to claim
to be inside the scope of i, that means you need to apply it to the
innermost frame.  If you apply it to the innermost frame, you might end
up applying it when we're at the beginning of a function, which is just
wrong.

BTW, I think the NORMAL_FRAME check is wrong too:

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

get signal

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

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

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

[Andrew Cagney]

> 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

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

[Daniel Jacobowitz]

On Tue, Mar 09, 2004 at 08:51:05PM -0500, Andrew Cagney wrote:
> 
> >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.

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

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.

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.

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?

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.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

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

[Daniel Jacobowitz]

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

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

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

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

[Andrew Cagney]

> 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

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

[Daniel Jacobowitz]

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

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

[Andrew Cagney]

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

GDB can't tell the difference - for a variable that has gone out of 
scope, gdb can't tell if it has or hasn't been destroyed -- it has to 
trust GCC.

However [to play sick mind games] there's nothing in the rule book 
saying that GDB/GCC need to follow the language rules.  It should be 
possible for GCC to manipulate things such that a variable remains 
visible until its location has been reused.

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


Andrew

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

[Andrew Cagney]

> 1 void foo ()
>   2 {
>   3   int i = 1;
>   4   {
>   5     int i = 2;
>   6     bar(i);
>   7   }
>   8   bar (i);
>   9 }
> 
> cv> Is line 7 still in the scope of the inner definition of variable `i'?
> cv> Which `i' should be printed at that point?
> 
> My intuition says that the inner "i" is in scope at line 7.

Yes, the inner "i" should be in scope.  That line, which hasn't yet been 
executed, will destory the inner block.  I think that is covered by the 
GCC-O0 rule?

Andrew

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

[Daniel Jacobowitz]

On Tue, Mar 09, 2004 at 05:32:12PM -0500, Andrew Cagney wrote:
> >>Yes, the inner "i" should be in scope.  That line, which hasn't yet been 
> >>>executed, will destory the inner block.  I think that is covered by the 
> >>>GCC-O0 rule?
> >
> >
> >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?

Right now, frame_unwind_address_in_block returns PC for any frame,
whose next frame is a normal frame, other than the innermost.  If
you're here:

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

and you want to use something like the address-in-block hack to claim
to be inside the scope of i, that means you need to apply it to the
innermost frame.  If you apply it to the innermost frame, you might end
up applying it when we're at the beginning of a function, which is just
wrong.

BTW, I think the NORMAL_FRAME check is wrong too:

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

get signal

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

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

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

[Michael Elizabeth Chastain]

  1 void foo ()
  2 {
  3   int i = 1;
  4   {
  5     int i = 2;
  6     bar(i);
  7   }
  8   bar (i);
  9 }

cv> Is line 7 still in the scope of the inner definition of variable `i'?
cv> Which `i' should be printed at that point?

My intuition says that the inner "i" is in scope at line 7.
That means my intutition is faulty.  :(

> I tested the whole gdb.cp testsuite on linux-x-sh with and without the
> patch and the only difference in the testsuite output where the tests
> directly affected by this change:

I still want to add a copyright notice to misc.cc, and then clone the
file, and then make the change only in classes.cc.  I think it's a bit
better for every test script to have a dedicated unique test program.

Michael C

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

[Andrew Cagney]

> 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

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

[Andrew Cagney]

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

GDB can't tell the difference - for a variable that has gone out of 
scope, gdb can't tell if it has or hasn't been destroyed -- it has to 
trust GCC.

However [to play sick mind games] there's nothing in the rule book 
saying that GDB/GCC need to follow the language rules.  It should be 
possible for GCC to manipulate things such that a variable remains 
visible until its location has been reused.

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


Andrew

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

[Daniel Jacobowitz]

On Tue, Mar 09, 2004 at 08:51:05PM -0500, Andrew Cagney wrote:
> 
> >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.

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

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.

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.

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?

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.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

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

[Andrew Cagney]

> 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

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

[Daniel Jacobowitz]

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

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

[Andrew Cagney]

>>Yes, the inner "i" should be in scope.  That line, which hasn't yet been 
>>> executed, will destory the inner block.  I think that is covered by the 
>>> GCC-O0 rule?
> 
> 
> 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?

Andrew

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

[Daniel Jacobowitz]

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

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

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

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

[Daniel Jacobowitz]

On Tue, Mar 09, 2004 at 03:38:04PM -0500, Andrew Cagney wrote:
> >1 void foo ()
> >  2 {
> >  3   int i = 1;
> >  4   {
> >  5     int i = 2;
> >  6     bar(i);
> >  7   }
> >  8   bar (i);
> >  9 }
> >
> >cv> Is line 7 still in the scope of the inner definition of variable `i'?
> >cv> Which `i' should be printed at that point?
> >
> >My intuition says that the inner "i" is in scope at line 7.
> 
> Yes, the inner "i" should be in scope.  That line, which hasn't yet been 
> executed, will destory the inner block.  I think that is covered by the 
> GCC-O0 rule?

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.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

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

[Michael Elizabeth Chastain]

mec> Is it okay for gcc to emit debug info that "i" is out of scope here?
drow> I think so.  It's unfortunate.

Okay, that makes three people in favor of accepting this limited
scoping from gcc 3.4, good enough for me.

drow> Duplicate the file, then, since we've decided this is a bad practice?

You're right, this is better.

I was secretly hoping not to touch misc.cc at all, because as soon as I
go to touch it, I have to add a proper copyright notice, and then
re-test with all the *.exp anyways.

I'd better get to work.

Michael C

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

[Daniel Jacobowitz]

On Tue, Mar 09, 2004 at 10:11:11AM -0500, Michael Chastain wrote:
> Right.
> 
> I want to raise the question: is this really a bug in the gdb test suite,
> or is it a bug in gcc?
> 
> That is: is a local variable required to exist at the closing brace of a
> function?
> 
> I think your answer is "no, it's not required to exist, therefore the
> gdb test suite should change".  My answer is "reluctantly, no,
> it's not required to exist"; I don't think the famous gcc -O0
> debug info clause covers this case.  I'm curious what drow and
> carlton and other people have to say.
> 
>   void foo ()
>   {
>     int i;
>     i = 1;
>     bar (i);
>   }
> 
>   (gdb) break bar
>   (gdb) run
>   (gdb) finish
>   (gdb) print i
> 
> Is it okay for gcc to emit debug info that "i" is out of scope here?

I think so.  It's unfortunate.

> misc.cc is used by three *.exp files so I do not want to touch it
> at all, so I am dis-approving your patch.  I will write a patch to
> remove the "gdb_test next" in test_enums instead.

Duplicate the file, then, since we've decided this is a bad practice?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

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

[Corinna Vinschen]

Hi,

with gcc 3.4.0, the gdb.cp/classes.exp test has four FAILs on sh-elf:

  FAIL: gdb.cp/classes.exp: print obj_with_enum (2)
  FAIL: gdb.cp/classes.exp: print obj_with_enum.priv_enum
  FAIL: gdb.cp/classes.exp: ptype obj_with_enum.priv_enum
  FAIL: gdb.cp/classes.exp: ptype obj_with_enum

Basically, the testsuite tries to print the value of a local variable
on a closing brace.  This fails due to the debug info given in this
case:

 <1><1398>: Abbrev Number: 37 (DW_TAG_subprogram)
     DW_AT_sibling     : <13e1> 
     DW_AT_external    : 1      
     DW_AT_name        : enums1 
     DW_AT_decl_file   : 1      
     DW_AT_decl_line   : 430    
     DW_AT_MIPS_linkage_name: _Z6enums1v        
     DW_AT_low_pc      : 0x1480 5248    
     DW_AT_high_pc     : 0x14ac 5292    
     DW_AT_frame_base  : 1 byte block: 5e       (DW_OP_reg14; )
 <2><13bd>: Abbrev Number: 28 (DW_TAG_lexical_block)
     DW_AT_low_pc      : 0x1488 5256    
     DW_AT_high_pc     : 0x149a 5274    
 <3><13c6>: Abbrev Number: 38 (DW_TAG_variable)
     DW_AT_name        : obj_with_enum  
     DW_AT_decl_file   : 1      
     DW_AT_decl_line   : 431    
     DW_AT_type        : <12a2> 
     DW_AT_location    : 2 byte block: 91 0     (DW_OP_fbreg: 0; )

As you can see, the function has a lexical block attached.  The local
variable is a child of that lexical block.  The lexical block consists
of the whole body of the function, except for the prologue and the
epilogue code.

When the testsuite steps to the closing brace of the function, $pc is
set to the first instruction of the epilogue.  This is exactly the
first instruction which doesn't belong to the lexical block anymore.
Logically, the local variable doesn't exist anymore at this point.

So GDB prints `No symbol "obj_with_enum" in current context.'

Since the above debug information is correct, also GDBs behaviour is
correct.  The testsuite wrongly assumes, that the scope of the local
class member includes the closing brace.

I'd suggest to change the testsuite case to add another line to the
function enums1(), so that it's sure to be still in the scope of the
local variable obj_with_enum.


Corinna


	* gdb.cp/misc.cc (enums1): Add a line to extend scope of
	local variable obj_with_enum.

Index: gdb.cp/misc.cc
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.cp/misc.cc,v
retrieving revision 1.1
diff -u -p -r1.1 misc.cc
--- gdb.cp/misc.cc	23 Aug 2003 03:55:59 -0000	1.1
+++ gdb.cp/misc.cc	8 Mar 2004 19:59:17 -0000
@@ -433,6 +433,7 @@ void enums1 ()
   obj_with_enum.x = 0;
   enums2 ();
   obj_with_enum.priv_enum = ClassWithEnum::green;
+  obj_with_enum.priv_enum = ClassWithEnum::yellow;
 }
 
 class ClassParam {


-- 
Corinna Vinschen
Cygwin Developer
Red Hat, Inc.

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

[Michael Elizabeth Chastain]

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

I'm wondering too.

Here is the big scope bug in 3.4:

  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13956

There are two more bugs with tree-ssa:

  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14048
  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14049

I think I was referring to weirdness with 14048 and 14049,
but is in the tree-ssa branch, not gcc 3.4.

Michael C

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

[Corinna Vinschen]

Hi Michael,

On Mar  9 10:11, Michael Elizabeth Chastain wrote:
> That is: is a local variable required to exist at the closing brace of a
> function?
> 
> I think your answer is "no, it's not required to exist, therefore the
> gdb test suite should change".  My answer is "reluctantly, no,
> it's not required to exist"; I don't think the famous gcc -O0
> debug info clause covers this case.  I'm curious what drow and
> carlton and other people have to say.

basically this problem is similar to the "having the same variable
defined twice in a function" problem:

  1 void foo ()
  2 {
  3   int i = 1;
  4   {
  5     int i = 2;
  6     bar(i);
  7   }
  8   bar (i);
  9 }

Is line 7 still in the scope of the inner definition of variable `i'?
Which `i' should be printed at that point?

>   void foo ()
>   {
>     int i;
>     i = 1;
>     bar (i);
>   }
> 
>   (gdb) break bar
>   (gdb) run
>   (gdb) finish
>   (gdb) print i
> 
> Is it okay for gcc to emit debug info that "i" is out of scope here?

IMHO yes.  Keep in mind that it's a *local* variable.  It's practically
dead at this point.  $pc sits already in the epilogue which destroys the
variable anyway.  Just one `stepi' would perhaps *really* destroy the
variable and GDB might print some entirely confused value.

> cv> I'd suggest to change the testsuite case to add another line to the
> cv> function enums1(), so that it's sure to be still in the scope of the
> cv> local variable obj_with_enum.
> 
> misc.cc is used by three *.exp files so I do not want to touch it
> at all, so I am dis-approving your patch.  I will write a patch to
> remove the "gdb_test next" in test_enums instead.

I tested the whole gdb.cp testsuite on linux-x-sh with and without the
patch and the only difference in the testsuite output where the tests
directly affected by this change:

  7c7,10
  < (gdb) KFAIL: gdb.cp/classes.exp: ptype obj_with_enum (PRMS: gdb/57)
  ---
  > (gdb) FAIL: gdb.cp/classes.exp: print obj_with_enum (2)
  > (gdb) FAIL: gdb.cp/classes.exp: print obj_with_enum.priv_enum
  > (gdb) FAIL: gdb.cp/classes.exp: ptype obj_with_enum.priv_enum
  > (gdb) FAIL: gdb.cp/classes.exp: ptype obj_with_enum


Corinna

-- 
Corinna Vinschen
Cygwin Developer
Red Hat, Inc.

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

[Michael Elizabeth Chastain]

Too busy to look right now, but my recollection is that gcc 3.4.X
(and later) actually behave a little differently for inner blocks
versus the outermost block of a function.  That is, my recollection
is that the scoping problem happens only with the outermost block.

Michael C

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

[Daniel Jacobowitz]

On Tue, Mar 09, 2004 at 01:59:59PM +0100, Corinna Vinschen wrote:
> 	* gdb.cp/misc.cc (enums1): Add a line to extend scope of
> 	local variable obj_with_enum.
> 
> Index: gdb.cp/misc.cc
> ===================================================================
> RCS file: /cvs/src/src/gdb/testsuite/gdb.cp/misc.cc,v
> retrieving revision 1.1
> diff -u -p -r1.1 misc.cc
> --- gdb.cp/misc.cc	23 Aug 2003 03:55:59 -0000	1.1
> +++ gdb.cp/misc.cc	8 Mar 2004 19:59:17 -0000
> @@ -433,6 +433,7 @@ void enums1 ()
>    obj_with_enum.x = 0;
>    enums2 ();
>    obj_with_enum.priv_enum = ClassWithEnum::green;
> +  obj_with_enum.priv_enum = ClassWithEnum::yellow;
>  }
>  
>  class ClassParam {
> 

Personally, I recommend using a different (new) variable; otherwise,
we'll be back here in a release when GCC decides to do a little bit
more dead code elimination at -O0.

Otherwise, I agree with your analysis and recommend this patch for
approval.  I've been thinking that it would be nice to have a way to
view recently out-of-scope variables, but I couldn't work out either
the mechanism or the interface, so...

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

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

[Michael Elizabeth Chastain]

Hi Corinna,

cv> Basically, the testsuite tries to print the value of a local variable
cv> on a closing brace.  This fails due to the debug info given in this
cv> case:

I have been seeing this also on native i686-pc-linux-gnu.

cv> When the testsuite steps to the closing brace of the function, $pc is
cv> set to the first instruction of the epilogue.  This is exactly the
cv> first instruction which doesn't belong to the lexical block anymore.
cv> Logically, the local variable doesn't exist anymore at this point.

Right.

I want to raise the question: is this really a bug in the gdb test suite,
or is it a bug in gcc?

That is: is a local variable required to exist at the closing brace of a
function?

I think your answer is "no, it's not required to exist, therefore the
gdb test suite should change".  My answer is "reluctantly, no,
it's not required to exist"; I don't think the famous gcc -O0
debug info clause covers this case.  I'm curious what drow and
carlton and other people have to say.

  void foo ()
  {
    int i;
    i = 1;
    bar (i);
  }

  (gdb) break bar
  (gdb) run
  (gdb) finish
  (gdb) print i

Is it okay for gcc to emit debug info that "i" is out of scope here?

cv> I'd suggest to change the testsuite case to add another line to the
cv> function enums1(), so that it's sure to be still in the scope of the
cv> local variable obj_with_enum.

misc.cc is used by three *.exp files so I do not want to touch it
at all, so I am dis-approving your patch.  I will write a patch to
remove the "gdb_test next" in test_enums instead.

Michael C

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

[Michael Elizabeth Chastain]

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

I'm wondering too.

Here is the big scope bug in 3.4:

  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13956

There are two more bugs with tree-ssa:

  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14048
  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14049

I think I was referring to weirdness with 14048 and 14049,
but is in the tree-ssa branch, not gcc 3.4.

Michael C

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

[Michael Elizabeth Chastain]

Too busy to look right now, but my recollection is that gcc 3.4.X
(and later) actually behave a little differently for inner blocks
versus the outermost block of a function.  That is, my recollection
is that the scoping problem happens only with the outermost block.

Michael C

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

[Corinna Vinschen]

Hi Michael,

On Mar  9 10:11, Michael Elizabeth Chastain wrote:
> That is: is a local variable required to exist at the closing brace of a
> function?
> 
> I think your answer is "no, it's not required to exist, therefore the
> gdb test suite should change".  My answer is "reluctantly, no,
> it's not required to exist"; I don't think the famous gcc -O0
> debug info clause covers this case.  I'm curious what drow and
> carlton and other people have to say.

basically this problem is similar to the "having the same variable
defined twice in a function" problem:

  1 void foo ()
  2 {
  3   int i = 1;
  4   {
  5     int i = 2;
  6     bar(i);
  7   }
  8   bar (i);
  9 }

Is line 7 still in the scope of the inner definition of variable `i'?
Which `i' should be printed at that point?

>   void foo ()
>   {
>     int i;
>     i = 1;
>     bar (i);
>   }
> 
>   (gdb) break bar
>   (gdb) run
>   (gdb) finish
>   (gdb) print i
> 
> Is it okay for gcc to emit debug info that "i" is out of scope here?

IMHO yes.  Keep in mind that it's a *local* variable.  It's practically
dead at this point.  $pc sits already in the epilogue which destroys the
variable anyway.  Just one `stepi' would perhaps *really* destroy the
variable and GDB might print some entirely confused value.

> cv> I'd suggest to change the testsuite case to add another line to the
> cv> function enums1(), so that it's sure to be still in the scope of the
> cv> local variable obj_with_enum.
> 
> misc.cc is used by three *.exp files so I do not want to touch it
> at all, so I am dis-approving your patch.  I will write a patch to
> remove the "gdb_test next" in test_enums instead.

I tested the whole gdb.cp testsuite on linux-x-sh with and without the
patch and the only difference in the testsuite output where the tests
directly affected by this change:

  7c7,10
  < (gdb) KFAIL: gdb.cp/classes.exp: ptype obj_with_enum (PRMS: gdb/57)
  ---
  > (gdb) FAIL: gdb.cp/classes.exp: print obj_with_enum (2)
  > (gdb) FAIL: gdb.cp/classes.exp: print obj_with_enum.priv_enum
  > (gdb) FAIL: gdb.cp/classes.exp: ptype obj_with_enum.priv_enum
  > (gdb) FAIL: gdb.cp/classes.exp: ptype obj_with_enum


Corinna

-- 
Corinna Vinschen
Cygwin Developer
Red Hat, Inc.

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

[Michael Elizabeth Chastain]

mec> Is it okay for gcc to emit debug info that "i" is out of scope here?
drow> I think so.  It's unfortunate.

Okay, that makes three people in favor of accepting this limited
scoping from gcc 3.4, good enough for me.

drow> Duplicate the file, then, since we've decided this is a bad practice?

You're right, this is better.

I was secretly hoping not to touch misc.cc at all, because as soon as I
go to touch it, I have to add a proper copyright notice, and then
re-test with all the *.exp anyways.

I'd better get to work.

Michael C

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

[Daniel Jacobowitz]

On Tue, Mar 09, 2004 at 10:11:11AM -0500, Michael Chastain wrote:
> Right.
> 
> I want to raise the question: is this really a bug in the gdb test suite,
> or is it a bug in gcc?
> 
> That is: is a local variable required to exist at the closing brace of a
> function?
> 
> I think your answer is "no, it's not required to exist, therefore the
> gdb test suite should change".  My answer is "reluctantly, no,
> it's not required to exist"; I don't think the famous gcc -O0
> debug info clause covers this case.  I'm curious what drow and
> carlton and other people have to say.
> 
>   void foo ()
>   {
>     int i;
>     i = 1;
>     bar (i);
>   }
> 
>   (gdb) break bar
>   (gdb) run
>   (gdb) finish
>   (gdb) print i
> 
> Is it okay for gcc to emit debug info that "i" is out of scope here?

I think so.  It's unfortunate.

> misc.cc is used by three *.exp files so I do not want to touch it
> at all, so I am dis-approving your patch.  I will write a patch to
> remove the "gdb_test next" in test_enums instead.

Duplicate the file, then, since we've decided this is a bad practice?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

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

[Michael Elizabeth Chastain]

Hi Corinna,

cv> Basically, the testsuite tries to print the value of a local variable
cv> on a closing brace.  This fails due to the debug info given in this
cv> case:

I have been seeing this also on native i686-pc-linux-gnu.

cv> When the testsuite steps to the closing brace of the function, $pc is
cv> set to the first instruction of the epilogue.  This is exactly the
cv> first instruction which doesn't belong to the lexical block anymore.
cv> Logically, the local variable doesn't exist anymore at this point.

Right.

I want to raise the question: is this really a bug in the gdb test suite,
or is it a bug in gcc?

That is: is a local variable required to exist at the closing brace of a
function?

I think your answer is "no, it's not required to exist, therefore the
gdb test suite should change".  My answer is "reluctantly, no,
it's not required to exist"; I don't think the famous gcc -O0
debug info clause covers this case.  I'm curious what drow and
carlton and other people have to say.

  void foo ()
  {
    int i;
    i = 1;
    bar (i);
  }

  (gdb) break bar
  (gdb) run
  (gdb) finish
  (gdb) print i

Is it okay for gcc to emit debug info that "i" is out of scope here?

cv> I'd suggest to change the testsuite case to add another line to the
cv> function enums1(), so that it's sure to be still in the scope of the
cv> local variable obj_with_enum.

misc.cc is used by three *.exp files so I do not want to touch it
at all, so I am dis-approving your patch.  I will write a patch to
remove the "gdb_test next" in test_enums instead.

Michael C

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

[Daniel Jacobowitz]

On Tue, Mar 09, 2004 at 01:59:59PM +0100, Corinna Vinschen wrote:
> 	* gdb.cp/misc.cc (enums1): Add a line to extend scope of
> 	local variable obj_with_enum.
> 
> Index: gdb.cp/misc.cc
> ===================================================================
> RCS file: /cvs/src/src/gdb/testsuite/gdb.cp/misc.cc,v
> retrieving revision 1.1
> diff -u -p -r1.1 misc.cc
> --- gdb.cp/misc.cc	23 Aug 2003 03:55:59 -0000	1.1
> +++ gdb.cp/misc.cc	8 Mar 2004 19:59:17 -0000
> @@ -433,6 +433,7 @@ void enums1 ()
>    obj_with_enum.x = 0;
>    enums2 ();
>    obj_with_enum.priv_enum = ClassWithEnum::green;
> +  obj_with_enum.priv_enum = ClassWithEnum::yellow;
>  }
>  
>  class ClassParam {
> 

Personally, I recommend using a different (new) variable; otherwise,
we'll be back here in a release when GCC decides to do a little bit
more dead code elimination at -O0.

Otherwise, I agree with your analysis and recommend this patch for
approval.  I've been thinking that it would be nice to have a way to
view recently out-of-scope variables, but I couldn't work out either
the mechanism or the interface, so...

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

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

[Corinna Vinschen]

Hi,

with gcc 3.4.0, the gdb.cp/classes.exp test has four FAILs on sh-elf:

  FAIL: gdb.cp/classes.exp: print obj_with_enum (2)
  FAIL: gdb.cp/classes.exp: print obj_with_enum.priv_enum
  FAIL: gdb.cp/classes.exp: ptype obj_with_enum.priv_enum
  FAIL: gdb.cp/classes.exp: ptype obj_with_enum

Basically, the testsuite tries to print the value of a local variable
on a closing brace.  This fails due to the debug info given in this
case:

 <1><1398>: Abbrev Number: 37 (DW_TAG_subprogram)
     DW_AT_sibling     : <13e1> 
     DW_AT_external    : 1      
     DW_AT_name        : enums1 
     DW_AT_decl_file   : 1      
     DW_AT_decl_line   : 430    
     DW_AT_MIPS_linkage_name: _Z6enums1v        
     DW_AT_low_pc      : 0x1480 5248    
     DW_AT_high_pc     : 0x14ac 5292    
     DW_AT_frame_base  : 1 byte block: 5e       (DW_OP_reg14; )
 <2><13bd>: Abbrev Number: 28 (DW_TAG_lexical_block)
     DW_AT_low_pc      : 0x1488 5256    
     DW_AT_high_pc     : 0x149a 5274    
 <3><13c6>: Abbrev Number: 38 (DW_TAG_variable)
     DW_AT_name        : obj_with_enum  
     DW_AT_decl_file   : 1      
     DW_AT_decl_line   : 431    
     DW_AT_type        : <12a2> 
     DW_AT_location    : 2 byte block: 91 0     (DW_OP_fbreg: 0; )

As you can see, the function has a lexical block attached.  The local
variable is a child of that lexical block.  The lexical block consists
of the whole body of the function, except for the prologue and the
epilogue code.

When the testsuite steps to the closing brace of the function, $pc is
set to the first instruction of the epilogue.  This is exactly the
first instruction which doesn't belong to the lexical block anymore.
Logically, the local variable doesn't exist anymore at this point.

So GDB prints `No symbol "obj_with_enum" in current context.'

Since the above debug information is correct, also GDBs behaviour is
correct.  The testsuite wrongly assumes, that the scope of the local
class member includes the closing brace.

I'd suggest to change the testsuite case to add another line to the
function enums1(), so that it's sure to be still in the scope of the
local variable obj_with_enum.


Corinna


	* gdb.cp/misc.cc (enums1): Add a line to extend scope of
	local variable obj_with_enum.

Index: gdb.cp/misc.cc
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.cp/misc.cc,v
retrieving revision 1.1
diff -u -p -r1.1 misc.cc
--- gdb.cp/misc.cc	23 Aug 2003 03:55:59 -0000	1.1
+++ gdb.cp/misc.cc	8 Mar 2004 19:59:17 -0000
@@ -433,6 +433,7 @@ void enums1 ()
   obj_with_enum.x = 0;
   enums2 ();
   obj_with_enum.priv_enum = ClassWithEnum::green;
+  obj_with_enum.priv_enum = ClassWithEnum::yellow;
 }
 
 class ClassParam {


-- 
Corinna Vinschen
Cygwin Developer
Red Hat, Inc.