I Followed the steps to bootstrap an ARMv7-hardfp in a chroot, using qemu. I got it working, but there was some things required different than the linked document describes:
1. I had to mount -rbind /proc and /dev.
/dev was already populated in the tarball, but I needed /dev/pts also bound - else I got warnings about no more ptys.
Similarly, the /proc/sys/fs/binfmt_misc mountpoint needs to be preserved within the chroot too, else you cannot enter the chroot.
2. For some reason, /usr/libexec/gcc/armv7a-hardfloat-linux-gnueabi/4.5.3/cc1 has the value 0x08 for byte 15 of the file. (i.e. e_ident of ELF header) The ELF spec states (as I read it) this is reserved (should be zero) and readers should ignore whatever is read.
For cc1, it is not zero (all other binaries seem to work as expected) and the binfmt registration line is written to explicitly expect zeroes, and not 'don't care'.
I found this line worked for me:
echo ':arm2:M::\x7fELF\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x28\x00:\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\x00\xff\xfe\xff\xff\xff:/qemu-wrapper:' > /proc/sys/fs/binfmt_misc/register
But this only ignores the problematic byte. A full solution possibly should ignore all bytes in the header the spec requires us to.
I am not sure if it is a problem or not that cc1 has that byte set in the first place.
This manifests as emerge errors "configure: error: C compiler cannot create executables", so perhaps FAQ 6.1 could reflect this as one possible cause. (reading the config.log pointed me to cc1 resulting in 'cannot execute binary' leading to examination of the binfmt matching string).
Same issue using lxc-gentoo and building an ARM container via binfmt. qemu-binfmt set an incorrect value for the arm2 registration. David's change worked for me, allowing the container to start.
Please provide a patch for the document if you want this fixed
should be fixed by: