I was looking through the build scripts in XNU to see how MIG is being used. While there are some cases where we need to explicitly set the arch to its 32-bit equivalent (ex: i386 instead of x86-64), those situations seem to be the exception rather than the norm.
As a result, I don't think we should be hardcoding i386 as a fallback. We should use the primary architecture instead.
While I was working on fixing up `darling-coredump` for ARM64 support, I noticed that there is some x86 code that doesn't really need to be hardcoded at compile time.
If there aren't any other unexpected issues, this should also allow one (in theory) to process a x86 core dump on a non-x86 device.
Turns out that it causes regressions for some users (see #1443). I'm going to move this change into a branch for testing and debugging and merge it back in once it's working reliably for everyone.
This change isn't too important for most users of Darling; at the moment, the only significant thing it does is allow xcodebuild to work, but that's not essential at the moment.
From the discussion in Discord, there are some strange/potentionally problematic design choices with the current inline assembly code.
To take advantage of the GNU register asm(...) feature, the std version need to be set to gnu11, instead of c11.
CoreServices itself doesn't define any constants other than its
version number and string. Plus, some of the values we had were just
flat-out wrong, while the same constants in LaunchServices were correct
(but unused since they were being shadowed by CoreServices).
LoginWindow is responsible for setting up the user session with launchd.
For us, shellspawn serves the same purpose as LoginWindow, so we
initialize the session there. This does require some additional dancing
around with processes and sockets since launchd only expects a single
process to register a session for a given user; this means that we
couldn't just keep the old behavior with each shellspawn connection
getting a new process and simply add-on launchd session initialization.
In the new approach, we introduce a new shellsession daemon that forks-off
instances for a user sessions; shellspawn now becomes a LaunchAgent that gets
started by launchd when the user session starts. We then connect to this
instance of the shellspawn daemon.
