From: kamlesh kumar <kamleshbhalui@gmail.com>
To: David Blaikie <dblaikie@gmail.com>
Cc: Simon Marchi <simon.marchi@polymtl.ca>, gdb <gdb@sourceware.org>
Subject: Re: gdb unable to print alias variable
Date: Sun, 27 Jun 2021 08:40:27 +0530 [thread overview]
Message-ID: <CABKRkgi_fd4L68-DSFXX9OdiRWSgWqom0oAELci2d8y5H8L4Aw@mail.gmail.com> (raw)
In-Reply-To: <CAENS6EsBfHNvTn_pLuC-Tf6ceB1idF9-gT9jt2UYsaKJkCcktQ@mail.gmail.com>
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
next prev parent reply other threads:[~2021-06-27 3:11 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-24 0:34 kamlesh kumar
2021-06-26 2:50 ` Simon Marchi
2021-06-27 1:49 ` David Blaikie
2021-06-27 3:10 ` kamlesh kumar [this message]
2021-06-27 16:11 ` David Blaikie
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CABKRkgi_fd4L68-DSFXX9OdiRWSgWqom0oAELci2d8y5H8L4Aw@mail.gmail.com \
--to=kamleshbhalui@gmail.com \
--cc=dblaikie@gmail.com \
--cc=gdb@sourceware.org \
--cc=simon.marchi@polymtl.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).