[Bug symtab/17201] New: problems with gdb-generated plt symbols

["dje at google dot com" <sourceware-bugzilla@sourceware.org>]

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.