Re: gdb unable to print alias variable
David Blaikie via Gdb <[email protected]>
| Newsgroups | gmane.comp.gdb.devel |
|---|---|
| Message-ID | <CAENS6EuZOHy3zsw=ygRyy68MMYPgxt5HHvih6vYhCOr1SBdfew@mail.gmail.com> |
On Sat, Jun 26, 2021 at 8:11 PM kamlesh kumar <[email protected]> wrote: > David, > I haven't updated the llvm review yet, but here is the diff I have used > https://reviews.llvm.org/differential/diff/354719/ Ah, thanks. I tried this patch and it seems to work fine with gdb for me? oooh... it works if the debugger's context is in the translation unit with the using declaration - if you're stepped into (or haven't started the program) some function in another translation unit, the using decl isn't in scope and so isn't used: (gdb) ptype newname type = <data variable, no debug info> (gdb) start Temporary breakpoint 1 at 0x401114: file alias.cpp, line 3. Starting program: /usr/local/google/home/blaikie/dev/scratch/a.out p Temporary breakpoint 1, main () at alias.cpp:3 3 int main(){} (gdb) ptype newname type = int That's probably appropriate behavior for gdb to interpret a using declaration, as being local to the translation unit (though I don't think C++ technically defines it that way - I think even a using declaration is considered to be a name for the whole program, but it's the sort of ODR violation that's /super/ common and hard to think of a reason why it'd break any implementation). This might explain GCC's choice of representing an alias with a variable rather than an imported declaration - so that it would the debug info would be externally visible in other translation units. > > 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 >