Mailing List Archive

On 4/1/2018 11:40 PM, Matt Turner wrote:
> 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.

Big or little endian? If little,


> == 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.

SGI machines I have access to are in a similar state. Except I'm the only nut
playing with these systems it seems, and I've got a massive patch backlog
that's no where near the quality that upstream would accept. My git foo is
also terrible for maintaining them, given that kernel upstream seems to like
one patch for every minor change, it seems.

Better BRIDGE support for IP27 (SGI Origin) is where most everything begins. I
know //what// needs to be done to unscrew that system (mostly), but I just
haven't had time to write the C code that'd do it. Following that, IP30 is
branched off of my current IP27 work, so once IP27 support is fixed upstream,
IP30 could be split apart and some portions sent in.

As far as IP30 goes, it works. Probably the most capable of the available SGI
machine support right now. Still suffers from the 2GB RAM limit because
something still ain't right in dealing with the 512MB PHYS_OFFSET and the wacky
BRIDGE DMA mess.

IP32/R5K/RM7K works, too. Still nothing on the R10K/R12K variants. All of
this hoopla about Spectre and Meltdown on x86 definitely made my day, though
</smirk>

Long ways down on my TODO list is to try and port nyef's IP35 work from 4.2.x
to something more recent. IP35 could re-use much of the IP27 base (once
BRIDGE/PCI is fixed), just with appropriate changes to deal with BEDROCK's
design as a successor to the HUB. Plenty of example code from the Altix port
in the 2.5.x kernel to reference, too. Would enable faster build machines.

Lack of time, though. I need a TARDIS...


> == 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.

We'll probably need this to also be able to play with LTO, since that's a
significant memory consumer, especially if you use several LTO threads.


> == 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.

I got a mostly-working netboot image built in December for my IP32 system,
based off of uclibc-ng and 4.13.16. Building the image right now needs a fresh
stage3 uclibc-ng/mips2, a custom script I wrote in Python, and copy/pasting
specific commands. End goal is to take that logic and turn it into a
"netboot3" target for Catalyst. I stopped when catalyst-3 debuted, because I
didn't get around to looking at the changes from catalyst 2.x to 3.x. But the
script works manually, with some post-cleanup commands.

However, I held off on publishing anything because the most recent stage builds
were done under gcc-6.4.0, and with the resolution of gcc PR81443, I can now
run gcc-7.3.x on my SGI systems. I plan on starting another series of stage
runs under catalyst 2.x once OpenRC gets fixed for the uclibc-ng target (see
bug #650908). Six targets (n32/{mips3,mips4,mips4_r12k}, o32, multilib, &
uclibc-ng) takes about a month on my Octane right now. Mostly because gcc's
build time is utterly insane.

If anyone wants, I can publish the December builds for the SGI big-endian
stages. Maybe a few netboot targets if I can find the time, likely based on
4.13.x because 4.14/4.15 had the firmware tree stripped out, and there's a
quirky bug where input over ssh on my Octane has a very weird, sporadic latency
at random, which I think is a bug I'll be forced to bisect down at some point.

Also, if anyone has a mips3/mips4/mips4 ISA, big-endian musl stage, hook me up.
I'd love to use musl for netboot targets, as even uclibc-ng is pushing ~12MB
for a full netboot image, I am still not 100% certain the older SGI machines
will take it (namely IP22, not that I even have a working unit anymore).

SGI bootable CDs are not impossible (all the tools are still in the tree), but
we really need netboot images first. Any future boot CD will be command line
only. The X11 world has moved so far ahead, that even if Octane's X11 Impact
driver got fixed, I doubt the experience would be anything but "fun".

--
Joshua Kinard
Gentoo/MIPS
kumba@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

On 4/2/2018 3:37 AM, Joshua Kinard wrote:
> On 4/1/2018 11:40 PM, Matt Turner wrote:
>> 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.
>
> Big or little endian? If little,

Helps to finish my sentences. Except I don't remember where I was going to go
with this bit.

--
Joshua Kinard
Gentoo/MIPS
kumba@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

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

On 4/1/18 11:40 PM, Matt Turner wrote:
>
> My plan is to add stable 17.0 mips profiles when the keywording is
> sorted out and kill two birds with one stone.
>

Many thanks! I think I was the last person to touch those. This was
one of those things I had in the back of my mind as a to do, but I know
I won't have time to get to it, so I really appreciate keeping those
profiles alive.

>
> I want to support the tree main ABIs: Old 32 ("o32"), New 32 ("n32"),
> and New 64 ("n64").

Yes. This is the ideal.

--
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail : blueness@gentoo.org
GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA
GnuPG ID : F52D4BBA

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
kumba@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

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

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
kumba@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