This is the mail archive of the
mailing list for the binutils project.
Re: MIPS HAVE_32BIT_ADDRESSES bogon ?
firstname.lastname@example.org ("Thiemo Seufer") writes:
> > I'm wondering if maybe HAVE_32BIT_ADDRESSES should be defined as:
> > (HAVE_32BIT_GPRS
> > || ((bfd_arch_bits_per_address (stdoutput) == 32
> > || ! HAVE_64BIT_OBJECTS)
> > && mips_pic != EMBEDDED_PIC))
> Does EMBEDDED_PIC _always_ have 64 bit addresses or only in combination
> with -mlong64?
It's possible to code a program entirely in assembler which uses
EMBEDDED_PIC, and 64-bit addresses. (Given that it's for embedded
use, that's not as insane a statement as it might seem... Certainly
it's a reasonable thing for e.g. small test programs.)
So, it's certainly possible to have 64-bit addresses w/o the C
compiler flag -mlong64.
> If the latter, it's better to check for -mlong64 for this
> purpose, an option which doesn't exist in gas yet.
I actually think this is a bit insane. The notion of having to
explicitly tell the assembler that higher-level langauge 'pointers'
and 'longs' (what's a long to the mips assembler? that thing that
.long generates as 4 bytes? 8-) seems ... wrong.
What's the _harm_ in generating 'd' ops for embedded-pic if there are
64-bit GPRs? (heck, what's wrong with using them for e.g. n32?!)
I guess I actually don't get, in general, the harm of using the 'd'
ops when ptr size is 32 bits. is this to make _sure_ you get
overflow? do e.g. SGI assemblers do this?
Actually, this led me to an "uh oh!": mips-opc.c is quite happy to
unconditinoally implement e.g. 'la' as addiu... that seems ... wrong,