The script relies on the System libraries existing in the SDK, otherwise, the linker will fail. For some reason, some of these files are ignored by the .gitignore file. I'm not sure why that is the case...
In an official macOS SDK, .tbd (a text-based library stub) files are used instead. However, I wasn't able to figure out if these files can be used on Linux. So for the time being, I'll just symbol-link the .dylib files when needed.
Implemented CMake methods for:
* Deleting the old headers before generating the new headers.
* Updating the "Developer" and "framework-include" headers.
* Generating the private frameworks headers into their proper dedicated folders ("PrivateFrameworks" and "framework-private-include")
Updated multiple frameworks to take advantage of this feature.
This commit includes support for Mach port filters in kqueue (via the new kqchan facility in darlingserver).
Additionally, ccache usage can now be disabled via DARLING_NO_CCACHE.
The goal of this new branch is to implement Darling entirely in userspace, no LKM necessary.
This first commit re-introduces mldr (a userspace Mach-O loader last used about 4 years ago in 89d6e6ddb1) together with some updates from the Mach-O loading code in the LKM.
This commit also sets up the basis for darlingserver: RPC and process/thread tracking.
The biggest improvement is the ability to log xtrace's output to a separate file for each thread. Jumbled output has been a big reason why xtrace is hard to use with multi-threaded programs, but this provides a nice optional solution to that problem. It doesn't come without its drawbacks, however: because xtrace has to open descriptors for the logfiles, it can affect program behavior, especially if the program sees the descriptors and decides to do something with them (like close them, which some programs do).
xtrace no longer buffers output on the stack (which could lead to stack overflows or truncated output). Actually, it doesn't buffer output at all anymore, which might be an issue (it means more potentially jumbled output when using the normal output method). If turns out to be a signifcant issue, we can re-add buffering in xtrace_log using a per-thread buffer rather than an on-stack one.
The kevent family of syscalls is now properly described! This means that those calls will now print much more useful output.
Also, to work around a stack overflow issue when running within signal handlers, xtrace now overrides the default sigstack with its own larger one. It's not apparent why xtrace is using so much stack space, but it seems like 16KiB is enough for now (rather than the default of 8KiB).
Executing the xtrace command with no arguments now produces a help message describing the various environment variables that can be used to modify xtrace's behavior.
Also, the simple printf family of functions in libsystem_kernel now support various argument sizes.
Finally, there's no reason to call the wrapper for `semaphore_signal_trap` in `bsdthread_terminate` (causing unnecessary xtrace output), so call our implementation directly instead.
* Fix the Carbon framework to properly reexport the right frameworks
* Add many missing Carbon-related type definitions
* A couple of fixes in some submodules (see their commits)
We basically have to reimplement locking, memory allocation, and TLS for xtrace directly on top of Linux syscalls because it can't use almost anything external (it can pretty much only use libsystem_kernel).
The one exception is that we use `pthread_key`s from libpthread to make TLS easier to implement. The only side effect that has is that it's one less available key for the application we're tracing to use, but we shouldn't ever see that cause problems (and if we do see it cause problems later on, then we can revise that).
