It affects default configuration of latest stable release of GCC. echo -e '#include <string>\nstd::string foovar;'|g++ -c -o 20.o -Wall -g -x c++ -;nm -C 20.o|grep -w foovar 0000000000000000 B foovar[abi:cxx11] gdb -batch ./20.o -ex "p foovar" -ex "p 'foovar[abi:cxx11]'" Actual results: No symbol "foovar" in current context. $1 = {static npos = <optimized out>, _M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 0x0 <__static_initialization_and_destruction_0(int, int)>}, _M_string_length = 0, {_M_local_buf = '\000' <repeats 15 times>, _M_allocated_capacity = 0}} Expected results: $1 = "" (I do not care what it should for the second print.) One can use gcc -D_GLIBCXX_USE_CXX11_ABI=0 to get the old behavior. One could also configure gcc for the old behavior with: --with-default-libstdcxx-abi=gcc4-compatible GDB: b900245c3b92fc460a3f7fa17d14eb08f9ab4c76 7.10.50.20160107-git FAIL: g++ (GCC) 5.3.1 20160107 FAIL: g++ (GCC) 6.0.0 20150530 (experimental) I read it should affect already gcc-5.1 but I haven't verified that. The pretty printing bug is probably in libstdc++ pretty printers, I do not make that a subject of this PR.
A fail in gdb.cp/no-dmgl-verbose.exp is due to this PR. break 'f(std::string)'^M Function "f(std::string)" not defined.^M (gdb) FAIL: gdb.cp/no-dmgl-verbose.exp: setting breakpoint at 'f(std::string)' GDB can insert breakpoint if I add __cxx11 after std::, like this, (gdb) b 'f(std::__cxx11::string)' Breakpoint 1 at 0x8: file /home/yaoqi01/SourceCode/gnu/build-gdb/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.cp/no-dmgl-verbose.cc, line 23. Also, if I compile test case with -D_GLIBCXX_USE_CXX11_ABI=0, gdb works again,
Still a problem in GCC 6.3, GDB 7.10 -> With -D_GLIBCXX_USE_CXX11_ABI=1 (gdb) p fooVar p fooVar No symbol "fooVar" in current context. (gdb) info variables ... std::__cxx11::string fooVar[abi:cxx11]; .... (gdb) p 'fooVar[abi:cxx11]' p 'fooVar[abi:cxx11]' $2 = "hello world" -> With -D_GLIBCXX_USE_CXX11_ABI=0 (gdb) p fooVar p fooVar $2 = "hello world" Any chance somebody can have a look at this? thanks!
There is a patch series that has been submitted by Pedro which should address (or at least mitigate) this issue. See https://sourceware.org/ml/gdb-patches/2017-06/msg00012.html .
*** Bug 18601 has been marked as a duplicate of this bug. ***
The master branch has been updated by Pedro Alves <palves@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=bd69330db86b2367aac8aac5915f1686451c9d5d commit bd69330db86b2367aac8aac5915f1686451c9d5d Author: Pedro Alves <palves@redhat.com> Date: Wed Nov 29 19:33:24 2017 +0000 Breakpoints in symbols with ABI tags (PR c++/19436) Trying to set a breakpoint in a function with an ABI tag does not work currently. E.g., debugging gdb itself, we see this with the "string_printf" function: (top-gdb) b string_print [TAB] (top-gdb) b string_printf[abi:cxx11](char const*, ...) [RET] No source file named string_printf[abi. Make breakpoint pending on future shared library load? (y or [n]) Quoting doesn't help: (top-gdb) b 'string_printf[abi:cxx11]'(char const*, ...) malformed linespec error: unexpected string, "(char const*, ...)" (top-gdb) b 'string_printf[abi:cxx11](char const*, ...)' No source file named string_printf[abi. Make breakpoint pending on future shared library load? (y or [n]) n This patch fixes this, and takes it a bit further. The actual symbol name as demangled by libiberty's demangler is really string_printf[abi:cxx11](char const*, ...) however, this patch makes it possible to set the breakpoint with string_printf(char const*, ...) too. I.e., ignoring the ABI tag. And to match, it teaches the completer to complete the symbol name without the ABI tag, i.e., "string_pri<TAB>" -> "string_printf(char const*, ...)" If however, you really want to break on a symbol with the tag, then you simply start writing the tag, and GDB will preserve it, like: "string_printf[a<TAB>" -> "string_printf[abi:cxx11](char const*, ...)" Grows the gdb.linespec/ tests like this: -# of expected passes 8977 +# of expected passes 9176 gdb/ChangeLog: 2017-11-29 Pedro Alves <palves@redhat.com> PR c++/19436 * NEWS: Mention setting breakpoints on functions with C++ ABI tags. * completer.h (completion_match_for_lcd) <match, mark_ignored_range>: New methods. <finish>: Consider ignored ranges. <clear>: Clear ignored ranges. <m_ignored_ranges, m_finished_storage>: New fields. * cp-support.c (cp_search_name_hash): Ignore ABI tags. (cp_symbol_name_matches_1, cp_fq_symbol_name_matches): Pass the completion_match_for_lcd pointer to strncmp_iw_with_mode. (test_cp_symbol_name_cmp): Add [abi:...] tags unit tests. * language.c (default_symbol_name_matcher): Pass the completion_match_for_lcd pointer to strncmp_iw_with_mode. * linespec.c (linespec_lexer_lex_string): Don't tokenize ABI tags. * utils.c (skip_abi_tag): New function. (strncmp_iw_with_mode): Add completion_match_for_lcd parameter. Handle ABI tags. * utils.h (strncmp_iw_with_mode): Add completion_match_for_lcd parameter. gdb/testsuite/ChangeLog: 2017-11-29 Pedro Alves <palves@redhat.com> PR c++/19436 * gdb.linespec/cpls-abi-tag.cc: New file. * gdb.linespec/cpls-abi-tag.exp: New file. gdb/doc/ChangeLog: 2017-11-29 Pedro Alves <palves@redhat.com> PR c++/19436 * gdb.texinfo (Debugging C Plus Plus): Document setting breakpoints in functions with ABI tags.
"print" (In reply to Jan Kratochvil from comment #0) > It affects default configuration of latest stable release of GCC. > > > > echo -e '#include <string>\nstd::string foovar;'|g++ -c -o 20.o -Wall -g -x > c++ -;nm -C 20.o|grep -w foovar > 0000000000000000 B foovar[abi:cxx11] > gdb -batch ./20.o -ex "p foovar" -ex "p 'foovar[abi:cxx11]'" This now works in master: gdb -batch ./20.o -ex "p foovar" -ex "p 'foovar[abi:cxx11]'" $1 = "" $2 = "" which turns out to be a happy consequence of the commit listed above. I'm leaving the bug open because while bd69330db86b added comprehensive tests for breakpoints-on-symbols-with-abi-tags, it added none for print/expressions.
(In reply to Yao Qi from comment #1) > A fail in gdb.cp/no-dmgl-verbose.exp is due to this PR. FTR, this FAIL still exists, as mentioned here: https://sourceware.org/ml/gdb-patches/2019-10/msg00308.html.