| View previous topic :: View next topic |
| Author |
Message |
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54234
Location: 56N 3W
|
 Posted: Thu Dec 15, 2016 2:45 pm Post subject: qemu-static for arm64 on amd64 |
 |
|
Team,
I've been building for 64 bit Raspberry Pi 3 with a mix of cross compiling, cross distcc and native builds.
A few odds and ends provoke build fails, possibly because 1G RAM is really not enough to link in.
I'm using gcc-6.2.0-r1 and the gold linker too, just because I can.
To test the RAM theory, I thought I would try qemu-static. So by way of something nice and easy for the
qemu-static chroot to do I tried emerge -K. No compiling, just unpack and install the binary.
However, it fails with
| Code: | >>> /usr/lib/gcc/aarch64-unknown-linux-gnu/6.2.0/libvtv.so -> libvtv.so.0.0.0
>>> /usr/lib/gcc/aarch64-unknown-linux-gnu/6.2.0/libasan.so.3 -> libasan.so.3.0.0
>>> /usr/lib/gcc/aarch64-unknown-linux-gnu/6.2.0/liblsan.so.0 -> liblsan.so.0.0.0
>>> /usr/lib/gcc/aarch64-unknown-linux-gnu/6.2.0/libubsan.so.0 -> libubsan.so.0.0.0
>>> /usr/lib/gcc/aarch64-unknown-linux-gnu/6.2.0/libtsan.so.0 -> libtsan.so.0.0.0
qemu: Unsupported syscall: 277 |
That snippit is gcc but binutils does the same thing.
Google says that syscall by number varies with arch. So is this qemu-arm64 not implementing syscall 277 or the underlying amd64 kernel?
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
 |
Hu
Moderator
Joined: 06 Mar 2007
Posts: 21624
|
| Posted: Fri Dec 16, 2016 2:41 am Post subject: |
|
|
That message occurs in one place in qemu source (looking at version 2.5.0, but likely applicable to other versions): | linux-user/syscall.c:10019: | | gemu_log("qemu: Unsupported syscall: %d\n", num); |
The logged variable is an input parameter to that function, do_syscall. That can be reached through the default: or unimplemented: labels of a switch statement. Based on the values used in the switch case statements, I think 277 should be looked up in the syscall numbers for the emulated system, not the host system. You said this is arm64, which I think is aarch64/syscall_nr.h in qemu. Perhaps unsurprisingly given the error, there is no #define in aarch64/syscall_nr.h that expands to 277. Looking at Linux kernel sources, my guess is arch/arm64/include/asm/unistd32.h:578:#define __NR_mq_timedreceive 277. As pointed out by deagol two posts further down, 277 is not __NR_mq_timedreceive. It is seccomp.
[Edit: grey out incorrect statement. Add green statement.]
Last edited by Hu on Wed Dec 21, 2016 2:35 am; edited 1 time in total |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54234
Location: 56N 3W
|
| Posted: Sat Dec 17, 2016 9:26 pm Post subject: |
|
|
Hu,
Thanks for the explanation. I've moved on on another path.
I found that my cross environment was using binutils-2.27 and that things that failed on the Pi cross compiled there.
Switching to that on the Pi itself fixed almost all the linker issues, so I'm back to the Pi with binutils-2.27.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
deagol
n00b
Joined: 12 Jul 2014
Posts: 61
|
| Posted: Tue Dec 20, 2016 10:04 am Post subject: |
|
|
I'm also cross compiling a gentoo user-space for a raspberry pi3 and aarch64.
That turned out to be quite a ride... And one of the more annoying things was this missing syscall in qemu.
It made running emerge-chroot a real pain, since every single packet merge hits the issue. Freezing the emerge...
After killing the emerge task (kill -9) the packet could still be merged manually (using ebuild), but that made it a really cumbersome to install packages in the chroot environment... So I dug a bit deeper and found a workaround I want to share here:
First, qemu has the syscall at least defined in aarch64/syscall_nr.h (checked upstream git):
| Code: | #define TARGET_NR_seccomp 277
|
But the code handling the syscall in qemu is still missing.
Looking at a stalled merge it turns out that the problematic binary is /usr/bin/scanelf.
With that knowledge there is a simple workaround: Disable seccomp support for pax-utils:
/etc/portage/package.use/package.use
| Code: | app-misc/pax-utils -seccomp
|
and re-emerging app-misc/pax-utils is doing the trick. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Gentoo on ARM
