[OE-core] [PATCHv3 5/6] feature-arm-vfp.inc: respect vfpv4 when setting -mfloat-abi and ARMPKGSFX_EABI

[Martin Jansa]

On Wed, Nov 18, 2015 at 07:37:21PM +0100, Martin Jansa wrote:
> * without this change it wasn't possible to use call-convention hard
>   together with vfpv4
> 
> Signed-off-by: Martin Jansa <Martin.Jansa at gmail.com>
> ---
>  meta/conf/machine/include/arm/feature-arm-vfp.inc | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/meta/conf/machine/include/arm/feature-arm-vfp.inc b/meta/conf/machine/include/arm/feature-arm-vfp.inc
> index e23d377..75c05fb 100644
> --- a/meta/conf/machine/include/arm/feature-arm-vfp.inc
> +++ b/meta/conf/machine/include/arm/feature-arm-vfp.inc
> @@ -13,5 +13,8 @@ TUNEVALID[vfpv4] = "Enable Vector Floating Point Version 4 (vfpv4) unit."
>  ARMPKGSFX_FPU .= "${@bb.utils.contains('TUNE_FEATURES', 'vfpv4', '-vfpv4', '' ,d)}"
>  
>  TUNEVALID[callconvention-hard] = "Enable EABI hard float call convention, requires VFP."
> -TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'vfp', bb.utils.contains('TUNE_FEATURES', 'callconvention-hard', ' -mfloat-abi=hard', ' -mfloat-abi=softfp', d), '' ,d)}"
> +TUNE_CCARGS .= "${@bb.utils.contains_any('TUNE_FEATURES', [ 'vfp', 'vfpv3d16', 'vfpv3', 'vfpv4' ], bb.utils.contains('TUNE_FEATURES', 'callconvention-hard', ' -mfloat-abi=hard', ' -mfloat-abi=softfp', d), '' ,d)}"
>  ARMPKGSFX_EABI .= "${@bb.utils.contains('TUNE_FEATURES', [ 'callconvention-hard', 'vfp' ], 'hf', '', d)}"
> +ARMPKGSFX_EABI .= "${@bb.utils.contains('TUNE_FEATURES', [ 'callconvention-hard', 'vfpv3d16' ], 'hf', '', d)}"
> +ARMPKGSFX_EABI .= "${@bb.utils.contains('TUNE_FEATURES', [ 'callconvention-hard', 'vfpv3' ], 'hf', '', d)}"
> +ARMPKGSFX_EABI .= "${@bb.utils.contains('TUNE_FEATURES', [ 'callconvention-hard', 'vfpv4' ], 'hf', '', d)}"

These last 4 lines should be normal assignment, otherwise the "hf"
suffix can be duplicated for tunes with multiple vfp* in TUNE_FEATURES

I've found 2 more issues (not caused by this patchset in cortexr4 tune)
and there are some issues in power6, power7, sh3 and supersparc tunes.

I'm using this script:
http://git.openembedded.org/openembedded-core-contrib/tree/scripts/tune/test.sh?h=jansa/tune2-test

to check that "bitbake -e openssl" works for every available DEFAULTTUNE
and stored log files are useful to see how the CC/CCARGS variables are
changing for each of them, you can see results in last commits in this
branch:
http://git.openembedded.org/openembedded-core-contrib/log/?h=jansa/tune2-test
http://git.openembedded.org/openembedded-core-contrib/tree/scripts/tune?h=jansa/tune2-test

http://git.openembedded.org/openembedded-core-contrib/tree/scripts/tune/log.fake-power6?h=jansa/tune2-test
http://git.openembedded.org/openembedded-core-contrib/tree/scripts/tune/log.fake-power7?h=jansa/tune2-test
http://git.openembedded.org/openembedded-core-contrib/tree/scripts/tune/log.fake-sh3?h=jansa/tune2-test
http://git.openembedded.org/openembedded-core-contrib/tree/scripts/tune/log.fake-supersparc?h=jansa/tune2-test

It's highly recommended to use the script together with memres bitbake,
the execution time is at least 10 times shorted, but the changes aren't
picked between runs, so make sure to restart bitbake after changing the
tunes.

I'll send updated patchset soon.

Regards,
-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20151207/42e2c229/attachment-0002.sig>