Re: [Qemu-devel] [PATCH v3] target/mips: Support R5900 GCC programs in user mode

[Maciej W. Rozycki]

Hi Fredrik,

> Many thanks for your review, Maciej,

 You are welcome!

> >  Eventually you'll have to remove all these instructions (plus LL and SC) 
> > from the system emulation mode.  In fact I think it would make sense to do 
> > that right away, because I believe it will be a reasonably simple update. 
> > However if it turns out to be a can of worms after all, then I think we 
> > can defer it, because we do not have a bare-metal environment ready for 
> > this CPU anyway (or do we?).
> 
> Indeed, very simple. I added a new check function check_insn_opc_user_only,
> similar to check_insn_opc_removed, conditional on USER_ONLY and so a simple
> 
>       check_insn_opc_user_only(ctx, INSN_R5900);
> 
> has to be added for these OPC cases. To test this I tried to build GCC with
> the target mips64r5900el but it unfortunately didn't work as GCC failed to
> compile itself:
> 
>       ../sysdeps/mips/mips64/mul_1.S:49: Error: opcode not supported on
>               this processor: r5900 (mips3) `dmultu $8,$7'

 That file is a part of GMP rather that GCC I believe.  A copy is used 
by glibc too.

 I think you'll have to arrange for GMP and glibc builds to avoid this 
file for R5900 targets, either by supplying a handcoded R5900 assembly 
alternative that avoids the missing instruction (possibly by using a 
sequence of MULTU operations), or by using the generic C-language 
version from mul_1.c.

 I wouldn't recommend placing an architecture override within the 
generic 64-bit MIPS assembly so as to force it to build, as any kernel 
DMULTU emulation is bound to be slower, because it'll have to do all 
that we need to do here anyway, and then it'll add the overhead of 
calling an exception handler.

 I suspect there will be more such cases to handle in GMP and glibc.  
As GMP holds the master copies of code you'll need to submit any updates 
to that project first, and once accepted they can be carried over to 
glibc.

 As I suggested before you may wish to focus on making o32 work first 
rather than keeping being distracted by 64-bit issues, so that we have 
at least some functional code upstream before diving into enhancements 
and corner cases.

 HTH,

  Maciej