Re: gdb unable to print alias variable

David,
I haven't updated the llvm review yet, but here is the diff I have used
https://reviews.llvm.org/differential/diff/354719/

On Sun, Jun 27, 2021 at 7:19 AM David Blaikie <[email protected]> wrote:
>
> imported declaration can also be used to bring a single name from a namespace:
>
> namespace ns {
>
>   int i = 32;
>
> }
>
> using ns::i;
>
> int main() {
>
> }
>
> 0x0000002a:   DW_TAG_namespace
>
>                 DW_AT_name      ("ns")
>
>
> 0x0000002f:     DW_TAG_variable
>
>                   DW_AT_name    ("i")
>
>                   DW_AT_type    (0x00000045 "int")
>
>                   DW_AT_external        (true)
>
>                   DW_AT_decl_file       ("/usr/local/google/home/blaikie/dev/scratch/import.cpp")
>
>                   DW_AT_decl_line       (2)
>
>                   DW_AT_location        (DW_OP_addr 0x404028)
> ...
>
>
> 0x0000004c:   DW_TAG_imported_declaration
>
>                 DW_AT_decl_file ("/usr/local/google/home/blaikie/dev/scratch/import.cpp")
>
>                 DW_AT_decl_line (4)
>
>                 DW_AT_import    (0x0000002f)
>
>
> Which looks closer to the alias situation - I would guess the only reason the alias imported_declaration isn't working as intended is that maybe GDB looks at the symbol table first and since it finds a symbol with that name it favors the symbol (but finds no debug info describing it and complains about that)
>
> Let's see if I hand modify the DWARF so there's no symbol, but otherwise an imported declaration that looks pretty close to what would be produced in the alias situation...
>
> Hmm, that seems to work correctly for me. Let me try Kamlesh's original patch...
>
> Yeah, using the example code below, and the D103131 patch... hmm, OK the current version of the patch only does DW_TAG_variables, and the first version of the patch does DW_TAG_variables /and/ a DW_TAG_imported_declaration without a name - that doesn't look like the DWARF shown at the start of this thread.
>
> Kamlesh - which version of the patch are you testing that produced the DWARF shown in the start of this thread? Because hand-crafted DWARF/file that I tried that used an imported declaration as shown above, seemed to work OK for me with lldb. So I'm not sure what's making your experience different from mine.
>
> - Dave
>
> On Fri, Jun 25, 2021 at 7:50 PM Simon Marchi via Gdb <[email protected]> wrote:
>>
>>
>>
>> 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
>> > ([email protected]: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