RISC-V: Handle capability return values.

Add simple handling of capability function arguments (also used for
return values) and update riscv_return_value to propagate tags.

Set is_tagged and FLAG_CAPABILITY in arch_capability/pointer_type.

Set tagged and FLAG_CAPABILITY on C++ reference types.

make_pointer_type: Set TYPE_INSTANCE_FLAG_CAPABILITY on cap pointers.

For purecap this isn't always set by DWARF attributes, and in particular
it isn't for CHERI-RISC-V.

gdb tdesc: Handle mismatched pointer register types.

In the XML target descriptions, registers can be given a type of
"code_ptr" or "data_ptr".  GDB always uses the builtin type for "void
*" for these registers.  However, this is wrong if the register's size
does not match (e.g. the legacy "sp" and "pc" ARM64 registers when
using a purecap binary for which "void *" is a capability).  If the
sizes don't match, try to find a matching type such as "long" or
"intcap_t" to use instead.

CHERI-RISC-V: Improve handling of hybrid binaries.

- Add CHERI to the RISC-V ISA features if an ELF file contains the
  "xcheri" attribute.  This is set in both hybrid and purecap
  ELF files.  This isn't needed for purecap ELF files but does enable
  capability types and the "__capability" keyword on hybrid
  binaries and libraries.

- Add address_class gdbarch methods so that capability pointer types
  are tagged as capabilities in hybrid binaries.  This is a bit gross.
  Ideally riscv_address_class_type_flags would only enable the
  TYPE_INSTANCE_FLAG_CAPABILITY if the passed in byte_size (from
  DW_ATTR_byte_size) was equal to riscv_isa_clen() (aka
  gdbarch_capability_bit()).  However, for some reason this gdbarch
  method doesn't take the gdbarch member.  For now, rely on the fact
  that it is only called if either there is a DW_ATTR_address_space
  attribute on a pointer, or if the byte_size doesn't match the
  default pointer size.  Assuming there is no DW_ATTR_address_space
  defined for RISC-V yet, this means it should only be called for a
  size mismatch, and since we don't allow creating integer pointers in
  purecap, this means it can only be called for capability pointers
  for hybrid binaries.

CHERI-RISC-V: Support for displaying capability attributes.

This supports both the compact format (always used for annotating
pointer variables) and the verbose format (available via set print
compact-capabilities off) when displaying individual capabilities.

git subrepo clone https://github.com/CTSRD-CHERI/cheri-compressed-cap gdb/cheri-compressed-cap

subrepo:
  subdir:   "gdb/cheri-compressed-cap"
  merged:   "6762a19ba9f"
upstream:
  origin:   "https://github.com/CTSRD-CHERI/cheri-compressed-cap"
  branch:   "master"
  commit:   "6762a19ba9f"
git-subrepo:
  version:  "0.4.3"
  origin:   "???"
  commit:   "???"

Native support for FreeBSD CHERI-RISC-V.

bfd/binutils: Support for CHERI-RISC-V memory tag segments.

Add FreeBSD support for CHERI-RISC-V.

- Register maps and sets for the capability register set and support
  for them in core dumps.

- A CheriABI signal frame unwinder.

- Support CheriABI when fetching the address of TLS variables.

- Extend fbsd_report_signal_info for CHERI exceptions to give the
  name of the relevant capability register.

riscv-tdep: Export riscv_features_from_bfd.

fbsd-tdep: Export fbsd_report_signal_info.

Don't call tag_map_regno twice for each index.

Handle JALR.CAP in riscv_next_pc().

This fixes stepping into some functions in purecap.

CHERI-RISC-V: Add basic hybrid and purecap support.

Add basic CHERI-RISC-V support including CHERI registers.

Co-authored-by: John Baldwin <jhb@FreeBSD.org>

Add RISC-V CHERI register xml files

Co-authored-by: John Baldwin <jhb@FreeBSD.org>

Support for disassembling CHERI-RISC-V capmode instructions.

Add a separate table of capmode instructions and change
riscv_disassemble_insn to look for a match in this table first when
using capmode.  If a match isn't found, fall back to the normal table.

Capmode is currently enabled for any ELF file which has the capmode
flag set in the ELF header flags.

Initial support for disassembling CHERI-RISC-V instructions.

This does not yet handle capability mode.

riscv_parsing_subset_version: Handle "0p0" version strings.

Use a boolean to determine if a version is present (similar to
what is done in riscv_parse_prefixed_ext) rather than assuming
that both versions set to 0 means no version was present.

This fixes parsing of an attribute string of
"rv64i2p0_m2p0_a2p0_f2p0_d2p0_c2p0_xcheri0p0" which previously failed
with the error:

BFD: x ISA extension `xcheri' must be set with the versions

Add CHERI-RISC-V ELF header flags.

corelow: Implement the target read_capability method.

This locates the relevant memtag.cheri section to fetch the tag and
uses target_read_memory to fetch the rest of the capability's
contents.

get_next_core_memtag_section: Accept section name as an argument.

This permits callers to search for other memory tag section types.

Retire gdbarch_get/set_cap_tag_from_address.

These methods are no longer used as core GDB code now reads and
writes capabilities atomically.

bfd/binutils: Handle Morello memory tag core dump segments.

This is similar to the support for MTE core dump segments.

Don't treat *intcap_t as pointers.

TYPE_CODE_CAPABILITY is used for intcap_t and uintcap_t, whereas
capability-sized pointers use TYPE_CODE_PTR with the TYPE_CAPABILITY
flag.  This avoids trying to indirect scalar capability values in
some places.  Cosmetically it stops the output of the '(intcap_t)'
prefixes in front of capability values.

value_fetch_lazy_memory: Fetch tags for *intcap_t as well.

uintcap_t/intcap_t types don't have TYPE_CAPABILITY set, only pointer
types have this flag set.

value_primitive_field: Always mark capabilities lazy.

value_primitive_field copies the subrange of a non-lazy value into
the new value for a subobject.  However, the value of outer objects
never contain tags.  Instead, always mark new values as lazy if they
are a capability or are a structure containing a capability member.

eXamine: Update to support capabilities.

- For the address ('a') size, pick a suitable size corresponding to
  ptraddr_t for pure capability ABIs.

- Add a new 'C' size flag that prints memory as capabilities, either in
  the default compact format, or as hex via 'x'.  The hex format does not
  yet include tags.

Use PIOD_READ_CHERI_CAP to read memory capabilities from running processes.

x: Print CHERI memory tags using a similar format to MTE.

Default gdbarch_capability_bit to 0, not ptr_bit.

This allows testing for 0 to distinguish architectures without
capabilities.  Make use of this to only add in builtin types for
architectures which support capabilities.

Write memory capabilities atomically.

Use target_write_capability to write a capability atomically in
put_frame_register.

Read memory capabilities atomically.

When resolving a lazy memory capability value, use
target_read_capability to read the entire capability directly rather
than only using it to read the tag.  Also, just use
target_read_capability directly without requiring a gdbarch wrapper
method.

Copy ELF header flags from executable to core file.

Add a 'set program-interpreter' command.

This is a bit of a hack, but it allows you to override the initial
path to the runtime linker instead of having GDB always trust the
contents of .interp.  This is useful for running purecap binaries
under a hybrid world or vice versa via 'run'.

aarch64-fbsd-nat: Support the capability register set for Morello.

aarch64-fbsd: Use a static regset for the TLS register set.

This uses custom collect/supply regset handlers which pass the TLS
register number from the gdbarch_tdep as the base register number.

fbsd-nat: Add a have_register_set helper function.

This is similar to have_regset but is used for older register sets that
pre-date PT_GETREGSET and use separate fetch and store ptrace operations.

Elide "__capability" modifier for purecap ABIs.

capability: Don't print redundant "sealed" for sentries.

Morello: Add gdbarch_print_cap* methods.

Add capability::metadata_str.

This returns a string of just the metadata for a capability.

capability::to_str uses this method when outputting the compact form.

Use gdbarch_print_cap* methods when printing capabilities.

For pointers, use gdbarch_print_cap_attributes after printing the
pointer's address normally.

For printing a raw capability, use gdbarch_print_cap.

I removed the fetch of the tag from memory explicitly in
generic_value_print_capability as it should already be fetched for
memory values in value_fetch_lazy_memory.

Add gdbarch methods for printing capabilities.

gdbarch_print_cap prints a full capability in either verbose or
compat forms.

gdbarch_print_cap_attributes prints just the metadata such as bounds
and permissions of a capability without the address.

Morello: CheriBSD architecture support.

- Register set for NT_CAPREGS.

- Signal frame unwinder.

- Use CTPIDR instead of TPIDR to find the TCB for purecap when
  resolving TLS variables.

frame_unwind_register_unsigned: Return address from capabilities.

Make 'info sharedlibrary' more readable with CHERI.

In particular, use the smaller of address or pointer bit count to determine
the size of the address field.

Update solib*.c to work with CHERI capabilities.

- Treat dyn_ptr members of .dynamic entries as addresses rather than
  pointers.

- Don't truncate pointers in svr4_truncate_ptr() if the pointer size is
  larger than a CORE_ADDR as the truncation effectively sets them to
  zero in this case.  This should perhaps be using
  gdbarch_integer_to_address() instead of it's own explicit truncation
  anyway.

Morello: Set gdbarch_ptr_bit to 128 for purecap.

fbsd-tdep: Add a custom AUXV parser.

This returns the address of the entries that pass pointers rather
than the first N bytes of the capability.

fbsd-tdep: Report MI details for CHERI signals.

Add support for siginfo with CHERI.

- Add siginfo sizes and offsets to support $_siginfo in core dumps.
- Align the si_addr and si_value fields in siginfo which fixes the
  layout of $_siginfo for CHERI.
- Add the new si_capreg field for SIGPROT to the siginfo type.
- Support CHERI siginfo in the live FreeBSD target.

Teach GDB about SIGPROT.

Recognize capreg note and add a psuedo-section for GDB to find.

trad_frame_set_reg_regmap: Permit a non-zero register base.

Similar to the register base used with
regcache::collect/supply_regset, this value is added to the register
number in valid register map entries.

value_fetch_lazy_register: Copy tag from fetched register value.

Morello Linux: Use cap register number macros in regmap.

Morello: Add macros for cap registers that accept a base register.

Morello: Initialize morello_capability_pseudo_type to nullptr.

remote: Assume tagged registers supply tag in a leading byte.

aarch64-linux: Use tag_map to populate register tags in the regcache.

fbsd-nat: Pass an optional register base to the register set helpers.

This is needed to permit using the helpers for register sets with a
variable base.  In particular regnum needs to be converted into a
relative register number before passed to regcache_map_supplies.

fbsd-nat: Use regset supply/collect methods.

fbsd-nat includes various helper routines for fetching and storing
register sets via ptrace where the register set is described by a
regset.  These helper routines directly invoke the
supply/collect_regset regcache methods which doesn't permit a regset
to provide custom logic when fetching or storing a register set.
Instead, just use the function pointers from the struct regset
directly.

regcache: Add collect/supply_regset variants that accept a register base.

Some register sets described by an array of regcache_map_entry
structures do not have fixed register numbers in their associated
architecture but do describe a block of registers whose numbers are at
fixed offsets relative to some base register value.  An example of
this are the TLS register sets for the ARM and AArch64 architectures.

Currently OS-specific architectures create register maps and register
sets dynamically using the register base number.  However, this
requires duplicating the code to create the register map and register
set.  To reduce duplication, add variants of the collect_regset and
supply_regset regcache methods which accept a base register number.
For valid register map entries (i.e. not REGCACHE_MAP_SKIP), add this
base register number to the value from the map entry to determine the
final register number.

morello: Remove the tag_map register.

gdbarch: Remove method for register tags.

This functionality is now provided by regcache register tags.

aarch64-tdep: Update for register tags in regcache.

regcache: Add support for register tags.

If a register's type is tagged, then allocate a byte in the register
cache buffer to hold the tag.  Separate methods are provided for
supplying and collecting the tag as a bool.

struct type: Add TYPE_TAGGED property on types.

Set this property on capability types and capability-sized pointer
types.

make_capability_type: Use gdbarch_capability_bit to set size.

Add CPSR C64 bit (26)

Teach Morello GDB about bit 26 (C64), which shows if we have C64
execution state enabled or disabled.

Make various linker tests more robust

Various linker tests have been failing on aarch64-none-linux-gnu for a
while now.  We've ignored their failure since we knew they were from us
writing the tests with hard-coded values based on the aarch64-none-elf
toolchain.

A while ago we introduced a record/check feature in the testsuite that
has allowed re-writing some tests in a more general manner.  This commit
adjusts the remaining tests using this new feature.

While updating these remaining tests we also changed the record/check
feature to replace *all* occurrences of a `check` pattern in the line we
want to use.  This seems like what would be the expected behaviour,
although we did not actually need that change in this commit.

Only one testcase was slightly tricky to generalise.

This was the `morello-pcc-bounds-include-readonly` testcase.  We wanted
to ensure that the `othersection` was included in PCC bounds, but that
othersection was usually not the last RO section.  Since it was usually
not the last RO section we could not calculate the bounds that should be
given to our capability.

When using hard-coded addresses this was fine since we could just ensure
that the hard-coded address was large enough to span .othersection.
The record/check functionality does not allow checking that a value is
acceptable (i.e. the "check" part does not pass the values we see to
some procedure).  Rather it generates a value that the line should
match.

Hence in order to make this particular test general we emitted the
section headers, found the last read-only section, then asserted that
the size of the capability with executable permissions spanned up to the
end of that section.

The method by which we find the last read-only section could change
between different targets, but it at least works on both
aarch64-none-elf and aarch64-none-linux.

Add linker tests for TLS changes

This includes:
  - New tests for the new functionality for Morello TLS.
  - Adding target check for `-shared` to Morello tests that require
    a target that supports shared libraries.
  - Tests to ensure the extra error-checking emits errors when needed.
  - New tests for the new relocations defined for Morello TLS.
  - Some fixups for existing tests that don't seem like they deserve a
    separate commit.

Notes about some changes that seem like they require it:

tlsle-symbol-offset testcase:
  Do not use `-shared` as a linker argument.
  This testcase is checking for Local-Exec relocations, using these
  relocations in a shared library is simply not valid.  AFAICS there's
  no need for the `-shared` flag in this testcase, since it's just there
  to check that the tls LE relocations accept an addend.

  This was working before since we did not error on such things, but
  with the extra hardening that I've added we are now erroring on them.

morello-sec-start_stop-round testcase:
  We were originally searching for a specific __data_start symbol
  marking the start of the data section.  This was not part of what we
  actually wanted to test, and the symbol which was printed was
  different on aarch64-none-linux-gnu.  Hence we change our regex to
  search for any symbol to allow the test to pass on both targets.

morello-tlsie-overflow testcase:
  This testcase adds some padding in the .text section so that the GOT
  is very far away from the relocation which attempts to access it.
  This means that the relocation can not be satisfied and we can check
  for the resulting error message.

Extra error checking around TLS relocations

We add the following extra error checking:
  1) That TLS relocations (including SIZE relocations, but excluding
     Local-Exec relocations) are not requested against a symbol plus
     addend.
  2) That SIZE relocations are requested against a defined symbol in the
     current binary (i.e. one that the static linker knows the size of).
  3) A TLS Local-Exec relocation must be against a symbol in the current
     binary.

All the above also have error messages that describe the problem so that
the user could fix it.

Treating a relocation against a "symbol plus addend" as an error is due
to a combination of factors.
  - The linker implementation does not have any way to represent a GOT
    entry of "symbol plus addend".  Hence we currently just have silent
    bugs if asked to implement those relocations which require a GOT
    entry if they have a "symbol plus addend" relocation.
  - It would be wasteful anyway to have multiple entries in the GOT for
    e.g. sym+off1, sym+off2.
  - Morello size relocations don't support "symbol plus addend" since
    the meaning would have to be defined (is this the *remaining* size
    of the symbol?) and there is no known use for this.

We allow local-exec relocation on "symbol plus addend" since then the
addend just implements an offset into the object we're accessing (rather
than a new GOT entry for the location of "symbol plus addend").
There is also an existing testcase in the BFD linker to allow such
relocations.  The compiler can always avoid emitting these if it wants.

Notes on implementation:
  - We choose to check errors in final_link_relocate rather than
    check_relocs since this is where most existing error checking is
    done.
  - We check for errors around addends in relocate_section rather than
    final_link_relocate or check_relocs since final_link_relocate does
    not get told the *original* relocation (before TLS relaxation) and
    check_relocs does not know about addends coming from the result of
    previous relocations on the same code.
    N.b. in order to emit multiple errors when there are multiple
    relocations with an addend we change things in relocate_section to
    store a "return value" in a local variable and set it to false if
    any problem was seen but not return early.

Remove layout_sections_again argument to size_stubs

This was originally the first place that a function in
bfd/elfnn-aarch64.c was given a reference to
gldaarch64_layout_sections_again, and hence was the natural place to
store the function onto the elf hash table.

Ever since the introduction of elfNN_c64_resize_sections we have been
performing this operation in that function before this size_stubs
function.

Hence it seems sensible to remove the argument and now superfluous
operation from elfNN_aarch64_size_stubs.

Implement Morello TLS relaxations

The majority of the code change here is around TLS data stubs.  The new
TLS ABI requires that when relaxing a General Dynamic or Initial Exec
access to a variable to a Local Exec access, the linker emits data stubs
in a read-only section.

We do this with the below approach:
  - check_relocs notices that we need TLS data stubs by recognising that
    some relocation will need to be relaxed to a local-exec relocation.
  - check_relocs then records a hash table entry mapping the symbol that
    we are relocating against to a position in some data stub section.
    It also ensures that this data stub section has been created, and
    increments our data stub section size.
  - This section is placed in the resulting binary using the standard
    subsection and wildcard matching implemented by the generic linker.
  - In elfNN_aarch64_size_dynamic_sections we allocate the actual buffer
    for our data stub section.
  - When it comes to actually relaxing the TLS sequence,
    relocate_section directly populates the data stub using the address
    and size of the TLS object that has already been calculated, it then
    uses final_link_relocate to handle adjusting the text so that it
    points to this data stub.

Notes on implementation:

Mechanism by which we create and populate a TLS data section:
  There are currently three different ways by which the AArch64 backend
  creates and populates a special section.  These are
    - The method by which the .got (and related sections) are populated.
    - The method by which the interworking stubs are populated.
    - The method by which erratum 843419 stub sections are populated.

  We have gone with an approach that mostly follows that used to
  populate the .got.  Here we give an outline of the approaches and
  provide the reasoning by which the approach used by the .got was
  chosen.

  Handling the .got section:
  - Create a section on an existing BFD.
  - Mark that section as SEC_LINKER_CREATED.
  - Record the existing BFD as the `dynobj`.
  - bfd_elf_final_link still calls elf_link_input_bfd on the object.
  - elf_link_input_bfd avoids emitting the section (because of
    SEC_LINKER_CREATED).
  - bfd_elf_final_link then emits the special sections on `dynobj` after
    all the non-special sections on all objects have been relocated.
  - Allows updating the .got input section in relocate_section &
    final_link_relocate knowing that its contents will be output once all
    relocations on standard input sections have been processed.

   Handling interworking stub sections.
   - Create a special stub file.
   - Create sections on that stub file for each input section we need a
     stub for.
   - Manually populate the sections in build_stubs (which is called
     through `ldemul_finish` *before* `ldwrite` and hence before any
     other files are relocated).

   Handling erratum 843419 stub sections.
   - Create a special stub file.
   - Create sections on that stub file for each input section we need a
     stub for.
   - Ensure that the stub file is marked with class ELFCLASSNONE.
   - Ensure that the list of input sections for the relevant output
     section statement has the veneered input section *directly before*
     the stub section which has the veneer.
   - When relocating and outputting sections, having ELFCLASSNONE means
     that we output sections on the stub_file only when we see the
     corresponding input statement.  Without that class marker
     bfd_elf_final_link calls elf_link_input_bfd which writes out the
     data for all input sections on the relevant BFD.
   - Since we have ensured the input statement for our stub section is
     directly after the input statement for the section we are emitting
     veneers for, we know that the veneered section will be relocated
     and output before we output our stub section.
   - Hence we can copy relocated data from the veneered section into our
     stub section and know that our stub section will be output after
     this modification has been made.

  In deciding what to do with the read-only TLS data stubs we noticed
  the following problems with each approach:
  - The ABI requires that the read-only TLS data stubs are emitted into
    a read-only section.  This will necessarily be a different output
    section to .text where the requirement for these stubs is found.
    The temporal order in which output sections are written to the
    output file is tied to the order in which the in-memory linker
    statements are kept, and that is tied to the linker script provided
    by the user.  Hence we can not rely on ordering and ELFCLASSNONE to
    ensure that our data stub section is emitted after the relevant TLS
    sequences have been relaxed.  (We need to know our data stub section
    is written to the output after we have populated it as otherwise the
    data would not propagate to the resulting binary).
  - I think it is easier and simpler to find the data needed for the TLS
    data stubs in relocate_section just as we relax the relevant TLS
    sequences.  Hence I don't want to use the approach used for
    interworking stubs of populating the entire section beforehand.
  - Adding a section to `dynobj` would mean that we're adding a section
    to a user input BFD, which is not quite as clear as having a
    separate BFD for our special stub section.  It also means we treat
    this particular section as a "dynamic" section.  This is a little
    confusing nomenclature-wise.

  Based on the above trade-offs we chose the .got approach (accepting
  the negative that this will be stored on a user BFD).  N.b. using the
  .got approach and requiring the section get allocated in
  `size_dynamic_sections` is not problematic for static executables
  despite the nomenclature.  This function always gets called.

  One difference between how we handle the data stubs and how the .got
  is handled is that we do not count the number of data stubs required
  in size_dynamic_sections, but rather total it as we see relocations
  needing these stubs in check_relocs.
  We do this largely to avoid requiring another data member on all
  symbols to indicate information about whether this symbol needs a data
  stub and where that data stub is.  The number of TLS symbols are
  expected to be much smaller than the number of symbols with an entry
  in the GOT and hence a separate hash table just containing entries for
  those symbols which need such information is likely to often be
  smaller.

  N.b. it is interesting to mention that for all relocations which need
  a data stub we would make an input section on `dynobj` in
  `check_relocs` if that relaxation were not performed.  This is since
  if we did not realise they could be relaxed these relocations would
  have needed a .got entry.

  N.b. we must use make_section_anyway to create our TLS data stubs
  section in order to avoid any problems with our linker defined section
  having the same name as a section already defined by the user.

We do not use local stub symbols:
  The TLS ABI describes data stubs using specially named symbols.  These
  are not part of the ABI.  We could have associated the position of a
  data stub with a particular symbol by generating a symbol internally
  using some name mangling scheme that matches that in the TLS ABI
  examples and points to the data stub for a particular symbol.  We take
  the current approach on the belief that it is "neater" to avoid
  relying on such a name-mangling scheme and the associated sprintf
  calls.

final_link_relocate handling the adjusted relocation for data stubs:
  final_link_relocate does not actually use the `h` or `sym` arguments
  to decide anything for the two relocations we need to handle once we
  have relaxed an IE or GD TLS access sequence to a LE one.

  The relocations we need are BFD_RELOC_MORELLO_ADR_HI20_PCREL and
  BFD_RELOC_AARCH64_ADD_LO12.  For both (and in fact for most
  relocations) we only use `h` and `sym` for catching and reporting
  errors.

  This means we don't actually have to update the `h` and/or `sym`
  variables before calling elfNN_aarch64_final_link_relocate.

Allocate TLS data stubs on dynobj
  This uses the same approach that the linker uses to ensure that the
  .got sections are emitted after all relocations have been processed.

  elf_link_input_bfd avoids sections with SEC_LINKER_CREATED, and
  bfd_elf_final_link emits all SEC_LINKER_CREATED sections on the dynobj
  *after* standard sections have been relocated.

  This means that we can populate the contents of the TLS data stub
  section while performing relocations on all our other sections (i.e.
  in the same place as we perform the relaxations on the TLS sequences
  that we recognise need these data stubs).

Assert that copy_indirect_symbol is not a problem
  copy_indirect_symbol takes information from one symbol and puts it
  onto another.  The point is to ensure that any symbol which simply
  refers to another has all its cached information on that symbol to
  which it refers rather than itself.  If we could ever call this
  function on a symbol which we have found needs an associated data stub
  created, then we could have to handle adjusting the hash table
  associating a symbol with a data stub.  We do not believe this is
  needed, and add an assert instead.

  The proof that this is not a problem is a little tricky.  However it
  *shouldn't* be a problem given what it's handling.  This is handling
  moving cached information from an indirected symbol to the symbol it
  represents.  That is needed when the information was originally put on
  the indirected symbol, and that happens when the indirection was
  originally the other way around.  The two ways that this reversal of
  indirection can happen is through resolving dynamic weak symbols and
  versioned symbols.  Both of these are not something we can see with
  SYMBOL_REFERENCES_LOCAL TLS symbols (see below).

  We only need to worry about copy_indirect_symbol transferring
  information *from* a symbol which we have generated a TLS relaxation
  against to LE.

  In order to satisfy the criteria that we have generated a TLS
  relaxation hash entry against a symbol, we must have already have run
  check_relocs.  This means that of the ways in which
  copy_indirect_symbol can be called we have eliminated all but
  _bfd_elf_fix_symbol_flags and bfd_elf_record_link_assignment.

  bfd_elf_record_link_assignment handles symbol assignments in a linker
  script.  Such assignments can not be made on TLS symbols (we end up
  generating a non-TLS symbol).

  _bfd_elf_fix_symbol_flags only calls copy_indirect_symbol on symbols
  which have is_weakalias set.  These are symbols "from a dynamic
  object", and we only ever call the hook when the real definition is in
  a non-shared object.  Hence we would not have performed this
  relaxation on the symbol (because it is not SYMBOL_REFERENCES_LOCAL).

  Hence I don't believe this is something that we can trigger and we add
  an assertion here rather than add code to handle the case.

Add new relocations to linker (excluding relaxations)

Some notes on the implementation decisions:

Use _bfd_aarch64_elf_resolve_relocation on :size: relocations
  This is unnecessary, since all that function does in the case of
  :size: relocations is to return the value it was given as an argument.
  For the analogous MOVW_G0 relocations this function adds the addend
  and emits a warning in the case of a weak undefined TLS symbol.

TPREL128/TLSDESC relocs now add size of symbol in fragment to satisfy
the ABI requirement.
  This only happens when we know the size of the relevant symbol, we
  also emit the location of the symbol in a TPREL128 fragment when that
  is known too.

See PR for documentation https://github.com/ARM-software/abi-aa/pull/80

Implementation note:
Handling the size of a symbol according to whether the static linker
knows what it is was very slightly tricky.  Using the macro
`SYMBOL_REFERENCES_LOCAL` to check whether we knew the size of a symbol
is a problem.  That macro treats PROTECTED visibility symbols as *not*
local.  This is in order to handle the case where a reference to a
protected function symbol could end up having the value of an
executable's PLT (in order to handle function equality and hard-coded
addresses in an executable).

Since TLS symbols can not be function symbols (n.b. this refers to the
TLS object and not the resolver), this requirement does not apply.  That
means we should check this property with something like
`SYMBOL_CALLS_LOCAL` (which is the existing macro to treat protected
symbols differently).

Given the confusing nomenclature here, we add a new AArch64 backend
macro called `TLS_SYMBOL_REFERENCES_LOCAL` so that we have a nice name
for it.

N.b. in this patch we adjust all uses of `SYMBOL_REFERENCES_LOCAL` which
are known to be acting on TLS symbols.  This includes some places where
it does not matter whether a symbol is protected or not because the
condition also requires that we're in an executable (like in deciding
whether a relocation can be relaxed).  This was done simply for
conformity and neatness.

Add new relocations to GAS

Also add the ability to disassemble these relocations correctly.

Include checking that many different sizes work with different
instructions, include error checking that the `size` relocation is not
allowed in a64 mode.  Ensure that the size relocation is not allowed on
instructions other than mov[kz].

See the arm ABI aaelf64-morello document for the definition of these
new relocations.

Regenerate bfd/bfd-in2.h and bfd/libbfd.h from bfd/reloc.c.

Adjust TLS relaxation condition

In aarch64_tls_transition_without_check and elfNN_aarch64_tls_relax we
choose whether to perform a relaxation to an IE access model or an LE
access model based on whether the symbol itself is marked as local (i.e.
`h == NULL`).

This is problematic in two ways.  The first is that sometimes a global
dynamic access can be relaxed to an initial exec access when creating a
shared library, and if that happens on a local symbol then we currently
relax it to a local exec access instead.  This usually does not happen
since we only relax an access if aarch64_can_relax_tls returns true and
aarch64_can_relax_tls does not have the same problem.  However, it can
happen when we have seen both an IE and GD access on the same symbol.
This case is exercised in the newly added testcase tls-relax-gd-ie-2.

The second problem is that deciding based on whether the symbol is local
misses the case when the symbol is global but is still non-interposable
and known to be located in the executable.  This happens on all global
symbols in executables.
This case is exercised in the newly added testcase tls-relax-ie-le-4.

Here we adjust the condition we base our relaxation on so that we relax
to local-exec if we are creating an executable and the relevant symbol
we're accessing is stored inside that executable.

Alongside that general fix, we adjust the existing exclusion parameters
for Morello relaxations.  Patches are in-flight to replace the existing
Morello TLS relocation handling with the more recent TLS ABI.  This
patch simply adjusts the existing handling to use a more robust method
to determine the case when a GD -> LE relaxation can be performed.

-- Updating tests for new relaxation criteria

Many of the tests added to check our relaxation to IE were implemented
by taking advantage of the fact that we did not relax a global symbol
defined in an executable.

Since a global symbol defined in an executable is still not
interposable, we know that a TLS version of such a symbol will be in the
main TLS block.  This means that we can perform a stronger relaxation on
such symbols and relax their accesses to a local-exec access.

Hence we have to update all tests that relied on the older suboptimal
decision making.

The two cases when we still would want to relax a general dynamic access
to an initial exec one are:
1) When in a shared library and accessing a symbol which we have already
   seen accessed with an initial exec access sequence.
2) When in an executable and accessing a symbol defined in a shared
   library.

Both of these require shared library support, which means that these
tests are now only available on targets with that.

I have chosen to switch the existing testcases from a plain executable
to one dynamically linked to a shared object as that doesn't require
changing the testcases quite so much (just requires accessing a
different variable rather than requiring adding another code sequence).

The tls-relax-all testcase was an outlier to the above approach, since
it included a general dynamic access to both a local and global symbol
and inspected for the difference accordingly.

This is the same logical change as
https://sourceware.org/pipermail/binutils/2022-July/121660.html

Standardise check for static PDE

We have hit multiple problems checking for a static non-PIE binary using
incorrect conditions.  In looking into a TLS relaxation that should not
have happened we found another.  To help avoid this problem in the
future (and to make reading the code a lot easier for someone who isn't
familiar with the BFD linker flags) we now perform the check for a
static PDE with a macro called `static_pde`.

N.b. this macro can only be used after we've created any needed dynamic
sections.  That happens when loading symbols, which is very early on and
hence before any of the places we want to use this macro.  However it's
still good to note it's not always a valid check.

Improve Morello feature detection

Given HWCAP2_MORELLO changed for Linux Kernel 5.18, this breaks Morello GDB's
heuristic for detecting the Morello feature.

When possible, switch to detecting the Morello feature through the availability
of the NT_ARM_MORELLO register set (which means PTRACE_PEEKCAP and
PTRACE_POKECAP are also available).  For corefiles, switch to using the presence
of the Morello register set section.

For extended-remote mode, check for the two possible values of HWCAP2_MORELLO.

[Morello GDB] Fix a couple hardware watchpoint issues around capabilities

This patch fixes a couple issues around hardware watchpoint triggers related to
capabilities.

1 - When a capability changes and the hardware watchpoint triggers, Morello
GDB should display the tag state for new/old values correctly.

2 - Take the capability tag into consideration when checking for content
changes to the watched area. The 128 bits may be the same, but the tag state
may differ.

[Morello GDB] Fix AUXV reading/parsing for corefiles and remote targets

The last fix to enable GDB to read pure-cap AUXV information (with 128-bit
entries) only handled native GDB.

The following patch enables the same logic for corefiles and remote targets.

[Morello GDB] Fix bug in conditional definition of morello structs

The previous commit fixing this issue (bf5ddcecc07c2d89e824851f5f940ebe7e2af0fd)
failed to spot an issue with include ordering.

Fix all such issues with this patch.

Neaten up a clause in final_link_relocate

Originally this clause included lines checking `!bfd_link_pic &&
bfd_link_executable`.  I left these in to ensure that the new Morello
part to the clause did not interfere with the original stock AArch64
part of the clause.

Now we have split the condition into multiple if statements for clarity,
we can remove the confusing parts of the clause.  This clause is to
catch any symbols that go in the GOT but would not be otherwise given a
relocation by finish_dynamic_symbol.  We can express that check better
with a modified condition.

What we want to do in this clause is to account for all GOT entries
which would not get a dynamic relocation otherwise, but need a RELATIVE
dynamic relocation for Morello.  This is any symbol for which
c64_should_not_relocate is false and WILL_CALL_FINISH_DYNAMIC_SYMBOL is
false.  Changing the clause to only mention these two predicates (plus
ensuring that we do not mess around with such relocations when creating
a relocatable object file rather than a final binary) explains the
purpose of this condition much better.

N.b. see the commit message of 8f5baae3d15 for the reasoning for the
original decision to not change the conditional.

Use global GOT type to determine GOT action

morello-binutils: Use global GOT type to determine GOT action

In final_link_relocate we currently use whether the relocation we're
looking at is a Morello relocation to decide whether we should treat the
GOT entry as a Morello GOT entry or not.

This is problematic since we can have an AArch64 relocation against a
capability GOT entry (even if it isn't a very useful thing to have).

The current patch decides whether we need to emit a MORELLO RELATIVE
relocation in the GOT based on whether the GOT as a whole contains
capabilities rather than based on whether the first relocation against
this GOT is a Morello relocation.

Until now we did not see any problem from this.  Here we add a testcase
that triggers the problem.

Make emit-relocs-morello-6 work on different targets

This testcase has not been passing on linux targets for a while due to
the hard-coding of addresses.  Here we use the record/check feature to
make the testcase more robust and explain what's getting checked a
little better.

Account for weak undefined symbols in Morello

Originally we believed we had accounted for these symbols within the
existing if conditional.  It turns out that with `-pie
--no-dynamic-linker` on the command line (which causes the `link_info`
member `dynamic_undefined_weak` to be set to 0) such symbols can bypass
elfNN_aarch64_allocate_dynrelocs putting these symbols into the dynamic
symbol table.  Hence we can have such symbols without a dynamic index
and our existing conditionals need to be adjusted.

On further inspection we notice that GOT entries for *hidden* undefined
weak symbols were still getting RELATIVE relocations.  This is quite
unnecessary since it's known that the entry should be the NULL
capability, but on top of that it relies on the runtime to have a
special case to not add the load displacement to RELATIVE relocations
with completely zero fragments.

We make two logical adjustments.
The first is that in our handling of CAPINIT relocations we add a
clause to avoid emitting a relocation for any undefined weak symbol
which we know for certain should end up with the NULL capability at
runtime.  In this clause we ensure that the fragment is completely zero.

The second is around handling GOT entries.  For these we ensure that
elfNN_aarch64_allocate_dynrelocs does not allocate a dynamic relocation
for the GOT entry of such symbols and that
elfNN_aarch64_final_link_relocate leaves the GOT entry empty and without
any relocation.

N.b. in implementing this change the conditionals became quite
confusing.  We split them up quite unnecessarily into different else/if
statements for clarity at the expense of verbosity.

We also add tests to check the behaviour of undefined weak symbols for
dynamically linked PDE's/PIE's/static executables/shared objects.

N.b.2 We also add an extra assert in final_link_relocate.  This function
deals with GOT entries for symbols both in the internal hash table and
not in the hash table.  Binutils decides whether symbols should be in
the hash table or not based on their binding.  WEAK binding symbols are
put in the hash table.  That said, final_link_relocate has a
`weak_undef_p` local flag to describe whether a given symbol is weak
undefined or not.  This flag is defined for both symbols in the hash
table and symbols not in the hash table.

I believe that the only time we have weak_undef_p set in
final_link_relocate when the relevant symbol is not in the hash table is
when we have "removed" a relocation from our work list by modifying it
to be a R_AARCH64_NONE relocation against the STN_UNDEF symbol (e.g.
during TLS relaxation).

Such cases would not fall into the GOT relocation clause.  Hence I don't
think we can ever see weak_undef_p symbols which are not in the hash
table in this clause.  It's worth an assertion to catch the possibility
that this is wrong.

Emit CAPINIT relocations for dynamically linked PDE's

Until now CAPINIT relocations were only emitted for position independent
code.  For a data relocation against a symbol in some other shared
object this was problematic since we don't know the address that said
symbol will be at.  We ended up emitting a broken RELATIVE relocation.

This also happened to be problematic for function pointers, since a
CAPINIT relocation did not ensure that a PLT entry was created in this
binary.  When a PLT entry was not created we again had a broken RELATIVE
relocation.

We could have fixed the problem with function pointers by ensuring that
a CAPINIT relocation caused a PLT entry to be emitted and the RELATIVE
relocation hence to point to that PLT entry.  Here we choose to always
emit a CAPINIT relocation and let the dynamic linker resolve that to a
local PLT entry if one exists, but if one does not exist let the dynamic
linker resolve it to the actual function in some other shared library.

Alongside this change we ensure that we leave 0 as the value in the
fragment for a CAPINIT relocation.  The dynamic linker already has to
decide which symbol to use, and it would have the value of the local
symbol available if it chooses to use it.  Hence there is no reason for
the static linker to leave the value of one option in the fragment of
this CAPINIT relocation.

This patch also introduces quite a few new testcases.
These are to check that we should only add a special PLT entry as the
canonical address for pointer equality when a function pointer is
accessed via code relocations -- and we ensure this does not happen for
accessing data pointers or accesses via CAPINIT data relocations.

Outside of the new testcases, we also adjust
emit-relocs-morello-3{,-a64c}.d.  These testcases checked for a CAPINIT
relocation in a shared object.  Now we no longer populate that fragment
we need to adjust the testcase accordingly.

Use htab->c64_rel more, do not use GOT_CAP

Each symbol that has a reference in the GOT has an associated got_type.
For capabilities we currently have a new got_type of GOT_CAP for
capability entries in the GOT.

We do not allow capability entries in the GOT for an A64 (or hybrid)
binary, and only allow capability entries in the GOT for a purecap
binary.  Hence there is no need to maintain a per-symbol indication of
whether the associated GOT entry for this symbol is a capability or not.

There is already an existing flag on the hash table to indicate whether
the GOT contains capabilities or addresses.  We can replace every use of
the existing GOT_CAP with a check of this flag.

Doing such a transformation means we can not express an invalid state
(there is no longer any way to express a GOT which contains some
addresses and some capabilities).  It also solves a bug where we
introduce a PLT to be the canonical address of a function after having
seen a R_AARCH64_LDST128_ABS_LO12_NC relocation.  The existing manner of
deciding whether an entry in the GOT should be a capability or address
based on the relocation we generated it from could not work in a binary
when we only have this relocation.  It should be determined based on the
flags of the input object files we saw (i.e. are these purecap object
files or not).

N.b. this also fixes an observed problem that could have been fixed in
the existing regime.  In this case the JUMP_SLOT of a PLT entry added to
be the canonical address of a function which was addressed directly in
code (with both a Morello and AArch64 relocation) had got_type of
GOT_UNKNOWN (because it was simply not marked) and hence
elfNN_aarch64_create_small_pltn_entry was generating an AArch64
relocation because the GOT entry was not GOT_CAP.

This patch also adjusts the "should this GOT contain capabilities" flag
to report yes/no based on the EF_AARCH64_CHERI_PURECAP flag of the
inputs rather than based on whether we've seen any morello relocations
pointing into the GOT.
NOTE:  We do not remove the existing times where we set this flag based
on MORELLO relocations.  This is left for a future patch when we look
into the handling of hybrid code and the GOT.

N.b. this required two changes in the testsuite.
morello-capinit.d required updating since the size of the GOT section
was previously incorrectly calculated.  There is no GOT relocation in
this testcase, which meant that the existing method of finding the size
of the dummy first GOT entry was incorrect (gave the size of an AArch64
entry).  Since the size of the GOT is now different the PCC bounds is
now different, and we hence need to update the values checking for the
PCC bounds in this testcase.

We take this opportunity to make the testcase more robust by using the
new record/check testsuite feature.  This means the testcase now passes
on other targets (i.e. both bare-metal and for none-linux).

emit-relocs-morello.d had a minor change for the same reason.  Since the
alignment requirement of the GOT changed this changed the start position
too.  When the start position changed objdump decided not to output an
extra line of 0000000.

Conditionally define user_morello_state and user_cap structs

If we don't have the Morello kernel headers, we need to define our own
structures to read capability registers and capabilities.

Teach gdbserver about 32-byte auxv entries for the PCuABI

In order for GDBServer to work correctly with the PCuABI, it needs to
understand that there are auxv entries of 16 bytes and 32 bytes.

Fix fetching of auxv for PCuABI

The entries of the auxv for the PCuABI are 128-bit in size.  Teach GDB about
this so it can at least fetch some sane values.  It currently can't fetch the
capabilities, but should be enough for now.

Morello do not create RELATIVE relocs for dynamic GOT entries

For dynamic symbol GOT entries, the linker emits relocations for that
entry in finish_dynamic_symbol.

Since Morello capabilities always need dynamic relocations to initialise
GOT entries at runtime, we need to emit relocations for any capability
GOT entries.  Two examples which are not needed for non-Morello linking
are static linking and for global symbols defined and referenced in a
PDE.

In order to ensure we emit those relocations we catch them in the
existing clause of final_link_relocate that looks for GOT entries that
require relocations which are not handled by finish_dynamic_symbol.
Before this patch, the clause under which those relocations were emitted
would include dynamic GOT entries in dynamically linked position
dependent executables.
These symbols hence had RELATIVE relocations emitted to initialise them
in the executables GOT by final_link_relocate, and GLOB_DAT relocations
emitted to initialise them by finish_dynamic_symbol.

The RELATIVE relocation is incorrect to use, since the static linker
does not know the value of this symbol at runtime (i.e. it does not know
the location in memory that the the shared library will be loaded).

This patch ensures that the clause in final_link_relocate does not
catch such dynamic GOT entries by ensuring that we only catch symbols
when we would not otherwise call finish_dynamic_symbol.

N.b. we also add an assertion in the condition-guarded block, partly to
catch similar problems earlier, but mainly to make it clear that
`relative_reloc` should not be set when finish_dynamic_symbol will be
called.

N.b.2 The bfd_link_pic check is a little awkward to understand.
Due to the definition of WILL_CALL_FINISH_DYNAMIC_SYMBOL, the only time
that `!bfd_link_pic (info) && !WILL_CALL_FINISH_DYNAMIC_SYMBOL` is false
and
`!WILL_CALL_FINISH_DYNAMIC_SYMBOL (is_dynamic, bfd_link_pic (info), h)`
is true is when the below holds:
  is_dynamic && !h->forced_local && h->dynindx == -1

This clause is looking for local GOT relocations that are not in the
dynamic symbol table, in a binary that will have dynamic sections.

This situation is the case that this clause was originally added to
handle (before the Morello specific code was added).  It is the case
when we need a RELATIVE relocation because we have a PIC object, but
finish_dynamic_symbol would not be called on the symbol.

Since all capability GOT entries need relocations to initialise them it
would seem unnecessary to include the bfd_link_pic check in our Morello
clause.  However the existing clause handling these relocations for
AArch64 specifically avoids adding a relocation for
bfd_link_hash_undefweak symbols.  By keeping the `!bfd_link_pic (info)`
clause in the Morello part of this condition we ensure such undefweak
symbols are still avoided.

I do not believe it is possible to trigger the above case that requires
this `bfd_link_pic` clause (where we have a GOT relocation against a
symbol satisfying):
  h->dynindx == -1 && !h->forced_local
  && h->root.type == bfd_link_hash_undefweak
  && bfd_link_pic (info) && bfd_link_executable (info)
I believe this is because when creating an undefweak symbol that has a
GOT reference we hit the clause in elfNN_aarch64_allocate_dynrelocs
which ensures that such symbols are put in `.dynsym` (and hence have a
`h->dynindx != -1`).  A useful commit to reference for understanding
this is ff07562f1e.

Hence there is no testcase for this part.  We do add some code that
exercises the relevant case (but does not exercise this particular
clause) into the morello-dynamic-link-rela-dyn testcase.

Predicate fixes around srelcaps and capability GOT relocations

This patch clears up some confusing checks around where to place
capability relocations initialising GOT entries.

Our handling of capability entries for the GOT had a common mistake in
the predicates that we used.  Statically linked executables need to have
all capability relocations contiguous in order to be able to mark their
start and end with __rela_dyn_{start,end} symbols.  These symbols are
used by the runtime to find dynamic capability relocations that must be
performed.  They are not needed when dynamically linking as then it is
the responsibility of the dynamic loader to perform these relocations.

We generally used `bfd_link_executable (info) && !bfd_link_pic (info)`
to check for statically linked executables.  This predicate includes
dynamically linked PDE's.  In most cases seen we do not want to include
dynamically linked PDE's.

This problem manifested in a few different ways.  When the srelcaps
section was non-empty we would generate the __rela_dyn_{start,end}
symbols -- which meant that these would be unnecessarily emitted for
dynamically linked PDE's.  In one case we erroneously increased the size
of this section on seeing non-capability relocations, and since no
relocations were actually added we would see a set of uninitialised
relocations.

Here we inspected all places in the code handling the srelcaps section
and identified 5 problems.  We add tests for those problems which can
be seen (some of the problems are only problems once others have been
fixed) and fix them all.

Below we describe what was happening for each of the problems in turn:

---
Avoid non-capability relocations during srelcaps sizing

elfNN_aarch64_allocate_dynrelocs increases the size for relocation
sections based on the number of dynamic symbol relocations.

When increasing the size of the section in which we store capability
relocations (recorded as srelcaps in the link hash table) our
conditional erroneously included non-capability relocations.  We were
hence allocating space in a section like .rela.dyn for relocations
populating the GOT with addresses of non-capability symbols in a
statically linked executable (for non-Morello compilation).

This change widens the original if clause so it should catch CAP
relocations that should go in srelgot, and tightens the fallback else if
clause in allocate_dynrelocs to only act on capability entries in the
GOT, since those are the only ones not already caught which still need
relocations to populate.

Implementation notes:
While not necessary, we also stop the fallback conditional checking
!bfd_link_pic and instead put an assertion that we only ever enter the
conditions block in the case of !bfd_link_pic && !dynamic.
This is done to emphasise that this condition is there to account for
all the capability GOT entries for the hash table which need relocations
and are not caught by the existing code.  The fact that this should only
happen when building static executables seems like an emergent property
rather than the thing we would want to check against.

This is tested with no-morello-syms-static.

---
size_dynamic_sections use srelcaps for statically linked executables
and srelgot for dynamically linked binaries.

When creating a statically linked executable the srelcaps section will
always be initialised and that is where we should put all capability
relocations.  When creating a dynamically linked executable the srelcaps
may or may not be initialised (depending on if we saw CAPINIT
relocations) and either way we should put GOT relocations into the
srelgot section.

Though there is no functional change to look for, this code path is
exercised with the morello-static-got test and
morello-dynamic-link-rela-dyn for statically linked and dynamically
linked PDE's respectively.

---
Capability GOT relocations go in .rela.got for dynamically linked PDEs

final_link_relocate generates GOT relocations for entries in the GOT
that are not handled by the generic ELF relocation code.  For Morello
we require relocations for any entry in the GOT that needs to be a
capability.

For *static* linking we keep track of a section specifically for
capability relocations.  This is done in order to be able to emit
__rela_dyn_{start,end} symbols at the start and end of an array of these
relocations (see commit 40bbb79e5a3 for when this was introduced and
commit 8d4edc5f8 for when we ensured that MORELLO_RELATIVE relocations
into the GOT were included in this section).

The clause in final_link_relocate that decides whether we should put
MORELLO_RELATIVE relocations for initialising capability GOT entries
into this special section currently includes dynamically linked PDE's.
This is unnecessary, since for dynamically linked binaries we do not
want to emit such __rela_dyn_{start,end} symbols.

While this behaviuor is in general harmless (especially since both
input sections srelcaps and srelgot have the same output section in the
default linker scripts), this commit changes it for clarity of the code.
We now only put these relocations initialising GOT entries into the
srelcaps section if we require it for some reason.  The only time we do
require this is when statically linking binaries and we need the
__rela_dyn_* symbols.  Otherwise we put these entries into the `srelgot`
section which exists for holding GOT entries together.

Since this diff is not about a functional change we do not include a
testcase.  However we do ensure that the testcase
morello-dynamic-link-rela-dyn is written so as to exercise the codepath
which has changed.

---
Only ensure that srelcaps is initialised when required

In commit 8d4edc5f8 we started to ensure that capability relocations for
initialising GOT entries were stored next to dynamic RELATIVE
relocations arising from CAPINIT static relocations.

This was done in order to ensure that all relocations creating a
capability were stored next to each other, allowing us to mark the range
of capability relocations with __rela_dyn_{start,end} symbols.

We only need to do this for statically linked executables, for
dynamically linked executables the __rela_dyn_{start,end} symbols are
unnecessary.

When doing this, and there were no CAPINIT relocations that initialised
the srelcaps section, we set that srelcaps section to the same section
as srelgot.  Despite what the comment above this clause claimed we
mistakenly did this action when dynamically linking a PDE (i.e. we did
not *just* do this for static non-PIE binaries).

With recent changes that ensure we do not put anything in this srelcaps
section when not statically linking this makes no difference, but
changing the clause to correctly check for static linking is a nice
cleanup to have.

Since there is no observable change expected this diff has no
testcase, but the code path is exercised with morello-dynamic-got.

---
Only emit __rela_dyn_* symbols for statically linked exes

The intention of the code to emit these symbols in size_dynamic_sections
was only to emit symbols for statically linked executables.  We recently
noticed that the condition that has been used for this also included
dynamically linked PDE's.

Here we adjust the condition so that we only emit these symbols for
statically linked executables.

This allows initailisation code in glibc to be written much simpler,
since it does not need to determine whether the relocations have been
handled by the dynamic loader or not -- if the __rela_dyn_* symbols
exist then this is definitely a statically linked executable and the
relocations have not been handled by the dynamic loader.

This is tested with morello-dynamic-link-rela-dyn.

Account for LSB on DT_INIT/DT_FINI entries

When DT_INIT and/or DT_FINI point to C64 functions they should have
their LSB set.  I.e. these entries should contain the address of the
relevant functions and not a slight variation on them.

This is already done by Morello clang, and we want GNU ld updated to
match.

Here we account for these LSB's for Morello in the same way as the Arm
backend accounts for the Thumb LSB.  This is done in the
finish_dynamic_sections hook by checking the two dynamic section
entries, looking up the relevant functions, and adding that LSB onto the
entry value.

In our testcase we simply check that the INIT and FINI section entries
have the same address as the _init and _fini symbols.

Handle locally-resolving entries in the GOT

In standard AArch64 linking by the BFD linker, dynamic symbols in PIC
code have their dynamic relocations created by
elfNN_aarch64_finish_dynamic_symbol.  Any required information in the
relevant fragment is added by elfNN_aarch64_final_link_relocate.

Non-dynamic symbols that are supposed to go in the GOT have their
RELATIVE relocations created in elfNN_aarch64_final_link_relocate next
to the place where the fragment is populated.

The code in elfNN_aarch64_finish_dynamic_symbol was not updated when we
ensured that RELATIVE relocations against function symbols were
generated with the PCC base stored in their fragment and an addend
defined to make up the difference so that the relocation pointed at the
relevant function.

On top of this, elfNN_aarch64_final_link_relocate was never written to
include the size and permission information in the GOT fragment for
RELATIVE relocations that will be generated by
elfNN_aarch64_finish_dynamic_symbol.

This patch resolves both issues by adding code to
elfNN_aarch64_final_link_relocate to handle setting up the fragment of a
RELATIVE relocation that elfNN_aarch64_finish_dynamic_symbol will
create, and adding code in elfNN_aarch64_finish_dynamic_symbol to use
the correct addend for the RELATIVE relocation that it generates.

Implementation choices:

The check in elfNN_aarch64_final_link_relocate for "cases where we would
generate a RELATIVE relocation through
elfNN_aarch64_finish_dynamic_symbol" is believed to handle undefined
weak symbols by checking SYMBOL_REFERENCES_LOCAL on the belief that the
latter would not return true if on undefined weak symbols.  This is not
as clearly correct as the rest of the condition, so seems reasonable to
bring to the attention of anyone interested.

We add an assertion that this is the case so we get alerted if it is
not, we could choose to include !UNDEFWEAK_NO_DYNAMIC_RELOC in the
condition instead, but believe that would lead to confusion in the code
(i.e. why check something that will always be false).

Similarly, when we check against SYMBOL_REFERENCES_LOCAL to decide
whether to populate the fragment for this relocation this does not
directly correspond to `h->dynindx == -1` (which would indicate that
this symbol is not in the dynamic symbol table).
This means that our clause catches symbols which would appear in the
dynamic symbol table as long as SYMBOL_REFERENCES_LOCAL returns true.
The only case in which we know this can happen is for PROTECTED
visibility data when GNU_PROPERTY_NO_COPY_ON_PROTECTED is set.
When this happens a RELATIVE relocation is generated (since this is
an object we know will resove to the current binary) and the static
linker provides the permissions and size of the associated object in the
relevant fragment.
This behaviour matches all other RELATIVE relocations and allows the
dynamic loader to assume that all RELATIVE relocations should have their
associated permissions and size provided.
We mention this behaviour since the symbol for this object will appear
in the dynamic symbol table and hence the dynamic loader *could*
determine the size and permissions itself.

In our condition to decide whether to update this relocation we include
a check that we `WILL_CALL_FINISH_DYNAMIC_SYMBOL`.  This is not
necessary, since the combination of conditions implies it, however it
makes things much clearer as to what we're checking for.

Testsuite notes:

When testing our change here we check:
  1) The addend and base of the RELATIVE relocation gives the required
     address of the hidden function.
  2) The bounds of the RELATIVE relocation is non-zero.
  3) The permissions of the RELATIVE relocation are executable.
Lacking in this particular test is a check that the PCC bounds are
calculated correctly, and that the base we define is the base of the
PCC.  We rely on existing tests to check our calculation of the PCC
bounds.

Allow WZR in alt-base loads and stores

The alt-base loads and stores allow WZR and XZR to be specified
as the register being loaded or stored.  We were accepting the
XZR forms but not the WZR ones.

The easiest fix is to drop the separate Wt operand type.  Most
other instructions handle the W/X distinction using the qualifiers
instead, and all instructions that used Wt already specified W
qualifiers.