First posted on https://sourceware.org/pipermail/gdb/2022-November/050431.html GDB 12.1 works as expected in this case. For the following C++ program built with "g++ -g -o test test.cc" (no matter what optimization level used): template <typename T = int> int t0(int n) { int sum = 0; for (int i = 0; i < n; ++i) { sum += i * i; } return sum; } int t1(int n) { int sum = 0; for (int i = 0; i < n; ++i) { sum += i * i; } return sum; } int main() { int a = t0(5); int b = t1(5); return a + b; } We cannot use "b t0" command, however, after I use tab completion once, GDB recognize this: (gdb) b t0 Function "t0" not defined. Make breakpoint pending on future shared library load? (y or [n]) n (gdb) #b t0<int>(int) (gdb) b t0 Breakpoint 1 at 0x117d: file test.cc, line 4.
Confirmed. It's a bit hard to bisect because we hit a bunch of other crashes and compilation failure, but it's most likely due to the new DWARF reader. Adding the 13.1 milestone, hopefully we can fix it, since it's a regression.
Yes, it's hard to bisect. I once tried when I posted that mail. I'm a little surprised GDB can recognize the function after a tab completion, it looks like GDB can cache the completed names.
What happens is that the first scan (the cooked index) takes the name from the DWARF and gets "t0<>". The cooked index just uses strncasecmp to find entries, so it doesn't find this name. Full symbol name matching, I think, is done with strncmp_iw_with_mode, which handles a lot of weird cases and ignores the "<>": /* Skip template parameters in STRING1 if STRING2 does not contain any. E.g.: [...] So, that sucks. I'm not completely sure how to solve it. Perhaps stripping the template parmaeters before recording the entry in the index would work. One idea is to have two entries, both with and without the parameters, but I wonder about combinatorial explosion if there are nested templates like a<>::b<>::c<>::d<> -- since the entries record parent information. Another idea is to change the hashing and the lookup to use strncmp_iw_with_mode somehow, at least for C++ names.
> Another idea is to change the hashing I forgot the index uses a sorted vector, not a hash table. I tried using strcmp_iw_ordered, but that doesn't really have the right semantics. Now I'm working on a patch to implement a custom comparison function.
Patch seems to work.
https://sourceware.org/pipermail/gdb-patches/2022-December/194795.html
The master branch has been updated by Tom Tromey <tromey@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=ac37b79cc440e37fc704d425a6e450afb3c7ee89 commit ac37b79cc440e37fc704d425a6e450afb3c7ee89 Author: Tom Tromey <tromey@adacore.com> Date: Wed Dec 14 14:37:41 2022 -0700 Fix parameter-less template regression in new DWARF reader PR c++/29896 points out a regression in the new DWARF reader. It does not properly handle a case like "break fn", where "fn" is a template function. This happens because the new index uses strncasecmp to compare. However, to make this work correctly, we need a custom function that ignores template parameters. This patch adds a custom comparison function and fixes the bug. A new test case is included. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29896
The gdb-13-branch branch has been updated by Tom Tromey <tromey@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=83d3152401cce0c6fd5cd2d4a140bbf5d89a5d9c commit 83d3152401cce0c6fd5cd2d4a140bbf5d89a5d9c Author: Tom Tromey <tromey@adacore.com> Date: Wed Dec 14 14:37:41 2022 -0700 Fix parameter-less template regression in new DWARF reader PR c++/29896 points out a regression in the new DWARF reader. It does not properly handle a case like "break fn", where "fn" is a template function. This happens because the new index uses strncasecmp to compare. However, to make this work correctly, we need a custom function that ignores template parameters. This patch adds a custom comparison function and fixes the bug. A new test case is included. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29896 (cherry picked from commit ac37b79cc440e37fc704d425a6e450afb3c7ee89)
Fixed.
Fix has a bug: https://sourceware.org/pipermail/gdb-patches/2023-January/195828.html
For the record, Tom fixed this via this commit: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=c121e82c39659d1140b1a6a3cfd72c765741b9f5 This was also ported to the gdb-13-branch: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=7ba1fc5a18e0e5f61ab0939aed4f8b816a7a477a Closing. Thanks Tom!