From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4937 invoked by alias); 25 Jul 2014 23:01:07 -0000 Mailing-List: contact gdb-prs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-prs-owner@sourceware.org Received: (qmail 4908 invoked by uid 48); 25 Jul 2014 23:01:06 -0000 From: "dje at google dot com" To: gdb-prs@sourceware.org Subject: [Bug symtab/17201] New: problems with gdb-generated plt symbols Date: Fri, 25 Jul 2014 23:01:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: symtab X-Bugzilla-Version: HEAD X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: dje at google dot com X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2014-q3/txt/msg00155.txt.bz2 https://sourceware.org/bugzilla/show_bug.cgi?id=17201 Bug ID: 17201 Summary: problems with gdb-generated plt symbols Product: gdb Version: HEAD Status: NEW Severity: normal Priority: P2 Component: symtab Assignee: unassigned at sourceware dot org Reporter: dje at google dot com 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. -- You are receiving this mail because: You are on the CC list for the bug.