From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-patches-return-17274-listarch-gdb-patches=sourceware.cygnus.com@sources.redhat.com>
Received: (qmail 18554 invoked by alias); 1 Aug 2002 21:47:23 -0000
Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm
Precedence: bulk
List-Subscribe: <mailto:gdb-patches-subscribe@sources.redhat.com>
List-Archive: <http://sources.redhat.com/ml/gdb-patches/>
List-Post: <mailto:gdb-patches@sources.redhat.com>
List-Help: <mailto:gdb-patches-help@sources.redhat.com>, <http://sources.redhat.com/ml/#faqs>
Sender: gdb-patches-owner@sources.redhat.com
Received: (qmail 18545 invoked from network); 1 Aug 2002 21:47:21 -0000
Received: from unknown (HELO cygnus.com) (205.180.83.203)
  by sources.redhat.com with SMTP; 1 Aug 2002 21:47:21 -0000
Received: from redhat.com (reddwarf.sfbay.redhat.com [172.16.24.50])
	by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id OAA20563;
	Thu, 1 Aug 2002 14:46:39 -0700 (PDT)
Message-ID: <3D49A814.A75E2C66@redhat.com>
Date: Thu, 01 Aug 2002 14:47:00 -0000
From: Michael Snyder <msnyder@redhat.com>
Organization: Red Hat, Inc.
X-Accept-Language: en
MIME-Version: 1.0
To: Andrew Cagney <ac131313@ges.redhat.com>
CC: Kevin Buettner <kevinb@redhat.com>, gdb-patches@sources.redhat.com
Subject: Re: [PATCH] 64-bit support for Irix 6
References: <1020731172757.ZM21630@localhost.localdomain> <3D494F95.5060708@ges.redhat.com> <3D499BCF.2E79188@redhat.com> <3D49A72F.7040108@ges.redhat.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-SW-Source: 2002-08/txt/msg00024.txt.bz2

Andrew Cagney wrote:
> 
> > Andrew Cagney wrote:
> >
> >>
> >
> >> >
> >> >  #include "mips/tm-bigmips.h"
> >> >
> >> > +#undef MIPS_REGSIZE
> >> > +#define MIPS_REGSIZE 8
> >> > +
> >> >  /* SGI's assembler doesn't grok dollar signs in identifiers.
> >> >     So we use dots instead.  This item must be coordinated with G++. */
> >> >  #undef CPLUS_MARKER
> >> > @@ -89,11 +92,12 @@
> >> >        32 * sizeof(double) + ((N) - 32) * MIPS_REGSIZE)
> >> >
> >> >  #undef  REGISTER_VIRTUAL_TYPE
> >> > +/* define 8 byte register type */
> >> >  #define REGISTER_VIRTUAL_TYPE(N) \
> >> >       (((N) >= FP0_REGNUM && (N) < FP0_REGNUM+32) ? builtin_type_double \
> >> >        : ((N) == 32 /*SR*/) ? builtin_type_uint32 \
> >> >        : ((N) >= 70 && (N) <= 89) ? builtin_type_uint32 \
> >> > -      : builtin_type_int)
> >> > +      : builtin_type_long_long)
> >> >
> >> >  /* Force N32 ABI as the default. */
> >> >  #define MIPS_DEFAULT_ABI MIPS_ABI_N32
> >> >
> >
> >>
> >> Kevin, this is wrong.
> >>
> >> It is no longer acceptable to add support for an additional sub-target
> >> using non-multi-arch mechanisms.
> >
> >
> > Does that mean that if we touch a macro, we have to multi-arch it?
> 
> If you want to fix a bug in a macro then you should first (separatly)
> convert it to a macro/function pair.  I believe this is accepted as
> ``current best pratice''.
> 
> If you want to change a bunch of macros to support an additional
> architecture variant then they need to be multi-arch.  GDB no longer
> accepts an architecture variants that isn't multi-arch.
> 
> > For instance, if we touch the PUSH_ARGUMENTS function, and
> > PUSH_ARGUMENTS
> > hasn't been multi-arched, do we have to multi-arch it?
> 
> If you mean mips_push_arguments, then that is already part of the
> multi-arch vector. 

Umm... no it isn't.  I can see why you think it is
(set_gdbarch_push_arguments is called), but the call to
PUSH_ARGUMENTS is still going thru the macro in tm-mips.h.

> Just don't forget that any changes to that function
> should be multi-arch friendly.

So I can use code similar to what is already there
(eg.  "if (tdep->mips_abi == MIPS_ABI_N32)")
rather than splitting the function into variously
mips_n32_push_argument etc.?