Long story short: 1. we pass --with-abi= to gcc to set the default ABI for compiler, 2. instead, clang has hardcoded default ABI matching CHOST: n64 for mips64* and o32 for mips*. Of course, proper build can be forced with -mabi=. However, this makes sense only for multilib ebuilds. Non-multilib are going to use whatever CC/CXX user set, so if user sets 'clang', it may build a different ABI than 'gcc'. Possible solutions: 1. support only profiles that have matching ABIs (I guess you don't like that), 2. change clang defaults (NeedPatch), 3. make clang choose mips ABI based on tool prefix (won't work with plain 'clang', requires changing CHOST of default ABI, NeedPatch), 4. replace all of 'clang' and '$CHOST-clang' with wrapper that add proper -mabi= (relatively easy to do yet a bit unclean, and requires adding ${ABI}_CFLAGS for each ABI).
Hmm, I missed the most useful option: 5. Fix the mips profiles to be sane.
(In reply to Michał Górny from comment #1) > Hmm, I missed the most useful option: > > 5. Fix the mips profiles to be sane. I am somewhat puzzled as to what is broken with the profiles for mips. We're not hacking around anything. The existing CHOST values have been that way for years. o32: mips[el]-unknown-linux-gnu n32: mips[el]64-unknown-linux-gnu + -mabi=n32 n64: mips[el]64-unknown-linux-gnu + -mabi=64 There's some more archaic ABIs out there, such as o64 and eabi, but we don't use them. Purportedly, there's a newer/ish CHOST for n32 called mips[el]64-unknown-linux-gnuabin32, but no one I know of has done extensive testing of it to see which packages actually recognize it. These are all for glibc only, too. uclibc and musl have their own endings, and I don't think either have a dedicated n32 CHOST value like -gnuabin32. Keep in mind we've got a pretty complex mix of variables with MIPS platforms. IMHO, I think the bug here is with clang, as their mips support is no where near as feature-complete as gcc's.
No, the bug is that you force default ABI at compile-time of gcc, and expect everything to randomly guess what you wanted there. It's nowhere suitable for cross, and I don't really see adding another magical configuration option to workaround CHOST values that are broken by design and make ABI unpredictable.
(In reply to Michał Górny from comment #1) > Hmm, I missed the most useful option: > > 5. Fix the mips profiles to be sane. What would we have to do for this exactly, which changes, do you know?
(In reply to Michał Górny from comment #0) > Long story short: > > 1. we pass --with-abi= to gcc to set the default ABI for compiler, > > 2. instead, clang has hardcoded default ABI matching CHOST: n64 for mips64* > and o32 for mips*. There's a 3rd ABI, which is the one we use primary: n32. What is the CHOST for that? > Of course, proper build can be forced with -mabi=. However, this makes sense > only for multilib ebuilds. Non-multilib are going to use whatever CC/CXX > user set, so if user sets 'clang', it may build a different ABI than 'gcc'. Right, and we set --with-abi=n32 for n32 stages. > Possible solutions: > > 1. support only profiles that have matching ABIs (I guess you don't like > that), Seems like that would preclude multilib? > 2. change clang defaults (NeedPatch), > > 3. make clang choose mips ABI based on tool prefix (won't work with plain > 'clang', requires changing CHOST of default ABI, NeedPatch), > > 4. replace all of 'clang' and '$CHOST-clang' with wrapper that add proper > -mabi= (relatively easy to do yet a bit unclean, and requires adding > ${ABI}_CFLAGS for each ABI). These three seem like options we should consider last. (In reply to Michał Górny from comment #1) > Hmm, I missed the most useful option: > > 5. Fix the mips profiles to be sane. What do you mean? What do you suggest?
(In reply to Matt Turner from comment #5) > (In reply to Michał Górny from comment #0) > > Long story short: > > > > 1. we pass --with-abi= to gcc to set the default ABI for compiler, > > > > 2. instead, clang has hardcoded default ABI matching CHOST: n64 for mips64* > > and o32 for mips*. > > There's a 3rd ABI, which is the one we use primary: n32. What is the CHOST > for that? clang doesn't have n32 triple at the moment. I was planning to add support for it once we are able to actually use it. > > Possible solutions: > > > > 1. support only profiles that have matching ABIs (I guess you don't like > > that), > > Seems like that would preclude multilib? Exactly the opposite. I think that by this step I meant having clang supported only on those profiles where CHOST for each ABI matches one supported for clang, i.e. CHOST_n64 == mips64*, CHOST_o32 == mips-*, CHOST_n32 == mips64-*n32. We'd effectively kill clang support on the non-multilib profiles that don't guarantee that. > (In reply to Michał Górny from comment #1) > > Hmm, I missed the most useful option: > > > > 5. Fix the mips profiles to be sane. > > What do you mean? What do you suggest? Something along the following: mips64/n32/make.defaults:CHOST="mips64-unknown-linux-gnu" mipsel/mips64el/n32/make.defaults:CHOST="mips64el-unknown-linux-gnu" -> mips64/n32/make.defaults:CHOST="mips64-unknown-linux-gnun32" mipsel/mips64el/n32/make.defaults:CHOST="mips64el-unknown-linux-gnun32" Note that I've only done a quick grep, so I might've missed some profile. But these two are the major offenders. Not that I have any clue how to safely change CHOST on a profile. You'd probably have to introduce a new profile, and require explicit action from users.
Ping. Could we get this done for 17.0 profiles?
TL;DR: I don't think mips profiles are in any way wrong or deviate from gcc upstream defaults. If you need parity then you need to agree on CHOST meaning in gcc and llvm/clang upstreams for both n32 (gentoo's n32) and 64 (gentoo's n64) ABIs. Both seem to mismatch. Longer version: This bug seems to imply that GCC being configured as ./configure --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=mips64-unknown-linux-gnu targets to something other than N32 ABI. It does not. N32 ABI is the default: $ ../gcc/configure --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=mips64-unknown-linux-gnu $ make $ ./gcc/xgcc -B./gcc/ -dM -E - </dev/null | fgrep ABI #define __GXX_ABI_VERSION 1012 #define _MIPS_SIM _ABIN32 #define _ABIN32 2 Upstream default comes from here: https://github.com/gcc-mirror/gcc/blob/master/gcc/config.gcc#L2134 Thus gcc (default=n32) and clang (default=64 as asserted by comment #1, I didn't check) already disagree on CHOST=mips64-unknown-linux-gnu ABI meaning and it needs to be fixed upstream(s) first. You might notice gcc/config.gcc has no CHOST at all assigned for default_mips_abi=64 and no CHOST assigned for MIPS_ABI_DEFAULT=ABI_64 Thus if you need CHOST parity for ABI=64 you would need to propose something to gcc (and perhaps glibc and binutils) upstream to settle on canonical 64-bit CHOST. Here is the full list of mips ABIs gcc knows about: https://github.com/gcc-mirror/gcc/blob/master/gcc/config.gcc#L4613 case ${default_mips_abi} in 32) tm_defines="$tm_defines MIPS_ABI_DEFAULT=ABI_32" ;; o64) tm_defines="$tm_defines MIPS_ABI_DEFAULT=ABI_O64" ;; n32) tm_defines="$tm_defines MIPS_ABI_DEFAULT=ABI_N32" ;; 64) tm_defines="$tm_defines MIPS_ABI_DEFAULT=ABI_64" ;; eabi) tm_defines="$tm_defines MIPS_ABI_DEFAULT=ABI_EABI" ;; esac The ABI assignment and default mapping happens in the same file: https://github.com/gcc-mirror/gcc/blob/master/gcc/config.gcc#L2099
TL;WR: you're wrong.
In other words, you could spend less time trying to prove wrong is right, and more time fixing it. But as far as I'm concerned, this can just block clang keywording forever and I can direct all the users to you so that they can learn that there's a higher purpose in not being able to use the software they like -- it helps one person believe yet another partial stupid incompatible customization of Gentoo is valid!
(In reply to Michał Górny from comment #10) > In other words, you could spend less time trying to prove wrong is right, > and more time fixing it. I proved nothing. I merely stated the facts to get the understanding of problem at hand because it's absolutely not obvious from the bug. It has no linked bugs and has a few claims that imply gentoo does something that deviates from upstream. Please be more specific what is 'it' here. I'll also post here relevant snippet from IRC: > 22:40:43 < mgorny> the mips team already agreed the profiles need fixing If it did I do not see the agreement here in the bug. You have proposed here 5 solutions. Which one(s?) did mips team agree to apply in your understanding? Who did agree so I would get some context from them. This bug did not state where actual deviation takes place so I had to do spelunking to understand which profiles are affected so far. Now I need to do the same for clang :) You did not state the end goal on how consistent end state should look like across gcc/clang and other distros.
#c6 states exactly what needs to be changed. https://wiki.debian.org/Multiarch/Tuples It should consistently be: CHOST_o32="mips[el]-unknown-linux-gnu" CHOST_n32="mips64[el]-unknown-linux-gnuabin32" CHOST_n64="mips64[el]-unknown-linux-gnuabi64" Those profiles need to be changed to use safe CHOST for o32: arch/mips/mipsel/mips64el/multilib/o32/make.defaults:CHOST_o32="mips64el-unknown-linux-gnu" arch/mips/mipsel/mips64el/multilib/make.defaults:CHOST_o32="mips64el-unknown-linux-gnu" arch/mips/mips64/multilib/o32/make.defaults:CHOST_o32="mips64-unknown-linux-gnu" arch/mips/mips64/multilib/make.defaults:CHOST_o32="mips64-unknown-linux-gnu" i.e. they need to have 'mips64' changed to just 'mips'. Those profiles need to be changed to use valid CHOST for n32: arch/mips/mipsel/mips64el/n32/make.defaults:CHOST_n32="mips64el-unknown-linux-gnu" arch/mips/mipsel/mips64el/multilib/n32/make.defaults:CHOST_n32="mips64el-unknown-linux-gnu" arch/mips/mipsel/mips64el/multilib/make.defaults:CHOST_n32="mips64el-unknown-linux-gnu" arch/mips/mips64/n32/make.defaults:CHOST_n32="mips64-unknown-linux-gnu" arch/mips/mips64/multilib/n32/make.defaults:CHOST_n32="mips64-unknown-linux-gnu" arch/mips/mips64/multilib/make.defaults:CHOST_n32="mips64-unknown-linux-gnu" They all need to have 'abin32' appended. For consistency, it would be also nice to change those: arch/mips/mipsel/mips64el/n64/make.defaults:CHOST_n64="mips64el-unknown-linux-gnu" arch/mips/mipsel/mips64el/multilib/n64/make.defaults:CHOST_n64="mips64el-unknown-linux-gnu" arch/mips/mipsel/mips64el/multilib/make.defaults:CHOST_n64="mips64el-unknown-linux-gnu" arch/mips/mips64/n64/make.defaults:CHOST_n64="mips64-unknown-linux-gnu" arch/mips/mips64/multilib/n64/make.defaults:CHOST_n64="mips64-unknown-linux-gnu" arch/mips/mips64/multilib/make.defaults:CHOST_n64="mips64-unknown-linux-gnu" ...and append 'abi64' consistently to them.
> Now I need to do the same for clang Clang on the other side has no "triple" (as they call tuple) that defaults to n32 ABI. Their targets are only o32 and n64: https://github.com/llvm-mirror/clang/blob/3edd9221b28c4a229ae5e211a367f6988c12e879/lib/Driver/ToolChains/Arch/Mips.cpp#L86 if (ABIName.empty() && (Triple.getVendor() == llvm::Triple::MipsTechnologies || Triple.getVendor() == llvm::Triple::ImaginationTechnologies)) { ABIName = llvm::StringSwitch<const char *>(CPUName) .Case("mips1", "o32") .Case("mips2", "o32") .Case("mips3", "n64") .Case("mips4", "n64") .Case("mips5", "n64") .Case("mips32", "o32") .Case("mips32r2", "o32") .Case("mips32r3", "o32") .Case("mips32r5", "o32") .Case("mips32r6", "o32") .Case("mips64", "n64") .Case("mips64r2", "n64") .Case("mips64r3", "n64") .Case("mips64r5", "n64") .Case("mips64r6", "n64") .Case("octeon", "n64") .Case("p5600", "o32") .Default(""); } CPUName is an <arch> part of <arch>-<vendor>-<os>-<abi> triple. Thus today CHOST does not really matter for n32/n64 cases. None of them work. Both upstreams need to be taught about new CHOST tuples to have common ground. Thus proposed change in #c12 will not improve anything neither for gcc nor for clang users unless the relevant bits will be fixed in the compiler. Preparing CHOST upfront makes sense provided both gcc and clang upstreams commit on changing the meaning of "new" triplets. It's surprising to see lack of support of proposed triplets in both upstreams even when those are used in debian for a while. Why is that? Technically any of compilers can change meaning of any CHOST they support. Practically though it will be a breakage for users that will observe ABI change once CHOST changes. Hence why I stress the details of what compiler already use to understand the scope of impact for them and for us now and in the future. This morning's vanilla gcc still does not understand gnuabi64 and we would need to deviate from upstream's ABI: $ ../gcc/configure --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=mips64-unknown-linux-gnuabi64 $ make $ ./gcc/xgcc -B./gcc/ -dM -E - </dev/null | fgrep ABI #define __GXX_ABI_VERSION 1012 #define _MIPS_SIM _ABIN32 #define _ABIN32 2
Because there is no point in me preparing patches for upst when Gentoo randomly changes CHOST for no reason other than "we can"
(In reply to Michał Górny from comment #14) > Because there is no point in me preparing patches for upst when Gentoo > randomly changes CHOST for no reason other than "we can" [once again] Did file a bug about the discrepancy across gcc/clang to either of upstreams and whether they are aware of the difference? 1. I don't think Gentoo changes CHOST frequently (or at all) Unless you refer to https://github.com/gentoo/gentoo-gitmig-20150809-draft/commit/9b41ef4f185ac29066749e1bab2cdd314d3023a5 which has no mention of either: mips@ approving it, any bugs, context or a change. Say, this clearly does not work today (3 years passed) in Gentoo's clang: $ clang -target mips64-unknown-linux-gnuabin32 -E a.c -dM - </dev/null | fgrep -i abi #define _ABI64 3 2. In my opinion Gentoo should adopt upstream definition and interpretation of tuple (whatever definition it is) and help upstreams reconcile tuple definitions. Whether one particular tuple (say, mips64-unknown-linux-gnuabi64) it interpreted the same across different upstreams is remaining to be seen. Otherwise no matter which obscure enough tuple Gentoo picks it will differ for gcc/clang and we would have to alter their default interpretation using downstream patches.
And in my opinion, I do not care beyond getting clang to work. GCC has a hack, we've been happy to use it through all these years, I don't care. Clang is fully triplet-based, so start using sane triplets. Or for a start, you could start using one triplet to mean the same thing instead of using two different triplets for the same thing depending on whether it's default or not. Which is what this was about before you started diverging the topic.
I'll try to summarise then. = The problem = For 3 ABIs mips needs 3 different CHOSTs to make multilib work. Otherwise (I guess) multilib ${CHOST}-wrappers mean something incorrect. Example: if we have 'mips64-unknown-linux-gnu-curl-config --libs' it always returns the same -L/usr/lib<something> path for two different ABIs that share CHOST (wrong). Gentoo partially mitigates ${CHOST}-wrapped being not correct by passing proper CFLAGS_${abi} / LDFLAGS_${abi} (and friends) to make ebuilds work. It sort of works for gcc but does not work for other ${CHOST}-wrapped binaries. = Possible solutions = It does not matter much which exact CHOST values we pick because gcc/clang upstreams disagree on any value we pick for n32/n64. Two CHOSTs were ok (arguably, except being used for n64 ABI as well): - mips-unknown-linux-gnu (o32, OK) - mips64-unknown-linux-gnu (n32, contentious) The third is missing: - ?? (n64, missing) AFAIU it does not matter which one we pick as none work the same on clang/gcc right now. Note: none of proposed changes below should change code generation by the toolchains. They only affect file names on disk. == Action 0 : settle on tuple meanings in Gentoo == mips@ needs to decide which tuples they want to chose as canonical CHOST for ABI and document them as such. Worth considering actions below WRT impact. == Action 1 (seemingly uncontroversial): settle on n64 tuple and change profiles == Steal debian's - mips64[el]-unknown-linux-gnuabi64 (n64) Profiles affected (multilib and native): mips64/multilib/make.defaults:CHOST="mips64-unknown-linux-gnu" mips64/n64/make.defaults:CHOST="mips64-unknown-linux-gnu" mips64/make.defaults:CHOST="mips64-unknown-linux-gnu" mipsel/mips64el/multilib/make.defaults:CHOST="mips64el-unknown-linux-gnu" mipsel/mips64el/n64/make.defaults:CHOST="mips64el-unknown-linux-gnu" mipsel/mips64el/make.defaults:CHOST="mips64el-unknown-linux-gnu" Consequence: users will have to suffer profile switch. Is n64 used much? Looks like not much. Perhaps could be changed straight away. == Action 2 (more contentious): settle on n32 tuple and change profiles == === Option 1: revert mips64[el]-unknown-linux-gnuabin32 -> mips64-unknown-linux-gnu === Profiles affected (multilib only): mips64/multilib/n64/make.defaults:CHOST_n32="mips64-unknown-linux-gnuabin32" mips64/multilib/o32/make.defaults:CHOST_n32="mips64-unknown-linux-gnuabin32" mipsel/mips64el/multilib/n64/make.defaults:CHOST_n32="mips64el-unknown-linux-gnuabin32" mipsel/mips64el/multilib/o32/make.defaults:CHOST_n32="mips64el-unknown-linux-gnuabin32" This should not brick users' systems because it's used only in two profiles for non-default ABI. Rebuilding affected packages should keep system alive. === Option 2: finish mips64-unknown-linux-gnu -> mips64[el]-unknown-linux-gnuabin32 === Profiles affected: mips64/multilib/make.defaults:CHOST="mips64-unknown-linux-gnu" mips64/n32/make.defaults:CHOST="mips64-unknown-linux-gnu" mips64/make.defaults:CHOST="mips64-unknown-linux-gnu" mipsel/mips64el/multilib/make.defaults:CHOST="mips64el-unknown-linux-gnu" mipsel/mips64el/n32/make.defaults:CHOST="mips64el-unknown-linux-gnu" mipsel/mips64el/make.defaults:CHOST="mips64el-unknown-linux-gnu" = The related problems brought up here (don't require action) = - (as topic states) gcc and clang do not agree on ABI. Yes they don't and it's not Gentoo's fault but how two compilers understand tuples. Changing just CHOST* values won't fix ABI mismatch for any tuple. Gentoo will need to apply changes downstream anyway. - mips64-unknown-linux-gnu<->mips64-unknown-linux-gnuabin32 CHOST changes Changing this CHOST value brings nothing except causing users the hurdle to switch from one to another. At least today. mips64-unknown-linux-gnuabin32 could be better long-term when the tuple will be understood by both upstreams (if ever).
If I were to choose I'd pick: > == Action 0 : settle on tuple meanings in Gentoo == - mips-unknown-linux-gnu (o32) - mips64[el]-unknown-linux-gnu (n32, follow gcc and existing non-multilib) - mips64[el]-unknown-linux-gnuabi64 (n64) > == Action 1 (seemingly uncontroversial): settle on n64 tuple and change > profiles == > Steal debian's > - mips64[el]-unknown-linux-gnuabi64 (n64) and apply the changes to existing profiles right away. > == Action 2 (more contentious): settle on n32 tuple and change profiles == > === Option 1: revert mips64[el]-unknown-linux-gnuabin32 -> > mips64-unknown-linux-gnu === and apply the changes to existing profiles right away.
(In reply to Sergei Trofimovich from comment #17) > = The related problems brought up here (don't require action) = > > - (as topic states) gcc and clang do not agree on ABI. > > Yes they don't and it's not Gentoo's fault but how two compilers > understand tuples. Changing just CHOST* values won't fix ABI mismatch for > any tuple. Gentoo will need to apply changes downstream anyway. Bullshit. I will push clang changes upstream. As long as they are harmless and don't break other distributions using clang, that is. > - mips64-unknown-linux-gnu<->mips64-unknown-linux-gnuabin32 CHOST changes > > Changing this CHOST value brings nothing except causing users the hurdle > to switch from one to another. At least today. > mips64-unknown-linux-gnuabin32 could be better long-term when the tuple will > be understood by both upstreams (if ever). Except the latter tuple is *unique* and guaranteed to be safe. The former ends up as ugly Gentoo patch not to break compatibility with other distributions which use it for something else.
I recently came across the Python/Rust debate in tech news and reading through that led me back to this bug, since Rust apparently requires LLVM. If I understand correctly, the basic complaint is that we in the mips team have been using a rather generic CHOST tuple for multiple ABIs, passing --mabi= to select the ABI, and this is confusing LLVM or it is unsupported by LLVM? If I got that right, and considering we are probably due for a new set of profiles, I don't have a problem switching to newer or more-specific CHOST tuples for the three main ABIs we support via new profiles. I suppose it'd look something like this: o32/glibc (pure 32-bit): - mips-unknown-linux-gnu (big-endian) - mipsel-unknown-linux-gnu (little-endian) o32/musl: - mips-unknown-linux-musl - mipsel-unknown-linux-musl n32/glibc (hybrid 32-bit/64-bit): - mips64-unknown-linux-gnueabin32 - mips64el-unknown-linux-gnueabin32 n32/musl (WIP): - mips64-unknown-linux-musl - mips64el-unknown-linux-musl n64/glibc (pure 64-bit; unsupported on Gentoo): - mips64-unknown-linux-gnueabi64 - mips64el-unknown-linux-gnueabi64 n64/musl (pure 64-bit; unsupported period?): - mips64-unknown-linux-musl - mips64el-unknown-linux-musl multilib/glibc (n32 is primary ABI, rest built as-needed): - mips64-unknown-linux-gnu - mips64el-unknown-linux-gnu multilib/musl (n32 is primary ABI, rest built as-needed): - mips64-unknown-linux-musl - mips64el-unknown-linux-musl Notes: * uclibc-ng support is dead right now, so we skip * o64 ABI is strictly for SGI IP32 kernel builds and has no application to userland * eabi ABI is unused and, in fact, I believe incomplete in the toolchain ---- On the glibc side, switching to ABI-specific CHOSTs is not impossible for existing installs. It DOES require being VERY careful, and some of the information in the old Gentoo/FreeBSD gcc upgrade guide is really helpful here (because you always had to change the CHOST when upgrading gcc on that platform). It'd be best to do this in a new profile obviously. Multilib userlands can use the existing logic and CHOST tuples we have since they mix multiple ABIs together. The primary ABI is n32, with o32 and n64 components built as needed (mostly @system packages). A key problem with musl is, as far as I know, its ecosystem does not have any approved CHOST tuples for the different MIPS ABIs. Other than the obvious split between o32 and n32/n64, there is no way to uniquely identify an n32 musl userland from an n64 musl userland by CHOST alone. In other words, it'd mirror our existing setup for glibc-based userlands, so we can keep that logic around for it. Given that musl support in Gentoo is still its own work in progress, and we don't support pure n64 userlands at all, that's not a major issue as far as I am concerned. Focus can be on the glibc-side of things for now. --- As far as LLVM goes, the last time I looked at it, it did not support the "old" ISA levels for MIPS. E.g., MIPS-II, MIPS-III, and MIPS-IV (as they were known). LLVM apparently skipped straight to the "new" ISAs, like mips32rX or mips64rX. If this is still the case, then that becomes a blocker, at least for myself, since I rely on old MIPS hardware (SGI systems) to target this architecture. If LLVM has since fixed this and it supports the old ABIs fine, then we're probably okay. Note that there are two unique SGI machine platforms that use non-coherent cache designs, and thus require special compiler support. One, the IP28 system, may still work, but I need to try building a 5.4 LTS kernel for it and booting (it probably needs more work beyond that). The other, SGI IP32 w/ R10K+ CPUs, is unsupported in Linux, so it is not a concern for us. Specific to IP28, gcc has a compiler flag called '-mr10k-cache-barrier' that controls the generation of compiler barriers at certain points. It's primarily used by the Linux kernel for that platform, but may also have uses in userland (though none have ever been found). LLVM would be completely unsuable on these platforms unless someone wants to port the compiler support from gcc to LLVM for this extreme corner case. Thoughts?
Also, the obvious question, but where are we at in Gentoo to actually enabling clang/LLVM as a system compiler, replacing gcc entirely? E.g., is there a 'toolchain-config' package that would replace gcc-config and binutils-config and also allows selection of an LLVM-based compiler to compile packages with?
(In reply to Joshua Kinard from comment #21) > Also, the obvious question, but where are we at in Gentoo to actually > enabling clang/LLVM as a system compiler, replacing gcc entirely? E.g., is > there a 'toolchain-config' package that would replace gcc-config and > binutils-config and also allows selection of an LLVM-based compiler to > compile packages with? There is no definite movement that I'm aware of. There are a few people who fix clang support here and there but so far CC=clang CXX=clang++ is the way to go. Note that I'm not sure if it doesn't break stuff though.
The relevant code as of today is: https://github.com/llvm/llvm-project/blob/main/clang/lib/Driver/ToolChains/Arch/Mips.cpp#L89 which means: - n32 target must be *-gnueabin32 - n64/o32 is determined via CPU name, I think it would be cleanest to just use mips64* and mips32* respectively The key point is the CHOST_foo constants in every profile must be unique in that profile, and must meet the above rules. You may want to reconsider how many profiles to actually support. You seem to be working on mips alone right now, so maybe start with the most useful stuff and go from there. Not sure if there's real value in mips multilib. Normally we do multilib to support precompiled software but I honestly doubt this is something you're going to use on mips.
(In reply to Michal Górny from comment #23) > The relevant code as of today is: > https://github.com/llvm/llvm-project/blob/main/clang/lib/Driver/ToolChains/ > Arch/Mips.cpp#L89 > > which means: > > - n32 target must be *-gnueabin32 This is doable in a new n32 profile. > - n64/o32 is determined via CPU name, I think it would be cleanest to just > use mips64* and mips32* respectively So this is where things get weird with the MIPS architecture. This code in LLVM looks like an ISA-to-ABI mapping, and mips' ISAs are strange to the uninitiated. Effectively, there are two classes, "old ISAs" and "new ISAs". The old ISAs are what I focus on because my SGI systems fall into those. They include MIPS-I (mips1) to MIPS-IV (mips4). My SGI Octane runs R14000 CPUs, which are MIPS-IV ISA. The oldest SGI system that we can theoretically support is an SGI Indy running an R4000 CPU, which is MIPS-III. MIPS-II only ever existed in the R6000 CPU, which themselves only existed in couch-sized Cray supercomputers back in the late 80's. MIPS-I includes things like the R3000 (PlayStation, DECstation), and the R2000 (does it exist anymore?). MIPS-V (mips5) was proposed by SGI, but never came to be. Many of its ideas were incorporated into the mips64r* ISA series after SGI moved to Itanium. There's also weird CPU's like the Playstation 2's R5900, which is MIPS-III with specific MIPS-IV features backported. That support might get added to the Linux kernel at some point (active github repo working on the code). We'll cross that bridge when we get there. Another thing about the old ISAs is they were layered like an onion. MIPS-II would add new features, but also include all of the features of MIPS-I. Etc up to MIPS-IV. However, MIPS-I and MIPS-II were only 32-bit. MIPS-III was the first 64-bit ISA, followed by MIPS-IV. When the "new" ISAs came about, they partially abandoned this layered approach, with MIPS32rX branching off of MIPS-II and MIPS64rX branching off of MIPS-IV (carrying forward some of the unimplemented MIPS-V features as well). Each MIPS32rX/MIPS64rX I believe was developed in parallel, such that MIPS64r6 can execute MIPS32r6 ISA, so not as layered like the old ISAs, but still able to behave similarly. There were five total revisions of these new ISAs, of which at least two have been released. r1 was development, r2 was released, r3 was development, r4 was skipped because the number 4 is bad luck in Asia, r5 I think was development (may have seen a limited release), and r6 is the latest of both of the new ISAs. As such, for our purposes, 32-bit targets aim for MIPS-II, as this is the common denominator for any 32-bit MIPS target. Meaning I can build them on my old SGI gear and not worry that someone running a newer MIPS32rX platform can't use them. Equally, for 64-bit targets, the common denominator is MIPS-III or MIPS-IV, which someone with MIPS64rX gear should also be able to execute. I cannot compile to the MIPS32rX or MIPS64rX targets directly because my SGI hardware can't execute those ISAs. That means when it comes to the userland ABIs, our "o32" profile MUST use "mips[el]-*", NOT "mips32[el]-*", since I support old SGI gear. As such, the CHOST for an o32 profile would be "mips[el]-unknown-linux-gnu, the ABI "o32", and the ISA "mips2". For n32 targets, CHOST would be "mips64[el]-unknown-linux-gnueabin32", the ABI would be "n32", and the ISA defaulted to "mips3" but overridable by the user to "mips4" (arguably, this should be a separate profile). If we ever wanted to support n64 profiles for a pure n64-userland, I would do similar to n32, just using the correct CHOST and ABI, but keeping the same default ISA. Multilib can stay as-is. Musl targets will stick with the embedded profiles under that team. > The key point is the CHOST_foo constants in every profile must be unique in > that profile, and must meet the above rules. It seems that LLVM's rule selection is a bit kludgy here. They try to select o32 or n64 based on CHOST tuple, but basically throw in a special-case exemption for n32. What this suggests is the LLVM developers were somewhat baffled on how to handle the n32 ABI. They assumed that the ABI is a binary value, either 32-bits or 64-bits only. n32 is a hybrid of the two (pointers are 32bits long, but overall, behaves like a full 64bit ABI). Intel/AMD architecture attempted similar with the ill-fated x32 ABI. People just couldn't wrap their heads around it, I guess, and that effort is functionally dead. But for MIPS, if you can do 64-bits, then n32 is the ABI you really want. n64 should only come into play in limited circumstances (like databases). This is what SGI's IRIX did from 6.2.x to the final release of 6.5.31. It seems LLVM doesn't understand this fully, so there might be some issues down the road there. We should only need to set one CHOST_foo constant in each profile to match the ABI, not all three. The ABI can determine the appropriate default ISA to use, and the user can override in /etc/portage/make.conf if they wish. Does this sound logical? > You may want to reconsider how many profiles to actually support. You seem > to be working on mips alone right now, so maybe start with the most useful > stuff and go from there. Not terribly surprising. MIPS is in a weird state right now. SGI hardware is still rather plentiful in the US and Canada on eBay for some odd reason (compare that to Sun sparc32 hardware). So people can run old SGI stuff, even though some of the platforms are buggy as hell. And if the Linux/MIPS upstream guys ever get SGI IP35 support working, well, SGI will live on for another 1-2 decades, cause SGI hardware was built to last. But outside of that, your only other choices (outside of non-embedded stuff, which our team doesn't handle directly) are Chinese-made Loongsong hardware, which is hard to get outside of that country. In rare cases, it might be possible to stumble across old Swarm machines (Debian uses/used these for their mips "buildd" systems). I'll carry the flame as long as I can. Managing the profiles isn't really hard, just tedious (but that's Gentoo's fault for the way "cascading profiles" work to begin with). I'm likely to add new ones, run them in chroots for while to work the kinks out, migrate my Octane's filesystem to them, then deprecate the old before removal after a year or so. It's a bit easier since I built my NAS appliance to hold all of these chroots. As I get one or two more SGI systems online, they can all connect to the NAS over NFS and be used to build stuff to a central location, instead of it all existing on one machine's hard drive. Push comes to shove, there's always the RISC-V bandwagon, which is backed by several of the original MIPS creators, so... > Not sure if there's real value in mips multilib. Normally we do multilib to > support precompiled software but I honestly doubt this is something you're > going to use on mips. Since we don't support a pure-n64 environment, multilib acts as a way to test current n64 support during compile to help find bugs. Plus a multilib environment can be used as a base to start a pure-n64 environment if anyone ever wanted to pursue that. So it has a minor purpose to futureproof things a little bit. It's usually my last build target when doing catalyst runs as well, so that if some problem comes up that I cannot solve, I can skip it and just release what I already have.
Created attachment 717522 [details] New MIPS 21.0 profiles, attempt #1 Attached is a tar.xz of a 21.0 MIPS profile set. Completely untested. Unpack it in profiles/, and it'll inflate to default/linux/mips/21.0. I think I have the correct overrides in place to force the CHOST values to the versions that clang/llvm is going to be happy with, but will also work for gcc/binutils. It seems for our 17.0 profiles, those really just create a bunch of 'eapi' files and 'parent' pointers to stuff in profiles/arch/mips. So for now, the 21.0 large replicates that, but clobbers the non-multilib folders with a make.defaults that changes only the CHOST values. Everything else stays the same, including the passing of -mabi to the C compiler. Long-long-term down the road (several years), I suppose the 17.0 profiles can go away and the 21.0 profile differences can be folded back into profiles/arch/mips, reducing 21.0 to being just like 17.0, containing just 'eapi' files and 'parent' pointers. I'll try to actually test these at some point after I finish catalyst runs. Changing of the CHOST requires rebuilding system packages, including the compiler, a few times, so that can wait until after new stages are built.
Are correct CHOSTs also set for multilib profiles somehow?
(In reply to Michał Górny from comment #26) > Are correct CHOSTs also set for multilib profiles somehow? Well, I think so. They are defined in profiles/arch/mips/{mips64,mipsel}/multilib/. Under that folder, there's a top-level make.defaults where CHOST is initially defined for mips64-unknown-linux-gnu (for mips64, mipsel similar), and then it specifies CHOST_n32/CHOST_n64/CHOST_o32 as the same value. But those values are later overridden in the n32/n64/o32 subfolders. Although, now that I look at it, I may have missed a bit in the multilib profiles. I probably need to clobber a few more values w/ additional make.defaults. This is why I never liked our cascaded profile setup. Complete mess and hard to maintain...although we get by cleverly w/ mips. I always preferred my stacked profiles idea I had back in '07 or so.
You may take a look at mah old tools: https://github.com/mgorny/profile-cleanup Particularly profile-dumper can be used to see what all that cascading combines into.
Created attachment 717558 [details] New MIPS 21.0 profiles, attempt #2
(In reply to Michal Górny from comment #28) > You may take a look at mah old tools: > > https://github.com/mgorny/profile-cleanup > > Particularly profile-dumper can be used to see what all that cascading > combines into. profile-dumper spits out a make.defaults that seems to contain the correct CHOST values, but none of the other variables defined in the various make.defaults files in the profile cascade. I think the issue is because I am building these 21.0 profiles in a temporary overlay, but the parent files all rely on relative directory structures to find the upper profile layers. That assumption breaks when used from within an overlay. Easy fix is to just copy the 21.0 profiles from my overlay to default/linux/mips, and then profile-dumper has all of the variables defined. From that list, here is what multilib looks like now with my fix in place for CFLAGS and CHOST*: CFLAGS="-O2 -pipe" CFLAGS_n32="-mabi=n32" CFLAGS_n64="-mabi=64" CFLAGS_o32="-mabi=32" CHOST="mips64-unknown-linux-gnu" CHOST_n32="mips64-unknown-linux-gnuabin32" CHOST_n64="mips64-unknown-linux-gnuabi64" CHOST_o32="mips-unknown-linux-gnu" We have to have a default CHOST, so the classic triplet seems to be best. My assumption is the CHOST_$abi versions override it at some point? And do these values look like they'll work for clang/llvm?
(In reply to Joshua Kinard from comment #30) > We have to have a default CHOST, so the classic triplet seems to be best. > My assumption is the CHOST_$abi versions override it at some point? Yes, multilib.eclass is using them when building for non-native ABI. > And do > these values look like they'll work for clang/llvm? Yes.
Created attachment 764960 [details] New MIPS 22.0 profiles I've circled back around to this, renamed the "21.0" to "22.0", and have a build machine actually testing this in a glibc-based n32/mips3 chroot that's been recently updated. Following the Gentoo Wiki on changing the CHOST value, this should be a straight-forward update. But we've had issues in the past with some software not using recent config.{sub,guess} files and choking on MIPS CHOSTs. It'll be about a week if everything goes smoothly (and if that damn kernel oops finally went away) before I'll have the chroot fully migrated over to the new CHOST. If that all goes to plan, I'll commit the new profile to git shortly after. Key changes here from the existing 17.0 MIPS profiles is for N32, N64, and Multilib profiles, the CHOST changes to an ABI-specific value. O32 CHOSTs are left alone. musl is also unaffected because it has a completely different profile folder, and to date, I don't think there are n32/n64-specific CHOST tuples for a musl MIPS target. That one is going to need to rely on passing -mabi= to $CC for a bit longer until I can poke Anthony or musl upstream to see how they want to handle that. I also am making the profile EAPI7 as a minimum, since EAPI5 is deprecated.
Btw, has clang/llvm finally added support for the N32 ABI? I took a quick look at the selection code linked in comment #23, and it still seems to prefer N64 ABI for any mips64* CPU names, and a few bypasses when it detects "gnuabin32" in CHOST, then and only then does it use N32. N32 should be the default ABI on any modern MIPS platform, with N64 being reserved for special cases only. This is what gcc has been doing for years, and it is how SGI compiled IRIX 6.5 for 64-bit targets using MIPSPro up until IRIX was abandoned in ~2006. So clang's logic on N64/N32 handling looks like it needs to be flipped around. That said, one step at a time...need to make sure the new CHOST plays nice with existing @system packages.
(In reply to Joshua Kinard from comment #32) > Created attachment 764960 [details] > New MIPS 22.0 profiles > > I've circled back around to this, renamed the "21.0" to "22.0", and have a > build machine actually testing this in a glibc-based n32/mips3 chroot that's > been recently updated. Following the Gentoo Wiki on changing the CHOST > value, this should be a straight-forward update. But we've had issues in > the past with some software not using recent config.{sub,guess} files and > choking on MIPS CHOSTs. > > It'll be about a week if everything goes smoothly (and if that damn kernel > oops finally went away) before I'll have the chroot fully migrated over to > the new CHOST. If that all goes to plan, I'll commit the new profile to git > shortly after. Please send the patches to the gentoo-dev ML using git-send-email and include this explanation in the commit message(s). > > Key changes here from the existing 17.0 MIPS profiles is for N32, N64, and > Multilib profiles, the CHOST changes to an ABI-specific value. O32 CHOSTs > are left alone. musl is also unaffected because it has a completely > different profile folder, and to date, I don't think there are > n32/n64-specific CHOST tuples for a musl MIPS target. That one is going to > need to rely on passing -mabi= to $CC for a bit longer until I can poke > Anthony or musl upstream to see how they want to handle that. > > I also am making the profile EAPI7 as a minimum, since EAPI5 is deprecated. Please do EAPI 5 instead as it's not deprecated for profiles.
kumba: please take a look at https://github.com/gentoo/gentoo/pull/27259 which fixes at least some of the profile issues with mips.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6163cd3fa19853dca27519180cc2980f78f52408 commit 6163cd3fa19853dca27519180cc2980f78f52408 Author: matoro <matoro@users.noreply.github.com> AuthorDate: 2022-09-15 00:00:07 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-09-23 00:05:15 +0000 profiles: bring musl on mips into line with 17.0 profiles This lets us get rid of default/linux/musl/ and hardened/ entirely (the latter was marked deprecated in January) Bug: https://bugs.gentoo.org/515694 Signed-off-by: Sam James <sam@gentoo.org> profiles/arch/mips/package.use.force | 6 +- profiles/arch/mips/package.use.mask | 4 ++ profiles/default/linux/{ => mips/17.0}/musl/eapi | 0 .../{musl/mips => mips/17.0/musl/mipsel}/eapi | 0 .../mips => mips/17.0/musl}/mipsel/make.defaults | 6 +- .../mips/mipsel => mips/17.0/musl/mipsel/n64}/eapi | 0 .../linux/mips/17.0/musl/mipsel/n64/make.defaults | 6 ++ .../default/linux/mips/17.0/musl/mipsel/n64/parent | 2 + .../linux/mips/17.0/musl/mipsel/o32}/eapi | 0 .../linux/mips/17.0/musl/mipsel/o32/make.defaults | 6 ++ .../default/linux/mips/17.0/musl/mipsel/o32/parent | 2 + .../default/linux/mips/17.0/musl/mipsel/parent | 2 + .../musl => default/linux/mips/17.0/musl/n64}/eapi | 0 .../default/linux/mips/17.0/musl/n64/make.defaults | 6 ++ profiles/default/linux/mips/17.0/musl/n64/parent | 2 + .../mips => default/linux/mips/17.0/musl/o32}/eapi | 0 .../default/linux/mips/17.0/musl/o32/make.defaults | 6 ++ profiles/default/linux/mips/17.0/musl/o32/parent | 2 + .../{musl/mips => mips/17.0/musl}/package.mask | 2 +- profiles/default/linux/mips/17.0/musl/parent | 3 + profiles/default/linux/musl/make.defaults | 16 ----- profiles/default/linux/musl/mips/make.defaults | 20 ------ profiles/default/linux/musl/mips/mipsel/parent | 1 - profiles/default/linux/musl/mips/package.use.force | 5 -- profiles/default/linux/musl/mips/parent | 1 - profiles/default/linux/musl/mips/use.force | 6 -- profiles/default/linux/musl/mips/use.mask | 6 -- profiles/default/linux/musl/package.mask | 84 ---------------------- profiles/default/linux/musl/package.use | 7 -- profiles/default/linux/musl/package.use.force | 9 --- profiles/default/linux/musl/package.use.mask | 18 ----- profiles/default/linux/musl/packages | 6 -- profiles/default/linux/musl/packages.build | 10 --- profiles/default/linux/musl/parent | 3 - profiles/default/linux/musl/use.force | 5 -- profiles/default/linux/musl/use.mask | 10 --- profiles/hardened/deprecated | 5 -- profiles/hardened/linux/musl/make.defaults | 5 -- profiles/hardened/linux/musl/mips/mipsel/eapi | 1 - profiles/hardened/linux/musl/mips/mipsel/parent | 2 - profiles/hardened/linux/musl/mips/parent | 2 - profiles/hardened/linux/musl/package.use.mask | 6 -- profiles/hardened/linux/musl/use.force | 8 --- profiles/hardened/linux/musl/use.mask | 13 ---- profiles/profiles.desc | 8 +-- 45 files changed, 52 insertions(+), 260 deletions(-)
Candidate for 23.0 profiles
See also https://github.com/gentoo/gentoo/pull/34648/files#r1442507661 (dev-util/perf's handling of MIPS ABIs).
This is fixed in the 23.0 profiles (available and stable now). Closing.
