[Bug symtab/17762] New: template lookup: partial syms vs syms differences

[Bug symtab/17762] New: template lookup: partial syms vs syms differences

[dje at google dot com]

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

            Bug ID: 17762
           Summary: template lookup: partial syms vs syms differences
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: symtab
          Assignee: unassigned at sourceware dot org
          Reporter: dje at google dot com

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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug symtab/17762] template lookup: partial syms vs syms differences

[dje at google dot com]

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

--- Comment #1 from dje at google dot com ---
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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug symtab/17762] template lookup: partial syms vs syms differences

[tromey at sourceware dot org]

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

Tom Tromey <tromey at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tromey at sourceware dot org

--- Comment #2 from Tom Tromey <tromey at sourceware dot org> ---
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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug symtab/17762] template lookup: partial syms vs syms differences

[tromey at sourceware dot org]

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

--- Comment #3 from Tom Tromey <tromey at sourceware dot org> ---
My test case:

template<char C>
int thetemplatefunction() { return C; }

int main() {
  char x = thetemplatefunction<1> ();
  return 0;
}

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug symtab/17762] template lookup: partial syms vs syms differences

[tromey at sourceware dot org]

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

--- Comment #4 from Tom Tromey <tromey at sourceware dot org> ---
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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug symtab/17762] template lookup: partial syms vs syms differences

[tromey at sourceware dot org]

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

--- Comment #5 from Tom Tromey <tromey at sourceware dot org> ---
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]

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug symtab/17762] template lookup: partial syms vs syms differences

[dblaikie at gmail dot com]

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

David Blaikie <dblaikie at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dblaikie at gmail dot com

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug symtab/17762] template lookup: partial syms vs syms differences

[tromey at sourceware dot org]

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

--- Comment #6 from Tom Tromey <tromey at sourceware dot org> ---
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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.