From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH v2 2/4] toolchain: add bfin support
Date: Sat, 28 May 2016 19:10:44 +0200 [thread overview]
Message-ID: <20160528191044.5d7919b7@free-electrons.com> (raw)
In-Reply-To: <20160528154229.GI22609@waldemar-brodkorb.de>
Hello,
On Sat, 28 May 2016 17:42:29 +0200, Waldemar Brodkorb wrote:
> > > -config BR2_GCC_TARGET_CPU
> > > +config BR2_TARGET_CPU
> >
> > This seems wrong. Why are you doing this?
>
> In the first patch I disabled --with-cpu for gcc and bfin, as gcc
> does not support --with-cpu on bfin. You could use
> -mcpu=$(BR2_TARGET_CPU) to optimize code for a specific Bfin CPU,
> that is the reason the second version of the patch renamed
> the config symbols for a later use.
Hum, this is really annoying. All the internal toolchain backend of
Buildroot is based on the assumption that the gcc configure options
--with-arch, --with-cpu, --with-float, --with-fpu and --with-abi allow
to specify the default values for -march, -mcpu, -mfloat, -mfpu and
-mabi. For this reason, we pass the values at gcc configure time, but
then afterwards we don't pass any mcpu/mfloat/march/... values when
building packages, because gcc is supposed to generate by default code
for the selected arch/cpu.
It seems like Blackfin violates this assumption, and it will require a
bit more work than the patch you're submitting to make things working.
It seems like we need to distinguish the cases where the arch/cpu/etc.
can be defined at gcc configure time from the cases where it cannot.
According to the gcc installation documentation
(https://gcc.gnu.org/install/configure.html) :
"""
--with-cpu=cpu
--with-cpu-32=cpu
--with-cpu-64=cpu
Specify which cpu variant the compiler should generate code for by
default. cpu will be used as the default value of the -mcpu= switch.
This option is only supported on some targets, including ARC, ARM,
i386, M68k, PowerPC, and SPARC. It is mandatory for ARC. The
--with-cpu-32 and --with-cpu-64 options specify separate default CPUs
for 32-bit and 64-bit modes; these options are only supported for
i386, x86-64 and PowerPC.
"""
So indeed, there is no guarantee that --with-cpu is supported on all
architectures.
> > At the very least, it needs to be explained in the commit log,
> > including the impact on the Blackfin external toolchain support.
>
> I thought it has no impact on the external toolchain.
> Is BR2_GCC_TARGET_CPU used in any way for external toolchains?
It is, yes. See toolchain-external.mk:
ifeq ($(call qstrip,$(BR2_GCC_TARGET_CPU_REVISION)),)
CC_TARGET_CPU_ := $(call qstrip,$(BR2_GCC_TARGET_CPU))
else
CC_TARGET_CPU_ := $(call qstrip,$(BR2_GCC_TARGET_CPU)-$(BR2_GCC_TARGET_CPU_REVISION))
endif
ifneq ($(CC_TARGET_CPU_),)
TOOLCHAIN_EXTERNAL_CFLAGS += -mcpu=$(CC_TARGET_CPU_)
TOOLCHAIN_EXTERNAL_TOOLCHAIN_WRAPPER_ARGS += -DBR_CPU='"$(CC_TARGET_CPU_)"'
endif
And then in the toolchain wrapper:
#ifdef BR_CPU
*cur++ = "-mcpu=" BR_CPU;
#endif
This logic ensures that the value of BR2_GCC_TARGET_CPU is always
passed as -mcpu by the toolchain wrapper.
Since the toolchain wrapper is also used for the internal toolchain, we
can re-use the same strategy to hardcode the mcpu value.
> So how we go further with the internal Bfin toolchain stuff?
The easiest option by far is to have a per-architecture hidden
Config.in boolean option that says whether the arch/mcpu/etc. options
should be set at gcc configure time or not. If it's set to "y", then we
do like we do today. If it's not set to "y", then the logic to build
the toolchain wrapper for the internal toolchain case should be
modified to pass -mcpu/-mabi/-mfloat/etc.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
prev parent reply other threads:[~2016-05-28 17:10 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-13 12:15 [Buildroot] [PATCH v2 2/4] toolchain: add bfin support Waldemar Brodkorb
2016-05-28 13:33 ` Thomas Petazzoni
2016-05-28 15:42 ` Waldemar Brodkorb
2016-05-28 17:10 ` Thomas Petazzoni [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160528191044.5d7919b7@free-electrons.com \
--to=thomas.petazzoni@free-electrons.com \
--cc=buildroot@busybox.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox