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 DAC201382C5 for ; Mon, 2 Apr 2018 17:28:12 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 563CAE0E1E; Mon, 2 Apr 2018 17:27:50 +0000 (UTC) Received: from resqmta-ch2-01v.sys.comcast.net (resqmta-ch2-01v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:33]) (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 2623DE0E1E for ; Mon, 2 Apr 2018 17:27:50 +0000 (UTC) Received: from resomta-ch2-18v.sys.comcast.net ([69.252.207.114]) by resqmta-ch2-01v.sys.comcast.net with ESMTP id 33E1fssk0RYl633FBfu675; Mon, 02 Apr 2018 17:27:45 +0000 Received: from [192.168.1.13] ([76.100.35.246]) by resomta-ch2-18v.sys.comcast.net with SMTP id 33F7fXqeY0dXT33F8flNIb; Mon, 02 Apr 2018 17:27:45 +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> From: Joshua Kinard Message-ID: <84e8aeb1-797e-a727-abe8-232dfc02d4af@gentoo.org> Date: Mon, 2 Apr 2018 13:27:40 -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: <1522662081.793.7.camel@gentoo.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfOA+mKyUUKIcxfdYv1v1ysUnM/k7HAnTQUEajowfCDaHAAa57clHkoNZwyK5Ya+aHjPAn1r3vIa+c/zHMm+5LHL/S1k+U9zpUqa53kPmLGkESPquc681 sUWsBMPYRAoWxPCXGAa68aPftsscDnIG7Z7cdnZcw+YkXVMiIgCfLCM9Bwv82FcF5i6pHrtK0REnw3u5MM6DAyfJUn/11U6SkBA5wsFB42lS9wmei7+JFk5O B2q4Qf5LnW+on7EG5DaZDbl5EXzcNS3U86iu58lYDA0= X-Archives-Salt: cadb563f-7b61-4029-898e-c15f869bf645 X-Archives-Hash: 50c37e5e8b32854fe2f8c3f4cdc54c66 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. 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. --- 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. -- 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