This pr is to document some problems I'm seeing with gdb-generated plt symbols. The first one is that in a shared library with --export-dynamic, there are two ELF symbols with the same name: 1) the real function 2) the gdb-generated copy of the @plt symbol The "bug" is kinda subtle and may not result in any broken behaviour, though I have another bug to add here that may be related. symbol_set_names has this: /* If this name is not in the hash table, add it. */ if (*slot == NULL /* A C version of the symbol may have already snuck into the table. This happens to, e.g., main.init (__go_init_main). Cope. */ || (gsymbol->language == language_go && (*slot)->demangled[0] == '\0')) { char *demangled_name = symbol_find_demangled_name (gsymbol, linkage_name_copy); A problem is that symbol_find_demangled_name has side-effects, and if a second symbol is looked up with the same name, then it won't get its language field updated from language_auto (which is what prim_record_minimal_symbol_full initially sets it to, the reason for which can be found in the docs for install_minimal_symbols). This then causes build_minimal_symbol_hash_tables to not install the symbol in the demangled hash table because this test fails: if (MSYMBOL_SEARCH_NAME (msym) != MSYMBOL_LINKAGE_NAME (msym)) It fails because while the demangled name got set, the language was left as "auto". This is a problem at least because it causes confusion when tracking down other real bugs: iterate_over_minimal_symbols, called from linespec.c:search_minsyms_for_name, won't find it, so while this symbol would get included in the result for the main executable, it's missing in the result for the shared lib.
See also pr 17199 for comments on plt symbol support.
Created attachment 7724 [details] testcase, part 1
Created attachment 7725 [details] testcase, part 2 Test compiled as follows: gcc -g -fpic -shared -Wl,--export-dynamic -o plt-shared-lib.so plt-shared-lib.c gcc -g -Wl,-rpath,$(pwd) -o plt-shared-user plt-shared-user.c plt-shared-lib.so [manually copied over, watch for typos]
Re: "I have another bug to add here that may be related": Turns out this is c++ related. In c++ foo(int)@plt == foo(int), whereas in C, which is what "testcase, part 1,2" use, I don't see the problem because foo@plt != foo. Here's what I see with C: bash$ gdb plt-shared-user.x64 (gdb) b foo Breakpoint 1 at 0x400580 (gdb) i b Num Type Disp Enb Address What 1 breakpoint keep y 0x0000000000400580 <foo@plt> (gdb) r Starting program: /home/dje/src/play/plt-shared-user.x64 Breakpoint 1, foo () at plt-shared-lib.c:4 4 int foo () { return bar (); } (gdb) i b Num Type Disp Enb Address What 1 breakpoint keep y 0x00007ffff7ff26f7 in foo at plt-shared-lib.c:4 breakpoint already hit 1 time (gdb) Note that gdb properly transferred the breakpoint from foo@plt in the executable to foo in the shared library. [We can certainly have a discussion on whether gdb should even set a breakpoint on foo@plt. I'm leaving that for a separate step.] Here's what I see with C++: bash$ gdb plt-shared-user-cc.x64 (gdb) b foo Breakpoint 1 at 0x400590 (gdb) i b Num Type Disp Enb Address What 1 breakpoint keep y 0x0000000000400590 <foo()@plt> (gdb) r Starting program: /home/dje/src/play/plt-shared-user-cc.x64 Breakpoint 1, 0x0000000000400590 in foo()@plt () (gdb) i b Num Type Disp Enb Address What 1 breakpoint keep y <MULTIPLE> breakpoint already hit 1 time 1.1 y 0x0000000000400590 <foo()@plt> 1.2 y 0x00007ffff7ff2590 <foo()@plt> 1.3 y 0x00007ffff7ff2707 in foo() at plt-shared-lib-cc.cc:4 (gdb) Geez.
Created attachment 7726 [details] c++ testcase, part 1
Created attachment 7727 [details] c++ testcase, part 2 Test compiled as follows: g++ -g -fpic -shared -Wl,--export-dynamic -o plt-shared-lib-cc.so plt-shared-lib-cc.cc g++ -g -Wl,-rpath,$(pwd) -o plt-shared-user-cc plt-shared-user-cc.cc plt-shared-lib-cc.so [manually copied over, watch for typos]
For completeness sake, --export-dynamic is unnecessary.
I think this should be fixed by the patch I posted here: https://sourceware.org/pipermail/gdb-patches/2023-January/195979.html
The master branch has been updated by Andrew Burgess <aburgess@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=f0bdf68d3fb6db1dd2b83e07062e2104cdb785c2 commit f0bdf68d3fb6db1dd2b83e07062e2104cdb785c2 Author: Andrew Burgess <aburgess@redhat.com> Date: Fri Dec 16 15:15:42 2022 +0000 gdb/c++: fix handling of breakpoints on @plt symbols This commit should fix PR gdb/20091, PR gdb/17201, and PR gdb/17071. Additionally, PR gdb/17199 relates to this area of code, but is more of a request to refactor some parts of GDB, this commit does not address that request, but it is probably worth reading that PR when looking at this commit. When the current language is C++, and the user places a breakpoint on a function in a shared library, GDB will currently find two locations for the breakpoint, one location will be within the function itself as we would expect, but the other location will be within the PLT table for the call to the named function. Consider this session: $ gdb -q /tmp/breakpoint-shlib-func Reading symbols from /tmp/breakpoint-shlib-func... (gdb) start Temporary breakpoint 1 at 0x40112e: file /tmp/breakpoint-shlib-func.cc, line 20. Starting program: /tmp/breakpoint-shlib-func Temporary breakpoint 1, main () at /tmp/breakpoint-shlib-func.cc:20 20 int answer = foo (); (gdb) break foo Breakpoint 2 at 0x401030 (2 locations) (gdb) info breakpoints Num Type Disp Enb Address What 2 breakpoint keep y <MULTIPLE> 2.1 y 0x0000000000401030 <foo()@plt> 2.2 y 0x00007ffff7fc50fd in foo() at /tmp/breakpoint-shlib-func-lib.cc:20 This is not the expected behaviour. If we compile the same test using a C compiler then we see this: (gdb) break foo Breakpoint 2 at 0x7ffff7fc50fd: file /tmp/breakpoint-shlib-func-c-lib.c, line 20. (gdb) info breakpoints Num Type Disp Enb Address What 2 breakpoint keep y 0x00007ffff7fc50fd in foo at /tmp/breakpoint-shlib-func-c-lib.c:20 Here's what's happening. When GDB parses the symbols in the main executable and the shared library we see a number of different symbols for foo, and use these to create entries in GDB's msymbol table: - In the main executable we see a symbol 'foo@plt' that points at the plt entry for foo, from this we add two entries into GDB's msymbol table, one called 'foo@plt' which points at the plt entry and has type mst_text, then we create a second symbol, this time called 'foo' with type mst_solib_trampoline which also points at the plt entry, - Then, when the shared library is loaded we see another symbol called 'foo', this one points at the actual implementation in the shared library. This time GDB creates a msymbol called 'foo' with type mst_text that points at the implementation. This means that GDB creates 3 msymbols to represent the 2 symbols found in the executable and shared library. When the user creates a breakpoint on 'foo' GDB eventually ends up in search_minsyms_for_name (linespec.c), this function then calls iterate_over_minimal_symbols passing in the name we are looking for wrapped in a lookup_name_info object. In iterate_over_minimal_symbols we iterate over two hash tables (using the name we're looking for as the hash key), first we walk the hash table of symbol linkage names, then we walk the hash table of demangled symbol names. When the language is C++ the symbols for 'foo' will all have been mangled, as a result, in this case, the iteration of the linkage name hash table will find no matching results. However, when we walk the demangled hash table we do find some results. In order to match symbol names, GDB obtains a symbol name matching function by calling the get_symbol_name_matcher method on the language_defn class. For C++, in this case, the matching function we use is cp_fq_symbol_name_matches, which delegates the work to strncmp_iw_with_mode with mode strncmp_iw_mode::MATCH_PARAMS and language set to language_cplus. The strncmp_iw_mode::MATCH_PARAMS mode means that strncmp_iw_mode will skip any parameters in the demangled symbol name when checking for a match, e.g. 'foo' will match the demangled name 'foo()'. The way this is done is that the strings are matched character by character, but, once the string we are looking for ('foo' here) is exhausted, if we are looking at '(' then we consider the match a success. Lets consider the 3 symbols GDB created. If the function declaration is 'void foo ()' then from the main executable we added symbols '_Z3foov@plt' and '_Z3foov', while from the shared library we added another symbol call '_Z3foov'. When these are demangled they become 'foo()@plt', 'foo()', and 'foo()' respectively. Now, the '_Z3foov' symbol from the main executable has the type mst_solib_trampoline, and in search_minsyms_for_name, we search for any symbols of type mst_solib_trampoline and filter these out of the results. However, the '_Z3foov@plt' symbol (from the main executable), and the '_Z3foov' symbol (from the shared library) both have type mst_text. During the demangled name matching, due to the use of MATCH_PARAMS mode, we stop the comparison as soon as we hit a '(' in the demangled name. And so, '_Z3foov@plt', which demangles to 'foo()@plt' matches 'foo', and '_Z3foov', which demangles to 'foo()' also matches 'foo'. By contrast, for C, there are no demangled hash table entries to be iterated over (in iterate_over_minimal_symbols), we only consider the linkage name symbols which are 'foo@plt' and 'foo'. The plain 'foo' symbol obviously matches when we are looking for 'foo', but in this case the 'foo@plt' will not match due to the '@plt' suffix. And so, when the user asks for a breakpoint in 'foo', and the language is C, search_minsyms_for_name, returns a single msymbol, the mst_text symbol for foo in the shared library, while, when the language is C++, we get two results, '_Z3foov' for the shared library function, and '_Z3foov@plt' for the plt entry in the main executable. I propose to fix this in strncmp_iw_with_mode. When the mode is MATCH_PARAMS, instead of stopping at a '(' and assuming the match is a success, GDB will instead search forward for the matching, closing, ')', effectively skipping the parameter list, and then resume matching. Thus, when comparing 'foo' to 'foo()@plt' GDB will effectively compare against 'foo@plt' (skipping the parameter list), and the match will fail, just as it does when the language is C. There is one slight complication, which is revealed by the test gdb.linespec/cpcompletion.exp, when searching for the symbol of a const member function, the demangled symbol will have 'const' at the end of its name, e.g.: struct_with_const_overload::const_overload_fn() const Previously, the matching would stop at the '(' character, but after my change the whole '()' is skipped, and the match resumes. As a result, the 'const' modifier results in a failure to match, when previously GDB would have found a match. To work around this issue, in strncmp_iw_with_mode, when mode is MATCH_PARAMS, after skipping the parameter list, if the next character is '@' then we assume we are looking at something like '@plt' and return a value indicating the match failed, otherwise, we return a value indicating the match succeeded, this allows things like 'const' to be skipped. With these changes in place I now see GDB correctly setting a breakpoint only at the implementation of 'foo' in the shared library. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=20091 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=17201 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=17071 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=17199 Tested-By: Bruno Larsen <blarsen@redhat.com> Approved-By: Simon Marchi <simon.marchi@efficios.com>
I believe that this issue is now resolved. The code mentioned in the original description has changed significantly in current GDB, and though there's test source code, there's no steps to reproduce in GDB, so I can't say 100% that the issue is fixed, but I'm going to assume it is, and this issue can be reopened if the problem is still visible. However, the problem discussed in comments 4,5, and 6 was reproducible, and is now fixed.