[Bug symtab/14025] New: "info var" doesn't find LOC_UNRESOLVED var

[Bug symtab/14025] New: "info var" doesn't find LOC_UNRESOLVED var

[dje at google dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=14025

             Bug #: 14025
           Summary: "info var" doesn't find LOC_UNRESOLVED var
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: symtab
        AssignedTo: unassigned@sourceware.org
        ReportedBy: dje@google.com
    Classification: Unclassified


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

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug symtab/14025] "info var" doesn't find LOC_UNRESOLVED var

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=14025

Tom de Vries <vries at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tromey at sourceware dot org,
                   |                            |vries at gcc dot gnu.org

--- Comment #1 from Tom de Vries <vries at gcc dot gnu.org> ---
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;
...

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug symtab/14025] "info var" doesn't find LOC_UNRESOLVED var

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=14025

--- Comment #2 from Tom de Vries <vries at gcc dot gnu.org> ---
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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug symtab/14025] "info var" doesn't find LOC_UNRESOLVED var

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=14025

--- Comment #3 from Tom de Vries <vries at gcc dot gnu.org> ---
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;
...

-- 
You are receiving this mail because:
You are on the CC list for the bug.