Re: gdb unable to print alias variable

[Simon Marchi <simon.marchi@polymtl.ca>]

On 2021-06-23 8:34 p.m., kamlesh kumar via Gdb wrote:
> Hi Devs,
> Currently clang does not produce debug info for alias variables, I am
> working on this feature, by having DW_TAG_imported_declaration for
> alias variable but gdb does not work with this.
> below is demonstration
> 
> consider this testcase,
> -----------
> int oldname = 1;
> extern int newname attribute((alias("oldname")));
> int main(){}
> ---------------------
> $clang test.c -g
> $gdb a.out
> (gdb) pt oldname
> type = int
> (gdb) pt newname
> type = <data variable, no debug info>
> (gdb) p newname
> 'newname' has unknown type; cast it to its declared type
> 
> Here is debug info in ./a.out by clang
> dumped debug info (using llvm-dwarfdump)
>  test.o: file format elf64-x86-64
> 
>  .debug_info contents:
>  0x00000000: Compile Unit: length = 0x00000067, format = DWARF32,
> version = 0x0004, abbr_offset = 0x0000, addr_size = 0x08 (next unit at
> 0x0000006b)
> 
>  0x0000000b: DW_TAG_compile_unit
>                DW_AT_producer    ("clang version 13.0.0
> (git@github.com:llvm/llvm-project.git
> 4cd7169f5517167ef456e82c6dcae669bde6c725)")
>                DW_AT_language    (DW_LANG_C99)
>                DW_AT_name        ("test.c")
>                DW_AT_stmt_list   (0x00000000)
>                DW_AT_comp_dir    ("/folk/kkumar/tcllvm/llvm-build-lldb-rel/bin")
>                DW_AT_low_pc      (0x0000000000000000)
>                DW_AT_high_pc     (0x0000000000000008)
> 
>  0x0000002a:   DW_TAG_variable
>                  DW_AT_name      ("oldname")
>                  DW_AT_type      (0x0000003f "int")
>                  DW_AT_external  (true)
>                  DW_AT_decl_file
> ("/folk/kkumar/tcllvm/llvm-build-lldb-rel/bin/test.c")
>                  DW_AT_decl_line (1)
>                  DW_AT_location  (DW_OP_addr 0x0)
> 
>  0x0000003f:   DW_TAG_base_type
>                  DW_AT_name      ("int")
>                  DW_AT_encoding  (DW_ATE_signed)
>                  DW_AT_byte_size (0x04)
> 
>  0x00000046:   DW_TAG_imported_declaration
>                  DW_AT_decl_file
> ("/folk/kkumar/tcllvm/llvm-build-lldb-rel/bin/test.c")
>                  DW_AT_decl_line (2)
>                  DW_AT_import    (0x0000002a)
>                  DW_AT_name      ("newname")
> 
>  0x00000051:   DW_TAG_subprogram
>                  DW_AT_low_pc    (0x0000000000000000)
>                  DW_AT_high_pc   (0x0000000000000008)
>                  DW_AT_frame_base        (DW_OP_reg6 RBP)
>                  DW_AT_name      ("main")
>                  DW_AT_decl_file
> ("/folk/kkumar/tcllvm/llvm-build-lldb-rel/bin/test.c")
>                  DW_AT_decl_line (3)
>                  DW_AT_type      (0x0000003f "int")
>                  DW_AT_external  (true)
> 
>  0x0000006a:   NULL
> 
> Even though the newname has desired info, gdb is unable to print the
> value or type of the newname.
> I would like to know whether this is a bug in gdb, or debug info
> itself is wrong(because of  DW_TAG_imported_declaration for newname)?
> Any other viable path to address alias variable debugging will be appreciated.

My intuition, from looking at where DW_TAG_imported_declaration can be
found in dwarf2/read.c, is that support for DW_TAG_imported_declaration
was done with namespace imports in mind.  For example, with this code:

    namespace foo
    {
      int x = 11;
    };

    namespace bar = foo;

    int main() {
        return bar::x;
    }

we get:

    0x0000002a:   DW_TAG_namespace
		    DW_AT_name [DW_FORM_strp]       ("foo")

    ...

    0x00000050:   DW_TAG_imported_declaration
		    DW_AT_decl_file [DW_FORM_data1] ("/home/simark/build/binutils-gdb/gdb/test.cpp")
		    DW_AT_decl_line [DW_FORM_data1] (6)
		    DW_AT_import [DW_FORM_ref4]     (0x0000002a)
		    DW_AT_name [DW_FORM_strp]       ("bar")


And GDB is able to use bar:

    (gdb) p bar::x
    $1 = 11

If DW_TAG_imported_declaration is ever used to describe variable
aliasing, then I don't see why that couldn't be supported in GDB, it
would just be a matter of implementing it (which may or may not be
difficult).

Simon