commits
I couldn't find any built library named `libelfloader`. I'm going to remove it to see if they are any weird side effects.
See the following for details: https://github.com/darlinghq/darling/issues/1113#issuecomment-1065830000
Having the import live in the `src` directory causes conflicts to appear, so I moved the import to `src/startup` instead.
Special environment variables need to be processed prior to the call to
`load_fat`, because mldr_binprefs needs to be read before then.
This fixes the `arch` command.
Now xtrace can tell you which descriptors were passed in to `select` as
well as which descriptors `select` returned as being active.
We shouldn't use Darwin TLS keys (even direct ones) after the thread is
destroyed, so instead, we store the RPC FD in a Linux thread local
variable and use the new explicit RPC call wrappers added in
this updated darlingserver commit.
This commit also adds `_dup_4libkqueue`, used by libkqueue to duplicate
descriptors without having libsystem_kernel call back into it with
`kqueue_dup`.
Also take into account that NT_FILE entries may be larger than memory regions we're checking
Because we now build a single package, DESTDIR is actually
`debian/<package-name>` rather than `debian/tmp`
(see https://www.debian.org/doc/manuals/debmake-doc/ch05.en.html#rules).
This means that we actually don't need to add `usr` to be installed;
it's already installed to the staging directory.
Additionally, setcap now respects the DESTDIR variable (used when
building the Debian package).
This is necessary as a result of the changes from 0e552ab5454c6c45005f0e8abfa34323c6025d3a.
We do want to make sure we don't replace any previous memory we didn't
load ourselves, so in order to keep that, we just unmap the memory we reserve,
since there's no race condition like there could have been when we were
doing this in the LKM. No one else can be allocating memory in our
process but us.
Since darlingserver doesn't need a kernel module, we no longer need a
DKMS package.
Note: I have not tested whether building the `.deb` actually works after
this change. I guess the CI will let me know ¯\_(ツ)_/¯
Also, don't worry about failures mapping PAGEZERO; sane systems
already map out enough pages to reserve the area around `NULL`
as invalid memory.
This should fix some crashes that some users were getting (with mldr overwriting itself).
This allows log messages that programs want to write to "/dev/console"
to be written to darlingserver's log stream instead. The alternative is
to just drop those messages, because "/dev/console" a privileged device
(plus, we don't want to be writing to Linux kernel's console anyways).
This should fix building with libavcodec 58 (which should also fix the CI build)
MLDR's copy of the RPC wrappers only uses the main socket created by MLDR on process startup. Therefore, when we were checking in calling those wrappers in the elfcalls thread code, we were using the main thread's socket rather than the new thread's socket.
Instead of that, we now have libsystem_kernel provide some RPC wrapper callbacks which the elfcalls code stores. Then, when it calls them, it'll use libsystem_kernel's copy of the RPC wrapper code, which automatically uses the current thread's socket.
Like I stated in the corresponding darlingserver commit, this is the initial implementation, with more changes and fixes sure to be needed later. But for now, it certainly works!
prctl actually expects pointers to (contiguous) string contents, not to string pointer arrays. This fixes `ps` output for mldr processes.
If we can't read a particular file, just zero out that memory region and move on; chances are that it's not important. Still report it, however (it might actually be important).
Some previously deprecated functions have now been removed entirely. Note that this updated implementation has NOT been tested.
Also, dserver RPC error codes should be negative; make them so.
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.
Additionally, the elfcalls threading code now handles opening a new RPC socket for the new thread.
Also, we now set close-on-exec RPC sockets on the client-side.
This partially reverts commit 63f9a0e16542a764a3dc79291a0097df1fe1ec46.
Added CloudKit stubs
Now the flag is only set for targets being built for the Darling environment, not those being built to run natively.
Fixes #1064
* Many syscalls have been updated to use darlingserver RPC calls instead of LKM calls.
* The elfcalls threading glue now performs checkins and checkouts for non-main threads.
* mldr's main stack allocation logic has been fixed to not overwrite the commpage.
* execve now works properly with mldr and informs the server of the success or failure of the execve call (using some close-on-exec FD trickery; see the corresponding commit in darlingserver for more details).
One very useful additional that merits its own paragraph is the new `darling-coredump` tool. binfmt_misc provides no way to register a coredump handler, and trying to intercept all the possible signals that can generate a coredump in-process and handle them appropriately is more trouble than it's worth. Therefore, I created a new tool that converts a kernel-generated ELF coredump into a proper Mach-O coredump. The tool is currently only compatible with kernel-generated coredumps; coredumps produced with `gcore` seem to be missing certain information that causes the tool to produce an invalid coredump (and I'm not quite sure what is wrong with it).
See darlinghq/darlingserver@be93cc46b7433687df5e8fa9325db6b97135b2eb
We shouldn't use Darwin TLS keys (even direct ones) after the thread is
destroyed, so instead, we store the RPC FD in a Linux thread local
variable and use the new explicit RPC call wrappers added in
this updated darlingserver commit.
This commit also adds `_dup_4libkqueue`, used by libkqueue to duplicate
descriptors without having libsystem_kernel call back into it with
`kqueue_dup`.
Because we now build a single package, DESTDIR is actually
`debian/<package-name>` rather than `debian/tmp`
(see https://www.debian.org/doc/manuals/debmake-doc/ch05.en.html#rules).
This means that we actually don't need to add `usr` to be installed;
it's already installed to the staging directory.
Additionally, setcap now respects the DESTDIR variable (used when
building the Debian package).
This is necessary as a result of the changes from 0e552ab5454c6c45005f0e8abfa34323c6025d3a.
We do want to make sure we don't replace any previous memory we didn't
load ourselves, so in order to keep that, we just unmap the memory we reserve,
since there's no race condition like there could have been when we were
doing this in the LKM. No one else can be allocating memory in our
process but us.
MLDR's copy of the RPC wrappers only uses the main socket created by MLDR on process startup. Therefore, when we were checking in calling those wrappers in the elfcalls thread code, we were using the main thread's socket rather than the new thread's socket.
Instead of that, we now have libsystem_kernel provide some RPC wrapper callbacks which the elfcalls code stores. Then, when it calls them, it'll use libsystem_kernel's copy of the RPC wrapper code, which automatically uses the current thread's socket.
Added CloudKit stubs
* Many syscalls have been updated to use darlingserver RPC calls instead of LKM calls.
* The elfcalls threading glue now performs checkins and checkouts for non-main threads.
* mldr's main stack allocation logic has been fixed to not overwrite the commpage.
* execve now works properly with mldr and informs the server of the success or failure of the execve call (using some close-on-exec FD trickery; see the corresponding commit in darlingserver for more details).
One very useful additional that merits its own paragraph is the new `darling-coredump` tool. binfmt_misc provides no way to register a coredump handler, and trying to intercept all the possible signals that can generate a coredump in-process and handle them appropriately is more trouble than it's worth. Therefore, I created a new tool that converts a kernel-generated ELF coredump into a proper Mach-O coredump. The tool is currently only compatible with kernel-generated coredumps; coredumps produced with `gcore` seem to be missing certain information that causes the tool to produce an invalid coredump (and I'm not quite sure what is wrong with it).