the team working on this effort also implemented IRIX userland support for QEMU
What does this mean?
I think of QEMU as emulating hardware... What exactly is being emulated here?
What does this mean?
I think of QEMU as emulating hardware... What exactly is being emulated here?
Now, if your ARM binary was compiled to look for libc at /lib/libc.so, but /lib/libc.so is the host's x86 libc, then that obviously won't work; and the easiest way to get the libraries all sorted out is to use a chroot with OS install of the target architecture. If you do go the chroot route, you need to make sure that `qemu-ARCHITECTURE` is statically linked, because it won't have access to the x86 libraries it needs to run after the chroot(2) call happens (which is why most normally-dynamically-linked distros have a "qemu-user-static" package in addition to their normal "qemu-user" package).
But with a multilib scheme like Debian's, where all libraries get installed to /lib/ARCHITECTURE-TRIPLET/ instead of /lib/, then it should be possible to install all of the appropriate target libraries on the host system without a chroot! You "should" just need to configure APT to let you install packages built for that architecture. (I haven't actually tried this; I'm not a Debian user, but I am envious of their multilib).
Do you have a link to a comprehensive guide on doing this by chance? I was thinking tomorrow I’d just launch an arm instance in AWS and figure it out but I have a dual Xeon workstation at work (windows) that I might try as well.
You can skip the first part about creating the image, since presumably you already have one. So the process for me is something like:
apt-get install qemu qemu-user-static binfmt-support
cp /usr/bin/qemu-arm-static ~/rpi_mnt/usr/bin
systemd-nspawn -D ~/rpi_mnt bin/bash
Sometimes qemu shows an error saying some operation isn't supported, but this hasn't broken anything yet for me, even after I did a whole Raspbian Stretch -> Buster upgrade this way.
Notable because the sgi indigo had a MIPS R3000A CPU.
Not quite. It means that they got qemu to emulate IRIX's syscall layer on linux. So you can run, lets say, a MIPS IRIX binary on x86 linux without having to emulate the entire machine.
Wine impersonates OS calls, (including syscalls) but does not perform emulation on the binary itself. Wine can only run windows applications written for x86, but not windows applications written for itanium.
This appears to be running both hardware emulation on the supplied binary, (which is what VMware/KVM/virtualbox etc do) as well as wine-like OS impersonation.
I made up the word "impersonates" for what wine does just to avoid confusion. It's not a word that's used in the literature afaik, although perhaps it (or a word like it) should be.