Summary: | GDB git doesn't recognize template function name | ||
---|---|---|---|
Product: | gdb | Reporter: | vimacs.hacks <vimacs.hacks> |
Component: | c++ | Assignee: | Tom Tromey <tromey> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | brobecker, simark, tromey |
Priority: | P2 | ||
Version: | HEAD | ||
Target Milestone: | 13.1 | ||
Host: | Target: | ||
Build: | Last reconfirmed: | 2022-12-13 00:00:00 | |
Bug Depends on: | |||
Bug Blocks: | 29366 |
Description
vimacs.hacks@gmail.com
2022-12-13 02:05:07 UTC
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. 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. 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! |