Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Simon Marchi via Gdb <gdb@sourceware.org>
To: David Blaikie <dblaikie@gmail.com>, gdb <gdb@sourceware.org>
Subject: Re: Decl/def matching with templates without template parameters in the DW_AT_name
Date: Wed, 11 Jan 2023 13:24:18 -0500	[thread overview]
Message-ID: <bc64ec5f-1143-c4f0-c6c3-8965b5f606f1@simark.ca> (raw)
In-Reply-To: <CAENS6Euttzaf5SJVn_UNd6PdTUPea73sByKo+rqbq_E5FTpdSw@mail.gmail.com>



On 1/6/23 12:37, David Blaikie via Gdb wrote:
> I've been working on reducing debug info size, especially for
> expression-template heavy code like in Tensorflow and Eigen.
> 
> To that end, I've implemented the flag -gsimple-template-names in
> Clang that simplifies the DW_AT_name for templates by omitting
> template parameters (eg: "vector" instead of "vector<int,
> std::allocator<int>>") when the DW_TAG_template_*_parameters contain
> sufficient information to reconstruct the original name.

This reduces the length of strings, and more importantly it allows more
sharing, is that it?  It doesn't change the layout of the DIE tree?

> This generally seems to work in GDB - that looks intentional (perhaps
> because someone else implemented this feature elsewhere, or just for
> canonicalization reasons (the full string with template parameters
> might have different whitespace, parentheses, other formatting)), it
> seems unlikely that GDB would accidentally be able to connect two
> "vector" declarations up to the right "vector" definitions based on
> the template parameters without intentional code to support this
> scenario.

Probably this code:

https://gitlab.com/gnutools/binutils-gdb/-/blob/1b9af5b949bff0c750ededb459400c1857fec416/gdb/dwarf2/read.c#L9002

> But one place I found a problem was in pretty printers. I have
> situations where a type declaration isn't resolved to a definition
> when working within a pretty printer (resulting in the pretty printer
> being unable to find member variables in the object/of that type) -
> but if I print out the variable/member it works correctly - or if I
> "list" the source of the file where the definition of the type is,
> then the pretty printer works correctly.
>
> Does this ring a bell for anyone/sound like something sufficient to
> file a bug, or would I need to dig in further to create an isolated
> reproduction to help communicate the issue I'm seeing?

I have no idea about what happens without digging into the code.  I just
remember some bug where GDB would generate the templated name with let's
say "<5u>" for an integer value template parameter, so if you entered
"<5>", it didn't match textually.  Maybe something like that is
happening.

I also found:

  https://sourceware.org/bugzilla/show_bug.cgi?id=17762

There's the possibility that the "partial symbol" and "expanded symbol"
don't have the same name.  So you could see a difference in behavior
depending on whether the CU has been expanded by GDB or not (I'm just
speculating).

Is it valid DWARF (5) for DW_AT_name of a templated struct instantiation
to omit the template parameters?  I don't see DWARF mandating one or the
other, so I assume that both including them or not are valid.  If so, I
think we can consider it a GDB bug if it doesn't process the "without"
version correctly.  Feel free to file a bug with the relevant background
information.  It would be useful to include some binaries, one compiled
with -gsimple-tempalte-names and one without, so it's easy to compare
the two.

Simon

  reply	other threads:[~2023-01-11 18:24 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-06 17:37 David Blaikie via Gdb
2023-01-11 18:24 ` Simon Marchi via Gdb [this message]
2023-01-11 23:50   ` David Blaikie via Gdb
2023-01-12  1:46     ` Simon Marchi via Gdb
2023-01-14 20:28       ` Tom Tromey
2023-01-16 21:18         ` Simon Marchi via Gdb
2023-01-18 22:08           ` David Blaikie via Gdb
2023-01-18 22:12         ` David Blaikie via Gdb
2023-01-18 22:01       ` David Blaikie via Gdb
2023-01-12  2:32     ` Simon Marchi via Gdb
2023-01-18 22:04       ` David Blaikie via Gdb

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=bc64ec5f-1143-c4f0-c6c3-8965b5f606f1@simark.ca \
    --to=gdb@sourceware.org \
    --cc=dblaikie@gmail.com \
    --cc=simark@simark.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