1 |
W dniu pon, 02.04.2018 o godzinie 13∶27 -0400, użytkownik Joshua Kinard |
2 |
napisał: |
3 |
> On 4/2/2018 5:41 AM, Michał Górny wrote: |
4 |
> > W dniu nie, 01.04.2018 o godzinie 20∶40 -0700, użytkownik Matt Turner |
5 |
> > napisał: |
6 |
> > |
7 |
> > > My plan is to add stable 17.0 mips profiles when the keywording is |
8 |
> > > sorted out and kill two birds with one stone. |
9 |
> > |
10 |
> > Does it involve fixing the CHOST inconsistency so that we can finally |
11 |
> > get LLVM keyworded? |
12 |
> |
13 |
> Bug #515694, right? Based on a very quick re-read, there are two |
14 |
> issues/blockers here: |
15 |
> |
16 |
> 1) Current Gentoo/MIPS support was originally based on gcc, thus, we've used |
17 |
> CHOST tuples that are recognized by gcc. |
18 |
|
19 |
As far as I'm aware GCC doesn't really care about which triplet is used. |
20 |
It's all controlled by --with-abi= option (I may have mistyped its |
21 |
name). |
22 |
|
23 |
> 2) clang lacks a CHOST tuple that defaults to n32. n32 is the "ideal" ABI for |
24 |
> a 64-bit platform that doesn't need full 64bit (n64) binary support. |
25 |
> |
26 |
> As far as I can tell, we need to fix #2 before we can do anything about #1. |
27 |
> Once clang has a discrete CHOST tuple for n32, that'll put it on parity with |
28 |
> gcc, which itself appears to have a batch of more specific tuples to select |
29 |
> different ABIs. You might want to just push upstream any patches you have that |
30 |
> adds this support first. |
31 |
|
32 |
It's chicken-egg problem. Before I can submit a patch upstream, I need |
33 |
someone with MIPS hardware and a proper profile (using disjoint, |
34 |
consistent triplets) to test it. Not to mention Gentoo needs to decide |
35 |
on the triplet in the first place. |
36 |
|
37 |
> |
38 |
> --- |
39 |
> |
40 |
> Having been around in the Very Beginning, I can tell you that one doesn't |
41 |
> change CHOSTs lightly on MIPS. There are a LOT of upstream projects that don't |
42 |
> use newer autotools and thus won't recognize the more specific CHOSTs. And |
43 |
> there are a few projects, like Perl, that use their own custom build system and |
44 |
> might need special fixes on top to use the more-specific tuples. |
45 |
> |
46 |
> That said, none of this addresses the issue of the multiple C library options |
47 |
> available. As far as I know, using different ABIs with uclibc-ng or musl |
48 |
> requires setting either a build or config option, or passing -mabi=xxx, along |
49 |
> with a gcc-like CHOST tuple. E.g., for my uclibc-ng chroot on my Octane, I am |
50 |
> sticking w/ o32 and thus use a CHOST of mips-unknown-linux-uclibc. If |
51 |
> clang/llvm can co-exist with C libraries other than glibc, this is likely an |
52 |
> additional complexity to consider. |
53 |
> |
54 |
> Also, last I checked, clang/llvm didn't have full support for the "old" MIPS |
55 |
> ISAs, namely mips3 and only part of mips4. It also has no knowledge of |
56 |
> scheduling for the old CPU families, like R10K. I helped write the current |
57 |
> R10K scheduling code for gcc a few years ago, so maybe could do something for |
58 |
> clang/llvm, though I have no idea how they implement CPU scheduling logic. |
59 |
> |
60 |
|
61 |
-- |
62 |
Best regards, |
63 |
Michał Górny |