Re: failed assertion hit in check_typedef

[Daniel Jacobowitz <drow at false dot org>]

On Mon, Feb 26, 2007 at 11:16:58PM -0800, Joel Brobecker wrote:
> So one of the unfortunate effects is that we end up in a situation
> when we have a copy of that type definition in our DSO, and also
> another copy in the main executable (more than one actually, but
> one is already too many).
> 
> As a result, we have a problem there (gdbtypes.c:check_typedef):
> 
>   else if (TYPE_STUB (type) && !currently_reading_symtab)
>     {
>       char *name = type_name_no_tag (type);
>       [...]
>       sym = lookup_symbol (name, 0, STRUCT_DOMAIN, 0, (struct symtab **) NULL);
>       if (sym)
>         make_cv_type (is_const, is_volatile, SYMBOL_TYPE (sym), &type);
>     }
> 
> the lookup_symbol routine finds the first one which, bad luck,
> just happens to be the definition from the main exectuable.

Maybe we really want a lookup_symbol call which looks just in the
correct objfile... well, I guess that wouldn't always help.

>       /* [repeat the comment already there (the one just above),
>          and explain that we avoid the overwrite if the two types are
>          not stored in the same obstack. Add explanation as to when
>          this can happen].  */
>       if (typeptr && *typeptr != NULL
>         && TYPE_OBJFILE (*typeptr) != TYPE_OBJFILE (type))
>       typeptr = NULL;
> 
> It takes quite a long while to run the testsuite on mips-irix,
> so I was wondering if I could get some feedback before I go too
> far into this route...

How about doing it in the caller?  If you go to check_typedef, you'll
see that there's already an example of the same thing.  If this is
DWARF2 and only started happening recently it may be the fault of your
recent fixes for what empty types constitute a declaration.

-- 
Daniel Jacobowitz
CodeSourcery