From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <gentoo-dev+bounces-85427-garchives=archives.gentoo.org@lists.gentoo.org>
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 <garchives@archives.gentoo.org>; 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 <gentoo-dev@lists.gentoo.org>; 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 <slyfox@gentoo.org>
To: James Le Cuirot <chewi@gentoo.org>
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: <mailto:gentoo-dev@lists.gentoo.org>
List-Help: <mailto:gentoo-dev+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-dev+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org>
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 <chewi@gentoo.org> 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