From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id F12981382C5 for ; Tue, 3 Apr 2018 05:24:25 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id C5C10E0BEC; Tue, 3 Apr 2018 05:24:00 +0000 (UTC) Received: from resqmta-ch2-03v.sys.comcast.net (resqmta-ch2-03v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 96F47E0BEC for ; Tue, 3 Apr 2018 05:24:00 +0000 (UTC) Received: from resomta-ch2-06v.sys.comcast.net ([69.252.207.102]) by resqmta-ch2-03v.sys.comcast.net with ESMTP id 3EQHf2luqC4y53EQHf4ZdK; Tue, 03 Apr 2018 05:23:57 +0000 Received: from [192.168.1.13] ([76.100.35.246]) by resomta-ch2-06v.sys.comcast.net with SMTP id 3EQFfixwnWoE03EQGfSDU6; Tue, 03 Apr 2018 05:23:57 +0000 Subject: [gentoo-mips] Re: [gentoo-dev] Monthly mips@ project status for April 2018 To: =?UTF-8?B?TWljaGHFgiBHw7Nybnk=?= , gentoo-dev@lists.gentoo.org Cc: mips@gentoo.org, gentoo-mips@lists.gentoo.org References: <20180402034037.GB21189@ivybridge.mattst88.com> <1522662081.793.7.camel@gentoo.org> <84e8aeb1-797e-a727-abe8-232dfc02d4af@gentoo.org> <1522701148.21713.5.camel@gentoo.org> From: Joshua Kinard Message-ID: Date: Tue, 3 Apr 2018 01:23:54 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-mips@lists.gentoo.org Reply-to: gentoo-mips@lists.gentoo.org MIME-Version: 1.0 In-Reply-To: <1522701148.21713.5.camel@gentoo.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfL8hVr/FpMj7fWY9BaGAhBFScIPIu5dKPOfPJDhsh+FYO/2wUBVx/VInoGKG+GtY2Q/4lW0GwlJsae1WGTDTSZzEjqRutRiLBfRpwsWv4R/m+YPyf5Yn zHNyNm74km5dmEv8+Y3yPYBhJ2FpiwTr+mcCm7njePdDav1P0cT/cI7cuSM0cadNfTBKjUk0BXLjJbGp6rdl4UDNXofJ7u/6u7upwCeM+lqo1mNNgt3E1l0b ZSynRt0v7LQNPOTdXOsbH5bmRQ3PHg9ZQ932PXv+bi8= X-Archives-Salt: e779f461-9e7c-4801-9ad5-5f99e411d53f X-Archives-Hash: be0fef48a03a8bf61d5c30673a48c847 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