From mboxrd@z Thu Jan 1 00:00:00 1970 From: Richard Sandiford To: Thiemo Seufer Cc: binutils@sources.redhat.com Subject: Re: [PATCH] Fix distinction of 32/64bit addresses in MIPS gas Date: Fri, 07 Sep 2001 07:02:00 -0000 Message-id: References: <20010831143107.A4532@lucon.org> <20010906105014.A32456@lucon.org> <20010906110751.B32621@lucon.org> <20010907055315.A351@rembrandt.csv.ica.uni-stuttgart.de> <20010907152225.A30834@rembrandt.csv.ica.uni-stuttgart.de> X-SW-Source: 2001-09/msg00087.html Thiemo Seufer 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