Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 666896 - cross-arm-none-eabi/gcc: Error: You cannot use any of --with-arch/cpu/fpu/float/mode with --with-multilib-list=rmprofile
Summary: cross-arm-none-eabi/gcc: Error: You cannot use any of --with-arch/cpu/fpu/flo...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Eclasses (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo Toolchain Maintainers
URL:
Whiteboard:
Keywords:
: 667030 (view as bug list)
Depends on:
Blocks:
 
Reported: 2018-09-23 17:32 UTC by Eugene Bright
Modified: 2018-09-27 22:26 UTC (History)
4 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Eugene Bright 2018-09-23 17:32:45 UTC
Currently gentoo toolchain eclass force --with-float=soft gcc compilation option on arm-* targets.
When multilib option is enabled this --with-float option looks be ignored.
But supplying --with-multilib-list option in addition breaks compilation.

Crossdev command.
> crossdev -s1 --env 'EXTRA_ECONF="--with-multilib-list=rmprofile"'  arm-none-eabi -s1 --ex-gdb --with-headers

Subsequent compilation error.
> Error: You cannot use any of --with-arch/cpu/fpu/float/mode with --with-multilib-list=rmprofile
Comment 1 Eugene Bright 2018-09-23 17:55:41 UTC
Patch is provided.
https://github.com/gentoo/gentoo/pull/9960

Please consider merging it.
Comment 2 Eugene Bright 2018-09-23 20:17:23 UTC
Special credits to rapsure and his post
https://forums.gentoo.org/viewtopic-t-1085836.html?sid=6b78204db4cafc23821c0ab419d5f766
Comment 3 Sergei Trofimovich (RETIRED) gentoo-dev 2018-09-24 22:55:58 UTC
USE=multilib might not exist in all context.

I suggest to add explicit match against 'arm-none-eabi' ${CTARGET} in autodetection and add a comment why autodetection does not apply to it.

Today crossdev forces multilib on all bare-metal targets.

Something like:
    arm-none-eabi)
	echo "no"
	return 0
Comment 4 Sergei Trofimovich (RETIRED) gentoo-dev 2018-09-25 19:38:53 UTC
*** Bug 667030 has been marked as a duplicate of this bug. ***
Comment 5 Eugene Bright 2018-09-25 20:46:04 UTC
User @rapsure struggles with target `arm-unknown-eabi`.
Please read [his post][1].
So we need more generic approach.

I suppose (let me know if I'm wrong) that lots of `--with-*` flags are overridden by multilib logic, so they are silently ignored. Only rare peaces of code do check options sanity and breaks compilation. Such a rare case is triggered by setting `--with-multilib-list=*`.
So almost every time multilib is ON, we should not guess and pass arch specific `--with-*` options.

[1]: https://forums.gentoo.org/viewtopic-t-1085836.html?sid=6b78204db4cafc23821c0ab419d5f766
Comment 6 Sergei Trofimovich (RETIRED) gentoo-dev 2018-09-25 21:25:05 UTC
(In reply to Eugene Bright from comment #5)
> User @rapsure struggles with target `arm-unknown-eabi`.
> Please read [his post][1].
> So we need more generic approach.

Sorry, it was pseudocode. Exact match depends on tuples supported by upstream and crossdev.

Here is crossdev handling code:
    https://gitweb.gentoo.org/proj/crossdev.git/tree/crossdev#n1140

    *-newlib|*-elf|*-eabi)
        set_use_force ${pkg} multilib;

gcc has a few hints on what is bare metal for it:
    https://github.com/gcc-mirror/gcc/blob/master/gcc/config.gcc#L1178

    arm*-*-eabi* | arm*-*-symbianelf* | arm*-*-rtems* | arm*-*-fuchsia*)  
      arm*-*-eabi*)
        tm_file="$tm_file newlib-stdint.h"

I think '*-newlib|*-elf|*-eabi)' under 'arm*)' should be fine. We can add a standalone helper to detect bare-metal targets based on ${CHOST}. It's used in a few places.

> I suppose (let me know if I'm wrong) that lots of `--with-*` flags are
> overridden by multilib logic, so they are silently ignored.

By gcc ebuild specifically? It's actually very little. For embedded targets it is literally:
    --enable-multilib
and that's it.

Or you meant by upstream's ./configure?

> Only rare peaces
> of code do check options sanity and breaks compilation. Such a rare case is
> triggered by setting `--with-multilib-list=*`.

You mean upstream gcc code here in a specific location, right? I presume it's about:
     https://github.com/gcc-mirror/gcc/blob/master/gcc/config.gcc#L3968

Note: it's specific only for arm and only for aprofile|rmprofile, not for any --with-multilib-list=.

> So almost every time multilib is ON, we should not guess and pass arch
> specific `--with-*` options.

This sentence is ambiguous. I'm not sure I got what you are saying: "should not guess and should not pass" or "should not guess and should pass"? Both sound wrong for a general case.

Or you mean for 'arm*' target specifically? Or bare-metal arm?

In this bug I suggest focusing first on restoring previous behaviour for bare-metal targets and then we can think of cleaning up more general target handling.
Comment 7 James Le Cuirot gentoo-dev 2018-09-26 21:00:34 UTC
I don't know about what crossdev should do as I wasn't even aware that it forced multilib in some cases. Shouldn't we just let the user choose?

For toolchain.eclass, I was thinking we should pass --with-multilib-list for arm if the multilib flag is enabled but I don't know whether it should be aprofile, rmprofile, or both. What is the purpose of these profiles?

Perhaps tc-is-softfloat should add a "multilib" return value if that is detected and CFLAGS don't dictate otherwise. This would prevent --with-float=soft being added and ultimately fix this issue. We don't currently use the CFLAGS when checking as CFLAGS for CTARGET don't really make sense but we could still use them when CHOST == CTARGET.

The first case statement in toolchain.eclass where it adds --with-float=hard seems unnecessary as this flag is also added further down in the arm clause of the other case statement. To my knowledge *-hardfloat-* and *eabihf do not apply on other arches.

Shall I prepare patches?
Comment 8 Paul Fertser 2018-09-26 21:06:53 UTC
James, rmprofile is meant for Cortex-M (microcontrollers) and Cortex-R (similar to Cortex-A but lacking MMU) devices. aprofile is meant for Cortex-A cores. GCC docs https://gcc.gnu.org/install/configure.html say that currently combining them both (with a comma, in a single --with-multilib-list option) sometimes produces suboptimal code but it's possible.
Comment 9 Eugene Bright 2018-09-26 22:12:04 UTC
Previously I meant that gcc build scripts (not eclasses) ignore `--with-float` option if multilib is enabled (my experiments support this statement). So guessing and passing of this option are meaningless. Combination of `--with-float` with `--with-multilib-list` explicitly causes compilation break and I see it as a hint to preventing such useless combining (the actual error message highlight more complete list of ignored flags).

It looks like we should not pass `--with-arch/cpu/fpu/float/mode` if multilib is ON regardless of nature of target (if it bare metal or not). So applying my patch as is (for all arm targets) sounds more reasonable for me.
Comment 10 Sergei Trofimovich (RETIRED) gentoo-dev 2018-09-26 22:42:41 UTC
(In reply to Eugene Bright from comment #9)
> Previously I meant that gcc build scripts (not eclasses) ignore
> `--with-float` option if multilib is enabled (my experiments support this
> statement). So guessing and passing of this option are meaningless.

Which ./configure flags did you do your experiment and how did you check the result? I'd like to reproduce it or find a counter example.

> It looks like we should not pass `--with-arch/cpu/fpu/float/mode` if
> multilib is ON regardless of nature of target (if it bare metal or not).

1. If you want to go that route you should change toolchain.eclass then, not tweak softfloat detection. But let's see how you came up with no-op conclusion.

2. Not passing cpu on normal targets will lower default instruction set to minimal available. It's not what Gentoo does today. microcontroller's multilibs are special in forcing their own arch and ABI flags.

> So applying my patch as is (for all arm targets) sounds more reasonable for me.

1. I think it is reasonable to force softfloat on *-softfloat-* targets. Be them multilib or not.

2. Your path assumes all callers have IUSE=multilib in scope. tc-is-softfloat() is a generic function and allowed to be called from any ebuild.
Comment 11 Eugene Bright 2018-09-27 21:05:48 UTC
I tested gcc compilation with and without my patch.
No EXTRA_ECONF, multilib is ON (multilib is also forced by crossdev).

Command `arm-none-eabi-gcc -print-multi-lib` showed the same results both times. Default multilib arm profile consist of hard float target as well as soft one regardless of presence of `--with-float` option.

This case, of course, doesn't prove anything. Further investigation of gcc building scripts is needed. I progress too slowly in this area.


> 1. I think it is reasonable to force softfloat on *-softfloat-* targets. Be them multilib or not.

Explicit is better then implicit. Silent ignoring of configuration options yields confusion.
It's better to break compilation when combination of *-softfloat-* target and multilib occurs. The error message must indicate diagnosed overwhelming user craziness IMHO.
Comment 12 Larry the Git Cow gentoo-dev 2018-09-27 22:26:40 UTC
The bug has been closed via the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=03138227aa0985a708bbb9ecf331baf06f75d5df

commit 03138227aa0985a708bbb9ecf331baf06f75d5df
Author:     Sergei Trofimovich <slyfox@gentoo.org>
AuthorDate: 2018-09-27 21:45:03 +0000
Commit:     Sergei Trofimovich <slyfox@gentoo.org>
CommitDate: 2018-09-27 22:26:32 +0000

    toolchain-funcs.eclass: softfloat detection, bug #666896
    
    commit 921cb9c10de4d237924a61a1c27f914dfb479a64
    "toolchain-funcs.eclass: Update tc-is-softfloat for new ARM tuples"
    changed autodetection of mst 'arm*' targets from from 'no'
    to 'yes'.
    
    It is incorrect at least for bare-metal targets that tend
    to pass their taget defaults.
    
    Bug #666896 is one example example command:
        # crossdev -s1 \
            --env 'EXTRA_ECONF="--with-multilib-list=rmprofile"' \
            arm-none-eabi
    
    rmprofile one of special cases for gcc as it explicitky does
    not myx with any arch-specific options and --with-float=soft
    breaks it:
    
        Error: You cannot use any of --with-arch/cpu/fpu/float/mode
        with --with-multilib-list=rmprofile
    
    The immediate fix is to restore initial autodetection for bare-metal
    targets.
    
    Reported-by: Eugene Bright
    Closes: https://bugs.gentoo.org/666896
    Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>

 eclass/toolchain-funcs.eclass | 7 +++++++
 1 file changed, 7 insertions(+)