From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3541 invoked by alias); 21 Apr 2010 21:11:47 -0000 Received: (qmail 3405 invoked by uid 22791); 21 Apr 2010 21:11:39 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=BAYES_00,MSGID_MULTIPLE_AT X-Spam-Check-By: sourceware.org Received: from mailhost.u-strasbg.fr (HELO mailhost.u-strasbg.fr) (130.79.200.152) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 21 Apr 2010 21:11: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 o3LLAxYn008632 ; Wed, 21 Apr 2010 23:11:00 +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 o3LLAxFC047530 ; Wed, 21 Apr 2010 23:10:59 +0200 (CEST) (envelope-from pierre.muller@ics-cnrs.unistra.fr) Received: from d620muller (lec67-4-82-230-53-140.fbx.proxad.net [82.230.53.140]) (user=mullerp mech=LOGIN) by mailserver.u-strasbg.fr (8.14.3/jtpda-5.5pre1) with ESMTP id o3LLAw5a042054 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) ; Wed, 21 Apr 2010 23:10:58 +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> <000001cada5c$49b8e1a0$dd2aa4e0$@muller@ics-cnrs.unistra.fr> <20100413152823.GG19194@adacore.com> <20100421151117.GA13675@adacore.com> In-Reply-To: <20100421151117.GA13675@adacore.com> Subject: RE: [RFC] Fix bug report 11479 Date: Wed, 21 Apr 2010 21:11:00 -0000 Message-ID: <001501cae197$280ca8b0$7825fa10$@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/msg00706.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: Wednesday, April 21, 2010 5:11 PM > =C0=A0: Pierre Muller > Cc=A0: gdb-patches@sourceware.org > Objet=A0: Re: [RFC] Fix bug report 11479 >=20 > > > 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... >=20 > 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. >=20 > 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=20 the problem I presented in the bug report. Pierre