public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: David Blaikie <dblaikie@gmail.com>
To: kamlesh kumar <kamleshbhalui@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 09:11:10 -0700	[thread overview]
Message-ID: <CAENS6EuZOHy3zsw=ygRyy68MMYPgxt5HHvih6vYhCOr1SBdfew@mail.gmail.com> (raw)
In-Reply-To: <CABKRkgi_fd4L68-DSFXX9OdiRWSgWqom0oAELci2d8y5H8L4Aw@mail.gmail.com>

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
>

      reply	other threads:[~2021-06-27 16: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
2021-06-27 16:11       ` David Blaikie [this message]

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='CAENS6EuZOHy3zsw=ygRyy68MMYPgxt5HHvih6vYhCOr1SBdfew@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).