mips: genmongoosev/start/start.S

[gregory.menke at gsfc.nasa.gov]

Ralf Corsepius writes:
 > On Tue, 2003-09-09 at 16:37, gregory.menke at gsfc.nasa.gov wrote:
 > > 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.
 > 
 > Don't! It seems to be horribly broken. At least I just have encountered
 > a breath-taking bug in gcc-3.3.2pre, which I verified to break at least
 > mips-rtems and i386-rtems, and suspect to probably break all rtems-gccs,
 > if not many more targets.
 > 
 > These "M_BIU" type of arguments are defines, aren't they?
 > If so, the bug I just tripped over, could be an explanation.

They are #defines, and there are quite a few all over the place, in
the mips cpukit also.  The Mongoose in particular puts a bunch of
hardware up at the very top of memory.  Many of the #defines are < 16
bits in magnitude, so those <might> be OK- but anything greater than
16 will have this problem.

 > > 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?
 > 
 > Not yet, Joel wants to release rtems-4.6 with
 > gcc-3.2.3/binutils-2.13.2.1 first. I am currently using a local version
 > of gcc-3.3.2pre with RTEMS's patches applied. I already submitted them
 > to Joel, but given the problems I encounter, I *strongly* discourage
 > anybody not wanting to get involved into gcc development to use it.
 > 
 > 
 > >   If I can get them, I'll download the new gcc and
 > > start working up a patch.
 > I'll send you my local nosrc.rpm, but ... it is the version exposing the
 > problems.

Okey dokey.  I'll at least experiment with it a little to maybe help
characterize the issue.

Gregm