Re: a couple of gas MIPS ABI issues.

[cgd at broadcom dot com]

ica2_ts@csv.ica.uni-stuttgart.de ("Thiemo Seufer") writes:
> Eric M. Christopher wrote:
> > Here's how I think this code should work:
> > 
> > 1) Keep the same abi as was used previously
> > 2) Allow access to register size of new ISA level.
> 
> That's a contradiction. Allowing different register sizes will
> break ABI conformance. IMHO .set mipsN should simply remove
> all restrictions which aren't ISA inherent. The ABI is one of
> these.

This is _not true_.


#define HAVE_64BIT_OBJECTS (mips_abi == N64_ABI)

/* We can only have 64bit addresses if the object file format
   supports it.  */
#define HAVE_32BIT_ADDRESSES                           \
   (HAVE_32BIT_GPRS                                    \
    || ((bfd_arch_bits_per_address (stdoutput) == 32   \
         || ! HAVE_64BIT_OBJECTS)                      \
        && mips_pic != EMBEDDED_PIC))

#define HAVE_64BIT_ADDRESSES (! HAVE_32BIT_ADDRESSES)


so, say you're compiling -mips3 -mabi=64 code, 64-bit ELF code.
Reasonable, right?  (OK, maybe it doesn't actually _work_ right now,
but that's another issue.  This a conceptual thing.)

Then you ".set mips64" for a particular assembly section that happens
to do some 'non-truly-mips64 stuff'.

e.g. it does say a dmtc/dmfc w/ a sel, but then also does an load
using an address specified w/ a label or something.


So, inside your .set mips64, you're going to have mips_abi == NO_ABI.

So, HAVE_32BIT_ADDRESSES, which used to evaluate to
0 (== (0 || ((0 || 0) && 1))) will now evaluate to
1 (== (0 || ((0 || 1) && 1))).


The point here is, the ABI does _not_ govern just the ISA level used.

It governs stuff like the size of GOT elements, etc.

When you want to just change the ISA level, you _do not_ want to
change the use of rest of the ABI-related features in the binary.
Really.  You _only_ want to change the ISA level.



chris