Re: [gentoo-dev] Monthly mips@ project status for April 2018
On 4/2/2018 4:32 PM, Michał Górny wrote: > W dniu pon, 02.04.2018 o godzinie 13∶27 -0400, użytkownik Joshua Kinard > napisał: >> On 4/2/2018 5:41 AM, Michał Górny wrote: >>> W dniu nie, 01.04.2018 o godzinie 20∶40 -0700, użytkownik Matt Turner >>> napisał: >>> My plan is to add stable 17.0 mips profiles when the keywording is sorted out and kill two birds with one stone. >>> >>> Does it involve fixing the CHOST inconsistency so that we can finally >>> get LLVM keyworded? >> >> Bug #515694, right? Based on a very quick re-read, there are two >> issues/blockers here: >> >> 1) Current Gentoo/MIPS support was originally based on gcc, thus, we've used >> CHOST tuples that are recognized by gcc. > > As far as I'm aware GCC doesn't really care about which triplet is used. > It's all controlled by --with-abi= option (I may have mistyped its > name). gcc might not, but odds are incredibly likely other software will. I want to say memory reminds me that glibc may be a culprit here, and may explain the reason why someone redesigned the triplets/tuples in the first place. E.g., I *think* (but can't corroborate) that the "mips64-unknown-linux-gnuabin32" tuple derived from glibc wanting to determine n32 support from the CHOST. Again, though, there are no known equivalents of this for uclibc-ng or musl targets that I know of. >> 2) clang lacks a CHOST tuple that defaults to n32. n32 is the "ideal" ABI >> for >> a 64-bit platform that doesn't need full 64bit (n64) binary support. >> >> As far as I can tell, we need to fix #2 before we can do anything about #1. >> Once clang has a discrete CHOST tuple for n32, that'll put it on parity with >> gcc, which itself appears to have a batch of more specific tuples to select >> different ABIs. You might want to just push upstream any patches you have >> that >> adds this support first. > > It's chicken-egg problem. Before I can submit a patch upstream, I need > someone with MIPS hardware and a proper profile (using disjoint, > consistent triplets) to test it. Not to mention Gentoo needs to decide > on the triplet in the first place. Is there an option to cross-compile clang/llvm using a CHOST added by your patch? That should at least validate that the CHOST logic works out. Any one of us could then test out a statically-linked binary generated from such a toolchain, assuming the target output matches one of our machines. As far as Gentoo "deciding", I have to argue that it's not an "our fault" thing or such. Back when the port was started in ~2003, there was no such thing as clang/llvm, so we used what CHOSTs gcc was happy with. Life continued on from there, with a few hiccups along the way. I know of no authority that sets/decides what CHOSTs are valid and what aren't. That'd probably be a nice thing to have, TBH, as my irritation with FreeBSD's versioned CHOSTs makes updating a Gentoo/FreeBSD userland mildly annoying. That said, I don't have much of a problem adopting the Debian versions[1]. We would just need a way to migrate existing installs, preferably w/o having to recompile everything... 1. https://wiki.debian.org/Multiarch/Tuples -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org 6144R/F5C6C943 2015-04-27 177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943 "The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between." --Emperor Turhan, Centauri Republic
Re: [gentoo-dev] Monthly mips@ project status for April 2018
W dniu pon, 02.04.2018 o godzinie 13∶27 -0400, użytkownik Joshua Kinard napisał: > On 4/2/2018 5:41 AM, Michał Górny wrote: > > W dniu nie, 01.04.2018 o godzinie 20∶40 -0700, użytkownik Matt Turner > > napisał: > > > > > My plan is to add stable 17.0 mips profiles when the keywording is > > > sorted out and kill two birds with one stone. > > > > Does it involve fixing the CHOST inconsistency so that we can finally > > get LLVM keyworded? > > Bug #515694, right? Based on a very quick re-read, there are two > issues/blockers here: > > 1) Current Gentoo/MIPS support was originally based on gcc, thus, we've used > CHOST tuples that are recognized by gcc. As far as I'm aware GCC doesn't really care about which triplet is used. It's all controlled by --with-abi= option (I may have mistyped its name). > 2) clang lacks a CHOST tuple that defaults to n32. n32 is the "ideal" ABI for > a 64-bit platform that doesn't need full 64bit (n64) binary support. > > As far as I can tell, we need to fix #2 before we can do anything about #1. > Once clang has a discrete CHOST tuple for n32, that'll put it on parity with > gcc, which itself appears to have a batch of more specific tuples to select > different ABIs. You might want to just push upstream any patches you have > that > adds this support first. It's chicken-egg problem. Before I can submit a patch upstream, I need someone with MIPS hardware and a proper profile (using disjoint, consistent triplets) to test it. Not to mention Gentoo needs to decide on the triplet in the first place. > > --- > > Having been around in the Very Beginning, I can tell you that one doesn't > change CHOSTs lightly on MIPS. There are a LOT of upstream projects that > don't > use newer autotools and thus won't recognize the more specific CHOSTs. And > there are a few projects, like Perl, that use their own custom build system > and > might need special fixes on top to use the more-specific tuples. > > That said, none of this addresses the issue of the multiple C library options > available. As far as I know, using different ABIs with uclibc-ng or musl > requires setting either a build or config option, or passing -mabi=xxx, along > with a gcc-like CHOST tuple. E.g., for my uclibc-ng chroot on my Octane, I am > sticking w/ o32 and thus use a CHOST of mips-unknown-linux-uclibc. If > clang/llvm can co-exist with C libraries other than glibc, this is likely an > additional complexity to consider. > > Also, last I checked, clang/llvm didn't have full support for the "old" MIPS > ISAs, namely mips3 and only part of mips4. It also has no knowledge of > scheduling for the old CPU families, like R10K. I helped write the current > R10K scheduling code for gcc a few years ago, so maybe could do something for > clang/llvm, though I have no idea how they implement CPU scheduling logic. > -- Best regards, Michał Górny
Re: [gentoo-dev] Monthly mips@ project status for April 2018
On 4/2/2018 5:41 AM, Michał Górny wrote: > W dniu nie, 01.04.2018 o godzinie 20∶40 -0700, użytkownik Matt Turner > napisał: > >> My plan is to add stable 17.0 mips profiles when the keywording is >> sorted out and kill two birds with one stone. > > Does it involve fixing the CHOST inconsistency so that we can finally > get LLVM keyworded? Bug #515694, right? Based on a very quick re-read, there are two issues/blockers here: 1) Current Gentoo/MIPS support was originally based on gcc, thus, we've used CHOST tuples that are recognized by gcc. 2) clang lacks a CHOST tuple that defaults to n32. n32 is the "ideal" ABI for a 64-bit platform that doesn't need full 64bit (n64) binary support. As far as I can tell, we need to fix #2 before we can do anything about #1. Once clang has a discrete CHOST tuple for n32, that'll put it on parity with gcc, which itself appears to have a batch of more specific tuples to select different ABIs. You might want to just push upstream any patches you have that adds this support first. --- Having been around in the Very Beginning, I can tell you that one doesn't change CHOSTs lightly on MIPS. There are a LOT of upstream projects that don't use newer autotools and thus won't recognize the more specific CHOSTs. And there are a few projects, like Perl, that use their own custom build system and might need special fixes on top to use the more-specific tuples. That said, none of this addresses the issue of the multiple C library options available. As far as I know, using different ABIs with uclibc-ng or musl requires setting either a build or config option, or passing -mabi=xxx, along with a gcc-like CHOST tuple. E.g., for my uclibc-ng chroot on my Octane, I am sticking w/ o32 and thus use a CHOST of mips-unknown-linux-uclibc. If clang/llvm can co-exist with C libraries other than glibc, this is likely an additional complexity to consider. Also, last I checked, clang/llvm didn't have full support for the "old" MIPS ISAs, namely mips3 and only part of mips4. It also has no knowledge of scheduling for the old CPU families, like R10K. I helped write the current R10K scheduling code for gcc a few years ago, so maybe could do something for clang/llvm, though I have no idea how they implement CPU scheduling logic. -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org 6144R/F5C6C943 2015-04-27 177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943 "The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between." --Emperor Turhan, Centauri Republic
Re: [gentoo-dev] Monthly mips@ project status for April 2018
W dniu nie, 01.04.2018 o godzinie 20∶40 -0700, użytkownik Matt Turner napisał: > I'd like to start giving ~monthly updates on the status of mips@ in > Gentoo. > > Recently I received a Loongson 3A system (quad-core 1.35GHz, 16GB RAM, > AMD graphics) which is significantly faster and more stable than any > other mips system I have. > > mips@ is currently assigned or cc'd on 29 bugs. This number is down from > probably >50 at the beginning of March. > > My list of to-do items consists of: > > == Switch to stable profiles == > https://github.com/gentoo/gentoo/pull/7672 > > While keeping mips unstable (KEYWORDS=~mips) I plan to switch the > profiles from exp to stable so that no new breakage is added. > > To that end, I've been working to test and keyword packages until we can > flip the switch without adding any breakage ourselves. See the github > pull request for the current status. I'll periodically rebase the branch > as I add more keywords to the main tree. If you're working on this actively, you can flip it from exp to dev again, to get CI warning-level coverage. We've flipped it to exp since nobody was really working on it and we wanted to focus on arm64 first but if you can promise us a continuous decrease in warning count, I see no problem in marking it dev. > My plan is to add stable 17.0 mips profiles when the keywording is > sorted out and kill two birds with one stone. Does it involve fixing the CHOST inconsistency so that we can finally get LLVM keyworded? -- Best regards, Michał Górny
[gentoo-dev] Monthly mips@ project status for April 2018
I'd like to start giving ~monthly updates on the status of mips@ in
Gentoo.
Recently I received a Loongson 3A system (quad-core 1.35GHz, 16GB RAM,
AMD graphics) which is significantly faster and more stable than any
other mips system I have.
mips@ is currently assigned or cc'd on 29 bugs. This number is down from
probably >50 at the beginning of March.
My list of to-do items consists of:
== Switch to stable profiles ==
https://github.com/gentoo/gentoo/pull/7672
While keeping mips unstable (KEYWORDS=~mips) I plan to switch the
profiles from exp to stable so that no new breakage is added.
To that end, I've been working to test and keyword packages until we can
flip the switch without adding any breakage ourselves. See the github
pull request for the current status. I'll periodically rebase the branch
as I add more keywords to the main tree.
My plan is to add stable 17.0 mips profiles when the keywording is
sorted out and kill two birds with one stone.
== Loongson 3A support ==
The Loongson 3A system I received requires a number of out of tree
patches to the kernel, gcc, binutils, and glibc. I've seen their
developers working to upstream kernel patches, but it's slow going and
there are a lot of them.
I haven't seen much work to upstream the other patches. I'm not sure how
to reasonably support hardware requiring so many out-of-tree patches.
== n64 (the ABI!) support ==
https://bugs.gentoo.org/show_bug.cgi?id=442548
https://bugs.gentoo.org/show_bug.cgi?id=513042
I want to support the tree main ABIs: Old 32 ("o32"), New 32 ("n32"),
and New 64 ("n64").
n32 is equivalent to amd64's x32 ABI: 64-bit ABI but with 32-bit
pointers. It's the default ABI we use for 64-bit MIPS.
I'd like to offer n64 support as well, but gcc is not quite ready. At
this point I have figured out the gcc build system enough to hack
something together that works. I just need to... upstream something I
guess?
== n64 toolchain in n32 system ==
https://bugs.gentoo.org/show_bug.cgi?id=477956
n32 (and o32) only offer 31-bits of address space (2GB). That's not
sufficient to link large libraries like webkit-gtk. For n32 systems, I'd
like the toolchain binaries to be n64, to avoid these problems.
That's going to be some amount of work on top of regular n64 support,
but hopefully not too much. multilib/ABI_MIPS support already exists and
works.
== stages and installation media ==
https://bugs.gentoo.org/show_bug.cgi?id=150402
https://bugs.gentoo.org/show_bug.cgi?id=348647
With so many subarchitectures, ABIs, and two byte orderings providing
stages and installation media has been a pain point.
I'd like to automate as much of this as possible. I really need Kumba to
build a new SGI CD, but well, that bug's been open since 2006.
signature.asc
Description: Digital signature
