[RFC] New proposed Managarm support for LLVM and Clang (#87845)

Clang Frontend
1

See the accompanying PR #87845 for the implementation of the Managarm target in LLVM (commit #1), in Clang (commit #2) and Clang tests (commit #3).

Managarm is a pragmatic microkernel with an asynchronous API for I/O that also provides a POSIX server, allowing us to port many Linux programs such as Wayland, Weston (the wayland reference compositor), and systemd, to name a few.

We have had contributors do talks about Managarm as well, one at CppCon 2020, and one each at FOSDEM in 2022 and 2025.

We are proposing to upstream our support that we have maintained, out-of-tree, since ~2019 (LLVM 6). To check off the criteria:

  1. We maintain a healthy presence on Discord and IRC (#managarm on Libera) for a community of volunteers that work on Managarm and people interested in Managarm. If we were to get accepted upstream, we would switch our toolchain to upstream instead of maintaining a set of patches on top of releases as we do now. The network effects of being upstream would also help us with programs that depend on LLVM, like our ports of Mesa (where we’re already upstream, and use LLVMpipe) or Rust (where we would also like to get upstream, however they requested we be upstream on LLVM first).

  2. Being in the Clang tree would allow downstream users of LLVM (such as Rust) to target Managarm with a stock toolchain, which would be achieved by this PR. This is a requirement for Rust, for instance.

  3. not applicable

  4. not applicable

  5. I am willing to maintain the Managarm target in LLVM/Clang, along with my co-contributors Dennisbonke, avdgrinten and 48cf (GitHub usernames). We regularly rebase on new LLVM releases and this work has historically been shared between us, and we would maintain that team going forward.

  6. Hopefully this has already been brought up to sniff by the previous reviews on the PR.

  7. The tests have been brought up analogous to the Hurd test cases (PR #78065). The tests pass on CI.

  8. The PR only touches LLVM and Clang. We’re willing to maintain the Managarm target across the impacted subtrees. Given that we’re a pretty vanilla ELF system with no special additions, I do not see problems for other parts of the tree.

Cheers,

Leo

7 Likes
2

I don’t have strong objections. However, few points:

  1. Have you considered providing a buildbot? It’s not outlined in the criteria for upstreaming, but would be very nice to have.
  2. The following doesn’t sound very compelling to me:

Every extension is more convenient to use when it’s upstream. Any downstream or user can say “get this into upstream first”. This line of reasoning doesn’t sound specific to me.

CC @AaronBallman @nikic

3

A build bot hosted on our side that builds LLVM trunk for our target? Yes, we can provide that (+ do some continuous integration testing by validating that LLVM trunk builds our kernel + drivers correctly – both of these components have already been built with LLVM for 5+ years).

3 Likes
4

It would be helpful to reference the PR as a link rather than just a number :slight_smile: Here is the actual PR: [llvm] Add triples for managarm by no92 · Pull Request #87845 · llvm/llvm-project · GitHub

So to clarify, what that change includes is basically:

  1. Support for building on Managarm, with the addition of defined(__managarm__) checks to a small number of places with OS-specific handling (mainly llvm::fs).
  2. Addition of the managarm OS and mlibc environment to Triple. The resulting triples have the form x86_64-unknown-managarm-mlibc.
  3. Addition of Clang driver support for managarm (in the sense of a new “toolchain”).

I think from an LLVM perspective this is fine, the main complexity here is in the clang driver part. @MaskRay should probably comment on that. But I don’t really see a strong reason not to include support for this target.

It may be useful to provide some more context on the managarm vs mlibc distinction. Like, do those always occur together, or do you also use mangarm with a different env, or mlibc on non-managarm?

1 Like
5

Thank you for the RFC! I have no specific objections to moving forward; having the post-commit CI bot will help immensely btw, so thank you for that!

6

It would be helpful to reference the PR as a link rather than just a number

Unfortunately, I ran into the 5 link limitation :wink:

It may be useful to provide some more context on the managarm vs mlibc distinction. Like, do those always occur together, or do you also use mangarm with a different env, or mlibc on non-managarm?

We’re currently only upstreaming the mlibc environment, as that is what regular userspace applications (that use the POSIX personality, so running under the posix-subsystem) use. The kernel (and possibly servers) might need a different one, and a future implementation of a different (non-POSIX) personality or a port of a different libc would mean that more managarm-environment combinations would be needed. This is not part of this RFC and PR and maybe something for the future, though.

The mlibc environment should be reusable for other OSes, as mlibc is written to be portable across operating systems by switching out the backend (“sysdeps”). For instance, supporting a linux-mlibc os-env would be of interest, but we don’t feel that this is ready for upstreaming, yet.

1 Like