Date: Wed, 2 Jun 2010 13:01:31 -0700 From: Juli Mallett <jmallett@FreeBSD.org> To: John Baldwin <jhb@freebsd.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r208737 - in head: contrib/binutils/bfd contrib/binutils/gas/config contrib/binutils/include/elf contrib/binutils/include/opcode contrib/binutils/opcodes contrib/gcc/config contrib/gcc/... Message-ID: <AANLkTilVZ07G6giuvVZOoV_-JLSThYg0fPVGsEumlfC9@mail.gmail.com> In-Reply-To: <201006020842.49509.jhb@freebsd.org> References: <201006021106.o52B63PZ035362@svn.freebsd.org> <201006020842.49509.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Jun 2, 2010 at 05:42, John Baldwin <jhb@freebsd.org> wrote: > On Wednesday 02 June 2010 7:06:03 am Juli Mallett wrote: >> =A0 o) Fix our GCC spec to define __mips64 for 64-bit targets, not __mip= s64__, the >> =A0 =A0 =A0former being what libgcc, etc., check and the latter seemingl= y being a >> =A0 =A0 =A0misspelling of a hand merge from a Linux spec. > > I wonder if it would be useful to define both? =A0The macros we check for > architecture-specific code for other architectures all have both leading = and > trailing underscores (e.g. __i386__, __amd64__, etc.). =A0Being able to u= se > __mips64__ instead of __mips64 for that in kernel sources, etc. would be > more consistent. __mips64 is a mistake and adding __mips64__ and using it would be a bigger one, I think, since it's kind of confusing and not actually useful enough to use consistently. MIPS64 is the name of a particular ISA, but not all 64-bit ISAs (indeed, the earliest 64-bit ISA is MIPS-III) are derived from it. __mips64 implies a 64-bit ABI, but there isn't a clean split between non-__mips64 ABIs and __mips64 ABIs such that those are the only two things you'd ever need to check for. We intend to support the n32 ABI in userland, which has 64-bit registers. Conditionals related to that kind of thing would become (__mips64__ || __mips_n32). I think it makes more sense to be consistent and use macros related to specific ABIs, macros related to specific ISAs and sometimes the macros related to the length of long and the size of a pointer, since there are some ABIs that we might support (o64) which can support strange combinations of those. Thanks, Juli.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTilVZ07G6giuvVZOoV_-JLSThYg0fPVGsEumlfC9>