[PATCH, binutils] Update bfd's Tag_CPU_arch knowledge

[Thomas Preudhomme]

Hi,

BFD's bfd_get_mach () function returns a bfd specific value representing
the architecture of the target which is populated from the Tag_CPU_arch
build attribute value of that target. Among other users of that
interfacem, objdump which uses it to print the architecture version of
the binary being examinated and to decide what instruction is available
if run with "-m arm" via its own mapping from bfd_mach_arm_X values to
feature bits available.

However, both BFD and objdump's most recent known architecture is
Armv5TE. When encountering a newer architecture bfd_get_mach will return
bfd_mach_arm_unknown. This is unfortunate since objdump uses that value
to allow all instructions on all architectures which is already what it
does by default, making the "-m arm" trick useless.

This patch updates BFD and objdump's knowledge of Arm architecture
versions up to the latest Armv8-M Baseline and Mainline, Armv8-R and
Armv8.4-A architectures. Since several architecture versions (eg. 8.X-A)
share the same Tag_CPU_arch build attribute value and
bfd_mach_arm values, the mapping from bfd machine value to feature bits
need to return the most featureful feature bits that would yield the
given bfd machine value otherwise some instruction would not disassemble
under "-m arm" mode. The patch rework that mapping to make this clearer
and simplify writing the mapping rules. In particular, for simplicity
all FPU instructions are allowed in all cases.

Finally, the patch also rewrite the cpu_arch_ver table in GAS to use the
TAG_CPU_ARCH_X macros rather than hardcode their value.

ChangeLog entries are as follows:

*** bfd/ChangeLog ***

2018-02-26  Thomas Preud'homme  <thomas.preudhomme@arm.com>

	* archures.c (bfd_mach_arm_5TEJ, bfd_mach_arm_6, bfd_mach_arm_6KZ,
	bfd_mach_arm_6T2, bfd_mach_arm_6K, bfd_mach_arm_7, bfd_mach_arm_6M,
	bfd_mach_arm_6SM, bfd_mach_arm_7EM, bfd_mach_arm_8, bfd_mach_arm_8R,
	bfd_mach_arm_8M_BASE, bfd_mach_arm_8M_MAIN): Define.
	* bfd-in2.h: Regenerate.
	* cpu-arm.c (arch_info_struct): Add entries for above new
	bfd_mach_arm values.
	* elf32-arm.c (bfd_arm_get_mach_from_attributes): Add Tag_CPU_arch to
	bfd_mach_arm mapping logic for pre Armv4 and Armv5TEJ and later
	architectures.  Force assert failure for any new Tag_CPU_arch value.

*** gas/ChangeLog ***

2018-02-26  Thomas Preud'homme  <thomas.preudhomme@arm.com>

	* config/tc-arm.c (cpu_arch_ver): Use symbolic TAG_CPU_ARCH macros
	rather than hardcode their values.

*** opcodes/ChangeLog ***

2018-02-26  Thomas Preud'homme  <thomas.preudhomme@arm.com>

	* arm-dis.c (select_arm_features): Fix typo in heading comment.  Allow
	all FPU features and add mapping from new bfd_mach_arm values to
	allowed CPU feature bits.

*** ld/ChangeLog ***

2018-02-26  Thomas Preud'homme  <thomas.preudhomme@arm.com>

	* testsuite/ld-arm/tls-descrelax-be8.d: Add architecture version in
	expected result.
	* testsuite/ld-arm/tls-descrelax-v7.d: Likewise.
	* testsuite/ld-arm/tls-longplt-lib.d: Likewise.
	* testsuite/ld-arm/tls-longplt.d: Likewise.

Testing: Testsuite for arm-none-eabi targets shows no regression. Also
ran the testsuite with modified objdump to always use build attribute to
select which instructions are available and only the following test FAIL
expectedly:

* Group relocation tests (ldc)
   -> no CPU or FPU set before first batch of instructions

* ARM basic instructions
   -> fails because disassembly now correctly shows instructions as not
      UNPREDICTABLE since the test is compiled for arm7m CPU (Armv3M)

* NOP<c> instructions
* Upredictable Instructions
   -> no CPU or FPU set

* gas/arm/v4bx
* ARMv4 interworking
   -> incorrect disassembly of bx expected since test has .arch armv4
      directive but bx only available from v4t onwards

Is this ok for master?

Best regards,

Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: update_bfd_Tag_CPU_arch_knowledge.patch
Type: text/x-patch
Size: 17398 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/binutils/attachments/20180629/102050af/attachment.bin>