RE: [RFC] Fix bug report 11479

["Pierre Muller" <pierre.muller@ics-cnrs.unistra.fr>]

> -----Message d'origine-----
> De : gdb-patches-owner@sourceware.org [mailto:gdb-patches-
> owner@sourceware.org] De la part de Joel Brobecker
> Envoyé : Wednesday, April 21, 2010 5:11 PM
> À : Pierre Muller
> Cc : gdb-patches@sourceware.org
> Objet : Re: [RFC] Fix bug report 11479
> 
> > >   But this is the trouble,
> > > the chain was not cycled before my patch,
> > > and thus the 'const type' was never resolved and its length
> > > was still left at zero.
> > >   I didn't really get what the loop line 4465
> > > is supposed to do, but it only operates on LOC_TYPEDEF,
> > > and on the file_symbol level, not at argument list of functions...
> 
> Pierre - I understand now what you were trying to say.  The problem in
> this situation is that there are no global variable of the type that
> we need to fix.
> 
> I think that the proper solution would be to enhance function
> cleanup_undefined_types_1 to also look at symbols inside function
> symbols.  That way, the problem should be fixed for all kinds of
> types, not just structs...

 I do not think that this is enough:
 the problem is more that TYPE_STUB macro refers
to the flag_stub of main_type, which means that
once the main_type flag_stub has been cleared,
all types having the same main_type will also return
zero for TYPE_STUB.
> The following should work: In the loop over file_symbols, check
> the symbol type: If it is a function, then get the function block,
> and iterate again on all symbols inside that block. If not a function,
> then we match the symbol itself.  We will probably need to move the
> symbol matching condition to its own function to avoid duplication...

  I still think that we should cycle over the type_chain
when the type is parsed.
  Otherwise we need your suggestion, plus a
check of for all types still having zero length.

But I still think that my patch is
already a good step. At least for 
the problem I presented in the bug report.

Pierre