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. thanks, john 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 > >
