public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: David Blaikie <dblaikie@gmail.com>
To: Simon Marchi <simon.marchi@polymtl.ca>
Cc: kamlesh kumar <kamleshbhalui@gmail.com>, gdb <gdb@sourceware.org>
Subject: Re: gdb unable to print alias variable
Date: Sat, 26 Jun 2021 18:49:08 -0700	[thread overview]
Message-ID: <CAENS6EsBfHNvTn_pLuC-Tf6ceB1idF9-gT9jt2UYsaKJkCcktQ@mail.gmail.com> (raw)
In-Reply-To: <e615dbcb-6967-b83a-e1c6-b51ef36afed8@polymtl.ca>

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
>

  reply	other threads:[~2021-06-27  1:49 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 [this message]
2021-06-27  3:10     ` kamlesh kumar
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=CAENS6EsBfHNvTn_pLuC-Tf6ceB1idF9-gT9jt2UYsaKJkCcktQ@mail.gmail.com \
    --to=dblaikie@gmail.com \
    --cc=gdb@sourceware.org \
    --cc=kamleshbhalui@gmail.com \
    --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).