Bug 33861 - Debugging info for C++ template parameters is incorrect
Summary: Debugging info for C++ template parameters is incorrect
Status: NEW
Alias: None
Product: gcc
Classification: Unclassified
Component: debug (show other bugs)
Version: 4.2.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: wrong-debug
Depends on:
Blocks:
 
Reported: 2007-10-22 14:12 UTC by Daniel Jacobowitz
Modified: 2021-09-12 05:20 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2007-10-22 14:13:05


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Daniel Jacobowitz 2007-10-22 14:12:02 UTC
Compile this code, reduced from gdb.cp/templates.cc:

===
char name[3];
template<char *V> struct Qux
{
  int foo();
};

template<char *V> int Qux<V>::foo()
{
  return V[0];
}

Qux<name> qux;
===

Look at the resulting debug information, by building with -c -g and using readelf -wi, or by compiling with -S -dA.  Take a look at the type of the instantiated foo.  G++ calls it Qux<(char*)(& name)>::foo().  But that's not right.

For the first thing, I believe it's not valid C++.  G++ certainly rejects the obvious ways of writing this.  But worse is that it is representable in the mangling.  The actual method:

  _ZN3QuxIXadL_Z4nameEEE3fooEv -> Qux<&(name)>::foo()

But this is validly mangled:

  _ZN3QuxIXcvPcadL_Z4nameEEE3fooEv -> Qux<(char*)(&(name))>::foo()

There are tons of other places where GCC emits debug info different from the demangler, usually in spacing or in the spelling of basic types (long unsigned int vs unsigned long); I have code in GDB to correct for all such cosmetic differences but I am reluctant to make it remove casts that could be important.
Comment 1 Daniel Jacobowitz 2007-10-22 14:13:04 UTC
Fixing bug 30161 might fix, or at least simplify, this too.  But I suspect this name still shows up in error messages where it is suboptimal.
Comment 2 Nathan Sidwell 2007-10-22 14:32:50 UTC
the testcase is valid.  [14.3.2]/2 essentially gives it as an example.  A literal '&' is optional in this case (para 1).

para 5 tells us that array to pointer decay happens here, and GCC internally represents that as CAST_EXPR (<type>, ADDR_EXPR (<array_obj>)).  It could have used ADDR_EXPR (ARRAY_REF (<array_obj>, 0)), but it doesn't.  That alternative is equally invalid as a non-type template argument.

explicitly writing '(char *)&name' in the source is ill-formed though.
Comment 3 Tom Tromey 2011-05-23 16:33:45 UTC
We've been discussing this on gdb-patches recently.
Note that PR 30161 doesn't really help.
Currently we get:

>  <2><51>: Abbrev Number: 5 (DW_TAG_template_value_param)
>     <52>   DW_AT_name        : V        
>     <54>   DW_AT_type        : <0xaf>   
>     <58>   DW_AT_location    : 6 byte block: 3 0 0 0 0 9f       (DW_OP_addr: 0; DW_OP_stack_value)

... but this requires that we be able to reliably map from address
to name, which is not in general possible.