https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94469
--- Comment #2 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #1)
> Do you know under which circumstances gdb asks which symbol to print?
> Because
> I've never seen this for C or C++ and it should be present for _all_ global
> variables when LTO is used and your analysis is correct.
>
The choice in printing is Ada-specific, for C/C++ it picks one.
> Or does Ada somehow not have variable shadowing and for C and C++ gdb
> implements
> shadowing rules, picking the "last" instance?
Unfortunately I have no knowledge of Ada as a language as such, so I cannot
comment on that.
As for which instance is found if there are two matches for C/C++, I'm not sure
if there are any guarantees.
---
Having said that, asking which match to print is Ada-specific, listing all
variables is not, and when doing that we get two variables instead of one:
...
(gdb) info variables
...
File gdb.ada/call_pn/foo.adb:
17: static pck.last_node_id: pck.node_id;
File gdb.ada/call_pn/pck.adb:
17: static pck.last_node_id: pck.node_id;
...
So, this might be a way to reproduce the problem outside of Ada.
I tried the following C test-case:
...
$ cat test.c
static int aaa;
int
main (void)
{
return 0;
}
$ cat test2.c
static int bbb;
$ cat test3.c
static int ccc;
...
and compiled using:
...
$ gcc-10 -g test.c test2.c test3.c -flto -flto-partition=none -ffat-lto-objects
-O0
...
and we have again duplicate variables (for bbb and ccc):
...
$ gdb.sh a.out
Reading symbols from a.out...
(gdb) info variables
All defined variables:
File init.c:
24: const int _IO_stdin_used;
File test.c:
1: static int aaa;
1: static int bbb;
1: static int ccc;
File test2.c:
1: static int bbb;
File test3.c:
1: static int ccc;
...
This seems to be the same issue to me.
Even more clearly, we cannot print the values of bbb and ccc:
...
$ gdb a.out
Reading symbols from a.out...
(gdb) p aaa
$1 = 0
(gdb) p bbb
$2 = <optimized out>
(gdb) p ccc
$3 = <optimized out>
...
because the one without DW_AT_location is shadowing the one with
DW_AT_location.
