Re: [PATCH] Fix distinction of 32/64bit addresses in MIPS gas

[Richard Sandiford <r dot sandiford at redhat dot com>]

Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de> writes:
> How could it do that? The o32 ABI does _not_ specify this flag,
> a file without any ABI flags set is a valid o32 file. I can't
> see what the use of the O32 header flag could be.

Ok, that hadn't twigged, sorry!

So, if I've understood you correctly, your take seems to be:

- O32 doesn't define an ABI bit for ELF, so every ELF file without
  an ABI flag set should be compatible with O32.

Whereas mine is:

- O32 doesn't define an ABI bit for ELF, so users dosn't have that
  safety net if they use the wrong options.  They need to remember
  to use the appropriate command-line switches, like -mabi=32.

  Fleshing that out a bit, I think:

  GAS has historically supported all sorts of wierd and wonderful
  combinations that don't have any representation in the ELF header
  flags.  And for which no ABI flags will be set.  I don't think that's
  reason enough not to allow them.  GAS should generate whatever code
  the command line tells it to, whether or not those options can be
  determined from the output file.

> [snip]
> I want to have full 64bit support, and it's conceptionally the right
> thing to keep the variants of 64bit support at a minimum.

Which is a great thing.  But people should be able to do things the old
way too!

> AFAICS my patch doesn't break the limited 64bit support.

Like you said in your previous mail, it means that $gp is now assumed to
be a 32-bit rather than 64-bit value.  There might be dynamic loaders
out there that handle the R_MIPS_64 extension, which could replace them
with genuine 64-bit (as opposed to sign-extended 32-bit) addresses.  I
don't know if either of those matter in practice.  But...

> > > I also found no reason why there is made use of 64bit instructions
> > > like daddiu for a 32bit load. It makes the code look different from
> > > o32 while doing the same.
> > 
> > But if the code was written or compiled with 64-bit addresses in mind,
> > it seems natural enough to use daddu in pointer arithmetic.  Does it do
> > any harm?
> 
> Yes, it inflates the number of variants without need.

...I really don't see why maintaining the old variant is a problem.  All
the main part of your patch did was change the definition of the
HAVE_32BIT_ADDRESSES macro, it didn't really seem to simplify the code
as such.

> > The only reason I can see for making HAVE_32BIT_ADDRESSES any
> > stricter is if there's a situation in which code written for 32-bit
> > addresses can't be assembled that way as things stand, presumably
> > because GAS's command-line options are too inflexible.
> 
> Then I would need to distinguish between (! HAVE_32BIT_ADDRESSES)
> and HAVE_64BIT_ADDRESSES, building a trap for everyone else.
> MIPS gas is really complicated enough with ISA, ABI and object
> formats.

I still don't see why you need to do that, sorry!  Sometimes these things
take a while to sink in.  In what situation would the two be different?
Like you say, they should be inverses.

Richard