Bug 246527 - emulators/qemu-user-static: please add syscall 574 (__realpathat)
Summary: emulators/qemu-user-static: please add syscall 574 (__realpathat)
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Kyle Evans
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-05-17 14:20 UTC by Martin Birgmeier
Modified: 2020-05-23 06:24 UTC (History)
2 users (show)

See Also:
bugzilla: maintainer-feedback? (emulation)


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Birgmeier 2020-05-17 14:20:06 UTC
Scenario:
- using qemu-user-static to cross compile ports in FreeBSD 13 armv6
- The native boot shows (in dmesg.boot)

FreeBSD 13.0-CURRENT #0 r361029M: Fri May 15 16:26:48 CEST 2020
    root@v903.xyzzy:/auto/z/OBJ/FreeBSD/amd64/head/arm.armv6/sys/RPI-B arm
FreeBSD clang version 10.0.0 (git@github.com:llvm/llvm-project.git llvmorg-10.0.0-0-gd32170dbd5b)

- But here, qemu-user-static is used instead, chrooting to the armv6 installation.
- The amd64 host is also at r361029.

Result:
- There are many lines of

qemu: unsupported syscall: 574 (calling anyway)
qemu: unsupported syscall: 574 (calling anyway)                                 
qemu: unsupported syscall: 574 (calling anyway)
qemu: unsupported syscall: 574 (calling anyway)

- These lines sometimes even confuse tools, causing the build to fail.

Could you please add the latest syscalls to this port?

-- Martin
Comment 1 Kyle Evans freebsd_committer freebsd_triage 2020-05-17 14:25:27 UTC
Hi,

Indeed, the latest version not yet in ports does have all the latest syscalls. New version is waiting for tracking down a signal regression from back in October that prevents build of cmake and others with the current port.
Comment 2 Martin Birgmeier 2020-05-17 14:46:26 UTC
Thanks Kyle for the quick feedback & all your work.

-- Martin
Comment 3 Kyle Evans freebsd_committer freebsd_triage 2020-05-17 15:08:40 UTC
Yup- I should have mentioned, if you do or are willing to build your own qemu-user-static port, I have a patch available here that updates it to a version that implements most of the latest syscalls and seemingly fixes issues with multi-threaded stuff: https://reviews.freebsd.org/D24655 -> It doesn't fix the aforementioned signal regression, but it's generally stable.
Comment 4 Martin Birgmeier 2020-05-17 15:17:51 UTC
Thank you, building right now.

Is the "signal regression" the issue where qemu would simply stop while emulating a program? - I have this all the time and then need to ^c and restart.

-- Martin
Comment 5 Kyle Evans freebsd_committer freebsd_triage 2020-05-17 15:25:35 UTC
Nope, as far as I can test that particular issue is fixed in the patch I've posted- I managed to build guile2 for aarch64 thrice without a hangup.

The signal issue generally results in a segfault and prompt build failure.
Comment 6 Martin Birgmeier 2020-05-17 15:32:21 UTC
Ok understood.

The build just finished, so now off to building armv6 ports... the noise is already gone, thanks for that!

And if I understand correctly the hangs should also be gone - looking forward to see that!

-- Martin
Comment 7 Martin Birgmeier 2020-05-17 16:47:18 UTC
Your patches are working nicely. I could not build binutils using emulation before because the configure stage was producing incorrect results. Now it is happily chugging along...

-- Martin
Comment 8 Martin Birgmeier 2020-05-23 06:24:33 UTC
Hi Kyle,

Some feedback: I am in the process of recompiling all ports for this armv6 installation after upgrading FreeBSD to head as of r361029. I have noticed two things:

First, there are still the hangs. They seem to mostly (only?) occur with running ld (lld), and then also mostly if that process is the end of a deep sequence of nested processes. So maybe this has something to do with some resource which gets exhausted by qemu? Maybe some file descriptor? (Maybe ld opens many file at the same time?)

Second, and this is new with the qemu built with your patch, some emulated programs result in an immediate signal 11, dumping a core for qemu. These programs are currently xgettext (from gettext-tools-0.20.2) and xmlcatalog (from libxml2-2.9.10); both of these ports have already been recompiled. Is it this issue when you mention the "signal regression"?

It is not even possible to run ldd on these binaries; "ldd /usr/local/bin/xgettext" results in the same immediate signal 11 core dump (of qemu).

Note that cmake-3.17.2 has been rebuilt successfully, but building glib20 (which needs xmlcatalog during building) is now not possible.

-- Martin