[Bug 253335] emulators/qemu-user-static php segfault building devel/pear for armv7
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253335 --- Comment #13 from Mark Johnston --- (In reply to Kyle Evans from comment #12) Yeah, I couldn't really understand the T_ALIGNFLT check. I can submit a patch tomorrow, but feel free to fix it if you prefer. I have another qemu-user-static bug to look at tomorrow. :) -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-emulation@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-emulation To unsubscribe, send any mail to "freebsd-emulation-unsubscr...@freebsd.org"
[Bug 253335] emulators/qemu-user-static php segfault building devel/pear for armv7
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253335 --- Comment #12 from Kyle Evans --- (In reply to Kyle Evans from comment #11) (I suspect I was somehow looking at the wrong trap type values and steered the previous discussion amiss. :-() -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-emulation@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-emulation To unsubscribe, send any mail to "freebsd-emulation-unsubscr...@freebsd.org"
[Bug 253335] emulators/qemu-user-static php segfault building devel/pear for armv7
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253335 --- Comment #11 from Kyle Evans --- (In reply to Mark Johnston from comment #10) Heh, I just arrived at the same conclusion, but hadn't yet found the logs where we were talking about this. IMO we should reapply the change, but correctly (drop T_ALIGNFLT, that seems completely wrong) and with an accurate commit message. -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-emulation@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-emulation To unsubscribe, send any mail to "freebsd-emulation-unsubscr...@freebsd.org"
[Bug 253335] emulators/qemu-user-static php segfault building devel/pear for armv7
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253335 Mark Johnston changed: What|Removed |Added CC||i...@freebsd.org --- Comment #10 from Mark Johnston --- The problem appears to be with this commit: https://github.com/qemu-bsd-user/qemu-bsd-user/commit/63d5d4f649f44f8e3d9105dec40a354d92a19550 That check is indeed needed. qemu relies on delivery of SIGSEGV to detect self-modifying code so that it can update its translation cache accordingly. This will manifest as a page fault, so ksi_trapno is T_PAGEFLT == 0xc on amd64. -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-emulation@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-emulation To unsubscribe, send any mail to "freebsd-emulation-unsubscr...@freebsd.org"
[Bug 253335] emulators/qemu-user-static php segfault building devel/pear for armv7
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253335 --- Comment #9 from Mark Johnston --- qemu is doing the mprotect here: Thread 1 hit Catchpoint 1 (call to syscall mprotect), 0x6049f48a in ?? () (gdb) bt #0 0x6049f48a in ?? () #1 0x602b413a in page_find_alloc (index=5, alloc=1) at /usr/home/markj/src/freebsd-ports/emulators/qemu-user-static/work/qemu-bsd-user-39244526c0af/accel/tcg/translate-all.c:497 #2 page_lock_pair (ret_p1=, phys1=4095827272, ret_p2=, phys2=4294967295, alloc=1) at /usr/home/markj/src/freebsd-ports/emulators/qemu-user-static/work/qemu-bsd-user-39244526c0af/accel/tcg/translate-all.c:882 #3 tb_link_page (tb=0x60598280 , phys_pc=4095827272, phys_page2=4294967295) at /usr/home/markj/src/freebsd-ports/emulators/qemu-user-static/work/qemu-bsd-user-39244526c0af/accel/tcg/translate-all.c:1628 #4 tb_gen_code (cpu=, pc=, cs_base=0, flags=1626480128, cflags=) at /usr/home/markj/src/freebsd-ports/emulators/qemu-user-static/work/qemu-bsd-user-39244526c0af/accel/tcg/translate-all.c:1831 #5 0x602b2a95 in cpu_loop_exit_restore (cpu=0xf4215000, pc=4096) at /usr/home/markj/src/freebsd-ports/emulators/qemu-user-static/work/qemu-bsd-user-39244526c0af/accel/tcg/cpu-exec-common.c:72 #6 0x602c2ff1 in target_cpu_loop (env=0x0) at /usr/home/markj/src/freebsd-ports/emulators/qemu-user-static/work/qemu-bsd-user-39244526c0af/bsd-user/arm/target_arch_cpu.h:259 #7 0x602c2f89 in target_cpu_loop (env=0x860933c00) In tb_page_add() I see: 1560 /* force the host page as non writable (writes will have a 1561page fault + mprotect overhead) */ but it looks like something's not implementing that...? -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-emulation@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-emulation To unsubscribe, send any mail to "freebsd-emulation-unsubscr...@freebsd.org"
[Bug 253337] Linuxulator: glibc's pthread_getattr_np reports stack size as 124K
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253337 Mark Linimon changed: What|Removed |Added Assignee|b...@freebsd.org|emulat...@freebsd.org -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-emulation@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-emulation To unsubscribe, send any mail to "freebsd-emulation-unsubscr...@freebsd.org"
[Bug 253335] emulators/qemu-user-static php segfault building devel/pear for armv7
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253335 --- Comment #8 from Mark Johnston --- Using truss on the host I can see that we are mprotecting the last page (containing the address in question) of that range to PROT_READ | PROT_EXEC. It doesn't show up in qemu's strace output, so presumably this is something internal to qemu. The only syscall which looks relevant here is a sysarch(ARM_SYNC_ICACHE), but it looks like qemu treats that as a no-op... -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-emulation@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-emulation To unsubscribe, send any mail to "freebsd-emulation-unsubscr...@freebsd.org"
[Bug 253335] emulators/qemu-user-static php segfault building devel/pear for armv7
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253335 Mark Johnston changed: What|Removed |Added Status|New |Open Assignee|kev...@freebsd.org |ma...@freebsd.org --- Comment #7 from Mark Johnston --- We're crashing on a write to 0xf4215a70. Shortly before, we had mmapped a region containing that address: 71585 mmap(0,65536,7,4098,-1,0) = 0xf4206000 71585 mprotect(0xf4206000,0x1,7) = 0 and I can't see any subsequent system calls that would modify that mapping, but procstat -v shows: 71585 0xf4206000 0xf4215000 rwx12 2 0 - df 71585 0xf4215000 0xf4216000 r-x12 2 0 - df so indeed the last page is not writeable. I'm not sure why libpcre is mprotect()ing a region to set the permissions specified by the preceding mmap() call. -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-emulation@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-emulation To unsubscribe, send any mail to "freebsd-emulation-unsubscr...@freebsd.org"
Re: [maqulator] FreeBSD running macOS binaries :-)
Dne 2021-02-08 16:29, Tomasz CEDRO napsal: Hello world :-) There is a nice QUCS [1] electronics simulation program (SPICE with GUI that works out of thebox). It is based on QT4 so it was removed from ports in March 2019. People use macOS binary with no problem. The question is - if we can somehow run Linux and Linux64 binaries - why don't we run macOS binaries??? These are also ELF, macOS uses lots of FreeBSD stuff, and the packages are self contained with all libraries, so it should be even easier than running Linux stuff (that always has some dependency issues like I am experiencing right now running closed-source FPGA toolchains). Did anyone consider running macOS programs on FreeBSD? Do you know how good it would be to run macOS quality software on FreeBSD and not really depend on Linux alternatives? :-) Hints and comments are welcome :-) Tomek [1] https://github.com/Qucs/ Yes, Its exists project for emulation macOS binares. ___ freebsd-emulation@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-emulation To unsubscribe, send any mail to "freebsd-emulation-unsubscr...@freebsd.org"
[Bug 253335] emulators/qemu-user-static php segfault building devel/pear for armv7
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253335 --- Comment #6 from Renato Botelho --- (In reply to Kyle Evans from comment #5) Luiz (loos@) also mentioned he built some aarch64 stuff on that box and he saw issues with lots of other binaries, it's not only PHP. We also see some messages like this one: Qemu unsupported ioctl: cmd=0xc0306365 dir=INOUT 'c' 101 48 -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-emulation@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-emulation To unsubscribe, send any mail to "freebsd-emulation-unsubscr...@freebsd.org"
Re: [maqulator] FreeBSD running macOS binaries :-)
On 2/8/21 10:29 AM, Tomasz CEDRO wrote: The question is - if we can somehow run Linux and Linux64 binaries - why don't we run macOS binaries??? These are also ELF, macOS uses lots of FreeBSD stuff, and the packages are self contained with all libraries, so it should be even easier than running Linux stuff (that always has some dependency issues like I am experiencing right now running closed-source FPGA toolchains). Libraries are the issue. Any native macOS program beyond a ported command-line util depends on one or more macOS proprietary libraries. Some of these are descended from NeXTSTEP, therefore some mac-compatibility concepts have discussed using GNUSTEP as a starting point, though there are large gaps in features by now. A few projects over the years have gotten Mach-O/Darwin binaries to load and execute on non-Darwin OSes, but that is only the first step, and not useful by itself. Did anyone consider running macOS programs on FreeBSD? Do you know how good it would be to run macOS quality software on FreeBSD and not really depend on Linux alternatives? :-) Linux emulation is already working for several commercial programs while "desktop Linux" shares in common most of the libraries of a typical FreeBSD Xorg desktop installation, this already lends itself to better integration than you'll find from a *STEP or WINE compatibility environment. On 2/8/21 10:29 AM, Tomasz CEDRO wrote: There is a nice QUCS [1] electronics simulation program (SPICE with GUI that works out of thebox). It is based on QT4 so it was removed from ports in March 2019. People use macOS binary with no problem. [1] https://github.com/Qucs/ This is already an open source project, looks like emulation/porting resources would better be spent on a QT5 migration or QT4 legacy port. ___ freebsd-emulation@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-emulation To unsubscribe, send any mail to "freebsd-emulation-unsubscr...@freebsd.org"
Re: Linuxulator: running one's own small Linux in FreeBSD?
‐‐‐ Original Message ‐‐‐ On Monday, February 8th, 2021 at 4:00 AM, wrote: > Message: 4 > > Date: Mon, 08 Feb 2021 02:51:55 + > > From: "Thomas Mueller" mueller6...@twc.com > > To: freebsd-emulation@freebsd.org > > Subject: Linuxulator: running one's own small Linux in FreeBSD? > > Message-ID: mailman.86.1612785601.7529.freebsd-emulat...@freebsd.org > > Is it possible to run one's own little Linux in FreeBSD by null-mounting > directory or partition on /compat/linux? > > I am thinking in particular of my own cross-compiled version (from FreeBSD or > NetBSD on amd64 aka x86_64) still in infancy, with busybox or otherwise? > > This busybox is cross-compiled for Linux (i486-linux-musl or > x86_64-linux-musl). > > Currently, this is on UFS2 aka ffsv2 file system. > > Would the Linux C library have to be glibc, or could it be uClibc-ng or (more > likely) musl? > > I would want to be able to try with more than one infant Linux installation > (one at a time), hence the desire to null-mount on /compat/linux rather than > copying to /compat/linux. > > Tom If it's just a local directory, you can use `sysctl' to tell the kernel what the emulation path is: sysctl compat.linux.emul_path=/foo/bar Then restart the `linux' service. ___ freebsd-emulation@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-emulation To unsubscribe, send any mail to "freebsd-emulation-unsubscr...@freebsd.org"
[maqulator] FreeBSD running macOS binaries :-)
Hello world :-) There is a nice QUCS [1] electronics simulation program (SPICE with GUI that works out of thebox). It is based on QT4 so it was removed from ports in March 2019. People use macOS binary with no problem. The question is - if we can somehow run Linux and Linux64 binaries - why don't we run macOS binaries??? These are also ELF, macOS uses lots of FreeBSD stuff, and the packages are self contained with all libraries, so it should be even easier than running Linux stuff (that always has some dependency issues like I am experiencing right now running closed-source FPGA toolchains). Did anyone consider running macOS programs on FreeBSD? Do you know how good it would be to run macOS quality software on FreeBSD and not really depend on Linux alternatives? :-) Hints and comments are welcome :-) Tomek [1] https://github.com/Qucs/ -- CeDeROM, SQ7MHZ, https://www.tomek.cedro.info ___ freebsd-emulation@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-emulation To unsubscribe, send any mail to "freebsd-emulation-unsubscr...@freebsd.org"
[Bug 253335] emulators/qemu-user-static php segfault building devel/pear for armv7
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253335 --- Comment #5 from Kyle Evans --- (In reply to Renato Botelho from comment #4) Given the timing, I'd suspect the recent elfload hacks that I did to try and fix kyua and direct-exec rtld. -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-emulation@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-emulation To unsubscribe, send any mail to "freebsd-emulation-unsubscr...@freebsd.org"
[Bug 253335] emulators/qemu-user-static php segfault building devel/pear for armv7
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253335 --- Comment #4 from Renato Botelho --- FYI, Same problem doesn't happen on a system running 12.2-STABLE and qemu-user-static version 3.1.0_1. `FreeBSD buildbot1-nyi.netgate.com 12.2-STABLE FreeBSD 12.2-STABLE acaac0eefa1(stable/12) GENERIC amd64` Also, There is an issue opened at qemu-bsd-user github page https://github.com/qemu-bsd-user/qemu-bsd-user/issues/5 -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-emulation@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-emulation To unsubscribe, send any mail to "freebsd-emulation-unsubscr...@freebsd.org"
Re: Linuxulator: running one's own small Linux in FreeBSD?
Good morning, Am 08.02.2021 um 03:51 schrieb Thomas Mueller : > Is it possible to run one's own little Linux in FreeBSD by null-mounting > directory or partition on /compat/linux? > I am thinking in particular of my own cross-compiled version (from FreeBSD or > NetBSD on amd64 aka x86_64) still in infancy, with busybox or otherwise? This might help for a start. I have not tried anything like this myself, yet. https://www.harshadsharma.com/posts/2020/12/ubuntu-bionic-on-freebsd-with-iocage-managed-jails/ HTH, Patrick -- punkt.de GmbH Patrick M. Hausen .infrastructure Kaiserallee 13a 76133 Karlsruhe Tel. +49 721 9109500 https://infrastructure.punkt.de i...@punkt.de AG Mannheim 108285 Geschäftsführer: Jürgen Egeling, Daniel Lienert, Fabian Stein signature.asc Description: Message signed with OpenPGP
Re: Linuxulator: running one's own small Linux in FreeBSD?
Quoting Thomas Mueller (from Mon, 08 Feb 2021 02:51:55 +): Is it possible to run one's own little Linux in FreeBSD by null-mounting directory or partition on /compat/linux? Short answer: most probably yes. [...] Would the Linux C library have to be glibc, or could it be uClibc-ng or (more likely) musl? It does not depend upon which glibc, but which syscalls / features are used. If it doesn't work because of some missing linux-part in the kernel, you normally have a message in the console/log/dmesg about which part of the linux kernel is not available in FreeBSD. When this happens, you either have the possibility to disable this kind of functionality in your linux-build, or to try to implement something similar in FreeBSD. Bye, Alexander. -- http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.orgnetch...@freebsd.org : PGP 0x8F31830F9F2772BF pgp7yCMvJcr31.pgp Description: Digitale PGP-Signatur
