[ks@localhost ~]$ cat test.cpp void f(int) __attribute ((abi_tag ("foo"))); void f(int) { } int main() { f(42); } [ks@localhost ~]$ g++ -g test.cpp [ks@localhost ~]$ [ks@localhost ~]$ nm -C a.out|grep foo 00000000004005b6 T f[abi:foo](int) [ks@localhost ~]$ [ks@localhost ~]$ gdb -q a.out Reading symbols from a.out...done. (gdb) b 'f[abi:foo](int)' No source file named f[abi. Make breakpoint pending on future shared library load? (y or [n]) n (gdb) GCC 5.1 uses abi_tag attribute for Dual ABI implementation: https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html This makes impossible to set breakpoints on some functions with new ABI, which is enabled by default: https://gcc.gnu.org/gcc-5/changes.html#libstdcxx
I hope to be working up a formal fix for this in the coming week, but I'd like to mention a few things, including a workaround. First, explicit locations (coming to a release some after 7.10 I suspect) "just work": (gdb) break -function f[abi:foo] Breakpoint 1 at 0x4005bd: file /home/keiths/tmp/18601.cc, line 4. Not that it will help you for the meantime (unless you apply my monstrously large locations API patches). I'll be returning to that series of patches this week, too. An aside: quote-enclosing (entire) linespecs does /nothing/ in the parser. Because IDEs have historically quote-enclosed all linespec locations, the parser has to ignore them. Another historical bug that we have to maintain. That's /not/ to say that quotes do nothing. As it is, I happen to know that there is another legacy bug that the linespec parser emulates that can be used to workaround your problem: (gdb) b 'f[abi:foo]':1 Breakpoint 1 at 0x4005bd: file /home/keiths/tmp/18601.cc, line 4. [The :1 should be a line-offset from the beginning of the function. That feature was never implemented, but since it was silently ignored in previous releases, that behavior was maintained when the linespec parser was rewritten.]
(In reply to Keith Seitz from comment #1) > I hope to be working up a formal fix for this in the coming week, but I'd > like to mention a few things, including a workaround. That didn't happen, but the cxx-improvements patch which I reviewed should help. That was reported in c++/19436, where there's been more discussion (and a link to the patch series). Let's close this bug and track progress there. *** This bug has been marked as a duplicate of bug 19436 ***