1 |
On 4/2/2018 4:32 PM, Michał Górny wrote: |
2 |
> W dniu pon, 02.04.2018 o godzinie 13∶27 -0400, użytkownik Joshua Kinard |
3 |
> napisał: |
4 |
>> On 4/2/2018 5:41 AM, Michał Górny wrote: |
5 |
>>> W dniu nie, 01.04.2018 o godzinie 20∶40 -0700, użytkownik Matt Turner |
6 |
>>> napisał: |
7 |
>>> |
8 |
>>>> My plan is to add stable 17.0 mips profiles when the keywording is |
9 |
>>>> sorted out and kill two birds with one stone. |
10 |
>>> |
11 |
>>> Does it involve fixing the CHOST inconsistency so that we can finally |
12 |
>>> get LLVM keyworded? |
13 |
>> |
14 |
>> Bug #515694, right? Based on a very quick re-read, there are two |
15 |
>> issues/blockers here: |
16 |
>> |
17 |
>> 1) Current Gentoo/MIPS support was originally based on gcc, thus, we've used |
18 |
>> CHOST tuples that are recognized by gcc. |
19 |
> |
20 |
> As far as I'm aware GCC doesn't really care about which triplet is used. |
21 |
> It's all controlled by --with-abi= option (I may have mistyped its |
22 |
> name). |
23 |
|
24 |
gcc might not, but odds are incredibly likely other software will. I want to |
25 |
say memory reminds me that glibc may be a culprit here, and may explain the |
26 |
reason why someone redesigned the triplets/tuples in the first place. E.g., I |
27 |
*think* (but can't corroborate) that the "mips64-unknown-linux-gnuabin32" tuple |
28 |
derived from glibc wanting to determine n32 support from the CHOST. Again, |
29 |
though, there are no known equivalents of this for uclibc-ng or musl targets |
30 |
that I know of. |
31 |
|
32 |
|
33 |
>> 2) clang lacks a CHOST tuple that defaults to n32. n32 is the "ideal" ABI for |
34 |
>> a 64-bit platform that doesn't need full 64bit (n64) binary support. |
35 |
>> |
36 |
>> As far as I can tell, we need to fix #2 before we can do anything about #1. |
37 |
>> Once clang has a discrete CHOST tuple for n32, that'll put it on parity with |
38 |
>> gcc, which itself appears to have a batch of more specific tuples to select |
39 |
>> different ABIs. You might want to just push upstream any patches you have that |
40 |
>> adds this support first. |
41 |
> |
42 |
> It's chicken-egg problem. Before I can submit a patch upstream, I need |
43 |
> someone with MIPS hardware and a proper profile (using disjoint, |
44 |
> consistent triplets) to test it. Not to mention Gentoo needs to decide |
45 |
> on the triplet in the first place. |
46 |
|
47 |
Is there an option to cross-compile clang/llvm using a CHOST added by your |
48 |
patch? That should at least validate that the CHOST logic works out. Any one |
49 |
of us could then test out a statically-linked binary generated from such a |
50 |
toolchain, assuming the target output matches one of our machines. |
51 |
|
52 |
As far as Gentoo "deciding", I have to argue that it's not an "our fault" thing |
53 |
or such. Back when the port was started in ~2003, there was no such thing as |
54 |
clang/llvm, so we used what CHOSTs gcc was happy with. Life continued on from |
55 |
there, with a few hiccups along the way. |
56 |
|
57 |
I know of no authority that sets/decides what CHOSTs are valid and what aren't. |
58 |
That'd probably be a nice thing to have, TBH, as my irritation with FreeBSD's |
59 |
versioned CHOSTs makes updating a Gentoo/FreeBSD userland mildly annoying. |
60 |
That said, I don't have much of a problem adopting the Debian versions[1]. We |
61 |
would just need a way to migrate existing installs, preferably w/o having to |
62 |
recompile everything... |
63 |
|
64 |
1. https://wiki.debian.org/Multiarch/Tuples |
65 |
|
66 |
-- |
67 |
Joshua Kinard |
68 |
Gentoo/MIPS |
69 |
kumba@g.o |
70 |
6144R/F5C6C943 2015-04-27 |
71 |
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943 |
72 |
|
73 |
"The past tempts us, the present confuses us, the future frightens us. And our |
74 |
lives slip away, moment by moment, lost in that vast, terrible in-between." |
75 |
|
76 |
--Emperor Turhan, Centauri Republic |