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 70FD9138334 for ; Thu, 26 Jul 2018 07:13:27 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 9405EE0844; Thu, 26 Jul 2018 07:13:19 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (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 10A36E0806 for ; Thu, 26 Jul 2018 07:13:18 +0000 (UTC) Received: from sf (trofi-1-pt.tunnel.tserv1.lon2.ipv6.he.net [IPv6:2001:470:1f1c:a0f::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: slyfox) by smtp.gentoo.org (Postfix) with ESMTPSA id 4C469335C9A; Thu, 26 Jul 2018 07:13:16 +0000 (UTC) Date: Thu, 26 Jul 2018 08:13:12 +0100 From: Sergei Trofimovich To: James Le Cuirot Cc: gentoo-dev@lists.gentoo.org, arm@gentoo.org Subject: Re: [gentoo-dev] [arm17] [PATCH] toolchain-funcs.eclass: Update tc-is-softfloat for new ARM triplets Message-ID: <20180726081312.6edad324@sf> In-Reply-To: <20180725231913.1acb1477@symphony.aura-online.co.uk> References: <20180724230928.30078-1-chewi@gentoo.org> <20180725003416.49416d46@sf> <20180725231913.1acb1477@symphony.aura-online.co.uk> X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.32; x86_64-pc-linux-gnu) 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-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Archives-Salt: ba104c52-f6b2-444e-bcbc-135cb712a41f X-Archives-Hash: 9d823af724c5b67f8d9e499194df218d On Wed, 25 Jul 2018 23:19:13 +0100 James Le Cuirot wrote: > > Then we could start warning users about the fact of inconsistency and point > > to migration procedure. And we could have cleaner ${CTARGET} matches against > > what Gentoo expects. > > Not sure about this. As I've said, I don't want to force users to > migrate. Would a warning be too annoying? I don't know where to put the warning yet. It thought of it as a longer-term plan not as today's change. Still would be nice to have helper today that would tell you that CHOST tuple has unexpected configuration. I would plug new helper's output as an 'einfo' into gcc and glibc packages :) > > 5. you don't use ${CFLAGS} here. I feel we should use them as people do occasionally > > override defaults. > > I considered it but can we reliably get the flags for CTARGET? Maybe not. On second thought let's not peek into users' CFLAGS. They are too volatile WRT user settings from emerge run to run. Let's sanitize toolchain defaults here. > > I suggest using *-gnueabihf. I don't think anything more generic is recognized by toolchains > > as a hardfloat target. > > There is also musleabihf and uclibceabihf. Would *eabihf be better? Good catch! Yes, -*eabihf is better. clang supports at least lib/Support/Triple.cpp: .StartsWith("eabihf", Triple::EABIHF) lib/Support/Triple.cpp: .StartsWith("gnueabihf", Triple::GNUEABIHF) lib/Support/Triple.cpp: .StartsWith("musleabihf", Triple::MuslEABIHF) > > Also please link to description of what you think canonical hardfloat tuples are supposed to > > be. Upstreams do not agree on the definition. > > I thought this was basically dictated by our profiles but okay. The whole excercise is to attempt to unbreak clang/gcc/other-distros interoperability. Is that correct? At least it's how I see need for change at all. Given that there is no explicit meaning attached to CHOST string anywhere we need a clear description what hardware/abi Gentoo tries to target. Profiles don't say anything about the meaning of CHOST string. They just use it. I'll clarify the question: what do given profile CHOST actually supposed to mean in terms of toolchain parameters? Example answers to the following parameters: - ABI - FPU ABI - minimal ARM ISA instruction set (integer) - assumed FPU ISA I'll take armv7a-unknown-linux-gnueabihf as an example in gentoo today: - ABI - gcc/clang: eabi - FPU ABI - gcc/clang: VFP - minimal ARM ISA instruction set - gcc/clang: armv7-a(?) - assumed FPU ISA - gcc: VFPv3 - clang: VFPv3+NEON What do we do about the VFPv3/VFPv3+NEON mismatch? Presence of neon at the very least causes glibc to disable IFUNC handling: https://bugs.gentoo.org/657760 . It's not a bug on it's own and does not cause the problems (I know of) but it's a visible difference. I'll try to add a toolchain page to describe today's Gentoo deviations from gcc's upstream default. armv6 answers to the above will be different. [ not directly related but still a mismatch that will cause problems: PIC/PIE defaults between gcc/clang in gentoo differ on arm as well ] -- Sergei