From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25240 invoked by alias); 28 Jun 2002 18:27:04 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 25226 invoked from network); 28 Jun 2002 18:27:02 -0000 Received: from unknown (HELO potter.sfbay.redhat.com) (205.180.83.107) by sources.redhat.com with SMTP; 28 Jun 2002 18:27:02 -0000 Received: from romulus.sfbay.redhat.com (IDENT:uRvYmDjIfNHN2QEaRfmXqKj241LR27hR@romulus.sfbay.redhat.com [172.16.27.251]) by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id g5SISLQ31175; Fri, 28 Jun 2002 11:28:21 -0700 Received: (from kev@localhost) by romulus.sfbay.redhat.com (8.11.6/8.11.6) id g5SIQxI26407; Fri, 28 Jun 2002 11:26:59 -0700 Date: Fri, 28 Jun 2002 11:27:00 -0000 From: Kevin Buettner Message-Id: <1020628182659.ZM26406@localhost.localdomain> In-Reply-To: Kevin Buettner "Re: [PATCH] more m68k multi-arch" (Jun 28, 11:03am) References: <20020624131028.A1510@tomago.toronto.redhat.com> <1020628180358.ZM26305@localhost.localdomain> To: Grace Sainsbury , gdb-patches@sources.redhat.com Subject: Re: [PATCH] more m68k multi-arch MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-06/txt/msg00571.txt.bz2 On Jun 28, 11:03am, Kevin Buettner wrote: > On Jun 24, 1:10pm, Grace Sainsbury wrote: > > > +#if !GDB_MULTI_ARCH > > #define STORE_STRUCT_RETURN(ADDR, SP) \ > > { write_register (A1_REGNUM, (ADDR)); } > > > > @@ -221,11 +228,13 @@ > > (TYPE_LENGTH(TYPE) >= 4 ? 0 : 4 - TYPE_LENGTH(TYPE)), \ > > TYPE_LENGTH(TYPE)) > > #endif > > +#endif //multi-arch > > I've noticed the addition of a number of ``#if !GDB_MULTI_ARCH'' > statements in your patch. Presumably, these are temporary until > you finish the job, right? (I'm wondering if it's necessary to > keep them around at all.) I've been looking at this some more... I've noticed the following define near the top of tm-m68k.h: #define GDB_MULTI_ARCH 0 Clearly, with this definition in place, you do need to keep the old definitions around, because those are the ones that will be used! It seems to me that your testing will be more productive if you do one of the following: 1) define GDB_MULTI_ARCH to be GDB_MULTI_ARCH_PARTIAL (1) instead of 0. or 2) change the macro definitions being replaced to instead refer to the newly defined functions in m68k-tdep.c. As it stands now, you are only testing that the functions that you've added to the tdep.c file build (i.e. compile), but GDB won't actually be using them. This means that if you make a typo, it won't be noticed until some later point when GDB_MULTI_ARCH is changed from 0 to some other value. Kevin