* [gentoo-mips] Re: [gentoo-dev] Monthly mips@ project status for April 2018
@ 2018-04-02 20:32 99% ` Michał Górny
0 siblings, 0 replies; 1+ results
From: Michał Górny @ 2018-04-02 20:32 UTC (permalink / raw
To: gentoo-dev; +Cc: mips, gentoo-mips
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
^ permalink raw reply [relevance 99%]
Results 1-1 of 1 | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
2018-04-02 3:40 [gentoo-mips] Monthly mips@ project status for April 2018 Matt Turner
2018-04-02 9:41 ` [gentoo-mips] Re: [gentoo-dev] " Michał Górny
2018-04-02 17:27 ` Joshua Kinard
2018-04-02 20:32 99% ` Michał Górny
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox