This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [PATCH 4/10, GAS/ARM] Rework selection of feature bits to base build attributes on
- From: "Richard Earnshaw (lists)" <Richard dot Earnshaw at arm dot com>
- To: Thomas Preudhomme <thomas dot preudhomme at foss dot arm dot com>, "binutils at sourceware dot org" <binutils at sourceware dot org>
- Date: Wed, 21 Jun 2017 14:48:43 +0100
- Subject: Re: [PATCH 4/10, GAS/ARM] Rework selection of feature bits to base build attributes on
- Authentication-results: sourceware.org; auth=none
- References: <e1ae3136-5d45-4816-1891-5fa779d7bc5f@foss.arm.com> <44704917-0a4a-f6ee-6704-12571b409aa6@foss.arm.com>
On 21/06/17 11:07, Thomas Preudhomme wrote:
> Hi,
>
> === Context ===
>
> This patch is part of a patch series to add support for ARMv8-R
> architecture. Its purpose is to set the feature bits on which to decide
> what the build attributes should be according to the mode
> (autodetection, user specified architecture or CPU, or
> -march/-mcpu=all).
>
> === Motivation ===
>
> Currently, the flags variable which is used to determine the build
> attribute is constructed from the instruction used (arm_arch_used and
> thumb_arch_used) as well as the user specified architecture or CPU
> (selected_cpu). This means when several .arch are specified the
> resulting feature bits can be such that no architecture provide them
> all and can thus result in incorrect Tag_CPU_arch. See for instance
> what having both .arch armv8-a and .arch armv8-m.base would result in.
> This is not caught by the testsuite because of further bugs in the
> Tag_CPU_arch build attribute value selection logic (see next patch in
> the series).
>
> === Patch description ===
>
> As one would expect, this patch solves the problem by setting flags
> from feature bits used if in autodetection mode [1] and from
> selected_cpu otherwise. The logic to set arm_ext_v1, arm_ext_v4t and
> arm_ext_os feature bits is also moved to only run in autodetection mode
> since otherwise the architecture or CPU would have a consistent set of
> feature bits already.
>
> [1] No architecture or CPU was specified by the user
>
> ChangeLog entry is as follows:
>
> *** gas/ChangeLog ***
>
> 2017-01-26 Thomas Preud'homme <thomas.preudhomme@arm.com>
>
> * config/tc-arm.c (aeabi_set_public_attributes): Populate flags from
> feature bits used or selected_cpu depending on whether a CPU was
> selected by the user.
>
> === Testing ===
>
> Testsuite shows no regression when run for arm-none-eabi targets.
>
> Is this ok for master branch?
>
OK.
R.
> Best regards,
>
> Thomas
>
> 04_rework_feature_bit_selection_logic.patch
>
>
> diff --git a/gas/config/tc-arm.c b/gas/config/tc-arm.c
> index 72fd1cc9854428577f1f98ab7703bf4dbdb9cbd5..530a27b1cc915846bcc208878925b60ccd003f6d 100644
> --- a/gas/config/tc-arm.c
> +++ b/gas/config/tc-arm.c
> @@ -26577,19 +26577,33 @@ aeabi_set_public_attributes (void)
> arm_feature_set arm_arch_v8m_base = ARM_ARCH_V8M_BASE;
> const cpu_arch_ver_table *p;
>
> - /* Choose the architecture based on the capabilities of the requested cpu
> - (if any) and/or the instructions actually used. */
> - ARM_MERGE_FEATURE_SETS (flags, arm_arch_used, thumb_arch_used);
> - ARM_MERGE_FEATURE_SETS (flags, flags, *mfpu_opt);
> - ARM_MERGE_FEATURE_SETS (flags, flags, selected_cpu);
> + /* Autodetection mode, choose the architecture based the instructions
> + actually used. */
> + if (no_cpu_selected ())
> + {
> + ARM_MERGE_FEATURE_SETS (flags, arm_arch_used, thumb_arch_used);
>
> - if (ARM_CPU_HAS_FEATURE (arm_arch_used, arm_arch_any))
> - ARM_MERGE_FEATURE_SETS (flags, flags, arm_ext_v1);
> + if (ARM_CPU_HAS_FEATURE (arm_arch_used, arm_arch_any))
> + ARM_MERGE_FEATURE_SETS (flags, flags, arm_ext_v1);
>
> - if (ARM_CPU_HAS_FEATURE (thumb_arch_used, arm_arch_any))
> - ARM_MERGE_FEATURE_SETS (flags, flags, arm_ext_v4t);
> + if (ARM_CPU_HAS_FEATURE (thumb_arch_used, arm_arch_any))
> + ARM_MERGE_FEATURE_SETS (flags, flags, arm_ext_v4t);
>
> - selected_cpu = flags;
> + /* We need to make sure that the attributes do not identify us as v6S-M
> + when the only v6S-M feature in use is the Operating System
> + Extensions. */
> + if (ARM_CPU_HAS_FEATURE (flags, arm_ext_os))
> + if (!ARM_CPU_HAS_FEATURE (flags, arm_arch_v6m_only))
> + ARM_CLEAR_FEATURE (flags, flags, arm_ext_os);
> +
> + /* Code run during relaxation relies on selected_cpu being set. */
> + selected_cpu = flags;
> + }
> + /* Otherwise, choose the architecture based on the capabilities of the
> + requested cpu. */
> + else
> + flags = selected_cpu;
> + ARM_MERGE_FEATURE_SETS (flags, flags, *mfpu_opt);
>
> /* Allow the user to override the reported architecture. */
> if (object_arch)
> @@ -26598,12 +26612,6 @@ aeabi_set_public_attributes (void)
> ARM_MERGE_FEATURE_SETS (flags, flags, *object_arch);
> }
>
> - /* We need to make sure that the attributes do not identify us as v6S-M
> - when the only v6S-M feature in use is the Operating System Extensions. */
> - if (ARM_CPU_HAS_FEATURE (flags, arm_ext_os))
> - if (!ARM_CPU_HAS_FEATURE (flags, arm_arch_v6m_only))
> - ARM_CLEAR_FEATURE (flags, flags, arm_ext_os);
> -
> tmp = flags;
> arch = 0;
> for (p = cpu_arch_ver; p->val; p++)
>