public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: Simon Marchi <simark@simark.ca>
To: David Blaikie <dblaikie@gmail.com>
Cc: gdb <gdb@sourceware.org>
Subject: Re: Decl/def matching with templates without template parameters in the DW_AT_name
Date: Wed, 11 Jan 2023 21:32:38 -0500	[thread overview]
Message-ID: <afe469ca-ac7d-365d-62ee-9097667571e4@simark.ca> (raw)
In-Reply-To: <CAENS6EuS8p18yp_5Tp4BXOL4Q+1XfJSQAk0O4Q6iQhtAw8ZMog@mail.gmail.com>

> Yeah, this is a case where DWARF is like "here are some tools you
> could use to express some language features, have at!" and doesn't say
> "to describe this particular language feature you must use DWARF in
> this particular way"
I just found this:

http://wiki.dwarfstd.org/index.php?title=Best_Practices#Names_of_Program_Entities

    For template instantiations, the DW_AT_name attribute should contain
    both the source language name of the object and the template
    parameters that distinguish one instantiation from another. The
    resulting string should be in the natural form for the language, and
    should have a canonical representation (i.e., different producers
    should generate the same representation). For C++, the string should
    match that produced by the target platform's canonical demangler;
    spaces should only be inserted where syntactically required by the
    compiler.

Of course, it's not normative.  According to the wiki history, this
particular bit was added by Cary Coutant, in case you want to ask him
why it is considered best practice.

I Googled bits of the previous quote, and found this bug about template
string canonicalization, and not including template parameters in the
string:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94845#c8

And this one, that sounds like the 2 vs 2u thing I talked about earler:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81932

Ah, and the thread that was on the GDB list about that:

https://inbox.sourceware.org/gdb/CAATAM3ED7B3wEJFmaZA_MaOtN5EGKSGFmusAf-Mg5hX35D2r6A@mail.gmail.com/

And the corresponding one on llvm-dev, to which you participated:

https://lists.llvm.org/pipermail/llvm-dev/2018-March/121541.html

It's not all relevant, but I re-read those to remember what the trouble
with the name strings with template parameters was.

My thought on all this is that if the name strings with template
parameters are not reliable and take a lot of space, and the same
information is described in a more structured way (as DIEs), then it
makes sense to drop the parameters from the string.

Simon


  parent reply	other threads:[~2023-01-12  2:32 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-06 17:37 David Blaikie
2023-01-11 18:24 ` Simon Marchi
2023-01-11 23:50   ` David Blaikie
2023-01-12  1:46     ` Simon Marchi
2023-01-14 20:28       ` Tom Tromey
2023-01-16 21:18         ` Simon Marchi
2023-01-18 22:08           ` David Blaikie
2023-01-18 22:12         ` David Blaikie
2023-01-18 22:01       ` David Blaikie
2023-01-12  2:32     ` Simon Marchi [this message]
2023-01-18 22:04       ` 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=afe469ca-ac7d-365d-62ee-9097667571e4@simark.ca \
    --to=simark@simark.ca \
    --cc=dblaikie@gmail.com \
    --cc=gdb@sourceware.org \
    /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).