From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5509 invoked by alias); 27 Feb 2007 12:02:54 -0000 Received: (qmail 5498 invoked by uid 22791); 27 Feb 2007 12:02:53 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Tue, 27 Feb 2007 12:02:44 +0000 Received: from dsl093-172-095.pit1.dsl.speakeasy.net ([66.93.172.95] helo=caradoc.them.org) by nevyn.them.org with esmtp (Exim 4.63) (envelope-from ) id 1HM12V-0007Ts-Rl; Tue, 27 Feb 2007 07:02:39 -0500 Received: from drow by caradoc.them.org with local (Exim 4.63) (envelope-from ) id 1HM12V-0001SS-M5; Tue, 27 Feb 2007 07:02:39 -0500 Date: Tue, 27 Feb 2007 13:14:00 -0000 From: Daniel Jacobowitz To: Joel Brobecker Cc: gdb@sourceware.org Subject: Re: failed assertion hit in check_typedef Message-ID: <20070227120239.GB5164@caradoc.them.org> Mail-Followup-To: Joel Brobecker , gdb@sourceware.org References: <20070227071658.GB13159@adacore.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070227071658.GB13159@adacore.com> User-Agent: Mutt/1.5.13 (2006-08-11) X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2007-02/txt/msg00270.txt.bz2 On Mon, Feb 26, 2007 at 11:16:58PM -0800, Joel Brobecker wrote: > So one of the unfortunate effects is that we end up in a situation > when we have a copy of that type definition in our DSO, and also > another copy in the main executable (more than one actually, but > one is already too many). > > As a result, we have a problem there (gdbtypes.c:check_typedef): > > else if (TYPE_STUB (type) && !currently_reading_symtab) > { > char *name = type_name_no_tag (type); > [...] > sym = lookup_symbol (name, 0, STRUCT_DOMAIN, 0, (struct symtab **) NULL); > if (sym) > make_cv_type (is_const, is_volatile, SYMBOL_TYPE (sym), &type); > } > > the lookup_symbol routine finds the first one which, bad luck, > just happens to be the definition from the main exectuable. Maybe we really want a lookup_symbol call which looks just in the correct objfile... well, I guess that wouldn't always help. > /* [repeat the comment already there (the one just above), > and explain that we avoid the overwrite if the two types are > not stored in the same obstack. Add explanation as to when > this can happen]. */ > if (typeptr && *typeptr != NULL > && TYPE_OBJFILE (*typeptr) != TYPE_OBJFILE (type)) > typeptr = NULL; > > It takes quite a long while to run the testsuite on mips-irix, > so I was wondering if I could get some feedback before I go too > far into this route... How about doing it in the caller? If you go to check_typedef, you'll see that there's already an example of the same thing. If this is DWARF2 and only started happening recently it may be the fault of your recent fixes for what empty types constitute a declaration. -- Daniel Jacobowitz CodeSourcery