This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] 64-bit support for Irix 6


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.?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]