[PATCH][Binutils][AArch64] Implement choice between Cortex-A53 erratum workarounds. (PR ld/24373)

[Tamar Christina]

Hi All,

The Cortex-A53 erratum currently has two ways it can resolve the erratum when
using the flag --fix-cortex-a53-843419:

1) If the address is within the range of an ADR instruction it rewrites the ADRP
   into an ADR, and those doesn't need the use of a veneer.

2) If the address is not within range, it adds a branch to a veneer which will
   execute the final bit of the erratum workaround and branch back to the call
   site.

When we do this we always generate the veneers and we always align the size of
the text section to 4KB.  This is because we only know which workaround we can
use after all linking has finished and all addresses are known.  This means even
though the veneers are not used, we still generate the section and we still
change the size of the input section.

This is problematic for small memory devices as this would require the user to
take about a ~4KB hit in memory even though it's not even used.

Since there's no real way to restart the linking process from the final write
phase this patch solves the issue by allowing the user more control over which
erratum workaround gets used.

Concretely this changes the option --fix-cortex-a53-843419 to take optional
arguments --fix-cortex-a53-843419[=full|adr|adrp]

- full (default): Use both ADRP and ADR workaround. This is equivalent to not
		  specifying any options and is the default behavior before this
		  patch.

- adr: Only use the ADR workaround, this will not cause any increase in binary
       size but linking will fail if the referenced address is out of range of
       an ADR instruction.

- adrp: Use only the ADRP workaround, this will never rewrite your ADRP.

In the cases where the user knows how big their binaries are the `adr` option
would prevent the unneeded overhead.

build on native hardware and regtested on
  aarch64-none-elf, aarch64-none-elf (32 bit host),
  aarch64-none-linux-gnu, aarch64-none-linux-gnu (32 bit host)

Cross-compiled and regtested on
  aarch64-none-linux-gnu, aarch64_be-none-linux-gnu

and no issues.

Ok for master? Does this warrant a NEWS entry?

Thanks,
Tamar

bfd/ChangeLog:

2019-05-14  Tamar Christina  <tamar.christina@arm.com>

	PR ld/24373
	* bfd-in.h (enum erratum_84319_opts): New
	(bfd_elf64_aarch64_set_options, bfd_elf32_aarch64_set_options): Change
	int to enum erratum_84319_opts.
	* bfd-in2.h: Regenerate.
	* elfnn-aarch64.c (struct elf_aarch64_link_hash_table): Change
	fix_erratum_843419 to use new enum, remove fix_erratum_843419_adr.
	(_bfd_aarch64_add_stub_entry_after): Conditionally create erratum stub.
	(aarch64_size_one_stub): Conditionally size erratum 843419 stubs.
	(_bfd_aarch64_resize_stubs): Amend comment.
	(elfNN_aarch64_size_stubs): Don't generate stubs when no workaround
	requested.
	(bfd_elfNN_aarch64_set_options): Use new fix_erratum_843419 enum.
	(_bfd_aarch64_erratum_843419_branch_to_stub): Implement selection of
	erratum workaround.
	(clear_erratum_843419_entry): Update erratum conditional.

ld/ChangeLog:

2019-05-14  Tamar Christina  <tamar.christina@arm.com>

	PR ld/24373
	* emultempl/aarch64elf.em (PARSE_AND_LIST_LONGOPTS): Add optional args
	to flags.
	(PARSE_AND_LIST_OPTIONS): Update help descriptions.
	(PARSE_AND_LIST_ARGS_CASES): Add new options to parser.
	* testsuite/ld-aarch64/aarch64-elf.exp: Add new run_dump_tests.
	* testsuite/ld-aarch64/erratum843419-adr.d: New test.
	* testsuite/ld-aarch64/erratum843419-adrp.d: New test.
	* testsuite/ld-aarch64/erratum843419-far-adr.d: New test.
	* testsuite/ld-aarch64/erratum843419-far-full.d: New test.
	* testsuite/ld-aarch64/erratum843419-far.s: New test.
	* testsuite/ld-aarch64/erratum843419-full.d: New test.
	* testsuite/ld-aarch64/erratum843419-near.s: New test.
	* testsuite/ld-aarch64/erratum843419-no-args.d: New test.

-- 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rb11221.patch
Type: text/x-diff
Size: 20229 bytes
Desc: rb11221.patch
URL: <https://sourceware.org/pipermail/binutils/attachments/20190514/883fa53b/attachment.bin>