From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32394 invoked by alias); 7 Sep 2009 18:24:14 -0000 Received: (qmail 32377 invoked by uid 22791); 7 Sep 2009 18:24:13 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00 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; Mon, 07 Sep 2009 18:24:07 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id A09432BAB73; Mon, 7 Sep 2009 14:24:05 -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 NN7CxLbPSI60; Mon, 7 Sep 2009 14:24:05 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 5A0932BAB24; Mon, 7 Sep 2009 14:24:05 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id EE251F589B; Mon, 7 Sep 2009 11:24:00 -0700 (PDT) Date: Mon, 07 Sep 2009 18:24:00 -0000 From: Joel Brobecker To: Doug Evans Cc: Jan Kratochvil , Joel Sherrill , "gdb@sourceware.org" , Ralf Corsepius , gdb-patches@sourceware.org Subject: Re: SPARC GDB Failure Message-ID: <20090907182400.GG30677@adacore.com> References: <4AA5161D.1020102@oarcorp.com> <20090907164528.GA6326@host0.dyn.jankratochvil.net> <20090907175406.GA13914@host0.dyn.jankratochvil.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) 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: 2009-09/txt/msg00162.txt.bz2 > Long-term-wise, maybe the thing to do is have all allocs of > gdbarch_tdep go through a function (gdbarch_tdep_alloc or some such). > That would make it clear how one *should* alloc them. Not sure if it is possible or not without having to pass the size explicitly. This structure is opaque to most of the code in GDB, and the size is usually only known inside the specific -tdep.c file. We might be able to work around that by defining a macro instead of having a function, but it's not clear whether it'd be a real improvement or not over a call to XZALLOC... -- Joel