4 ms·

Test cross-architecture without leaving home

27 points by zdw 5y ago

rurban 5y ago
It will stop working in embedded with the thousands of arm boards completely unsupported by qemu. 8 bitters are fine though with avr
- geofft 5y ago
  This is about user-mode QEMU, for which the question of "board" doesn't even apply - it runs on your host computer. https://qemu-project.gitlab.io/qemu/user/main.html https://qemu-project.gitlab.io/qemu/user/main.html Since the author's goal is to test userspace applications on Linux, not kernels or entire OSes, the choice of board should be irrelevant even if you're using full system emulation. For instance, there's the "virt" board: https://qemu.readthedocs.io/en/latest/system/arm/virt.html https://qemu.readthedocs.io/en/latest/system/arm/virt.html
sillystuff 5y ago
You can use qemu user mode even on the same architecture to support newer processor features e.g., wrap your executable with qemu-x86_64-static, even on an amd_64 system. This was my fix to using chromium after an update made it no longer work with processors that didn't support SSE2 (like my netbook's AMD C-50). I didn't really notice any difference in speed, but I didn't use chromium often either.
etaioinshrdlu 5y ago
At the end he mentions openbsd sharing the same ABI (as linux?). Is this correct?
- geofft 5y ago
  Yes, the ABI in the sense of calling convention is the same on just about all amd64 UNIXes, including even macOS. Wikipedia has a good reference: https://en.wikipedia.org/wiki/X86_calling_conventions#System_V_AMD64_ABI https://en.wikipedia.org/wiki/X86_calling_conventions#System... And Linux and OpenBSD both use ELF binaries. But that only really helps you if you're writing a self-contained library with no dependencies (which, I suppose you could be writing something like a SHA-256 implementation that takes a const char * and writes to a char *, or something). For just about any real program, you'll run into the problem that the libcs are different and the system call interfaces are different. If you want to use libc, most immediately, the filenames and symbol versions are different (e.g., you won't find libc.so.6 on OpenBSD, let alone /lib64/ld-linux-x86-64.so.2 or GLIBC_2.24). But also structure layouts will potentially be different, the values of constants will be different, etc. If you don't want to use libc, you'll run into the problem that the system call numbers aren't the same (even if the actual system call mechanism is the same!).
  - fomine3 5y ago
    It's time to cosmopolitan libc https://news.ycombinator.com/item?id=27180182 https://news.ycombinator.com/item?id=27180182

27 points by zdw 5y ago

It will stop working in embedded with the thousands of arm boards completely unsupported by qemu. 8 bitters are fine though with avr

geofft 5y ago
This is about user-mode QEMU, for which the question of "board" doesn't even apply - it runs on your host computer. https://qemu-project.gitlab.io/qemu/user/main.html https://qemu-project.gitlab.io/qemu/user/main.html Since the author's goal is to test userspace applications on Linux, not kernels or entire OSes, the choice of board should be irrelevant even if you're using full system emulation. For instance, there's the "virt" board: https://qemu.readthedocs.io/en/latest/system/arm/virt.html https://qemu.readthedocs.io/en/latest/system/arm/virt.html

sillystuff 5y ago

You can use qemu user mode even on the same architecture to support newer processor features e.g., wrap your executable with qemu-x86_64-static, even on an amd_64 system. This was my fix to using chromium after an update made it no longer work with processors that didn't support SSE2 (like my netbook's AMD C-50). I didn't really notice any difference in speed, but I didn't use chromium often either.

etaioinshrdlu 5y ago

At the end he mentions openbsd sharing the same ABI (as linux?). Is this correct?

geofft 5y ago
Yes, the ABI in the sense of calling convention is the same on just about all amd64 UNIXes, including even macOS. Wikipedia has a good reference: https://en.wikipedia.org/wiki/X86_calling_conventions#System_V_AMD64_ABI https://en.wikipedia.org/wiki/X86_calling_conventions#System... And Linux and OpenBSD both use ELF binaries. But that only really helps you if you're writing a self-contained library with no dependencies (which, I suppose you could be writing something like a SHA-256 implementation that takes a const char * and writes to a char *, or something). For just about any real program, you'll run into the problem that the libcs are different and the system call interfaces are different. If you want to use libc, most immediately, the filenames and symbol versions are different (e.g., you won't find libc.so.6 on OpenBSD, let alone /lib64/ld-linux-x86-64.so.2 or GLIBC_2.24). But also structure layouts will potentially be different, the values of constants will be different, etc. If you don't want to use libc, you'll run into the problem that the system call numbers aren't the same (even if the actual system call mechanism is the same!).
- fomine3 5y ago
  It's time to cosmopolitan libc https://news.ycombinator.com/item?id=27180182 https://news.ycombinator.com/item?id=27180182