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 B66011382C5 for ; Mon, 2 Apr 2018 20:32:42 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 3E79AE0F51; Mon, 2 Apr 2018 20:32:35 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (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 C4620E0EE3; Mon, 2 Apr 2018 20:32:34 +0000 (UTC) Received: from pomiot (d202-252.icpnet.pl [109.173.202.252]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mgorny) by smtp.gentoo.org (Postfix) with ESMTPSA id 1938B335CE0; Mon, 2 Apr 2018 20:32:31 +0000 (UTC) Message-ID: <1522701148.21713.5.camel@gentoo.org> Subject: Re: [gentoo-dev] Monthly mips@ project status for April 2018 From: =?UTF-8?Q?Micha=C5=82_G=C3=B3rny?= To: gentoo-dev@lists.gentoo.org Cc: mips@gentoo.org, gentoo-mips@lists.gentoo.org Date: Mon, 02 Apr 2018 22:32:28 +0200 In-Reply-To: <84e8aeb1-797e-a727-abe8-232dfc02d4af@gentoo.org> References: <20180402034037.GB21189@ivybridge.mattst88.com> <1522662081.793.7.camel@gentoo.org> <84e8aeb1-797e-a727-abe8-232dfc02d4af@gentoo.org> Organization: Gentoo Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.24.6 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Archives-Salt: 023073d0-1ea9-48cd-82a9-4a6417b357fb X-Archives-Hash: c1212ea34f1536597e9444c527ac0411 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