mips: genmongoosev/start/start.S

[Ralf Corsepius]

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.

>   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?

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.

Ralf