Hi, I'm using qemu-mips in a MIPS gentoo chroot (I used stage3-mips1-20130711.tar.bz2). Everything seems to work fine except self-built binaries, since they escape the magic string in the example shown here: http://www.gentoo.org/proj/en/base/embedded/handbook/?part=1&chap=5 Using a binary diff program I noticed that the problem is the 8th byte, which is set to 0x01 instead of 0x00. Ignoring that byte in the bitmask solves the problem. Original: echo ':mips:M::\x7fELF\x01\x02\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x08:\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff:/usr/bin/qemu-mips:' > /proc/sys/fs/binfmt_misc/register Fixed: echo ':mips:M::\x7fELF\x01\x02\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x08:\xff\xff\xff\xff\xff\xff\xff\x00\x00\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff:/usr/bin/qemu-mips:' > /proc/sys/fs/binfmt_misc/register Looks like a problem in the EI_OSABI ELF field (from `man elf`): EI_OSABI This byte identifies the operating system and ABI to which the object is targeted. Some fields in other ELF structures have flags and values that have platform-specific meanings; the interpretation of those fields is determined by the value of this byte. E.g.: ELFOSABI_NONE Same as ELFOSABI_SYSV ELFOSABI_SYSV UNIX System V ABI. Same meaning, different values.
Created attachment 354186 [details, diff] Patch to ignore EI_OSABI in binfmt Other platforms might suffer the same problem, but to avoid problems with untested configurations I'm not fixing them here.
Hi @embedded team, I think this is for you guys
we take things straight from the qemu project (scripts/qemu-binfmt-conf.sh). so the patch probably should be sent upstream to the qemu project.
ELFOSABI_NONE & ELFOSABI_SYSV have a value of 0x00. ELFOSABI_HPUX has 0x01 and generating ELFs with that would be broken.