* gdb unable to print alias variable @ 2021-06-24 0:34 kamlesh kumar 2021-06-26 2:50 ` Simon Marchi 0 siblings, 1 reply; 5+ messages in thread From: kamlesh kumar @ 2021-06-24 0:34 UTC (permalink / raw) To: gdb 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. ./kamlesh ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: gdb unable to print alias variable 2021-06-24 0:34 gdb unable to print alias variable kamlesh kumar @ 2021-06-26 2:50 ` Simon Marchi 2021-06-27 1:49 ` David Blaikie 0 siblings, 1 reply; 5+ messages in thread From: Simon Marchi @ 2021-06-26 2:50 UTC (permalink / raw) To: kamlesh kumar, gdb 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: gdb unable to print alias variable 2021-06-26 2:50 ` Simon Marchi @ 2021-06-27 1:49 ` David Blaikie 2021-06-27 3:10 ` kamlesh kumar 0 siblings, 1 reply; 5+ messages in thread From: David Blaikie @ 2021-06-27 1:49 UTC (permalink / raw) To: Simon Marchi; +Cc: kamlesh kumar, gdb 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 <gdb@sourceware.org> 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 > > (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 > ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: gdb unable to print alias variable 2021-06-27 1:49 ` David Blaikie @ 2021-06-27 3:10 ` kamlesh kumar 2021-06-27 16:11 ` David Blaikie 0 siblings, 1 reply; 5+ messages in thread From: kamlesh kumar @ 2021-06-27 3:10 UTC (permalink / raw) To: David Blaikie; +Cc: Simon Marchi, gdb 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 <dblaikie@gmail.com> 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 <gdb@sourceware.org> 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 >> > (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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: gdb unable to print alias variable 2021-06-27 3:10 ` kamlesh kumar @ 2021-06-27 16:11 ` David Blaikie 0 siblings, 0 replies; 5+ messages in thread From: David Blaikie @ 2021-06-27 16:11 UTC (permalink / raw) To: kamlesh kumar; +Cc: Simon Marchi, gdb On Sat, Jun 26, 2021 at 8:11 PM kamlesh kumar <kamleshbhalui@gmail.com> 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 <dblaikie@gmail.com> 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 <gdb@sourceware.org> > 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 > >> > (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 > ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2021-06-27 16:11 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-06-24 0:34 gdb unable to print alias variable kamlesh kumar 2021-06-26 2:50 ` Simon Marchi 2021-06-27 1:49 ` David Blaikie 2021-06-27 3:10 ` kamlesh kumar 2021-06-27 16:11 ` David Blaikie
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).