While debugging a failure in a sandbox I noticed odd behaviour with the templates.exp testcase. psyms have this (from mt print psym): Baz<int, (char)'\\001>::baz yet syms have Baz<int, (char)1>::baz and while single stepping through symbol lookup via quick fns, the lookup failed, as expected, because the "(char)1" version was passed for lookup and was compared with the "(char)'\\001'" version in the psym table. Is there a real problem here? Filing this so it's not forgotten.
More data. The output of "mt print type intBazOne": [this is with the gdb.cp/templates.exp testcase] ... Baz<int, (char)'\\001'>::~Baz() ... Baz<int, (char)1>::baz(int, int) ... Seems like there's a missing canonicalization somewhere.
This still seems to happen with the new reader. The DWARF says: <2b> DW_AT_name : (indirect string, offset: 0x52): thetemplatefunction<'\001'> There isn't a way to dump the cooked index directly (probably should fix) but you can gdb-add-index and examine that: [710] thetemplatefunction<(char)'\001'>: 0 [global, function] However info func says: 2: int thetemplatefunction<(char)1>(); I'm going to say the bug is somewhere in the full reader. This is a case that would be fixed by the lazy expansion idea, see bug #29398 -- there, the names would be directly constructed from the cooked index, so there's no possibility of divergence.
My test case: template<char C> int thetemplatefunction() { return C; } int main() { char x = thetemplatefunction<1> (); return 0; }
new_symbol calls dwarf2_physname, which demangles the mangled form of the name. This yield: (top-gdb) p demangled $14 = std::unique_ptr<char> = { get() = 0x2584aa0 "thetemplatefunction<(char)1>()" } ... i.e., disagreeing with the canonicalizer. This is bad. Maybe it's actually a bug in the canonicalizer, though at the same time it seems bad to depend on demangling. The cooked index uses DW_AT_name by default, I think the full reader should do the same.
Easiest to see with: (gdb) set debug check-physname on (gdb) set complaints 1000 (gdb) file /tmp/q Reading symbols from /tmp/q... (gdb) info func thetemplatefunction During symbol reading: Computed physname <thetemplatefunction<(char)'\001'>()> does not match demangled <thetemplatefunction<(char)1>()> (from linkage <_Z19thetemplatefunctionILc1EEiv>) - DIE at 0x2a [in module /tmp/q]
The lazy expansion idea would mean computing names directly from the index. IMO we should remove the demangling from the full symbol reader anyway. The indexer proves this isn't needed, so it's just overhead now.
I think this is fixed now because the index now shows the same form as info func: (gdb) | maint print objfiles | grep canon.*thetempl.*char canonical: thetemplatefunction<(char)1> (gdb) info func thetemplate All functions matching regular expression "thetemplate": File q.cc: 2: int thetemplatefunction<(char)1>(); Also I can't reproduce using comment#5. Comment#6 remains true but this should just be a separate bug.