Target triple of llvm-libc (Environment Component)

Runtimes C
,
1

There was a discussion at libc roundtable on the target triple of LLVM libc. (@michaelrj-google I failed to find the topic link, could you link the discussion here?)

This topic is for collecting general suggestions on the desired target triple for our libc.

The libc implementation typically decides the running environment. Hence, glibc, msvc, musl all have their own representations. For example, we have:

  • x86_64-pc-windows-msvc
  • aarch64-unknown-linux-gnu
  • x86_64-unknown-linux-musl

Historically, rust community choose to list the following in their tier2 target triples:

  • aarch64-pc-windows-gnullvm
  • i686-pc-windows-gnullvm
  • x86_64-pc-windows-gnullvm

These targets are for clang built MSYS2 environments.

Although llvm-libc is trying to implement most functions that glibc provide, we may choose to diverge the behavior from glibc at some points. (In fact, there are already some different design decisions). Therefore, gnullvm may not be a good name.

Currently, -llvm seems to be the most suitable choice.

2

It should definitely be x86_64-unknown-linux-llvm. Having this as a separate triple would allow users to switch between the LLVM libc’s full build and their system default more easily. As is stands if you install the full build you’re probably going to have a lot of stuff break so it would be nice to handle this via multilibs.

3

Here’s the roundtable notes: LLVM-libc Roundtable Meeting

I agree that -llvm seems like the best choice for the name.

1 Like
4

Should it be versioned? There are some areas where we cannot rely on different versions of glibc, but have no knowledge of what version is targeted.

5

We already version libc++ ABI and I think we should do so for LLVM libc as well. With that being said, we’re still far from having a stable ABI for LLVM libc so for the foreseeable future we’ll only have a single unstable version.

6

Note that gnuconfig already recognises -llvm, see https://git.savannah.gnu.org/cgit/config.git/commit/?id=5b83c2ff5da15451cb566e1837253d0f60543dd7.

I think @michaelrj-google and one of our GSoC contributors in Gentoo (catcream) had some discussion about it at the time.

i.e. I think we already have one.

7

thing-llvm looks uncontroversial.

I don’t believe musl does the symbol versioning noise of glibc and seems to be fine. Definitely better to not do the library scope symbol versioning thing if we can avoid it.

(libc has a stable abi afaik - it’s the functions defined by C, with the C calling convention - am I overlooking something?)

8

Introduction of new extension functions, and bug workarounds. Both of which are problems in the current TargetLibraryInfo.