RE: [RFC] Fix bug report 11479

["Pierre Muller" <pierre dot muller at ics-cnrs dot unistra dot fr>]

> -----Message d'origine-----
> De?: gdb-patches-owner@sourceware.org [mailto:gdb-patches-
> owner@sourceware.org] De la part de Joel Brobecker
> Envoyé?: Monday, April 12, 2010 5:55 PM
> À?: Pierre Muller
> Cc?: gdb-patches@sourceware.org
> Objet?: Re: [RFC] Fix bug report 11479
> 
> >   This is not a direct RFA for two reasons:
> [...]
> >  2) concerning  the fix in stabsread.c, this chain of different types
> >  that all point to the same main type could apparently be something
> >  else than just a simple 'const' or 'volatile' modifier.  But I don't
> >  think that I know enough about the other possibilities to know if I
> >  should exclude them from my patch by checking if only TYPE_CONST and
> >  TYPE_VOLATILE are different.
> 
> It's OK to post an RFA even if there are questions you don't know how
> to answer. If we don't either, then we'll just have to go with what
> we have and fix any problem we might find later.

  OK, I will remember that.
 
> > 2010-04-08  Pierre Muller  <muller@ics.u-strasbg.fr>
> >
> > 	* stabsread.c (read_struct_type): Also set length of
> > 	other types in the chain.
> 
> It would have been useful if you had also provided a copy of the stabs
> for us to look at. I think I managed to generate them from the C file
> you provided:
> 
>         .stabs  "t:p(0,21)=*(0,22)=k(0,23)=xsdummy:",160,0,28,-24
Yes, this is what I also got. 
> Followed later on by the actual definition:
> 
>         .stabs
> "dummy:T(0,23)=s16x:(0,1),0,32;y:(0,1),32,32;b:(0,13),64,64;;",128,0,0,
> 0
> 
> What I don't get is that the xsdummy should lead to what we call an
> undefined type in stabsread.c, which should be put in the undef_types
> queue. 
  Yes, 'x' is handled line 1540,
and 's' stands for structure, and if followed by a name
that is not yet defined, it will lead to a call
to add_undefined_type.
> This queue is then processed at the end to fix all undefined
> types, including the various volatile/const variants in the type chain.

  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...

The const or volatile modifier simply create
another type with the same main_type and is added to the chain.
So the chain seemed the easiest place for me to fix this.

> Any idea why this is not working this way for your example?
  Yes, see above. 
> > 2010-04-08  Pierre Muller  <muller@ics.u-strasbg.fr>
> > 	Test for bug 11479.
> > 	* gdb.stabs/gdb11479.exp: New file.
> > 	* gdb.stabs/gdb11479.c: New file.
> 
> Just a small cleanup request:
> 
> > +# Please email any bugs, comments, and/or additions to this file to:
> > +# bug-gdb@gnu.org

  I took just one other bug report and copied it...

Pierre