From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32242 invoked by alias); 12 Apr 2010 16:22:36 -0000 Received: (qmail 32230 invoked by uid 22791); 12 Apr 2010 16:22:35 -0000 X-SWARE-Spam-Status: No, hits=3.7 required=5.0 tests=BAYES_00,KAM_STOCKTIP,MSGID_MULTIPLE_AT,TW_XS X-Spam-Check-By: sourceware.org Received: from mailhost.u-strasbg.fr (HELO mailhost.u-strasbg.fr) (130.79.200.154) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 12 Apr 2010 16:22:26 +0000 Received: from baal.u-strasbg.fr (baal.u-strasbg.fr [IPv6:2001:660:2402::41]) by mailhost.u-strasbg.fr (8.14.3/jtpda-5.5pre1) with ESMTP id o3CGM1G4008504 ; Mon, 12 Apr 2010 18:22:01 +0200 (CEST) (envelope-from pierre.muller@ics-cnrs.unistra.fr) Received: from mailserver.u-strasbg.fr (ms2.u-strasbg.fr [IPv6:2001:660:2402:d::11]) by baal.u-strasbg.fr (8.14.0/jtpda-5.5pre1) with ESMTP id o3CGM0Yu054050 ; Mon, 12 Apr 2010 18:22:00 +0200 (CEST) (envelope-from pierre.muller@ics-cnrs.unistra.fr) Received: from d620muller (gw-ics.u-strasbg.fr [130.79.210.225]) (user=mullerp mech=LOGIN) by mailserver.u-strasbg.fr (8.14.3/jtpda-5.5pre1) with ESMTP id o3CGM0gj092806 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) ; Mon, 12 Apr 2010 18:22:00 +0200 (CEST) (envelope-from pierre.muller@ics-cnrs.unistra.fr) From: "Pierre Muller" To: "'Joel Brobecker'" Cc: References: <000f01cad75b$b53278a0$1f9769e0$@muller@ics-cnrs.unistra.fr> <20100412155453.GW19194@adacore.com> In-Reply-To: <20100412155453.GW19194@adacore.com> Subject: RE: [RFC] Fix bug report 11479 Date: Mon, 12 Apr 2010 16:22:00 -0000 Message-ID: <000001cada5c$49b8e1a0$dd2aa4e0$@muller@ics-cnrs.unistra.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2010-04/txt/msg00366.txt.bz2 > -----Message d'origine----- > De=A0: gdb-patches-owner@sourceware.org [mailto:gdb-patches- > owner@sourceware.org] De la part de Joel Brobecker > Envoy=E9=A0: Monday, April 12, 2010 5:55 PM > =C0=A0: Pierre Muller > Cc=A0: gdb-patches@sourceware.org > Objet=A0: Re: [RFC] Fix bug report 11479 >=20 > > 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. >=20 > 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. =20 > > 2010-04-08 Pierre Muller > > > > * stabsread.c (read_struct_type): Also set length of > > other types in the chain. >=20 > 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: >=20 > .stabs "t:p(0,21)=3D*(0,22)=3Dk(0,23)=3Dxsdummy:",160,0,28,-24 Yes, this is what I also got.=20 > Followed later on by the actual definition: >=20 > .stabs > "dummy:T(0,23)=3Ds16x:(0,1),0,32;y:(0,1),32,32;b:(0,13),64,64;;",128,0,0, > 0 >=20 > 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.=20 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,=20 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.=20 > > 2010-04-08 Pierre Muller > > Test for bug 11479. > > * gdb.stabs/gdb11479.exp: New file. > > * gdb.stabs/gdb11479.c: New file. >=20 > Just a small cleanup request: >=20 > > +# 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