Shadowed local variables in "info locals"

Shadowed local variables in "info locals"

[Aktemur, Tankut Baris]

Hi,

Suppose we have the following program:

     1  int
     2  main ()
     3  {
     4    int x = 42;
     5    {
     6      int x = 99;
     7      x = 99;
     8    }
     9    return 0;
    10  }

The "info locals" command, when stopped at line 7, gives

  (gdb) info locals
  x = 99
  x = 42

Is this a bug or an (un)intentional feature?

From one perspective, only one "x" is available for use in our context, and
thus only one "x" should be printed by "info locals".  This is the "bug" view.

From another perspective, the outer "x" and inner "x" are two different
variables that are located in separate locations but they just happen to have
the same name.  Therefore, displaying both is giving valuable information.
This is the "feature" view.

Displaying both names could be confusing for the user in particular if the 
values of the variables come from complex execution flows and if the user cannot
tell which "x" is which.  A potential improvement to the current state is
annotating the outer scope variable for clarity.  E.g.

  (gdb) info locals
  x = 99
  x = 42 <shadowed>

What are your thoughts?

-Baris


Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de>
Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva  
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928

Re: Shadowed local variables in "info locals"

[Simon Marchi]

On 2021-06-29 10:21 a.m., Aktemur, Tankut Baris via Gdb-patches wrote:
> Hi,
> 
> Suppose we have the following program:
> 
>      1  int
>      2  main ()
>      3  {
>      4    int x = 42;
>      5    {
>      6      int x = 99;
>      7      x = 99;
>      8    }
>      9    return 0;
>     10  }
> 
> The "info locals" command, when stopped at line 7, gives
> 
>   (gdb) info locals
>   x = 99
>   x = 42
> 
> Is this a bug or an (un)intentional feature?
> 
> From one perspective, only one "x" is available for use in our context, and
> thus only one "x" should be printed by "info locals".  This is the "bug" view.
> 
> From another perspective, the outer "x" and inner "x" are two different
> variables that are located in separate locations but they just happen to have
> the same name.  Therefore, displaying both is giving valuable information.
> This is the "feature" view.
> 
> Displaying both names could be confusing for the user in particular if the 
> values of the variables come from complex execution flows and if the user cannot
> tell which "x" is which.  A potential improvement to the current state is
> annotating the outer scope variable for clarity.  E.g.
> 
>   (gdb) info locals
>   x = 99
>   x = 42 <shadowed>
> 
> What are your thoughts?

I don't have a strong opinion.  I maybe lean more towards the side of
showing all the information, but making it clearer which variable is
which (i.e. the example above).

But I just wanted to note that a change for MI's -stack-list-locals
command may also be desirable.  It could be a new attribute in the
shadowed variable's record that says it is shadowed, that would not
break backwards compatibility.

Simon

Re: Shadowed local variables in "info locals"

[Tom Tromey]

>>>>> ">" == Aktemur, Tankut Baris via Gdb-patches <gdb-patches@sourceware.org> writes:

>>   (gdb) info locals
>>   x = 99
>>   x = 42

>> Is this a bug or an (un)intentional feature?

I think it's an intentional feature.

>> Displaying both names could be confusing for the user in particular if the 
>> values of the variables come from complex execution flows and if the user cannot
>> tell which "x" is which.  A potential improvement to the current state is
>> annotating the outer scope variable for clarity.  E.g.

>>   (gdb) info locals
>>   x = 99
>>   x = 42 <shadowed>

>> What are your thoughts?

I wonder if it could show the line number of the declaration as well.


One other oddity here is that, in Rust, it's pretty normal to redeclare
variables -- but then the previous one isn't available.

Like:

pub fn main() {
    let x = 5;
    let x = x + 7;
    let y = 8;
}

Then in gdb:

(gdb) info local
x = 12
x = 5

... but the 'x = 5' one is actually inaccessible.

I'm not sure how to handle this.  It may require some special debuginfo.

Tom

RE: Shadowed local variables in "info locals"

[Aktemur, Tankut Baris]

On Wednesday, June 30, 2021 6:55 PM, Tom Tromey wrote:
> >>>>> ">" == Aktemur, Tankut Baris via Gdb-patches <gdb-patches@sourceware.org> writes:
> 
> >>   (gdb) info locals
> >>   x = 99
> >>   x = 42
> 
> >> Is this a bug or an (un)intentional feature?
> 
> I think it's an intentional feature.
> 
> >> Displaying both names could be confusing for the user in particular if the
> >> values of the variables come from complex execution flows and if the user cannot
> >> tell which "x" is which.  A potential improvement to the current state is
> >> annotating the outer scope variable for clarity.  E.g.
> 
> >>   (gdb) info locals
> >>   x = 99
> >>   x = 42 <shadowed>
> 
> >> What are your thoughts?
> 
> I wonder if it could show the line number of the declaration as well.
> 
> 
> One other oddity here is that, in Rust, it's pretty normal to redeclare
> variables -- but then the previous one isn't available.
> 
> Like:
> 
> pub fn main() {
>     let x = 5;
>     let x = x + 7;
>     let y = 8;
> }
> 
> Then in gdb:
> 
> (gdb) info local
> x = 12
> x = 5
> 
> ... but the 'x = 5' one is actually inaccessible.
> 
> I'm not sure how to handle this.  It may require some special debuginfo.
> 
> Tom

Hi Tom, Simon,

Thank you for your comments.  We shall investigate what can be done to improve the
output of "info locals".

-Baris


Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de>
Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva  
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928