This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
mips address+symbol issue.
- From: cgd at broadcom dot com
- To: gcc at gcc dot gnu dot org,binutils at sources dot redhat dot com
- Cc: rsandifo at redhat dot com
- Date: 23 Jan 2004 13:00:59 -0800
- Subject: mips address+symbol issue.
This is case of strange compiler + assembler issues ("surprise
surprise" 8-). I ran into it testing mipsisa64-elf on real HW.
(strangely, sim didn't flag it, dunno what's up with that.)
I was testing code with and without -mno-explicit-relocs, to see if a
change i made to binutils was OK. (I was using a combined tree w/
sources as of 2004-01-21.)
The problematic test is gcc.c-torture/execute/960321-1.c. I was
testing on a real target board (BCM91250A), with "-Tcfe.ld" as the
linker script. The test binary comes out as EABI64 in that
configuration.
For the -O0 case, GCC is emitting code like:
acc_a:
.frame $fp,16,$31 # vars= 8, regs= 1/0, args= 0,
gp= 0
.mask 0x40000000,-8
.fmask 0x00000000,0
daddiu $sp,$sp,-16
sd $fp,8($sp)
move $fp,$sp
sd $4,0($fp)
ld $3,0($fp)
dla $2,a-2000000000
daddu $2,$3,$2
lb $2,0($2)
What's happening is that the assembler turns that 'dla' into:
14: 3c0288ca lui v0,0x88ca
14: R_MIPS_HI16 a
18: 24426c00 addiu v0,v0,27648
18: R_MIPS_LO16 a
and then at link time A ends in kseg0:
80022808 g O .data 0000000a a
so the final instructions in the object file end up as:
8002020c: 3c0208cd lui v0,0x8cd
80020210: 24429408 addiu v0,v0,-27640
which end up having the effect:
v0 = 0x8cc9408
Unfortunately:
0x8cc9408 + 2000000000 != 0x(ffffffff)80022808
without -mno-explicit-relocs, the compiler gets it right.
I can think of several possible solutions here:
(1) don't allow GCC to emit "dla sym+offset" for
-mno-explicit-relocs, or maybe just for -mno-explicit-relocs
and the ABIs which stuff 64-bit pointers into 32-bit object
files.
(2) make binutils emit long code sequences for sym + offset when
assembling objects for an ABI which stuffs 64-bit pointers
into 32-bit object files.
(3) punt. (maybe even xfail the test for some MIPS targets w/
-mno-explicit-relocs.)
It seems to me that (2) is *probably* the right fix, but others'
opinions would be appreciated. I think I'm OK with (3), too, but it
might bite others down the road...
chris