RFC/Proposal: Turning Zig target triples into quadruples #20690
Comments
ifreund
added
the
proposal
|
This is a well-written proposal. I'm going to provide what I consider the obvious push-back on it: Some triples can have multiple ABIs, but many cannot. For the ones which do, there's often an obvious default, and furthermore, it's a default which is lowest-common-denominator: code compiled for that ABI target will run, perhaps not optimally, on systems supporting one of the more advanced/enhanced ABIs. Given that, what's the argument for including it in the now-quadruple? I look at the example list, and I'm not even 100% sure that the remaining info needs to be an ABI tag, it looks more like a list of supported CPU "extras". Mostly we're talking about presence or absence of hard and soft floats in various widths, I'd add vector instructions to that consideration. This is something which could affect source code in a way which is independent of the triple itself (example: providing the classic integer-casting fast inverse square root for soft float platforms, because it isn't actually faster on modern ISAs). Why does this need to be a part of every Target, rather than continuing to conflate the libc with the base ABI, and provide a list of CPU features which is as independent as possible from the triple? To be clear, I'm not persuaded either way, I just think that the issue would benefit from a focused answer to this question. |
Can you give an example of this? I can't immediately think of a case where this is true. The ABI fundamentally affects the calling convention. In general, post-proposal, a given ABI can only be considered compatible with another ABI if the base ABI and option set both compare exactly equal. That is how an ABI works by definition.
It's not independent. If you compile a function using |
|
I really like this proposal -- it deals with an awkward overloading of the term "ABI" (which can be downright confusing), and provides a lot more flexibility around how ABIs are defined. I think your arguments for it are really solid. One question that does come to mind is whether mandating the user to always specify the ABI when they want to specify the libc is reasonable. For instance, on Linux, it feels a little silly to have to clarify the |
I address this exact point in the open questions. 🙂 I agree that there is merit to this. The current ordering of components in the proposal is so purely for aesthetic reasons. I'm very open to switching libc and ABI around to enable this. |
|
I'm proposing it the other way around: I think changing the libc is probably desired more often than changing the ABI! That said, my dev experience is largely x86_64-centric, so perhaps I'm underestimating how common it is to need to override the ABI on other targets. |
|
Oh, you're saying order as proposed but make the ABI optional, ok. Hmm. I'll think on that a bit. I definitely agree that this is the more common scenario on the mainstream platforms. |
|
I think I agree with you @mlugg. Especially if we go the route of making OS/libc components imply sensible default options for the ABI component as I described in the open questions. Some examples of how this would play out:
And so on. This will involve a fair amount of logic to handle these cases, but I think it stays within the realm of manageability. With this, I think explicitly specifying ABI will be relatively rare. The obvious cases would be toggling between Going this route also mitigates the complexity concern because most users won't have to fiddle with ABI stuff. |
|
I have updated the proposal so that you can specify neither libc nor ABI, only libc, or both libc and ABI, as discussed above. I've also added the behavior of picking sensible ABI defaults based on the other components to the core proposal. Would love to hear feedback on the remaining open questions. |
|
By the way, if this does get accepted, I'm volunteering to do the work in either the 0.15.0 or 0.16.0 cycle. |
This target triple was weird on multiple levels: * The `ilp32` ABI is the soft float ABI. This is not the main ABI we want to support on RISC-V; rather, we want `ilp32d`. * `gnuilp32` is a bespoke tag that was introduced in Zig. The rest of the world just uses `gnu` for RISC-V target triples. * `gnu_ilp32` is already the name of an ILP32 ABI used on AArch64. `gnuilp32` is too easy to confuse with this. * We don't use this convention for `riscv64-linux-gnu`. * Supporting all RISC-V ABIs with this convention will result in combinatorial explosion; see ziglang#20690.
This target triple was weird on multiple levels: * The `ilp32` ABI is the soft float ABI. This is not the main ABI we want to support on RISC-V; rather, we want `ilp32d`. * `gnuilp32` is a bespoke tag that was introduced in Zig. The rest of the world just uses `gnu` for RISC-V target triples. * `gnu_ilp32` is already the name of an ILP32 ABI used on AArch64. `gnuilp32` is too easy to confuse with this. * We don't use this convention for `riscv64-linux-gnu`. * Supporting all RISC-V ABIs with this convention will result in combinatorial explosion; see ziglang#20690.
This target triple was weird on multiple levels: * The `ilp32` ABI is the soft float ABI. This is not the main ABI we want to support on RISC-V; rather, we want `ilp32d`. * `gnuilp32` is a bespoke tag that was introduced in Zig. The rest of the world just uses `gnu` for RISC-V target triples. * `gnu_ilp32` is already the name of an ILP32 ABI used on AArch64. `gnuilp32` is too easy to confuse with this. * We don't use this convention for `riscv64-linux-gnu`. * Supporting all RISC-V ABIs with this convention will result in combinatorial explosion; see ziglang#20690.
This target triple was weird on multiple levels: * The `ilp32` ABI is the soft float ABI. This is not the main ABI we want to support on RISC-V; rather, we want `ilp32d`. * `gnuilp32` is a bespoke tag that was introduced in Zig. The rest of the world just uses `gnu` for RISC-V target triples. * `gnu_ilp32` is already the name of an ILP32 ABI used on AArch64. `gnuilp32` is too easy to confuse with this. * We don't use this convention for `riscv64-linux-gnu`. * Supporting all RISC-V ABIs with this convention will result in combinatorial explosion; see ziglang#20690.
|
I finally took the time to digest this. Thanks for the excellent writeup and background research, @alexrp. I think you've pretty clearly established that the ABI part of the target string needs to support a wider range of ABIs. One point where I want to diverge from this proposal is that I plan to replace all libcs with zig code at some point. That includes musl, mingw, and wasi-libc, and the static bits of glibc. This will happen invisibly, with the same target string, with no breaking changes (related: #2879). The idea of introducing a new "ziglibc" would only really affect the C headers. In other words the API. Furthermore, I'm not sure how valuable that would be as opposed to reusing e.g. musl's API. So, my counter-proposal to you is that the target string has "api" instead of "libc". It's a bit of a theoretical difference because it doesn't really affect the implications of this proposal. However, it's important to communicate that Zig is not guaranteeing that you literally are getting musl libc, mingw-w64 libc, etc., but that you are getting a compatible API. This also solves another open issue which I was unable to find, where someone wanted to include the libc headers but not actually link against libc. This use case would be represented with providing an API in the target string, but omitting I am marking this as accepted, along with establishing some issue close criteria:
Related: |
This seems entirely reasonable to me; I'm not married to the term "libc". I actually like the term "api" more even without your good arguments here.
Agree on this as well.
Some musl targets, such as that one, should actually continue to work as-is, but I take your point in regards to all other APIs, as the spelling for these will change. Should be fairly trivial to detect incorrect input like
Strongly agree, and this is what I touched on in my interaction with @mlugg above. My ideal here is that 95% of users should be completely oblivious to the fact that there exists a 4th target component because we just do the right thing (or as close to it as possible) by default.
I think we can extend this to other architectures like Arm and LoongArch as well. Any thoughts on the remaining open questions?:
|
How about "system"? I think that name would apply just as well to e.g. FreeBSD as it would to macOS.
hmm. I know they forked their headers from musl. If they have not patched those headers, then I think "musl" is still appropriate, and furthermore we should delete our copy of those headers and use the musl headers. However if they have patches, which I am guessing they do, then think the API should be named after that project, with the redundant part of the name stripped (the "libc"). So, "wasi". An example target would look like |
|
Ok, that makes sense to me. What do you think about |
There are a lot of wasi-specific patches to the Musl headers forked for wasi-libc. They've tried to use |
Just curious if this will make it even less likely for Zig to support Eyra is rust-based libc implementation that is built with Presently it's not usable with Zig as I haven't yet opened an issue with more details, but I was hoping that
I suppose this is similar to what eyra is doing? Which may make the support request redundant, but I think With Rust, cargo defaults musl to static linking as well. Alpine and related musl based distros instead patch that to dynamic linking since that makes more sense for software built and packaged for those distros. So there's a case for musl to support dynamic linking too AFAIK. |
that doesnt seem right, im on alpine and zig dynamically links musl by default. am i misunderstanding what you mean? |
Is Eyra fully (as in literally 100%) API/ABI compatible with glibc?
That's a known bug that still needs to be resolved. It's not an intentional design choice or anything. |
I think my concern is specific to
It's still in development, but viable for projects with the API surface that it covers. The developer AFAIK has no need for dynamic linking support so they're only focused on static linking, particularly for use with WASM IIRC. So no It is intended to match glibc AFAIK, and is built by using I don't believe it has any notion of glibc versioned symbols if you were referring to that. This isn't my area of expertise, I was just interested in it as a static glibc instead of musl. I know that Zig is better for the dynamic linking scenario with glibc where versioning is more important, which has been improving with each Zig release (I troubleshooted a symbols issue that was resolved from
I'm aware of the issue, although I recall there being at least another one about static linking with glibc (not even a basic hello world can be static linked, it build successfully when given the I was planning to open a new issue that referenced both target specific issues with a bit of additional context, is that still worthwhile? |
Note that, above, we discussed that wasi-libc should use
We very much care about getting the versioning right. Please do file an issue.
|
I believe the project author has a related project There's no incompatibility to my knowledge with what is implemented, just what is not yet implemented. That said it does differ where glibc would not fair well in static linking, such as with NSS, but since glibc isn't really intended for static linking I'm not sure if that's an incompatibility vs static support fix 🤔
The Since it mirrors compatibility with the
👍 Alright I'll add it to my backlog, should be up within a week or two. Few other tasks to tackle first. I was referring to: #4986 (comment) There's a few other issues on the tracker I'm aware of too, but activity on them seems stale (fair given how busy you must all be), so I thought it might be best to open a new issue that references those with a reproduction on current dev (or whenever I'm not sure what you wanted to point out with the issue you linked to, but for me it was that I could compile a hello world with:
I am aware of |
Once ziglang#20690 is implemented, these will go away in favor of a simple api field. But for now, they're convenient to have.
Once ziglang#20690 is implemented, these will go away in favor of a simple api field. But for now, they're convenient to have.
|
@polarathene (sorry, completely forgot to reply to this)
Just that programs compiled by Zig for Regarding eyra: As I understand it, the main benefit of this project is the static linking while being mostly-glibc-compatible, right? If so, it seems like Zig should easily be able to accommodate that use case by way of #2879 (eventually). We'd basically just be doing the same thing that eyra is doing. I understand that that's quite a ways off, though. I think we could consider some kind of temporary solution to allow eyra to work in the meantime. For example, having a separate
(Also, just a reminder on this point.) |
Yes I think so, I pointed out barriers to using it with Zig here: #17268 (comment) I know the project README states that it's libc ABI compatible, and that it uses the glibc target (it's not compatible with the musl target). The technical details beyond that information is a bit beyond my own expertise sorry 😅 There are some drawbacks with musl as a target, while the main drawback with glibc is caveats it has with static linking. Eyra still has quite a bit to implement AFAIK, it can build some common software but As per my link to #17268 there are some compatibility issues with Zig to support eyra. I was hoping if those were resolved that it could leverage Zig to build for other glibc platforms similar to musl support.
If that's the case that'd be great!
I'm not sure how compatible that would be from the Rust side with The author of Eyra also has a similar project that has it's own custom target Mustang, the two share the same approach under the hood AFAIK, just different ways to integrate. It sounds like your temporary solution with Zig would be similar to Mustang.
I don't know how beneficial Eyra is to Zig outside of Rust projects. It should work once Zig can support glibc static linked builds + equivalent
That got set back unfortunately as I encountered an OOM that took out my running containers related to the report 😅 I've got it on my backlog but there are higher priority items for me to tackle until I can revisit that to acquire all the relevant reproduction info. |
This is, at least today, a very broken target: It doesn't actually build either musl or wasi-libc even if you use -lc. It does give you musl headers, but that's it. Those headers are not terribly useful, however, without any implementation code. You can sort of call some math functions because they just so happen to have implementations in compiler-rt. But that's only true for a small subset, and I don't think users should be relying on the ABI surface of a library that is an implementation detail of the compiler. Clearly, a freestanding-capable libc of sorts is a useful thing as evidenced by newlib, picolibc, etc existing. However, calling it "musl" is misleading when it isn't actually musl-compatible, nor can it ever be because the musl API surface is inextricably tied to the Linux kernel. In the discussion on ziglang#20690, there was agreement that once we split up the API and ABI components in the target string, the API component should be about compatibility, not whether you literally get a particular implementation of it. Also, we decided that Linux musl and wasi-libc musl shouldn't use the same API tag precisely because they're not actually compatible. (And besides, how would any syscall even be implemented in freestanding? Who or what would we be calling?) So I think we should remove this triple for now. If we decide to reintroduce something like this, especially once ziglang#2879 gets going, we should come up with a bespoke name for it rather than using "musl".
Introduction
At the moment, a Zig target triple (without versions) generally has an obvious 1:1 mapping to a GNU target triple, with only a few exceptions. In this issue, I propose that we completely break with the GNU style of target triple and, in particular, make the choice of libc and ABI two distinct components of the triple. This will enable Zig target triples (then quadruples) to communicate information that they can't today and handle a much wider range of ABI options.
Background & Motivation
Zig target triples, AFAICT, have the goal of completely replacing the
-march,-mcpu,-mtune,-mabi, and-mmacosx-version-minoptions with a single, unified-targetoption to cover them all.-mcpuhasn't been integrated in the triple yet, but that work has been accepted in #4584 (and this proposal builds on that one). The only option that remains after that is-mabiwhich is notably missing fromzig build-objand friends, presumably on the assumption that the third component of the triple ought to cover it.I've spent the past few weeks doing what I think is a fairly exhaustive survey of the ISA and ABI landscape. I put the cutoff point roughly around the mid-1970s; anything prior to that is for all intents and purposes super dead and unlikely to change any of my conclusions here. Having read through ISA manuals and ABI documentation for basically every architecture that I could find a manual for, my conclusion is that there is far more nuance to ABI choice than the current style of target triple allows. This isn't theoretical either; I'll demonstrate some real cases where the current approach falls short in ways that actually matter, and I'll show why the current approach can't scale in the long term.
I'll go over just a few architectures here; there are others that would also illustrate the point well (e.g. SuperH and m68k), but I hope the following are sufficient.
RISC-V
RISC-V is the hot new ISA on the block, so it's probably the most pertinent example here. It currently defines the following ABIs:
ilp32(full soft float)ilp32f(softf64andf128; hardf32)ilp32d(softf128; hardf32andf64)ilp32e(full soft float; reduced register set)lp64(full soft float)lp64f(softf64andf128; hardf32)lp64d(softf128; hardf32andf64)lp64q(full hard float)zig build-objand friends simply have no way to select between these ABIs at the moment. We would have to add ABI tags for all of them, and we can already see that adding those for each ABI (plus glibc variants, plus musl variants) is going to get way out of hand. Additionally, I believe there are more ABIs to come; I've heard talk ofilp32ef, for example, and RV128 ABIs will presumably materialize at some point.Also worth noting here is that our current strategy of adopting
gnueabiandgnueabihf(and musl variants) to differentiate hard float vs soft float starts to break down once unusual float ABIs (32-bit and 128-bit) enter the picture.(Incidentally, these ABIs also show why the current
std.Target.FloatAbidefinition is not nuanced enough.)LoongArch
LoongArch has roughly the same situation as RISC-V, minus the Q and E extensions:
ilp32s(full soft float)ilp32f(softf64; hardf32)ilp32d(full hard float)lp64s(full soft float)lp64f(softf64; hardf32)lp64d(full hard float)An interesting thing to note here is that LoongArch is so far the only architecture I'm aware of to have done the sane thing and made the ABI actually, ya know, part of the ABI component of the target triple. So there's
-gnuforilp32d/lp64d,-gnuf32forilp32f/lp64f, and-gnusfforilp32s/lp64s. Good job! (It used to be-gnuf64instead of-gnu, but they simplified it because it's expected to be the common case.)PowerPC
PowerPC (or Power ISA) has had a long list of ABIs over the years, being a fairly old architecture. Some never really saw practical use (e.g. the Windows NT ABI). It's a bit hard to categorize the ones that are actually relevant, but I think they can roughly be put like this:
(Notably, Zig's current use of the bespoke
powerpc-linux-gnueabi(hf)triples is quite unfortunate because it implies an association with the PowerPC EABI, when that is not actually the case.)In addition to these broad-strokes ABIs, there are variations based around the definition of
long double. musl has done the simple thing and just declared that onlylong double = doubleis supported. Unfortunately, the rest of the world runs on one of two other definitions - either IEEE binary128 or the 128-bit "double-double" format that IBM came up with. The latter is unfortunately still very common, with binary128 only seeing limited use on newerpowerpc64ledistros (see #20579 for details). That last point is a real problem for Zig;zig build-objand friends default to the "double-double" format with no way to switch to binary128 for the distros where this is the default.But wait - there's more. Some of the above ABIs also have vector variants for efficient AltiVec usage. And of course there are also soft float variations of some of them.
And it gets much worse. You can also use a plethora of options such as
-malign-natural,-malign-power,-maix-struct-return, andmsvr4-struct-returnto explicitly override various aspects of the aforementioned ABIs.There's a near-incomprehensible number of possible combinations here.
MIPS
MIPS sits somewhere between RISC-V and PowerPC, with a lot of ABIs and configurability within those ABIs:
(MIPS support in Zig currently has the same issue as PowerPC where
gnueabi/gnueabihfare used to distinguish soft float and hard float, despite neither being EABI-based.)In addition to these, there are soft float variants and single/double-precision variants. There are also the FPXX and FP64A variants. Like PowerPC, options abound for overriding various aspects of the chosen ABI.
Miscellaneous
Some extra notes that apply to various architectures on top of what I've already written above:
gnu_ilp32(oraarch64_32as arch) for Arm64, and N32 for MIPS.Proposal
Hopefully I managed to convincingly get the point across that the current target triple format is not scalable enough for the task it's meant to achieve. Now I'll describe my idea for fixing this situation and future-proofing
std.Target.Most importantly, the triple should be replaced with a quadruple. Concretely, I'm proposing that it should now be of the form:
(Where
apiis basically libc.)You must now specify: Neither API nor ABI, only API, or both API and ABI.
Some API tags that I anticipate us recognizing would be:
system: A special tag used for platforms where there is only and can only be one libc (e.g. libSystem on macOS).none: A special tag for use if you don't want a libc at all (e.g. for thefreestandingOS tag).mingw: Uses UCRT via MinGW-w64.msvcrt: Uses UCRT and VCRuntime natively (i.e. requires MSVC / Windows SDK tooling).gnuandmusl: glibc and musl respectively.wasi: wasi-libc (modified musl).The ABI value is more complicated. In order to represent all the nuance necessary, it really needs to be treated in the same way that CPU model + features are. That is, you specify a base ABI and optionally add or subtract options, with the same
+and~syntax used for CPU features. The available ABIs and options are determined by the selected architecture, just like CPU model and features.If API and/or ABI are omitted, resolution works mostly as it does today. However, importantly, target resolution is augmented to pick sensible defaults for the ABI based on architecture, OS, and API choices. For example, if you specify
powerpc64-linux-musl,elfv2will be selected as the base ABI, as opposed toelfv1forpowerpc64-linux-gnu. This is becausemuslby definition requireselfv2. In addition to this, the base ABI also has sensible default options. In the aforementioned example, the complete resulting ABI is actuallyelfv2+ldbl64becausemuslalso mandateslong double = double. If for some reason you want to override that, you could useelfv2~ldbl64as the ABI component, but this is expected to be a rare need.Examples
Here's roughly how each triple in
zig targets | jq -r .libc[] | sortwould look post-proposal:aarch64_be-linux-gnu->aarch64_be-linux-gnu-lp64aarch64_be-linux-musl->aarch64_be-linux-musl-lp64aarch64-linux-gnu->aarch64-linux-gnu-lp64aarch64-linux-musl->aarch64-linux-musl-lp64aarch64-macos-none->aarch64-macos-system-lp64aarch64-windows-gnu->aarch64-windows-mingw-lp64(or-msvcrt-lp64+win)armeb-linux-gnueabi->armeb-linux-gnu-eabi+sfarmeb-linux-gnueabihf->armeb-linux-gnu-eabiarmeb-linux-musleabi->armeb-linux-musl-eabi+sfarmeb-linux-musleabihf->armeb-linux-musl-eabiarm-linux-gnueabi->arm-linux-gnu-eabi+sfarm-linux-gnueabihf->arm-linux-gnu-eabiarm-linux-musleabi->arm-linux-musl-eabi+sfarm-linux-musleabihf->arm-linux-musl-eabiarm-windows-gnu->arm-windows-mingw-eabi(or-msvcrt-eabi+win)csky-linux-gnueabi->csky-linux-gnu-abiv2+sfcsky-linux-gnueabihf->csky-linux-gnu-abiv2loongarch64-linux-gnu->loongarch64-linux-gnu-lp64dloongarch64-linux-musl->loongarch64-linux-musl-lp64dm68k-linux-gnu->m68k-linux-gnu-gnu(not to be confused with-sysvwhich is older and different!)m68k-linux-musl->m68k-linux-musl-gnu(likewise)mips64el-linux-gnuabi64->mips64el-linux-gnu-n64mips64el-linux-gnuabin32->mips64el-linux-gnu-n32mips64el-linux-musl->mips64el-linux-musl-n64mips64-linux-gnuabi64->mips64-linux-gnu-n64mips64-linux-gnuabin32->mips64-linux-gnu-n32mips64-linux-musl->mips64-linux-musl-n64mipsel-linux-gnueabi->mipsel-linux-gnu-o32+sfmipsel-linux-gnueabihf->mipsel-linux-gnu-o32mipsel-linux-musl->mipsel-linux-musl-o32mips-linux-gnueabi->mips-linux-gnu-o32+sf(see my notes on EABI above)mips-linux-gnueabihf->mips-linux-gnu-o32(likewise)mips-linux-musl->mips-linux-musl-o32powerpc64le-linux-gnu->powerpc64le-linux-gnu-elfv2powerpc64le-linux-musl->powerpc64le-linux-musl-elfv2+ldbl64powerpc64-linux-gnu->powerpc64-linux-gnu-elfv1powerpc64-linux-musl->powerpc64-linux-musl-elfv2+ldbl64powerpc-linux-gnueabi->powerpc-linux-gnu-svr4+sf(see my notes on EABI above)powerpc-linux-gnueabihf->powerpc-linux-gnu-svr4(likewise)powerpc-linux-musl->powerpc-linux-musl-svr4+ldbl64+secpltriscv32-linux-gnuilp32->riscv32-linux-gnu-ilp32d(yes, this one was confusingly named)riscv32-linux-musl->riscv32-linux-musl-ilp32driscv64-linux-gnu->riscv64-linux-gnu-lp64driscv64-linux-musl->riscv64-linux-musl-lp64ds390x-linux-gnu->s390x-linux-gnu-elfs390x-linux-musl->s390x-linux-musl-elfsparc64-linux-gnu->sparc64-linux-gnu-sysvsparc-linux-gnu->sparc-linux-gnu-sysvthumb-linux-gnueabi->thumb-linux-gnu-eabi+sfthumb-linux-gnueabihf->thumb-linux-gnu-eabithumb-linux-musleabi->thumb-linux-musl-eabi+sfthumb-linux-musleabihf->thumb-linux-musl-eabiwasm32-freestanding-musl->wasm32-freestanding-none-watc(WebAssembly Tool Conventions)wasm32-wasi-musl->wasm32-wasi-wasi-watc(likewise)x86_64-linux-gnu->x86_64-linux-gnu-sysvx86_64-linux-gnux32->x86_64-linux-gnu-x32x86_64-linux-musl->x86_64-linux-musl-sysvx86_64-macos-none->x86_64-macos-system-sysvx86_64-windows-gnu->x86_64-windows-mingw-sysv(or-msvcrt-win64)x86-linux-gnu->x86-linux-gnu-sysvx86-linux-musl->x86-linux-musl-sysvx86-windows-gnu->x86-windows-mingw-sysv(or-msvcrt-win32)Note that many triples are still missing here; this is just intended to give a rough idea of how things will look. Also, some of these names would certainly be subject to change and/or bikeshedding during implementation.
Anticipated Concerns
I just want to address upfront some (reasonable!) concerns that I'm almost certain will be on people's minds after reading this:
long doubleon PowerPC, downright unworkable. It's easy to keep things simple if you don't account for all cases. (Quotingzig zen: Edge cases matter.) Also, writing code for real hardware is necessarily more complex than e.g. a bytecode VM. I think it's actually entirely reasonable to ask that people understand the basics of their target environment, especially in cross-compilation scenarios. The behavior of picking sensible ABI defaults based on other components should help here. For native builds, things stay simple.zig zenagain: Avoid local maximums.)The text was updated successfully, but these errors were encountered: