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: Thu, 06 Sep 2001 20:53:00 -0000 Message-id: <20010907055315.A351@rembrandt.csv.ica.uni-stuttgart.de> References: <20010831204556.C17249@rembrandt.csv.ica.uni-stuttgart.de> <20010831143107.A4532@lucon.org> <20010906105014.A32456@lucon.org> <20010906110751.B32621@lucon.org> X-SW-Source: 2001-09/msg00064.html Richard Sandiford wrote: [snip] > I feel I'm missing something here, so sorry if I'm going round in > circles. I'm just not sure I understand what the problem is. > > AFAIK, R_MIPS_64 won't be used unless you have 64-bit addresses (and > hence 64-bit registers), or if you have an explicit pseudo-op like > .8byte. o32 binaries wouldn't be using either of those things anyway, > would they? That's right, but you can't tell if it is actually o32 conformant by looking at the ELF header. There is no flag which says "Warning! This object does not conform to any established ABI". It would be nice to have one. > I thought the consensus some time ago was that o32 implied 32-bit > registers, and therefore 32-bit addresses. The HAVE_??BIT_ macros are > already set up like that as long as you specify -mabi=32 on the command > line. That's all fine for 32bit, but I needed a way to check if 64bit addresses can be used generally (e.g. for dli). Something like ! HAVE_32BIT_ADDRESSES won't do that, because full 64bit support needs a 64bit object format. Having a HAVE_64BIT_ADDRESSES macro which is _not_ the inverse of HAVE_32BIT_ADDRESSES is ugly. 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. This was the one part of my patch. The other was to change (d)la to chose it's expansion in dependency of the address model instead of the insn name. That's the way the SGI assembler behaves, and this is the useful behaviour for ABI conformance. For 64bit code in an 32bit object file this may have side effects (the usability of R_MIPS_64 is not affected). I split up my patch in two parts, the dla change is appended below. Thiemo 2001-09-07 Thiemo Seufer /gas/ChangeLog * tc_mips.c (macro): Fix address load instruction. /gas/testsuite/ChangeLog * gas/mips/ld.d: Use 32bit instructions for addresses. * gas/mips/mips-gp64-fp32-pic.d: Likewise. * gas/mips/mips-gp64-fp32-pic.s: Likewise. * gas/mips/mips-gp64-fp32.d: Likewise. * gas/mips/mips-gp64-fp32.s: Likewise. * gas/mips/mips-gp64-fp64-pic.d: Likewise. * gas/mips/mips-gp64-fp64-pic.s: Likewise. * gas/mips/mips-gp64-fp64.d: Likewise. * gas/mips/mips-gp64-fp64.s: Likewise. * gas/mips/elempic.d: Likewise. * gas/mips/uld.d: Likewise. * gas/mips/usd.d: Likewise. diff -BurpNX /bigdisk/src/binutils-exclude src-orig/gas/config/tc-mips.c src/gas/config/tc-mips.c --- src-orig/gas/config/tc-mips.c Sat Aug 18 21:47:23 2001 +++ src/gas/config/tc-mips.c Tue Aug 21 18:21:49 2001 @@ -4288,7 +4458,7 @@ macro (ip) if (expr1.X_add_number == 0 && tempreg == PIC_CALL_REG) lw_reloc_type = (int) BFD_RELOC_MIPS_CALL16; macro_build ((char *) NULL, &icnt, &offset_expr, - dbl ? "ld" : "lw", + HAVE_32BIT_ADDRESSES ? "lw" : "ld", "t,o(b)", tempreg, lw_reloc_type, GP); if (expr1.X_add_number == 0) { diff -BurpNX /bigdisk/src/binutils-exclude src-orig/gas/testsuite/gas/mips/ld.d src/gas/testsuite/gas/mips/ld.d --- src-orig/gas/testsuite/gas/mips/ld.d Mon Jul 2 14:34:18 2001 +++ src/gas/testsuite/gas/mips/ld.d Tue Aug 21 19:20:35 2001 @@ -628,12 +628,12 @@ Disassembly of section .text: 0+05d0 <[^>]*> sw a1,4\(zero\) 0+05d4 <[^>]*> lui a0,[-0-9x]+ [ ]*5d4: [A-Z0-9_]*HI[A-Z0-9_]* .bss.* -0+05d8 <[^>]*> daddu a0,a0,a1 +0+05d8 <[^>]*> addu a0,a0,a1 0+05dc <[^>]*> ld a0,[-0-9]+\(a0\) [ ]*5dc: [A-Z0-9_]*LO[A-Z0-9_]* .bss.* 0+05e0 <[^>]*> lui at,[-0-9x]+ [ ]*5e0: [A-Z0-9_]*HI[A-Z0-9_]* .sbss.* -0+05e4 <[^>]*> daddu at,at,a1 +0+05e4 <[^>]*> addu at,at,a1 0+05e8 <[^>]*> sd a0,[-0-9]+\(at\) [ ]*5e8: [A-Z0-9_]*LO[A-Z0-9_]* .sbss.* 0+05ec <[^>]*> nop