public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c++/81932] Template arguments of type unsigned generate incorrect debugging information
       [not found] <bug-81932-4@http.gcc.gnu.org/bugzilla/>
@ 2020-04-29 12:28 ` robert at ocallahan dot org
  2020-04-29 12:50 ` robert at ocallahan dot org
                   ` (3 subsequent siblings)
  4 siblings, 0 replies; 5+ messages in thread
From: robert at ocallahan dot org @ 2020-04-29 12:28 UTC (permalink / raw)
  To: gcc-bugs

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

robert at ocallahan dot org <robert at ocallahan dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |robert at ocallahan dot org

--- Comment #29 from robert at ocallahan dot org <robert at ocallahan dot org> ---
(In reply to Jonathan Wakely from comment #26)
> The demangled names are not in a canonical/standardized format, or
> unambiguous, or portable between different compilers, so that isn't a
> complete solution.

Aren't those issues all fixable though?

The first and last points are basically the same. I don't know what differences
there are between the g++ and clang++ worlds other than where they have
actually diverged in their interpretation of C++ mangling ---
https://github.com/itanium-cxx-abi/cxx-abi/issues/68 --- which deserves to be
fixed for other reasons.

And if you make sure to include function parameter types, what ambiguities are
there in demangled names?

It certainly would be helpful to us (Pernosco debugger) if g++ produced DWARF
names that match the c++filt demangled names; see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94845. Seems like a step in the
right direction that couldn't hurt.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* [Bug c++/81932] Template arguments of type unsigned generate incorrect debugging information
       [not found] <bug-81932-4@http.gcc.gnu.org/bugzilla/>
  2020-04-29 12:28 ` [Bug c++/81932] Template arguments of type unsigned generate incorrect debugging information robert at ocallahan dot org
@ 2020-04-29 12:50 ` robert at ocallahan dot org
  2021-03-11 19:17 ` dhoyer at netapp dot com
                   ` (2 subsequent siblings)
  4 siblings, 0 replies; 5+ messages in thread
From: robert at ocallahan dot org @ 2020-04-29 12:50 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #30 from robert at ocallahan dot org <robert at ocallahan dot org> ---
(In reply to Xi Ruoyao from comment #27)
> Yes.  Could GDB search the symbol with linkage name?

This might work for function names but if you're trying to look up a type name
(e.g. for a cast expression) this doesn't work because types don't have linkage
names. We can often find a mangled name for a type as part of a function or
global variable linkage name, but we can't guarantee that.

Taking a user-provided type name and converting it into something we can look
up in DWARF is already pretty hard due to C++ vagaries, but not knowing how the
compiler canonicalizes these names makes it even harder, and it would simplify
things if the compiler at least matches the demangler.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* [Bug c++/81932] Template arguments of type unsigned generate incorrect debugging information
       [not found] <bug-81932-4@http.gcc.gnu.org/bugzilla/>
  2020-04-29 12:28 ` [Bug c++/81932] Template arguments of type unsigned generate incorrect debugging information robert at ocallahan dot org
  2020-04-29 12:50 ` robert at ocallahan dot org
@ 2021-03-11 19:17 ` dhoyer at netapp dot com
  2021-03-11 19:37 ` psmith at gnu dot org
  2021-03-11 19:42 ` dhoyer at netapp dot com
  4 siblings, 0 replies; 5+ messages in thread
From: dhoyer at netapp dot com @ 2021-03-11 19:17 UTC (permalink / raw)
  To: gcc-bugs

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

David Hoyer <dhoyer at netapp dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dhoyer at netapp dot com

--- Comment #31 from David Hoyer <dhoyer at netapp dot com> ---
(In reply to robert@ocallahan.org from comment #30)
> (In reply to Xi Ruoyao from comment #27)
> > Yes.  Could GDB search the symbol with linkage name?
> 
> This might work for function names but if you're trying to look up a type
> name (e.g. for a cast expression) this doesn't work because types don't have
> linkage names. We can often find a mangled name for a type as part of a
> function or global variable linkage name, but we can't guarantee that.
> 
> Taking a user-provided type name and converting it into something we can
> look up in DWARF is already pretty hard due to C++ vagaries, but not knowing
> how the compiler canonicalizes these names makes it even harder, and it
> would simplify things if the compiler at least matches the demangler.

This issue has gotten stale and yet is still a problem for us using debian
buster.   Is there any update?

^ permalink raw reply	[flat|nested] 5+ messages in thread

* [Bug c++/81932] Template arguments of type unsigned generate incorrect debugging information
       [not found] <bug-81932-4@http.gcc.gnu.org/bugzilla/>
                   ` (2 preceding siblings ...)
  2021-03-11 19:17 ` dhoyer at netapp dot com
@ 2021-03-11 19:37 ` psmith at gnu dot org
  2021-03-11 19:42 ` dhoyer at netapp dot com
  4 siblings, 0 replies; 5+ messages in thread
From: psmith at gnu dot org @ 2021-03-11 19:37 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #32 from Paul Smith <psmith at gnu dot org> ---
No movement AFAIK.  It's apparently the tip of a particularly gross iceberg. 
It doesn't seem like partial measures appeal to people, and no one has the
needed combination of time, knowledge, and contacts to attack the entire
iceberg.

For myself, since I build my own version of GCC for my work, I apply something
similar to (or maybe exactly, I can't remember now) Xi Ruoyao's patch attached
to this bug, and it Works For Me, at least for this specific problem.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* [Bug c++/81932] Template arguments of type unsigned generate incorrect debugging information
       [not found] <bug-81932-4@http.gcc.gnu.org/bugzilla/>
                   ` (3 preceding siblings ...)
  2021-03-11 19:37 ` psmith at gnu dot org
@ 2021-03-11 19:42 ` dhoyer at netapp dot com
  4 siblings, 0 replies; 5+ messages in thread
From: dhoyer at netapp dot com @ 2021-03-11 19:42 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #33 from David Hoyer <dhoyer at netapp dot com> ---
(In reply to Paul Smith from comment #32)
> No movement AFAIK.  It's apparently the tip of a particularly gross iceberg.
> It doesn't seem like partial measures appeal to people, and no one has the
> needed combination of time, knowledge, and contacts to attack the entire
> iceberg.
> 
> For myself, since I build my own version of GCC for my work, I apply
> something similar to (or maybe exactly, I can't remember now) Xi Ruoyao's
> patch attached to this bug, and it Works For Me, at least for this specific
> problem.

that is good to know.   I hate the idea of doing this... but maybe it becomes
required.

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2021-03-11 19:42 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <bug-81932-4@http.gcc.gnu.org/bugzilla/>
2020-04-29 12:28 ` [Bug c++/81932] Template arguments of type unsigned generate incorrect debugging information robert at ocallahan dot org
2020-04-29 12:50 ` robert at ocallahan dot org
2021-03-11 19:17 ` dhoyer at netapp dot com
2021-03-11 19:37 ` psmith at gnu dot org
2021-03-11 19:42 ` dhoyer at netapp dot com

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).