On Thu, Aug 14, 2014 at 2:15 AM, Peter A. Bigot <p...@pabigot.com> wrote:
> On 08/14/2014 12:32 AM, Khem Raj wrote:
>>
>> On Wed, Aug 13, 2014 at 6:55 PM, Peter A. Bigot <p...@pabigot.com> wrote:
>>>>
>>>> EXTRA_OECONF += '${@bb.utils.contains("TUNE_FEATURES", "armv7a",
>>>> "--with-cpu=generic-armv7-a", "", d)}'
>>>>
>>> Sorry a typo there you need --with-arch
>>>
>>>
>>> OK, that works. So do we need to do the same thing for every
>>> TUNE_FEATURES
>>> element that ends up changing the value of -march= in TUNE_CCARGS which
>>> ends
>>> up getting passed into gcc-runtime?
>>
>> Not really but arm v6+ is an exception here due to reasons explained
>> earlier. gcc as a target package is a bit
>> different than rest of them since it has mind of its own when it comes
>> to configuring it. It encodes certain
>> defaults into its driver etc. based on the configure parameters.
>> Ideally when we pass the flags via CFLAGS
>> it does it for most of packages but not for gcc.
>
>
> tl;dr: the proposed fix to gcc-target works for my example but I'm concerned
> it's a bandaid that doesn't address a more long-term risk.
>
> I understand gcc-target is different. I frame the issue as: bitbake (via
> toolchain-scripts.bbclass) ensures OE builds its applications with
> TARGET_CC_ARCH flags such as -march=FOO, but building gcc itself requires
> EXTRA_OECONF to pass different flags such as --with-arch=FOO which set the
> default behavior for the target compiler.
>
> There are actually a bunch of these gcc configuration options:
>
> --with-schedule=cpu
> --with-arch=cpu
> --with-arch-32=cpu
> --with-arch-64=cpu
> --with-tune=cpu
> --with-tune-32=cpu
> --with-tune-64=cpu
> --with-abi=abi
> --with-fpu=type
> --with-float=type
>
> all of which affect the default for the corresponding -m flags, and any of
> which may affect each other within gcc's configure script.
>
> It sounds like the intent is that the default behavior of the target gcc
> should match what bitbake is passing via TARGET_CC_ARCH. Of course, if that
> were guaranteed there wouldn't be any need for OE to apply TARGET_CC_ARCH at
> all, but I wouldn't suggest changing that.
>
> My concern is that gcc-runtime invokes configure in subdirectories of gcc's
> source tree, bypassing the top-level configure where some of the translation
> from (e.g.) --with-arch=FOO to -march=FOO is done. It then builds the
> libraries with TARGET_CC_ARCH flags appended to CC, CXX, and CPP.
>
> What this means is that the libraries built by gcc-runtime use
> TARGET_CC_ARCH settings that don't necessarily match the target compiler's
> defaults, and that ABI conflicts can result by linking in those libraries
> when the non-default settings were absent in non-OE application builds. ABI
> can only be "guaranteed" if every one of the -mFOO=BAR passed in
> TARGET_CC_ARCH (*or defaulted by the compiler*) has a corresponding
> -with-FOO=BAR option passed to (*or inferred by*) gcc's configure.
>
> That's a pretty strong assumption to make.
>
> It may be that this can be worked around for the specific case I raised by
> explicitly adding --with-arch=armv7-a to gcc-target's EXTRA_OECONF. I do
> have to wonder whether the same should be done for any of armv7 armv7-m
> armv7-r armv7e-m armv7ve armv8-a armv8-a+crc which are other -march options
> that are armv6+, and whether there are other ABI issues that might be hiding
> now or in the future because TARGET_CC_ARCH makes more assumptions than
> gcc-target does.
>
> The solution I propose is to rework gcc-runtime's override of CC/CXX/CPP so
> the libraries are built the same way they would be if they had been built
> during gcc-target.
>
we are actually pulling out the target runtime out of gut of gcc-cross
and then doing the match with target gcc
so as long as we make target gcc recipe confirm to this we are good. I
dont feel like we need to engineer a general solution here. Since what
we are addressing is an anamoly not norm. So lets keep it that way.
meaning patch it for arm where needed.
one day all < armv5 architectures will die out and we will be a happy
lot :) oh wait then aarch64-32 might spring another ABI concern who
knows
> From initial attempts this won't be easy to do. I'd be happy to keep trying
> if this worries other people, but if I'm being too picky I'll just suck it
> up and move on.
>
> Peter
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
