Adding in crt.c object file breaks the bash executable, luckly it is not need for later versions (10.5 or later) of macOS. So we can just not include it.
There seems to be a duplicate conflict:
```
/home/user/Downloads/darling/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sysmon/OS_sysmon_object.h:20:1: error: duplicate interface definition for class 'OS_object'
@interface OS_object
^
/home/user/Downloads/darling/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/os/object.h:203:1: note: previous definition is here
OS_OBJECT_DECL_BASE(object, NSObject);
```
The cdef.h header is used to automatically determine how a symbol should be defined. Since no platform was defined, the `__DARWIN_ONLY_UNIX_CONFORMANCE` would not properly get set to 1 if the arch is not `i386`.
This fixes the issues where x86_64 would have `$UNIX2003` appended to some of the symbols.
I recommend refering to the `COMPAT(5)` man page for a better understanding on this issue.
This machine is not always available, but when it is,
it's much faster (about 5-10 mins) than both the
GitHub Actions CI (3+ hours) and the old private CI machine (1+ hour).
The new `ENABLE_METAL` option can be set to `ON`/truthy, `OFF`/falsy,
or `AUTO` (the default). When set to `AUTO`, Metal support will only be
enabled if LLVM and Vulkan are available.
Note that even if Metal support is compiled-in, Metal will only be
available at runtime if LLVM and Vulkan are available. This also means
that you can build Darling on a host with LLVM and Vulkan available and
install it on machines without these libraries available with no issue
(the only effect would be that Metal would be unavailable at runtime on
these machines).
On some distros, LLVM is not placed in the root of `/usr/lib` and is
kept in a versioned subdirectory instead. Regardless of what the case
is, llvm-config should give us the right path.
*This* should finally fix the CI build.
These changes, most notably the last one, should greatly improve the
reliability of core dumps produced with `darling-coredump`.
* Mark areas with `protection == 0` as invalid. These regions aren't
supposed to be accessed anyways, so we might as well not dump them.
* Add a few debugging options: `DUMP_FLOAT_STATE` to enable/disable
dumping floating-point state, `ALIGN_REGIONS` to enable/disable
page-aligning dumped regions, and `INVALIDATE_DEVICES` to
enable/disable marking devices (in `/dev`) as invalid regions.
* Continuously retry file writes in `dump_emit` until the entire
buffer has been written. It's possible for the `write` system call
to simply write fewer bytes than what we give it for absolutely no
reason at all (well, it's because of write buffering, but that's not
something we control, so it's seemingly arbitrary to us). Therefore,
to ensure we write the full buffer in as many cases as possible, we
have to retry the `write` syscall until we either get a fatal error
or finish writing the contents.
* Always dump memory regions according to memory size, not file size.
As explained in a comment, LLDB assumes that contiguous memory
regions are also contiguous in the file. This is a reasonable
assumption, but it means that regions whose memory size is larger
than their file size have to be manually zero-extended in the file
to match their memory size. I actually had to clone LLDB and build
it locally and debug it (with LLDB) to figure out that this is what
it was doing and why it was loading an otherwise-correct core dump
improperly.
`darling-coredump` can now process 32-bit core dumps, but it doesn't seem
to produce anything usable (LLDB says the code memory is missing in the
core dump).
