From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27455 invoked by alias); 22 Apr 2010 01:11:29 -0000 Received: (qmail 27232 invoked by uid 22791); 22 Apr 2010 01:11:27 -0000 X-SWARE-Spam-Status: No, hits=3.6 required=5.0 tests=BAYES_00,KAM_STOCKTIP X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 22 Apr 2010 01:11:22 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id E9DB72BAB2B; Wed, 21 Apr 2010 21:11:20 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id CqU7f8SGpPa6; Wed, 21 Apr 2010 21:11:20 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 4576C2BAB8C; Wed, 21 Apr 2010 21:11:20 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id B7CD2F5895; Wed, 21 Apr 2010 18:11:19 -0700 (PDT) Date: Thu, 22 Apr 2010 01:11:00 -0000 From: Joel Brobecker To: Pierre Muller Cc: gdb-patches@sourceware.org Subject: Re: [RFC] Fix bug report 11479 Message-ID: <20100422011119.GF19194@adacore.com> 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> <001501cae197$280ca8b0$7825fa10$@muller@ics-cnrs.unistra.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001501cae197$280ca8b0$7825fa10$@muller@ics-cnrs.unistra.fr> User-Agent: Mutt/1.5.20 (2009-06-14) 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/msg00725.txt.bz2 > > 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. It's definitely something i got myself confused over. In the stabs I posted: .stabs "t:p(0,21)=*(0,22)=k(0,23)=xsdummy:",160,0,28,-24 .stabs "dummy:T(0,23)=s16x:(0,1),0,32;y:(0,1),32,32;b:(0,13),64,64;;",128,0,0,0 Type dummy is numbered (0,23), whereas I talked myself into thinking that type (0,23) would the be constant version of type dummy. With that confusion cleared, we do indeed clear the stub condition on our type at the time when we read the second stabs line above. So, by the time we reach the cleanup_undefined_types_1 stage, the type is actually no longer undefined. > I still think that we should cycle over the type_chain when the type > is parsed. I am afraid this might be the only solution indeed. For some reason, even after our pretty comprehensive investigating, I am still pretty reluctant about it, and I think it is because it looks wrong to perform this relatively unintuitive operation, and just do it for structs. Conceivably, you'd need to do the same for enums as well, right? I think we can reduce my anxiety by: - Adding detailed comments explaining what and why; - Putting the code inside a function so that we can reuse it elsewhere should the need arise; Do you think that this would be an acceptable approach? Sorry if I am slow, but stabsread, and stabs in general, are two horrible deprecated pieces of technology - so it's hard to remain current. -- Joel