Bug 14025

Summary: "info var" doesn't find LOC_UNRESOLVED var
Product: gdb Reporter: dje
Component: symtabAssignee: Not yet assigned to anyone <unassigned>
Status: NEW ---    
Severity: normal CC: tromey, vries
Priority: P2    
Version: HEAD   
Target Milestone: ---   
Host: Target:
Build: Last reconfirmed:

Description dje 2012-04-27 00:17:00 UTC
This patch to dw2-unresolved.exp shows a case that gdb doesn't handle.
The variable is there, but gdb doesn't print LOC_UNRESOLVED declarations.


Replace xyz with this bug's bug number.


Index: dw2-unresolved.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.dwarf2/dw2-unresolved.exp,v
retrieving revision 1.5
diff -u -p -r1.5 dw2-unresolved.exp
--- dw2-unresolved.exp  4 Jan 2012 08:17:51 -0000       1.5
+++ dw2-unresolved.exp  27 Apr 2012 00:10:34 -0000
@@ -34,3 +34,37 @@ gdb_continue_to_breakpoint "*extern_bloc

 # Expect the inner value 2.  Value 1 from the outer local block is shadowed.
 gdb_test "print/d var" "= 2"
+
+# Second version of test for bug xyz.
+# "info var var" should see the global var, but it does not.
+
+if { [prepare_for_testing dw2-unresolved.exp "dw2-unresolved" {dw2-unresolved-main.c dw2-unresolved.S} {debug}] } {
+    return -1
+}
+
+if ![runto_main] {
+    return -1
+}
+
+gdb_breakpoint "*extern_block_start"
+gdb_continue_to_breakpoint "*extern_block_start"
+
+# Expect the inner value 2.  Value 1 from the outer local block is shadowed.
+gdb_test "print/d var" "= 2"
+
+set test "ptype var"
+gdb_test_multiple $test $test {
+    -re "type = unsigned char\[\r\n]+$gdb_prompt $" {
+       pass $test
+    }
+}
+
+set test "info var var"
+gdb_test_multiple $test $test {
+    -re "  var\[\r\n\]+.*$gdb_prompt $" {
+       pass $test
+    }
+    -re "$gdb_prompt $" {
+       kfail symtab/xyz $test
+    }
+}
Comment 1 Tom de Vries 2020-04-01 09:43:34 UTC
Here's a non-dwarf-assembly test-case (copied from PR25755).

Consider the following test-case using source files test.c:
...
extern int aaa;

int
main (void)
{
  return 0;
}
...
and test2.c:
...
int aaa = 33;
...

Now consider compiling with debug info only for test.c:
...
$ gcc -c test.c -g; gcc -c test2.c; gcc test.o test2.o -g
...

We can print the value of the variable, but it's not listed with info variables:
...
$ gdb -batch a.out -ex "print aaa" -ex "info variables aaa"
$1 = 33
All variables matching regular expression "aaa":
...

If we compile instead all files with debug info, the variable is listed:
...
$ gcc test.c test2.c -g
$ gdb -batch a.out -ex "print aaa" -ex "info variables aaa"
$1 = 33
All variables matching regular expression "aaa":

File test2.c:
1:      int aaa;
...
Comment 2 Tom de Vries 2020-04-01 10:03:32 UTC
Now consider another test-case, also copied from PR25755, test3.c:
...
extern int aaa;

int aaa;

int
main (void)
{
  return 0;
}
...
compiled with debug info:
...
$ gcc -g test3.c
...

There are two DIEs related to the variable, one for the decl and one for the def:
...
 <1><f4>: Abbrev Number: 2 (DW_TAG_variable)
    <f5>   DW_AT_name        : aaa
    <f9>   DW_AT_decl_file   : 1
    <fa>   DW_AT_decl_line   : 1
    <fb>   DW_AT_type        : <0xff>
    <ff>   DW_AT_external    : 1
    <ff>   DW_AT_declaration : 1
 <1><106>: Abbrev Number: 4 (DW_TAG_variable)
    <107>   DW_AT_specification: <0xf4>
    <10b>   DW_AT_decl_line   : 3
    <10c>   DW_AT_location    : 9 byte block: 3 2c 10 60 0 0 0 0 0      (DW_OP_addr: 60102c)
...

In this case, we do print the variable:
...
$ gdb -batch a.out -ex "print aaa" -ex "info variables aaa"
$1 = 0
All variables matching regular expression "aaa":

File test3.c:
3:      int aaa;
...
but if we'd fix this PR we'd probably have something like:
...
All variables matching regular expression "aaa":

File test3.c:
1:      int aaa;
3:      int aaa;
...
which might be confusing.

We could go for something like this to clarify the situation:
...
All variables matching regular expression "aaa":

File test3.c:
1:      int aaa;  /* Declaration.  */
3:      int aaa;
...

Ultimately, there is an open question on whether we should be keeping decls in the symbol table, in cases in which they are of no use.  Fixing this PR will make that issue visible at the user level.
Comment 3 Tom de Vries 2020-04-01 10:11:47 UTC
And looking at the dwarf generated for an lto example (copied from VI in 25755 comment 0):
...
 <0><d2>: Abbrev Number: 1 (DW_TAG_compile_unit)
    <d8>   DW_AT_name        : <artificial>
 <1><110>: Abbrev Number: 4 (DW_TAG_variable)
    <111>   DW_AT_abstract_origin: <0x13d>
    <115>   DW_AT_location    : 9 byte block: 3 2c 10 60 0 0 0 0 0      (DW_OP_addr: 60102c)
 <0><12b>: Abbrev Number: 1 (DW_TAG_compile_unit)
    <131>   DW_AT_name        : test4.c
 <1><13d>: Abbrev Number: 2 (DW_TAG_variable)
    <13e>   DW_AT_name        : aaa
    <142>   DW_AT_decl_file   : 1
    <143>   DW_AT_decl_line   : 1
    <144>   DW_AT_decl_column : 5
    <145>   DW_AT_type        : <0x149>
    <149>   DW_AT_external    : 1
...
if we'd fix this PR we'd get a def and decl at the same line number:
...
All variables matching regular expression "aaa":

File test3.c:
1:      int aaa;  /* Declaration.  */
1:      int aaa;
...