From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thiemo Seufer To: binutils@sources.redhat.com Subject: Re: [PATCH] Fix distinction of 32/64bit addresses in MIPS gas Date: Fri, 07 Sep 2001 08:11:00 -0000 Message-id: <20010907171141.C30834@rembrandt.csv.ica.uni-stuttgart.de> 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/msg00089.html Richard Sandiford wrote: > 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. Not exactly. Most tools will _regard_ it as o32, even if it isn't. > 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. ABI header flags were invented for remembering it. It would be nice if the linker had a chance to find out what the file actually is. > 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. One NO_ABI_FLAG as a catchall would be enough to let at least the GNU tools know what the file is _not_. [snip] > > 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. This is always assumed for everything loaded in 32bit address space. > 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. They can't, because R_MIPS_64 holds only 32bit in this case. [snip] > > 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. It didn't increase complexity while providing all what I need for full 64bit support. That's the advantage over a 32BIT -- HALF_64BIT -- FULL_64BIT approach. [snip] > 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. Full 64bit support requires a 64bit object format to work, half 64bit support doesn't have one and has it's code in 32bit space. This means for e.g. "dli" a expansion to lui $a, %highest(sym) lui $b, %hi(sym) daddiu $a, %higher(sym) daddiu $b, %lo(sym) dsll32 $a, 0 daddu $a, $a, $b for 64bit addresses, while 32bit addresses should use lui $a, %hi(sym) addiu $a, %lo(sym) for performance and code size. The half 64bit version currently uses lui $a, %hi(sym) daddiu $a, %lo(sym) which does exactly the same but pretends to use 64bit addresses. I hope it got clearer now. Thiemo