On 09/11/2018 15:14, Maciej W. Rozycki wrote: > On Fri, 9 Nov 2018, Laurent Vivier wrote: > >> if you have time, o32 & n32 support needs to be reworked. >> >> We have two binaries qemu-mips and qemu-mipsn32 sharing the same ELF >> mask/magic. >> >> As n32 identifies a kernel ABI version, we should have only one binary >> for qemu-mips and qemu-mipsn32 and the ABI version should be identified >> at runtime as it is done for ARM: >> >> ce4defa062 Arm Linux EABI syscall support. > > Are you sure? So is the ARM ABI handled with ce4defa062 64-bit?
I'm sure of nothing. It's why it's better if someone involved in mips development has an opinion on it :) > The o32 ABI is 32-bit (32-bit GPR width) while n32 is 64-bit (64-bit GPR > width). The correspondence between the i386 ABI and the x86-64 x32 ABI is > analogous to these two ABIs. > How are these x86 ABIs handled WRT the user emulation mode; are they > analogous to the ARM ABIs you've mentioned? > >> [I think we can use e_flags for that] > > The EF_MIPS_ABI2 `e_flags' bit denotes the n32 ABI. The container format > is ELF32 obviously, because addressing is 32-bit with n32. OK, I understand better. It looks like qemu-sparc32plus or qemu-ppc64abi32. If this is the case, you're right we need different binaries. >> I never did the change because I don't know where to find mipsn32 >> binaries to test my changes. > > I believe MIPS64 Debian is all n32. Some readelf results: mips64el/stretch Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 Class: ELF64 Flags: 0x80000007, noreorder, pic, cpic, mips64r2 mipsel/stretch Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 Class: ELF32 Flags: 0x70001007, noreorder, pic, cpic, o32, mips32r2 mips/stretch/bin Magic: 7f 45 4c 46 01 02 01 00 00 00 00 00 00 00 00 00 Class: ELF32 Flags: 0x70001007, noreorder, pic, cpic, o32, mips32r2 So 32bit mips are all o32, 64bit is n32. Are there any distros that are 32bit but n32? Any binaries that need qemu-mipsn32 or qemu-mipsn32el? Thanks, Laurent