[PATCH 2/10, GAS/ARM] Keep separation between extensions and architecture bits throughout execution

Thomas Preudhomme thomas.preudhomme@foss.arm.com
Wed Jun 21 10:04:00 GMT 2017


Hi,

=== Context ===

This patch is part of a patch series to add support for ARMv8-R
architecture. Its purpose is to keep the distinction between
architecture feature bits and extension ones after parsing has occured.

=== Motivation ===

This distinction is necessary to allow the Tag_CPU_arch build attribute
value to be exactly as per the architecture of the selected CPU. With
mixed architecture and extension feature bit, it is impossible to find
an architecture with an exact match of feature bit and the build
attribute value logic must then select the closest match which might not
be the right architecture. The previous patch in the patch series makes
the distinction possible when parsing -mcpu and .cpu directives but the
distinction gets lost after. Similarly feature bits contributed by
extensions in -march or .arch_extensions directive are mixed together
with architecture extensions.

=== Patch description ===

The patch adds new feature bit pointer for extension feature bits.
Information from the parsing regarding extensions can then be kept
separate in those. This requires adapting arm_parse_extension to deal
with two feature bits, allowing the architecture bits to be marked as
const. It also requires extra care when setting cpu_variant and
selected_cpu because the extension bits are optional since there might
not be any extension in use.

Note that contrary to cpu feature bits, the extension feature bits are
made read/write and are always dynamically allocated. This allows to
unconditionally free them in arm_md_post_relax added for this occasion,
thereby fixing a longstanding memory leak when arm_parse_extension was
invoked (XNEW of ext_fset without corresponding XDELETE).
Introduction of arm_md_post_relax is necessary to only free the
extension feature bits after aeabi_set_attribute_string has been called
for the last time.

ChangeLog entry is as follows:

*** gas/ChangeLog ***

2017-03-24  Thomas Preud'homme  <thomas.preudhomme@arm.com>

	* config/tc-arm.c (dyn_mcpu_ext_opt): New static variable.
	(dyn_march_ext_opt): Likewise.
	(md_begin): Copy extension feature bits alongside architecture ones.
	Merge extensions feature bits in selected_cpu and cpu_variant if there
	is some.
	(arm_parse_extension): Pass architecture and extension feature bits in
	separate parameters, with architecture bits being read only.  Update
	**opt_p directly rather than *ext_set and initialize it if needed.
	(arm_parse_cpu): Stop merging architecture and extension feature bits
	and instead use mcpu_cpu_opt and dyn_mcpu_ext_opt to memorize them
	respectively.  Adapt to change in parameters of arm_parse_extension.
	(arm_parse_arch): Adapt to change in parameters of arm_parse_extension.
	(aeabi_set_attribute_string): Make function static.
	(arm_md_post_relax): New function.
	(s_arm_cpu): Stop merging architecture and extension feature bits and
	instead use mcpu_cpu_opt and dyn_mcpu_ext_opt to memorize them
	respectively.  Merge extension feature bits in cpu_variant
	if there is any.
	(s_arm_arch): Reset extension feature bit.  Set selected_cpu from
	*mcpu_cpu_opt and cpu_variant from selected_cpu and *mfpu_opt for
	consistency with s_arm_cpu.
	(s_arm_arch_extension): Update *dyn_mcpu_ext_opt rather than
	selected_cpu, allocating it before hand if needed.  Set selected_cpu
	from it and then cpu_variant.
	(s_arm_fpu): Merge *mcpu_ext_opt feature bits if any in cpu_variant.
	* config/tc-arm.h (md_post_relax_hook): Set to arm_md_post_relax.
	(aeabi_set_public_attributes): Delete external declaration.
	(arm_md_post_relax): Declare externally.

=== Testing ===

Testsuite shows no regression when run for arm-none-eabi targets.

Is this ok for master branch?

Best regards,

Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 02_keep_extensions_architectures_separate.patch
Type: text/x-patch
Size: 8791 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/binutils/attachments/20170621/288aceee/attachment.bin>


More information about the Binutils mailing list