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 09:20: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> <20010907171141.C30834@rembrandt.csv.ica.uni-stuttgart.de> X-SW-Source: 2001-09/msg00092.html Thiemo Seufer writes: > > - 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. OK. Even so, my answer's the same. > 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. Yes, that makes things clearer, thanks. In that case I'd personally vote for your idea of making the new expansion depend on another macro. Not HAVE_64BIT_ADDRESSES, since that (if ever used) really ought to be an inverse of HAVE_32BIT_ADDRESSES. But HAVE_64BIT_OBJECT_FILE, or whatever. Anyway, I think I finally understand the issue. Everyone else involved probably understood them ages ago, so sorry folks. I think there is a policy decision to be made here, though, it isn't just your run-of-the mill "fix". Richard