[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-dev
Subject:    Re: [gentoo-dev] [arm17] [PATCH] toolchain-funcs.eclass: Update tc-is-softfloat for new ARM triplets
From:       Sergei Trofimovich <slyfox () gentoo ! org>
Date:       2018-07-26 7:13:12
Message-ID: 20180726081312.6edad324 () sf
[Download RAW message or body]

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

[prev in list] [next in list] [prev in thread] [next in thread]