Looking at the system map from the generic build of 2.4.3, it looks like
the code is 64 bit. The upper 32 bits are "f" instead of 0. I built it
using the R4600 flag. This differs from the system map for 2.4.0-test9
where the upper 32 bits are 0. For the indy, do I specify mips2 to
generate 32 bit code? objdump says it is ELF32, but it doesn't look like
that. I would like to generate 32bit.
On Tue, 31 Jul 2001, Carsten Langgaard wrote:
> Ralf Baechle wrote:
> > On Tue, Jul 31, 2001 at 09:28:22AM +0200, Thiemo Seufer wrote:
> > > > The la macro is split into a lui and a daddiu. The daddiu is not correct
> > > > for a mips32 cpu. Getting rid of the -mcpu=4600 fixes the problem and
> > > > the daddiu is then changed addiu.
> > >
> > > This is IIRC a known bug in at least current binutils CVS, a patch
> > > to fix it really was already discussed.
> > Is this macro expaned by the compiler or assembler? Just -mcpu=r4600
> > should not make cc1 generate any instructions beyond MIPS I.
> > In the past we already had inline assembler fragments that left the
> > assembler
> > in .misp3 mode thus resulting the rest of the file bein assembled in
> > mips3 mode.
> Yes, and I'm sure I fixed that so it worked on MIPS32 CPUs, only leaving the
> "eret" instructions.
> > > > Is there a truly correct -mcpu option for a mips32 cpu?
> > None is really good, none is really bad ...
> > > In theory, no -mcpu option (which is to be deprecated in
> > > favor of -march/-mtune) and -mips32 as ISA flag _should_ work.
> > >
> > > In practice, the patch which adds this to gas was discussed on the
> > > binutils list the last days and is likely to go in CVS
> > > today or tomorrow.
> > Ralf