[Bug symtab/18258] New: Non-opaque type preference needs to take into account included symtabs

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

https://sourceware.org/bugzilla/show_bug.cgi?id=18258

            Bug ID: 18258
           Summary: Non-opaque type preference needs to take into account
                    included symtabs
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: symtab
          Assignee: unassigned at sourceware dot org
          Reporter: dje at google dot com

I don't have a reportable testcase for this, but I want to write this down
while it's fresh.

This loop in dw2_lookup_symbol:

      while ((per_cu = dw2_symtab_iter_next (&iter)) != NULL)
        {
          struct symbol *sym = NULL;
          struct compunit_symtab *stab = dw2_instantiate_symtab (per_cu);
          const struct blockvector *bv = COMPUNIT_BLOCKVECTOR (stab);
          struct block *block = BLOCKVECTOR_BLOCK (bv, block_index);

          /* Some caution must be observed with overloaded functions            
             and methods, since the index will not contain any overload         
             information (but NAME might contain it).  */
          sym = block_lookup_symbol (block, name, domain);

          if (sym && strcmp_iw (SYMBOL_SEARCH_NAME (sym), name) == 0)
            {
              if (!TYPE_IS_OPAQUE (SYMBOL_TYPE (sym)))
                return stab;

              stab_best = stab;
            }

          /* Keep looking through other CUs.  */
        }

doesn't take into account the fact that "stab" can actually be a list of
multiple symbol tables (stab->includes). In the program where I'm seeing the
problem:

(top-gdb) p stab->includes[0]@5
$161 =   {[0] = 0x1810cd0,
  [1] = 0xa94ed90,  <<< has opaque definition
  [2] = 0x10bfb7b0,  <<< has full definition
  [3] = 0x10e4ba90,
  [4] = 0x0}

So we find the opaque definition, and will never see the full definition,
unless the user happens to do something that causes 0x10bfb7b0 to be read in
via another symtab.

-- 
You are receiving this mail because:
You are on the CC list for the bug.