Issues such as this mention lack of system call support as the hindrance to running libc in full host build mode. Is that it? What other issues need to be taken care of to get it running?
Asking this as I recently migrated from an x86 machine and would like to work on libc from my macbook. I would be interested in starting the effort if there’s interest in this work by libc folks.
From pthread perspective, we are basically lacking all synchronization primitives.
If we assume latest macos, we can try os_sync_wait_on_address | Apple Developer Documentation and use it to replicate the Futex API used in threads.
Once we have that, it is easy to support a lot of the sync primitives by directly refactoring the linux futex implementation to generic implementation.
I have always been hoping to have an abstraction layer over wait_on_address, so that linux/windows/macos can share their implementations.
See how snmalloc do this: Code search results · GitHub
and the rust way:
As discussed in the issue you linked getting a full build of LLVM-libc to work on MacOS has some significant challenges. I’d love for it to be supported since there are many interested contributors like you who want to use a Mac for development.
If you want to work on the OS independent parts of LLVM-libc you could do your development in overlay mode which doesn’t require as much effort. If you’d like to work on the MacOS specific parts then I think the next step for that is to come up with a plan for how to implement the pieces that a proper full build needs. One place to start would be getting the exit function set up.
Can you say more about what specifically you want out of a libc on MacOS? What itch do you want to scratch? =)
Thank you for replying. I like this approach. As I understand, the plan would involve finding
missing functionalities between linux and macos, and adding them. exit would be
a good place to start. I assuming from the replies that macos port would be welcomed, so I will
get to work: Understand what’s missing, create RFCs and PRs to make progress.
Two things:
I’ve compiled a rough plan for porting libc to macos:
__support/OSUtil/darwin/ for both aarch64 and x86_64. This is the mechanism for all subsequent syscall wrappers.exit and abort: Following @michaelrj-google’s advice Implement _exit (unistd/darwin/), exit (stdlib/darwin/), and abort (stdlib/darwin/). This makes a “full build” at least runnable, as it can now terminate.__assert_fail: Create the Darwin-specific handler for assert.h. This is for internal development and testing of all subsequent modules. It can be built using abort.__support/threads/darwin/. This will be built on the macOS os_sync_wait_on_address API.Mutex: Port the generic Mutex class (__support/threads/mutex.h) to use this new os_sync_wait_on_address abstraction.call_once and CndVar.stdioWith synchronization available, this phase implements the I/O subsystems, enabling basic functionality like printf.
fcntl, unistd (read, write, lseek, close), and sys/stat (fstat). These are the syscalls needed for file operations.__support::File: Create the __support/File/darwin/ implementation. This internal abstraction requires the Mutex from Phase 2 for thread-safe operations.stdio: Create the stdio/darwin/ backend. This will provide the FILE* structures (including stdin, stdout, stderr) and functions (fopen, fprintf, fread), which are built on top of the __support::File abstraction.This phase adds the remaining core components required for a modern POSIX environment.
mman: Create sys/mman/darwin/ to provide memory management functions like mmap, munmap, and mprotect.__support/time/darwin/ for time abstractions and sys/time/darwin/ for syscalls like gettimeofday.setjmp/darwin/aarch64/ and x86_64/ assembly functions for setjmp and longjmp.spawn/darwin/, sys/wait/darwin/, and signal/darwin/ to support process creation and signal handling.pthreadThis final phase completes the library by implementing the remaining high-level POSIX APIs.
poll (poll/darwin/) and select (sys/select/darwin/). The poll implementation can be built on top of the macOS-native kqueue API (sys/event.h).sys/socket/darwin/ API.sys/ Modules: Implement the remaining POSIX sys/ modules, such as sys/resource, sys/utsname, and termios.pthreads: Build out the full pthread/ API (e.g., pthread_create) on top of the synchronization primitives from Phase 2 and the thread management APIs.dlfcn/darwin/ (dlopen, dlsym). (These are missing from linux too)I surely missed a lot more things, please let me know your thoughts.
Hi @michaelrj-google @SchrodingerZhu,
I got _Exit to work on macos with full build. I had some questions:
ninja check-libc) will fail. How should regressions be implemented? A possible implementation I see is editing a shell script every time a new test succeeds and running that script from actions.Overall the plan looks good. I have a couple of notes:
I’d prefer not to support x86_64 MacOS, since it’s pretty much unsupported by Apple at this point.
I’m planning on creating a new design for File to be more properly platform generic. It’s fine if you implement your version before that’s done, but be aware it might need to be updated.
Phase 4 is probably just going to be syscall wrappers, you could do that earlier or later if you wanted, it should be straightforward to write. Same with most of phase 5 other than pthreads.
For the actions test you can select which functions are available by adjusting the entrypoints.txt for your specific platform. That way check-libc will pass since it’s only testing the functions you’ve added.
Smaller and more focused PRs usually take less review bandwidth than large ones. Smaller reviews are easier understand all at once, where large reviews take more careful readings. That being said I don’t know how much extra review bandwidth I have. If you send the PRs to me I’ll try to get to them but they might take a while, so finding another maintainer who is less busy might make things move faster.
Creating an RFC seems like a good idea, that way more people will see it.