* 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).