mips: genmongoosev/start/start.S

gregory.menke at gsfc.nasa.gov gregory.menke at gsfc.nasa.gov
Tue Sep 9 14:37:12 UTC 2003


Ralf Corsepius writes:
 > Hi,
 > 
 > May-be there's a mips-expert on this list, who can help:
 > 
 > Compiling genmongoosev/start/start.S with gcc-3.3.2pre and binutils-2.14
 > fails with this error:
 > 
 > # mips-rtems4.7-gcc --pipe -B../../../../../../../lib/
 > -B../../../../../../../genmongoosev/lib/ -specs bsp_specs -qrtems -mips1
 > -G0 -isystem ../../../../../../../genmongoosev/lib/include   -DASM -o
 > o-optimize/start.o -c
 > .../../../../../../../../../../rtems.master/c/src/lib/libbsp/mips/genmongoosev/start/start.S
 > .../../../../../../../../../../rtems.master/c/src/lib/libbsp/mips/genmongoosev/start/start.S: Assembler messages:
 > .../../../../../../../../../../rtems.master/c/src/lib/libbsp/mips/genmongoosev/start/start.S:585: Error: load/store address overflow (max 32 bits)
 > .../../../../../../../../../../rtems.master/c/src/lib/libbsp/mips/genmongoosev/start/start.S:620: Error: load/store address overflow (max 32 bits)
 > .../../../../../../../../../../rtems.master/c/src/lib/libbsp/mips/genmongoosev/start/start.S:628: Error: load/store address overflow (max 32 bits)
 > ....
 > 
 > AFAIS, all lines gas is complaining about are of this type:
 > 
 >    sw  t0,M_BIU
 > 
 > gcc-3.2.x/binutils-2.13.x compiled this file without any complaint.
 > So, what is it that cause gcc-3.3.x/binutils-2.14 to fail?
 > Invalid ASM, previous versions of the toolchain has let pass through? A
 > bug in gcc-3.3.x, binutils-2.14? Invalid compiler options not matching
 > the expectations of this *.S-file?
 > 

I haven't upgraded to gcc 3.3 yet, so I can't test directly.  The
instructions are all load/store between a register & memory.  I
suspect its because of the size of the address, in these cases they
are all up at the top of memory; 0xffff0000 and above.  The Mongoose
manual indicates loads/stores are supposed to only have a 16 bit
offset from a base register.  I think we've been getting a freebie
from gcc up to this point; it must be rewriting the instruction to
DWIM via some internal register ($at perhaps?), and now isn't.  It
might be as simple as the new gas not enabling $at by default...

I think the fix will be fairly easy, just recoding the instructions so
they use the appropriate addressing model, it should be pretty easy.
Hopefully the MIPS cpukit is not also affected...

I checked the rtems.com source tree and couldn't find the gcc3.3
sources under snapshots/c_tools.  Are the standard OAR versions
available someplace?  If I can get them, I'll download the new gcc and
start working up a patch.

Gregm





More information about the users mailing list