Add readMemory and writeMemory requests to DAP

This adds the DAP readMemory and writeMemory requests.  A small change
to the evaluation code is needed in order to test this -- this is one
of the few ways for a client to actually acquire a memory reference.

gdb: cleanup around some set_momentary_breakpoint_at_pc calls

I noticed a couple of places in infrun.c where we call
set_momentary_breakpoint_at_pc, and then set the newly created
breakpoint's thread field, these are in:

  insert_exception_resume_breakpoint
  insert_exception_resume_from_probe

Function set_momentary_breakpoint_at_pc calls
set_momentary_breakpoint, which always creates the breakpoint as
thread-specific for the current inferior_thread().

The two insert_* functions mentioned above take an arbitrary
thread_info* as an argument and set the breakpoint::thread to hold the
thread number of that arbitrary thread.

However, the insert_* functions store the breakpoint pointer within
the current inferior_thread(), so we know that the thread being passed
in must be the currently selected thread.

What this means is that we can:

  1. Assert that the thread being passed in is the currently selected
  thread, and

  2. No longer adjust the breakpoint::thread field, this will already
  have been set correctly be calling set_momentary_breakpoint_at_pc.

There should be no user visible changes after this commit.

gdb: don't always print breakpoint location after failed condition check

Consider the following session:

  (gdb) list some_func
  1 int
  2 some_func ()
  3 {
  4   int *p = 0;
  5   return *p;
  6 }
  7
  8 void
  9 foo ()
  10 {
  (gdb) break foo if (some_func ())
  Breakpoint 1 at 0x40111e: file bpcond.c, line 11.
  (gdb) r
  Starting program: /tmp/bpcond

  Program received signal SIGSEGV, Segmentation fault.
  0x0000000000401116 in some_func () at bpcond.c:5
  5   return *p;
  Error in testing condition for breakpoint 1:
  The program being debugged stopped while in a function called from GDB.
  Evaluation of the expression containing the function
  (some_func) will be abandoned.
  When the function is done executing, GDB will silently stop.

  Breakpoint 1, 0x0000000000401116 in some_func () at bpcond.c:5
  5   return *p;
  (gdb)

What happens here is the breakpoint condition includes a call to an
inferior function, and the inferior function segfaults.  We can see
that GDB reports the segfault, and then gives an error message that
indicates that an inferior function call was interrupted.

After this GDB appears to report that it is stopped at Breakpoint 1,
inside some_func.

I find this second stop report a little confusing.  While it is true
that GDB stopped as a result of hitting breakpoint 1, I think the
message GDB currently prints might give the impression that GDB is
actually stopped at a location of breakpoint 1, which is not the case.

Also, I find the second stop message draws attention away from
the "Program received signal SIGSEGV, Segmentation fault" stop
message, and this second stop might be thought of as replacing in
someway the earlier message.

In short, I think things would be clearer if the second stop message
were not reported at all, so the output should, I think, look like
this:

  (gdb) list some_func
  1 int
  2 some_func ()
  3 {
  4   int *p = 0;
  5   return *p;
  6 }
  7
  8 void
  9 foo ()
  10 {
  (gdb) break foo if (some_func ())
  Breakpoint 1 at 0x40111e: file bpcond.c, line 11.
  (gdb) r
  Starting program: /tmp/bpcond

  Program received signal SIGSEGV, Segmentation fault.
  0x0000000000401116 in some_func () at bpcond.c:5
  5   return *p;
  Error in testing condition for breakpoint 1:
  The program being debugged stopped while in a function called from GDB.
  Evaluation of the expression containing the function
  (some_func) will be abandoned.
  When the function is done executing, GDB will silently stop.
  (gdb)

The user can still find the number of the breakpoint that triggered
the initial stop in this line:

  Error in testing condition for breakpoint 1:

But there's now only one stop reason reported, the SIGSEGV, which I
think is much clearer.

To achieve this change I set the bpstat::print field when:

  (a) a breakpoint condition evaluation failed, and

  (b) the $pc of the thread changed during condition evaluation.

I've updated the existing tests that checked the error message printed
when a breakpoint condition evaluation failed.

gdb: avoid repeated signal reporting during failed conditional breakpoint

Consider the following case:

  (gdb) list some_func
  1 int
  2 some_func ()
  3 {
  4   int *p = 0;
  5   return *p;
  6 }
  7
  8 void
  9 foo ()
  10 {
  (gdb) break foo if (some_func ())
  Breakpoint 1 at 0x40111e: file bpcond.c, line 11.
  (gdb) r
  Starting program: /tmp/bpcond

  Program received signal SIGSEGV, Segmentation fault.
  0x0000000000401116 in some_func () at bpcond.c:5
  5   return *p;
  Error in testing breakpoint condition:
  The program being debugged was signaled while in a function called from GDB.
  GDB remains in the frame where the signal was received.
  To change this behavior use "set unwindonsignal on".
  Evaluation of the expression containing the function
  (some_func) will be abandoned.
  When the function is done executing, GDB will silently stop.

  Program received signal SIGSEGV, Segmentation fault.

  Breakpoint 1, 0x0000000000401116 in some_func () at bpcond.c:5
  5   return *p;
  (gdb)

Notice that this line:

  Program received signal SIGSEGV, Segmentation fault.

Appears twice in the output.  The first time is followed by the
current location.  The second time is a little odd, why do we print
that?

Printing that line is controlled, in part, by a global variable,
stopped_by_random_signal.  This variable is reset to zero in
handle_signal_stop, and is set if/when GDB figures out that the
inferior stopped due to some random signal.

The problem is, in our case, GDB first stops at the breakpoint for
foo, and enters handle_signal_stop and the stopped_by_random_signal
global is reset to 0.

Later within handle_signal_stop GDB calls bpstat_stop_status, it is
within this function (via bpstat_check_breakpoint_conditions) that the
breakpoint condition is checked, and, we end up calling the inferior
function (some_func in our example above).

In our case above the thread performing the inferior function call
segfaults in some_func.  GDB catches the SIGSEGV and handles the stop,
this causes us to reenter handle_signal_stop.  The global variable
stopped_by_random_signal is updated, this time it is set to true
because the thread stopped due to SIGSEGV.  As a result of this we
print the first instance of the line (as seen above in the example).

Finally we unwind GDB's call stack, the inferior function call is
complete, and we return to the original handle_signal_stop.  However,
the stopped_by_random_signal global is still carrying the value as
computed for the inferior function call's stop, which is why we now
print a second instance of the line, as seen in the example.

To prevent this, I propose adding a scoped_restore before we start an
inferior function call.  This will save and restore the global
stopped_by_random_signal value.

With this done, the output from our example is now this:

 (gdb) list some_func
  1 int
  2 some_func ()
  3 {
  4   int *p = 0;
  5   return *p;
  6 }
  7
  8 void
  9 foo ()
  10 {
  (gdb) break foo if (some_func ())
  Breakpoint 1 at 0x40111e: file bpcond.c, line 11.
  (gdb) r
  Starting program: /tmp/bpcond

  Program received signal SIGSEGV, Segmentation fault.
  0x0000000000401116 in some_func () at bpcond.c:5
  5   return *p;
  Error in testing condition for breakpoint 1:
  The program being debugged stopped while in a function called from GDB.
  Evaluation of the expression containing the function
  (some_func) will be abandoned.
  When the function is done executing, GDB will silently stop.

  Breakpoint 1, 0x0000000000401116 in some_func () at bpcond.c:5
  5   return *p;
  (gdb)

We now only see the 'Program received signal SIGSEGV, ...' line once,
which I think makes more sense.

Finally, I'm aware that the last few lines, that report the stop as
being at 'Breakpoint 1', when this is not where the thread is actually
located anymore, is not great.  I'll address that in the next commit.

gdbserver: allow agent expressions to fail with invalid memory access

This commit extends gdbserver to take account of a failed memory
access from agent_mem_read, and to return a new eval_result_type
expr_eval_invalid_memory_access.

I have only updated the agent_mem_read calls related directly to
reading memory, I have not updated any of the calls related to
tracepoint data collection.  This is just because I'm not familiar
with that area of gdb/gdbserver, and I don't want to break anything,
so leaving the existing behaviour untouched seems like the safest
approach.

I've then updated gdb.base/bp-cond-failure.exp to test evaluating the
breakpoints on the target, and have also extended the test so that it
checks for different sizes of memory access.

gdbserver: allows agent_mem_read to return an error code

Currently the gdbserver function agent_mem_read ignores any errors
from calling read_inferior_memory.  This means that if there is an
attempt to access invalid memory then this will appear to succeed.

In this patch I update agent_mem_read so that if read_inferior_memory
fails, agent_mem_read will return an error code.

However, none of the callers of agent_mem_read actually check the
return value, so this commit will have no effect on anything.  In the
next commit I will update the users of agent_mem_read to check for the
error code.

I've also updated the header comments on agent_mem_read to better
reflect what the function does, and its possible return values.

gdb: include breakpoint number in testing condition error message

When GDB fails to test the condition of a conditional breakpoint, for
whatever reason, the error message looks like this:

  (gdb) break foo if (*(int *) 0) == 1
  Breakpoint 1 at 0x40111e: file bpcond.c, line 11.
  (gdb) r
  Starting program: /tmp/bpcond
  Error in testing breakpoint condition:
  Cannot access memory at address 0x0

  Breakpoint 1, foo () at bpcond.c:11
  11   int a = 32;
  (gdb)

The line I'm interested in for this commit is this one:

  Error in testing breakpoint condition:

In the case above we can figure out that the problematic breakpoint
was #1 because in the final line of the message GDB reports the stop
at breakpoint #1.

However, in the next few patches I plan to change this.  In some cases
I don't think it makes sense for GDB to report the stop as being at
breakpoint #1, consider this case:

  (gdb) list some_func
  1 int
  2 some_func ()
  3 {
  4   int *p = 0;
  5   return *p;
  6 }
  7
  8 void
  9 foo ()
  10 {
  (gdb) break foo if (some_func ())
  Breakpoint 1 at 0x40111e: file bpcond.c, line 11.
  (gdb) r
  Starting program: /tmp/bpcond

  Program received signal SIGSEGV, Segmentation fault.
  0x0000000000401116 in some_func () at bpcond.c:5
  5   return *p;
  Error in testing breakpoint condition:
  The program being debugged was signaled while in a function called from GDB.
  GDB remains in the frame where the signal was received.
  To change this behavior use "set unwindonsignal on".
  Evaluation of the expression containing the function
  (some_func) will be abandoned.
  When the function is done executing, GDB will silently stop.

  Program received signal SIGSEGV, Segmentation fault.

  Breakpoint 1, 0x0000000000401116 in some_func () at bpcond.c:5
  5   return *p;
  (gdb)

Notice that, the final lines of output reports the stop as being at
breakpoint #1, even though the inferior in not located within
some_func, and it's certainly not located at the breakpoint location.

I find this behaviour confusing, and propose that this should be
changed.  However, if I make that change then every reference to
breakpoint #1 will be lost from the error message.

So, in this commit, in preparation for the later commits, I propose to
change the 'Error in testing breakpoint condition:' line to this:

  Error in testing condition for breakpoint NUMBER:

where NUMBER will be filled in as appropriate.  Here's the first
example with the updated error:

  (gdb) break foo if (*(int *) 0) == 0
  Breakpoint 1 at 0x40111e: file bpcond.c, line 11.
  (gdb) r
  Starting program: /tmp/bpcond
  Error in testing condition for breakpoint 1:
  Cannot access memory at address 0x0

  Breakpoint 1, foo () at bpcond.c:11
  11   int a = 32;
  (gdb)

The breakpoint number does now appear twice in the output, but I don't
see that as a negative.

This commit just changes the one line of the error, and updates the
few tests that either included the old error in comments, or actually
checked for the error in the expected output.

As the only test that checked the line I modified is a Python test,
I've added a new test that doesn't rely on Python that checks the
error message in detail.

While working on the new test, I spotted that it would fail when run
with native-gdbserver and native-extended-gdbserver target boards.
This turns out to be due to a gdbserver bug.  To avoid cluttering this
commit I've added a work around to the new test script so that the
test passes for the remote boards, in the next few commits I will fix
gdbserver, and update the test script to remove the work around.

asan: csky floatformat_to_double uninitialised value

* csky-dis.c (csky_print_operand <OPRND_TYPE_FCONSTANT>): Don't
access ibytes after read_memory_func error.  Change type of
ibytes to avoid casts.

gdb/riscv: fix regressions in gdb.base/unwind-on-each-insn.exp

This commit builds on the previous one to fix all the remaining
failures in gdb.base/unwind-on-each-insn.exp for RISC-V.

The problem we have in gdb.base/unwind-on-each-insn.exp is that, when
we are in the function epilogue, the previous frame and stack pointer
values are being restored, and so, the values that we calculated
during the function prologue are no longer suitable.

Here's an example from the function 'bar' in the mentioned test.  This
was compiled for 64-bit RISC-V with compressed instruction support:

  Dump of assembler code for function bar:
     0x000000000001018a <+0>: add sp,sp,-32
     0x000000000001018c <+2>: sd ra,24(sp)
     0x000000000001018e <+4>: sd fp,16(sp)
     0x0000000000010190 <+6>: add fp,sp,32
     0x0000000000010192 <+8>: sd a0,-24(fp)
     0x0000000000010196 <+12>: ld a0,-24(fp)
     0x000000000001019a <+16>: jal 0x10178 <foo>
     0x000000000001019e <+20>: nop
     0x00000000000101a0 <+22>: ld ra,24(sp)
     0x00000000000101a2 <+24>: ld fp,16(sp)
     0x00000000000101a4 <+26>: add sp,sp,32
     0x00000000000101a6 <+28>: ret
  End of assembler dump.

When we are at address 0x101a4 the previous instruction has restored
the frame-pointer, as such GDB's (current) preference for using the
frame-pointer as the frame base address is clearly not going to work.
We need to switch to using the stack-pointer instead.

At address 0x101a6 the previous instruction has restored the
stack-pointer value.  Currently GDB will not understand this and so
will still assume the stack has been decreased by 32 bytes in this
function.

My proposed solution is to extend GDB such that GDB will scan the
instructions at the current $pc looking for this pattern:

  ld    fp,16(sp)
  add   sp,sp,32
  ret

Obviously the immediates can change, but the basic pattern indicates
that the function is in the process of restoring state before
returning.  If GDB sees this pattern then GDB can use the inferior's
position within this instruction sequence to help calculate the
correct frame-id.

With this implemented then gdb.base/unwind-on-each-insn.exp now fully
passes.

Obviously what I've implemented is just a heuristic.  It's not going
to work for every function.  If the compiler reorders the
instructions, or merges the epilogue back into the function body then
GDB is once again going to get the frame-id wrong.

I'm OK with that, we're no worse off that we are right now in that
situation (plus we can always improve the heuristic later).

Remember, this is for debugging code without debug information,
and (in our imagined situation) with more aggressive levels of
optimisation being used.  Obviously GDB is going to struggle in these
situations.

My thinking is, lets get something in place now.  Then, later, if
possible, we might be able to improve the logic to cover more
situations -- if there's an interest in doing so.  But I figure we
need something in place as a starting point.

After this commit gdb.base/unwind-on-each-insn.exp passes with no
failures on RV64.

gdb/riscv: support c.ldsp and c.lwsp in prologue scanner

Add support to the RISC-V prologue scanner for c.ldsp and c.lwsp
instructions.

This fixes some of the failures in gdb.base/unwind-on-each-insn.exp,
though there are further failures that are not fixed by this commit.

This change started as a wider fix that would address all the failures
in gdb.base/unwind-on-each-insn.exp, however, that wider fix needed
support for the two additional compressed instructions.

When I added support for those two compressed instructions I noticed
that some of the failures in gdb.base/unwind-on-each-insn.exp resolved
themselves!

Here's what's going on:

The reason for the failures is that GDB is trying to build the
frame-id during the last few instructions of the function.  These are
the instructions that restore the frame and stack pointers just prior
to the return instruction itself.

By the time we reach the function epilogue the stack offset that we
calculated during the prologue scan is no longer valid, and so we
calculate the wrong frame-id.

However, in the particular case of interest here, the test function
'foo', the function is so simple and short (the empty function) that
GDB's prologue scan could, in theory, scan every instruction of the
function.

I say "could, in theory," because currently GDB stops the prologue
scan early when it hits an unknown instruction.  The unknown
instruction happens to be one of the compressed instructions that I'm
adding support for in this commit.

Now that GDB understands the compressed instructions the prologue scan
really does go from the start of the function right up to the current
program counter.  As such, GDB sees that the stack frame has been
allocated, and then deallocated, and so builds the correct frame-id.

Of course, most real functions are not as simple as the test function
'foo'.  As such, we can't usually rely on scanning right up to the end
of the function -- there are some instructions we always need to stop
at because GDB can't reason about how they change the inferior
state (e.g. a function call).  The test function 'bar' is just such an
example.

After this commit, we can now build the frame-id correctly for every
instruction in 'foo', but there are some tests still failing in 'bar'.

gdb/riscv: convert riscv debug settings to new debug print scheme

Convert the RISC-V specific debug settings to use the new debug
printing scheme.  This updates the following settings:

  set/show debug riscv breakpoints
  set/show debug riscv gdbarch
  set/show debug riscv infcall
  set/show debug riscv unwinder

All of these settings now take a boolean rather than an integer, and
all print their output using the new debug scheme.

There should be no visible change for anyone not turning on debug.

opcodes/arm: adjust whitespace in cpsie instruction

While I was working on the disassembler styling for ARM I noticed that
the whitespace in the cpsie instruction was inconsistent with most of
the other ARM disassembly output, the disassembly for cpsie looks like
this:

  cpsie   if,#10

notice there's no space before the '#10' immediate, most other ARM
instructions have a space before each operand.

This commit updates the disassembler to add the missing space, and
updates the tests I found that tested this instruction.

gdb/testsuite: gdb.server/server-kill.exp 'info frame' before kill_server

This commit follows on from the following two commits:

  commit 80dc83fd0e70f4d522a534bc601df5e05b81d564
  Date:   Fri Jun 11 11:30:47 2021 +0100

      gdb/remote: handle target dying just before a stepi

And:

  commit 079f190d4cfc6aa9c934b00a9134bc0fcc172d53
  Date:   Thu Mar 9 10:45:03 2023 +0100

      [gdb/testsuite] Fix gdb.server/server-kill.exp for remote target

The first of these commits fixed an issue in GDB and tried to extend
the gdb.server/server-kill.exp test to cover the GDB fix.

Unfortunately, the changes to gdb.server/server-kill.exp were not
correct, and were causing problems when trying to run with the
remote-gdbserver-on-localhost board file.

The second commit reverts some of the gdb.server/server-kill.exp
changes introduced in the first commit so that the test will now work
correctly with the remote-gdbserver-on-localhost board file.

The second commit is just about GDB's testing infrastructure -- it's
not about the original fix to GDB from the first commit, the actual
GDB change was fine.

While reviewing the second commit I wanted to check that the problem
fixed in the first commit is still being tested by the
gdb.server/server-kill.exp script, so I reverted the change to
breakpoint.c that is the core of the first commit and ran the test
script ..... and saw no failures.

The first commit is about GDB discovering that gdbserver has died
while trying to insert a breakpoint.  As soon as GDB spots that
gdbserver is gone we mourn the remote inferior, which ends up deleting
all the breakpoints associated with the remote inferiors.  We then
throw an exception which is caught in the insert breakpoints code, and
we try to display an error that includes the breakpoint number
.... but the breakpoint has already been deleted ... and so GDB
crashes.

After digging a little, what I found is that today, when the test does
'stepi' the first thing we end up doing is calculating the frame-id as
part of the stepi logic, it is during this frame-id calculation that
we mourn the remote inferior, delete the breakpoints, and throw an
exception.  The exception is caught by the top level interpreter loop,
and so we never try to print the breakpoint number which is what
caused the original crash.

If I add an 'info frame' command to the test script, prior to killing
gdbserver, then now when we 'stepi' GDB already has the frame-id
calculated, and the first thing we do is try to insert the
breakpoints, this will trigger the original bug.

In order to reproduce this experiment you'll need to change a function
in breakpoint.c, like this:

  static void
  rethrow_on_target_close_error (const gdb_exception &e)
  {
    return;
  }

Then run gdb.server/server-kill.exp with and without this patch.  You
should find that without this patch there are zero test failures,
while with this patch there will be one failure like this:

  (gdb) PASS: gdb.server/server-kill.exp: test_stepi: info frame
  Executing on target: kill -9 4513    (timeout = 300)
  builtin_spawn -ignore SIGHUP kill -9 4513
  stepi
  ../../src/gdb/breakpoint.c:2863: internal-error: insert_bp_location: Assertion `bl->owner != nullptr' failed.
  A problem internal to GDB has been detected,
  further debugging may prove unreliable.
  ----- Backtrace -----
  ...

gdb/testsuite: fix failure in gdb.python/py-unwind.exp

A potential test failure was introduced with commit:

  commit 6bf5f25bb150c0fbcb125e3ee466ba8f9680310b
  Date:   Wed Mar 8 16:11:30 2023 +0000

      gdb/python: make the gdb.unwinder.Unwinder class more robust

In this commit a new test was added, however the expected output
pattern varies depending on which Python version GDB is linked
against.

Older versions of Python result in output like this:

    (gdb) python global_test_unwinder.name = "foo"
    Traceback (most recent call last):
      File "<string>", line 1, in <module>
    AttributeError: can't set attribute
    Error while executing Python code.
    (gdb)

While more recent versions of Python give a similar, but slightly more
verbose error message, like this:

    (gdb) python global_test_unwinder.name = "foo"
    Traceback (most recent call last):
      File "<string>", line 1, in <module>
    AttributeError: can't set attribute 'name'
    Error while executing Python code.
    (gdb)

The test was only accepting the first version of the output.  This
commit extends the test pattern so that either version will be
accepted.

[aarch64] tpidr2: Fix erroneous detection logic for TPIDR2

The detection logic for TPIDR2 was implemented incorrectly.  Originally
the detection was supposed to be through a ptrace error code, but in reality,
for backwards compatibility, the detection should be based on the size of
the returned iovec.

For instance, if a target supports both TPIDR and TPIDR2, ptrace will return a
iovec size of 16.  If a target only supports TPIDR and not TPIDR2, it will
return a iovec size of 8, even if we asked for 16 bytes.

This patch fixes this issue in code that is shared between gdb and gdbserver,
therefore both gdb and gdbserver are fixed.

Tested on AArch64/Linux Ubuntu 20.04.

Automatic date update in version.in

asan: heap buffer overflow printing ecoff debug info file name

A case of a string section ending with an unterminated string.  Fix it
by allocating one more byte and making it zero.  Also make functions
reading the data return void* so that casts are not needed.

* ecoff.c (READ): Delete type param.  Allocate one extra byte
to terminate string sections with a NUL.  Adjust invocation.
* elfxx-mips.c (READ): Likewise.
* libbfd-in.h (_bfd_alloc_and_read): Return a void*.
(_bfd_malloc_and_read): Likewise.
* libbfd.h: Regenerate.

ubsan: aarch64 parse_vector_reg_list

tc-aarch64.c:1473:27: runtime error: left shift of 7 by 30 places
cannot be represented in type 'int'.

* config/tc-aarch64.c (parse_vector_reg_list): Avoid UB left
shift.

rddbg.c stabs FIXMEs

This should sort out some very old FIXMEs in code handling stabs
debug info.  Necessary if we are to fuss over freeing up memory before
objdump and objcopy exit.  It is of course better from a user
viewpoint to *not* free memory, which takes some time, and leave that
to process exit.  The only reason to do so is that having many memory
leaks in binutils/ code tends to hide leaks in bfd/ or opcodes/, which
we should care about.

* budbg.h (parse_stab): Update prototype.
* debug.h (debug_start_source): Update prototype.
* debug.c (debug_start_source): Add name_used.  Set if stashed.
* rddbg.c (read_symbol_stabs_debugging_info): Always malloc
stab string passed to parse_stab.  Free stab string when
unreferenced.
(read_section_stabs_debugging_info): Likewise, and strings
section contents.
* stabs.c (parse_stab): Add string_used param.  Set if string
stashed.  Pass to debug_start_source.  Realloc file_types
array rather that using malloc.  Clarify comment about
debug_make_indirect_type.

Memory leak in process_abbrev_set

We may have added some abbrevs to the list before hitting an error.
Free the list elements too.  free_abbrev_list returns list->next so we
need to init it earlier to avoid an uninitialised memory access.

* dwarf.c (process_abbrev_set): Call free_abbrev_list on errors.
Set list->next earlier.

gdb: remove unused parameters in print_doc_of_command, apropos_cmd

I noticed the prefix parameter was unused in print_doc_of_command.  And
when removing it, it becomes unused in apropos_cmd.

Change-Id: Id72980b03fe091b22931e6b85945f412b274ed5e

Automatic date update in version.in

gdb/arm: Fix backtrace for pthread_cond_timedwait

GDB expected PC should point right after the SVC instruction when the
syscall is active. But some active syscalls keep PC pointing to the SVC
instruction itself.

This leads to a broken backtrace like:
 Backtrace stopped: previous frame identical to this frame (corrupt stack?)
 #0  0xb6f8681c in pthread_cond_timedwait@@GLIBC_2.4 () from /lib/arm-linux-gnueabihf/libpthread.so.0
 #1  0xb6e21f80 in ?? ()

The reason is that .ARM.exidx unwinder gives up if PC does not point
right after the SVC (syscall) instruction. I did not investigate why but
some syscalls will point PC to the SVC instruction itself. This happens
for the "futex" syscall used by pthread_cond_timedwait.

That normally does not matter as ARM prologue unwinder gets called
instead of the .ARM.exidx one. Unfortunately some glibc calls have more
complicated prologue where the GDB unwinder fails to properly determine
the return address (that is in fact an orthogonal GDB bug). I expect it
is due to the "vpush" there in this case but I did not investigate it more:

Dump of assembler code for function pthread_cond_timedwait@@GLIBC_2.4:
   0xb6f8757c <+0>:     push    {r4, r5, r6, r7, r8, r9, r10, r11, lr}
   0xb6f87580 <+4>:     mov     r10, r2
   0xb6f87584 <+8>:     vpush   {d8}

Regression tested on armv7l kernel 5.15.32-v7l+ (Raspbian 11).

Approved-By: Luis Machado <luis.machado@arm.com>

Automatic date update in version.in

lto: Don't add indirect symbols for versioned aliases in IR

Linker adds indirect symbols for versioned symbol aliases, which are
created by ".symver foo, foo@FOO", by checking symbol type, value and
section so that references to foo will be replaced by references to
foo@FOO if foo and foo@FOO have the same symbol type, value and section.
But in IR, since all symbols of the same type have the same value and
section, we can't tell if a symbol is an alias of another symbol by
their types, values and sections.  We shouldn't add indirect symbols
for versioned symbol aliases in IR.

bfd/

PR ld/30281
* elflink.c (elf_link_add_object_symbols): Don't add indirect
symbols for ".symver foo, foo@FOO" aliases in IR.

ld/

PR ld/30281
* testsuite/ld-plugin/lto.exp: Add PR ld/30281 test.
* testsuite/ld-plugin/pr30281.t: New file.
* testsuite/ld-plugin/pr30281.c: Likewise.

Fix maybe-uninitialized warning in frame.c

A recent patch caused my system gcc (Fedora 36, so gcc 12.2.1) to warn
about sym_addr being possibly uninitialized in frame.c.  It isn't, but
the compiler can't tell.  So, this patch initializes the variable.  I
also fixed a formatting buglet that I missed in review.

[gdb/testsuite] Fix gdb.base/trace-commands.exp with editing off

With test-case gdb.base/trace-commands.exp and editing off, I run into fails
because multi-line commands are issued using gdb_test_sequence, which
doesn't handle them correctly.

Fix this by using gdb_test instead.

Tested on x86_64-linux.

PR testsuite/30288
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30288

[gdb/testsuite] Fix gdb.threads/threadapply.exp with editing off

With test-case gdb.threads/threadapply.exp and editing set to on, we have:
...
(gdb) define remove^M
Type commands for definition of "remove".^M
End with a line saying just "end".^M
>remove-inferiors 3^M
>end^M
(gdb)
...
but with editing set to off, we run into:
...
(gdb) define remove^M
Type commands for definition of "remove".^M
End with a line saying just "end".^M
>remove-inferiors 3^M
end^M
>(gdb) FAIL: gdb.threads/threadapply.exp: thread_set=all: try remove: \
  define remove (timeout)
...

The commands are issued by this test:
...
gdb_define_cmd "remove" {
    "remove-inferiors 3"
}
...
which does:
- gdb_test_multiple "define remove", followed by
- gdb_test_multiple "remove-inferiors 3\nend".

Proc gdb_test_multiple has special handling for multi-line commands, which
splits it up into subcommands, and for each subcommand issues it and then
waits for the resulting prompt (the secondary prompt ">" for all but the last
subcommand).

However, that doesn't work as expected in this case because the initial
gdb_test_multiple "define remove" fails to match all resulting output, and
consequently the secondary prompt resulting from "define remove" is counted as
if it was the one resulting from "remove-inferiors 3".

Fix this by matching the entire output of "define remove", including the
secondary prompt.

Tested on x86_64-linux.

PR testsuite/30288
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30288

Remove language_demangle

I noticed that language_demangle shadows the global
"current_language".  When I went to fix this, though, I then saw that
language_demangle is only called in two places, and has a comment
saying it should be removed.  This patch removes it.  Note that the
NULL check in language_demangle is not needed by either of the
existing callers.

Regression tested on x86-64 Fedora 36.

Approved-By: Simon Marchi <simon.marchi@efficios.com>

Fix race in background index-cache writing

Tom de Vries pointed out a bug in the index-cache background writer --
sometimes it will fail.  He also noted that it fails when the number
of worker threads is set to zero.  These turn out to be the same
problem -- the cache can't be written to until the per-BFD's
"index_table" member is set.

This patch avoids the race by rearranging the code slightly, to ensure
the cache cannot possibly be written before the member is set.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30261

GDB: Add `info main' command

Allow consumers of GDB to extract the name of the main method.  This is
most useful for Fortran programs which have a variable main method.

Used by both MAP and DDT e.g. it is used to detect the presence of debug
information.

Co-Authored-By: Maciej W. Rozycki <macro@embecosm.com>

GDB: Bring back the handling of DW_CC_program

Fix a functional regression and restore the handling of DW_CC_program
code of DW_AT_calling_convention attribute for determining the name of
the starting function of the program where the DW_AT_main_subprogram
attribute has not been provided, such as with Fortran code compiled with
GCC versions 4.5.4 and below, or where DWARF version 3 or below has been
requested.  Without it "main" is considered the starting function.  Cf.
GCC PR fortran/43414.

Original code was removed with commit 6209cde4ddb8 ("Delete DWARF
psymtab code"), and then an update to complement commit 81873cc81eff
("[gdb/symtab] Support DW_AT_main_subprogram with -readnow.") has also
been included here.

GDB: Favor full symbol main name for backtrace stop

In the case where a Fortran program has a program name of "main" and
there is also a minimal symbol called main, such as with programs built
with GCC version 4.4.7 or below, the backtrace will erroneously stop at
the minimal symbol rather than the user specified main, e.g.:

(gdb) bt
#0  bar () at .../gdb/testsuite/gdb.fortran/backtrace.f90:17
#1  0x0000000000402556 in foo () at .../gdb/testsuite/gdb.fortran/backtrace.f90:21
#2  0x0000000000402575 in main () at .../gdb/testsuite/gdb.fortran/backtrace.f90:31
#3  0x00000000004025aa in main ()
(gdb)

This patch fixes this issue by increasing the precedence of the full
symbol when the language of the current frame is Fortran.

Newer versions of GCC transform the program name to "MAIN__" in this
case, avoiding the problem.

Co-Authored-By: Maciej W. Rozycki <macro@embecosm.com>

gdb: Remove extra if statement

The removed if statement is already checked in the parent if else
statement.

Co-Authored-By: Christina Schimpe <christina.schimpe@intel.com>

RISC-V: Allocate "various" operand type

This commit intends to move operands that require very special handling or
operand types that are so minor (e.g. only useful on a few instructions)
under "W".  I also intend this "W" to be "temporary" operand storage until
we can find good two character (or less) operand type.

In this commit, prefetch offset operand "f" for 'Zicbop' extension is moved
to "Wif" because of its special handling (and allocating single character
"f" for this operand type seemed too much).

Current expected allocation guideline is as follows:

1.  'W'
2.  The most closely related single-letter extension in lowercase
    (strongly recommended but not mandatory)
3.  Identify operand type

The author currently plans to allocate following three-character operand
types (for operands including instructions from unratified extensions).

1.  "Wif" ('Zicbop': fetch offset)
2.  "Wfv" (unratified 'Zfa': value operand from FLI.[HSDQ] instructions)
3.  "Wfm" / "WfM"
    'Zfh', 'F', 'D', 'Q': rounding modes "m" with special handling
                          solely for widening conversion instructions.

gas/ChangeLog:

* config/tc-riscv.c (validate_riscv_insn, riscv_ip): Move from
"f" to "Wif".

opcodes/ChangeLog:

* riscv-dis.c (print_insn_args): Move from "f" to "Wif".
* riscv-opc.c (riscv_opcodes): Reflect new operand type.

x86: convert testcases to use .insn

This can't be done for all insns currently encoded with .byte. For one
outside of 64-bit mode unused (typically ignored) register encoding bits
in VEX/XOP/EVEX prefixes can't be set to their non-default values, since
the necessary registers cannot be specified (and some of these bits
can't even be used outside of 64-bit mode). And then there are odd tests
like the first one in bad-bcast.s: Its purpose is to illegaly set EVEX.b
together with EVEX.W (which could be expressed; note though EVEX.W set
is invalid on its own), but then it also clears EVEX.B and EVEX.R' plus
it sets EVEX.vvvv to other than 0xf (rendering the test ambiguous,
because that's another #UD reason).

In {,x86-64-}disassem.s many bogus encodings exist - some with ModR/M
byte but insufficient displacement bytes, some using SIB encoding with
the SIB byte actually being the supposed immediate. Some of these could
be expressed by .insn, but I don't want to introduce bogus examples.
These will all need adjustment anyway once the disassembler is improved
in the way it deals with unrecognized encodings.

Generally generated code is meant to remain the same. {,x86-64-}nops.d
are exceptions because insn prefixes are emitted in a different order.
opcode{,-intel,-suffix}.d are also adjusted (along with an according
correction to opcode.s) to cover an apparent typo in the original tests
(xor when or was meant).

Where necessary --divide is added as gas option, to allow for the use
of the extension opcode functionality.

Comments are being adjusted where obviously wrong/misleading.

x86: document .insn

... and mention its introduction in NEWS.

x86: handle immediate operands for .insn

Since we have no insn suffix and it's also not realistic to infer
immediate size from the size of other (typically register) operands
(like optimize_imm() does), and since we also don't have a template
telling us permitted size(s), a new syntax construct is introduced to
allow size (and signedness) specification. In the absence of such, the
size is inferred from significant bits (which obviously may yield
inconsistent results at least for effectively negative values, depending
on whether BFD64 is enabled), and only if supplied expressions can be
evaluated at parsing time. Being explicit is generally recommended to
users.

Size specification is permitted at bit granularity, but of course the
eventually emitted immediate values will be padded up to 8-, 16-, 32-,
or 64-bit fields.

x86: allow for multiple immediates in output_disp()

.insn isn't going to have a constraint of only a single immediate when,
in particular, RIP-relative addressing is used.

x86: handle EVEX Disp8 for .insn

In particular the scaling factor cannot always be determined from pre-
existing operand attributes. Introduce a new {:d<N>} vector operand
syntax extension, restricted to .insn only, to allow specifying this in
(at least) otherwise ambiguous cases.

x86: process instruction operands for .insn

Deal with register and memory operands; immediate operands will follow
later, as will the handling of EVEX embedded broadcast and EVEX Disp8
scaling.

Note that because we can't really know how to encode their use, %cr8 and
up cannot be used with .insn outside of 64-bit mode. Users would need to
specify an explicit LOCK prefix in combination with %cr0 etc.

x86: parse special opcode modifiers for .insn

So called "short form" encoding is specified by a trailing "+r", whereas
a possible extension opcode is specified by the usual "/<digit>". Take
these off the expression before handing it to get_absolute_expression().

Note that on targets where / starts a comment, --divide needs passing to
gas in order to make use of the extension opcode functionality.

x86: parse VEX and alike specifiers for .insn

All encoding spaces can be used this way; there's a certain risk that
the bits presently reserved could be used for other purposes down the
road, but people using .insn are expected to know what they're doing
anyway. Plus this way there's at least _some_ way to have those bits
set.

For now this will only allow operand-less insns to be encoded this way.

x86: introduce .insn directive

For starters this deals with only very basic constructs.

Arm64/ELF: accept relocations against STN_UNDEF

While only a secondary issue there, the testcase of PR gas/27212 exposes
an oversight in relocation handling: Just like e.g. Arm32, which has a
similar comment and a similar check, relocations against STN_UNDEF have
to be permitted to satisfy the ELF spec.

Automatic date update in version.in

PR gdb/30219: Clear sync_quit_force_run in quit_force

PR 30219 shows an internal error due to a "Bad switch" in
print_exception() in gdb/exceptions.c.  The switch in question
contains cases for RETURN_QUIT and RETURN_ERROR, but is missing a case
for the recently added RETURN_FORCED_QUIT.  This commit adds that case.

Making the above change allows the errant test case to pass, but does
not fix the underlying problem, which I'll describe shortly.  Even
though the addition of a case for RETURN_FORCED_QUIT isn't the actual
fix, I still think it's important to add this case so that other
situations which lead to print_exeption() being called won't generate
that "Bad switch" internal error.

In order to understand the underlying problem, please examine
this portion of the backtrace from the bug report:

0x5576e4ff5780 print_exception
        /home/smarchi/src/binutils-gdb/gdb/exceptions.c:100
0x5576e4ff5930 exception_print(ui_file*, gdb_exception const&)
        /home/smarchi/src/binutils-gdb/gdb/exceptions.c:110
0x5576e6a896dd quit_force(int*, int)
        /home/smarchi/src/binutils-gdb/gdb/top.c:1849

The real problem is in quit_force; here's the try/catch which
eventually leads to the internal error:

  /* Get out of tfind mode, and kill or detach all inferiors.  */
  try
    {
      disconnect_tracing ();
      for (inferior *inf : all_inferiors ())
kill_or_detach (inf, from_tty);
    }
  catch (const gdb_exception &ex)
    {
      exception_print (gdb_stderr, ex);
    }

While running the calls in the try-block, a QUIT check is being
performed.  This check finds that sync_quit_force_run is (still) set,
causing a gdb_exception_forced_quit to be thrown.  The exception
gdb_exception_forced_quit is derived from gdb_exception, causing
exception_print to be called.  As shown by the backtrace,
print_exception is then called, leading to the internal error.

The actual fix, also implemented by this commit, is to clear
sync_quit_force_run along with the quit flag.  This will allow the
various cleanup code, called by quit_force, to run without triggering
a gdb_exception_forced_quit.  (Though, if another SIGTERM is sent to
the gdb process, these flags will be set again and a QUIT check in the
cleanup code will detect it and throw the exception.)

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30219
Approved-By: Simon Marchi <simon.marchi@efficios.com>

aarch64: Remove stray reglist variable

Sorry for not catching this during testing.  I was using a
host compiler that predated the switch to -fno-common.

aarch64: Add the RPRFM instruction

This patch adds the RPRFM (range prefetch) instruction.
It was introduced as part of SME2, but it belongs to the
prefetch hint space and so doesn't require any specific
ISA flags.

The aarch64_rprfmop_array initialiser (deliberately) only
fills in the leading non-null elements.

aarch64: Add the SVE FCLAMP instruction

aarch64: Add new SVE shift instructions

This patch adds the new SVE SQRSHRN, SQRSHRUN and UQRSHRN
instructions.

aarch64: Add new SVE saturating conversion instructions

This patch adds the SVE SQCVTN, SQCVTUN and UQCVTN instructions,
which are available when FEAT_SME2 is implemented.

aarch64: Add new SVE dot-product instructions

This patch adds the SVE FDOT, SDOT and UDOT instructions,
which are available when FEAT_SME2 is implemented.  The patch
also reorders the existing SVE_Zm3_22_INDEX to keep the
operands numerically sorted.

aarch64: Add the SVE BFMLSL instructions

This patch adds the SVE BFMLSLB and BFMLSLT instructions,
which are available when FEAT_SME2 is implemented.

aarch64: Add the SME2 UZP and ZIP instructions

This patch adds UZP and ZIP, which combine UZP{1,2} and ZIP{1,2}
into single instructions.

aarch64: Add the SME2 UNPK instructions

This patch adds SUNPK and UUNPK, which unpack one register's
worth of elements to two registers' worth, or two registers'
worth to four registers' worth.

aarch64: Add the SME2 shift instructions

There are two instruction formats here:

- SQRSHR, SQRSHRU and UQRSHR, which operate on lists of two
  or four registers.

- SQRSHRN, SQRSHRUN and UQRSHRN, which operate on lists of
  four registers.

These are the first SME2 instructions to have immediate operands.
The patch makes sure that, when parsing SME2 instructions with
immediate operands, the new predicate-as-counter registers are
parsed as registers rather than as #-less immediates.

aarch64: Add the SME2 saturating conversion instructions

There are two instruction formats here:

- SQCVT, SQCVTU and UQCVT, which operate on lists of two or
  four registers.

- SQCVTN, SQCVTUN and UQCVTN, which operate on lists of
  four registers.

aarch64: Add the SME2 FP<->FP conversion instructions

This patch adds the BFCVT{,N} and FCVT{,N} instructions,
which narrow a pair of .S registers to a single .H register.

aarch64: Add the SME2 FP<->int conversion instructions

This patch adds the SME2 versions of the FP<->integer conversion
instructions FCVT* and *CVTF.  It also adds FP rounding instructions
FRINT*, which share the same format.

aarch64: Add the SME2 CLAMP instructions

FCLAMP, SCLAMP and UCLAMP share the same format, although FCLAMP
doesn't have a .B form.

aarch64: Add the SME2 MOPA and MOPS instructions

[BSU]MOP[AS] share the same format.

aarch64: Add the SME2 vertical dot-product instructions

There are three instruction formats here:
- BFVDOT + FVDOT
- SVDOT + UVDOT
- SUVDOT + USVDOT

There are also 64-bit forms of SVDOT and UVDOT.

aarch64: Add the SME2 dot-product instructions

BFDOT, FDOT and USDOT share the same instruction format.
SDOT and UDOT share a different format.  SUDOT does not
have the multi vector x multi vector forms, since they
would be redundant with USDOT.

aarch64: Add the SME2 MLALL and MLSLL instructions

SMLALL, SMLSLL, UMLALL and UMLSLL have the same format.
USMLALL and SUMLALL allow the same operand types as those
instructions, except that SUMLALL does not have the multi-vector
x multi-vector forms (which would be redundant with USMLALL).

aarch64: Add the SME2 MLAL and MLSL instructions

The {BF,F,S,U}MLAL and {BF,F,S,U}MLSL instructions share the same
encoding.  They are the first instance of a ZA (as opposed to ZA tile)
operand having a range of offsets.  As with ZA tiles, the expected
range size is encoded in the operand-specific data field.

aarch64: Add the SME2 FMLA and FMLS instructions

aarch64: Add the SME2 maximum/minimum instructions

This patch adds the SME2 multi-register forms of F{MAX,MIN}{,NM}
and {S,U}{MAX,MIN}.  SQDMULH, SRSHL and URSHL have the same form
as SMAX etc., so the patch adds them too.

aarch64: Add the SME2 ADD and SUB instructions

Add support for the SME2 ADD. SUB, FADD and FSUB instructions.
SUB and FSUB have the same form as ADD and FADD, except that
ADD also has a 2-operand accumulating form.

The 64-bit ADD/SUB instructions require FEAT_SME_I16I64 and the
64-bit FADD/FSUB instructions require FEAT_SME_F64F64.

These are the first instructions to have tied register list
operands, as opposed to tied single registers.

The parse_operands change prevents unsuffixed Z registers (width==-1)
from being treated as though they had an Advanced SIMD-style suffix
(.4s etc.).  It means that:

  Error: expected element type rather than vector type at operand 2 -- `add za\.s\[w8,0\],{z0-z1}'

becomes:

  Error: missing type suffix at operand 2 -- `add za\.s\[w8,0\],{z0-z1}'

aarch64: Add the SME2 ZT0 instructions

SME2 adds lookup table instructions for quantisation.  They use
a new lookup table register called ZT0.

LUTI2 takes an unsuffixed SVE vector index of the form Zn[<imm>],
which is the first time that this syntax has been used.

aarch64: Add the SME2 predicate-related instructions

Implementation-wise, the main things to note here are:

- the WHILE* instructions have forms that return a pair of predicate
  registers.  This is the first time that we've had lists of predicate
  registers, and they wrap around after register 15 rather than after
  register 31.

- the predicate-as-counter WHILE* instructions have a fourth operand
  that specifies the vector length.  We can treat this as an enumeration,
  except that immediate values aren't allowed.

- PEXT takes an unsuffixed predicate index of the form PN<n>[<imm>].
  This is the first instance of a vector/predicate index having
  no suffix.

aarch64: Add the SME2 multivector LD1 and ST1 instructions

SME2 adds LD1 and ST1 variants for lists of 2 and 4 registers.
The registers can be consecutive or strided.  In the strided case,
2-register lists have a stride of 8, starting at register x0xxx.
4-register lists have a stride of 4, starting at register x00xx.

The instructions are predicated on a predicate-as-counter register in
the range pn8-pn15.  Although we already had register fields with upper
bounds of 7 and 15, this is the first plain register operand to have a
nonzero lower bound.  The patch uses the operand-specific data field
to record the minimum value, rather than having separate inserters
and extractors for each lower bound.  This in turn required adding
an extra bit to the field.

aarch64: Add the SME2 MOVA instructions

SME2 defines new MOVA instructions for moving multiple registers
to and from ZA.  As with SME, the instructions are also available
through MOV aliases.

One notable feature of these instructions (and many other SME2
instructions) is that some register lists must start at a multiple
of the list's size.  The patch uses the general error "start register
out of range" when this constraint isn't met, rather than an error
specifically about multiples.  This ensures that the error is
consistent between these simple consecutive lists and later
strided lists, for which the requirements aren't a simple multiple.

aarch64: Add support for predicate-as-counter registers

SME2 adds a new format for the existing SVE predicate registers:
predicates as counters rather than predicates as masks.  In assembly
code, operands that interpret predicates as counters are written
pn<N> rather than p<N>.

This patch adds support for these registers and extends some
existing instructions to support them.  Since the new forms
are just a programmer convenience, there's no need to make them
more restrictive than the earlier predicate-as-mask forms.

aarch64; Add support for vector offset ranges

Some SME2 instructions operate on a range of consecutive ZA vectors.
This is indicated by syntax such as:

   za[<Wv>, <imml>:<immh>]

Like with the earlier vgx2 and vgx4 support, we get better error
messages if the parser allows all ZA indices to have a range.
We can then reject invalid cases during constraint checking.

aarch64: Add support for vgx2 and vgx4

Many SME2 instructions operate on groups of 2 or 4 ZA vectors.
This is indicated by adding a "vgx2" or "vgx4" group size to the
ZA index.  The group size is optional in assembly but preferred
for disassembly.

There is not a binary distinction between mnemonics that have
group sizes and mnemonics that don't, nor between mnemonics that
take vgx2 and mnemonics that take vgx4.  We therefore get better
error messages if we allow any ZA index to have a group size
during parsing, and wait until constraint checking to reject
invalid sizes.

A quirk of the way errors are reported means that if an instruction
is wrong both in its qualifiers and its use of a group size, we'll
print suggested alternative instructions that also have an incorrect
group size.  But that's a general property that also applies to
things like out-of-range immediates.  It's also not obviously the
wrong thing to do.  We need to be relatively confident that we're
looking at the right opcode before reporting detailed operand-specific
errors, so doing qualifier checking first seems resonable.

aarch64: Add _off4 suffix to AARCH64_OPND_SME_ZA_array

SME2 adds various new fields that are similar to
AARCH64_OPND_SME_ZA_array, but are distinguished by the size of
their offset fields.  This patch adds _off4 to the name of the
field that we already have.

aarch64: Add a _10 suffix to FLD_imm3

SME2 adds various new 3-bit immediate fields, so this patch adds
an lsb position suffix to the name of the field that we already have.

aarch64: Add +sme2

This patch adds bare-bones support for +sme2.  Later patches
fill in the rest.

aarch64: Prefer register ranges & support wrapping

Until now, binutils has supported register ranges such
as { v0.4s - v3.4s } as an unofficial shorthand for
{ v0.4s, v1.4s, v2.4s, v3.4s }.  The SME2 ISA embraces this form
and makes it the preferred disassembly.  It also embraces wrapped
lists such as { z31.s - z2.s }, which is something that binutils
didn't previously allow.

The range form was already binutils's preferred disassembly for 3- and
4-register lists.  This patch prefers it for 2-register lists too.
The patch also adds support for wrap-around.

aarch64: Add support for strided register lists

SME2 has instructions that accept strided register lists,
such as { z0.s, z4.s, z8.s, z12.s }.  The purpose of this
patch is to extend binutils to support such lists.

The parsing code already had (unused) support for strides of 2.
The idea here is instead to accept all strides during parsing
and reject invalid strides during constraint checking.

The SME2 instructions that accept strided operands also have
non-strided forms.  The errors about invalid strides therefore
take a bitmask of acceptable strides, which allows multiple
possibilities to be summed up in a single message.

I've tried to update all code that handles register lists.

aarch64: Sort fields alphanumerically

This patch just sorts the field enum alphanumerically, which makes
it easier to see if a particular field has already been defined.

aarch64: Resync field names

This patch just makes the comments in aarch64-opc.c:fields match
the names of the associated FLD_* enum.

aarch64: Regularise FLD_* suffixes

Some FLD_imm* suffixes used a counting scheme such as FLD_immN,
FLD_immN_2, FLD_immN_3, etc., while others used the lsb as the
suffix.  The latter seems more mnemonic, and was a big help
in doing the SME2 work.

Similarly, the _10 suffix on FLD_SME_size_10 was nonobvious.
Presumably it indicated a 2-bit field, but it actually starts
in bit 22.

aarch64: Rename some of GAS's REG_TYPE_* macros

In GAS, the vector and predicate registers are identified by
REG_TYPE_VN, REG_TYPE_ZN and REG_TYPE_PN.  This "N" is obviously
a placeholder for the register number.  However, we don't use that
convention for integer and FP registers, and (more importantly)
SME2 adds "predicate-as-counter" registers that are denoted PN.

This patch therefore drops the "N" suffix from the existing
registers.  The main hitch is that Z was also used for the
zero register in things like R_Z, but using ZR seems more
consistent with the SP-based names.

aarch64: Add a aarch64_cpu_supports_inst_p helper

Quite a lot of SME2 instructions have an opcode bit that selects
between 32-bit and 64-bit forms of an instruction, with the 32-bit
forms being part of base SME2 and with the 64-bit forms being part
of an optional extension.  It's nevertheless useful to have a single
opcode entry for both forms since (a) that matches the ISA definition
and (b) it tends to improve error reporting.

This patch therefore adds a libopcodes function called
aarch64_cpu_supports_inst_p that tests whether the target
supports a particular instruction.  In future it will depend
on internal libopcodes routines.

aarch64: Reorder some OP_SVE_* macros

This patch just moves some out-of-order-looking OP_SVE_* macros.

aarch64: Rename aarch64-tbl.h OP_SME_* macros

This patch renames the OP_SME_* macros in aarch64-tbl.h so that
they follow the same scheme as the OP_SVE_* ones.  It also uses
OP_SVE_ as the prefix, since there is no real distinction between
the SVE and SME uses of qualifiers: a macro defined for one can
be useful for the other too.

aarch64: Tweak priorities of parsing-related errors

There are three main kinds of error reported during parsing,
in increasing order of priority:

- AARCH64_OPDE_RECOVERABLE (register seen instead of immediate)
- AARCH64_OPDE_SYNTAX_ERROR
- AARCH64_OPDE_FATAL_SYNTAX_ERROR

This priority makes sense when comparing errors reported against the
same operand.  But if we get to operand 3 (say) and see a register
instead of an immediate, that's likely to be a better match than
something that fails with a syntax error at operand 1.

The idea of this patch is to prioritise parsing-related errors
based on operand index first, then by error code.  Post-parsing
errors still win over parsing errors, and their relative priorities
don't change.

aarch64: Try to report invalid variants against the closest match

If an instruction has invalid qualifiers, GAS would report the
error against the final opcode entry that got to the qualifier-
checking stage.  It seems better to report the error against
the opcode entry that had the closest match, just like we
pick the closest match within an opcode entry for the
"did you mean this?" message.

This patch adds the number of invalid operands as an
argument to AARCH64_OPDE_INVALID_VARIANT and then picks the
AARCH64_OPDE_INVALID_VARIANT with the lowest argument.

aarch64: Tweak register list errors

The error for invalid register lists had the form:

  invalid number of registers in the list; N registers are expected at operand M -- `insn'

This seems a bit verbose.  Also, the "bracketing" is really:

  (invalid number of registers in the list; N registers are expected) at operand M

but the semicolon works against that.

This patch goes for slightly shorter messages, setting a template
that later patches can use for more complex cases.

aarch64: Make AARCH64_OPDE_REG_LIST take a bitfield

AARCH64_OPDE_REG_LIST took a single operand that specified the
expected number of registers.  However, there are quite a few
SME2 instructions that have both 2-register forms and (separate)
4-register forms.  If the user tries to use a 3-register list,
it isn't obvious which opcode entry they meant.  Saying that we
expect 2 registers and saying that we expect 4 registers would
both be wrong.

This patch therefore switches the operand to a bitfield.  If a
AARCH64_OPDE_REG_LIST is reported against multiple opcode entries,
the patch ORs up the expected lengths.

This has no user-visible effect yet.  A later patch adds more error
strings, alongside tests that use them.

aarch64: Add an operand class for SVE register lists

SVE register lists were classified as SVE_REG, since there had been
no particular reason to separate them out.  However, some SME2
instructions have tied register list operands, and so we need to
distinguish registers and register lists when checking whether two
operands match.

Also, the register list operands used a general error message,
even though we already have a dedicated error code for register
lists that are the wrong length.

aarch64: Commonise checks for index operands

This patch splits out the constraint checking for index operands,
so that it can be reused by new SME2 operands.

aarch64: Add an error code for out-of-range registers

libopcodes currently reports out-of-range registers as a general
AARCH64_OPDE_OTHER_ERROR.  However, this means that each register
range needs its own hard-coded string, which is a bit cumbersome
if the range is determined programmatically.  This patch therefore
adds a dedicated error type for out-of-range errors.

aarch64: Deprioritise AARCH64_OPDE_REG_LIST

SME2 has many instructions that take a list of SVE registers.
There are often multiple forms, with different forms taking
different numbers of registers.

This means that if, after a successful parse and qualifier match,
we find that the number of registers does not match the opcode entry,
the associated error should have a lower priority/severity than other
errors reported at the same stage.  For example, if there are 2-register
and 4-register forms of an instruction, and if the assembly code uses
the 2-register form with an out-of-range value, the out-of-range value
error against the 2-register instruction should have a higher priority
than the "wrong number of registers" error against the 4-register
instruction.

This is tested by the main SME2 patches, but seemed worth splitting out.

aarch64: Update operand_mismatch_kind_names

The contents of operand_mismatch_kind_names were out of sync
with the enum.

aarch64: Rework reporting of failed register checks

There are many opcode table entries that share the same mnemonic.
Trying to parse an invalid assembly line will trigger an error for
each of these entries, but the specific error might vary from one
entry to another, depending on the exact nature of the problem.

GAS has quite an elaborate system for picking the most appropriate
error out of all the failed matches.  And in many cases it works well.
However, one of the limitations is that the error is always reported
against a single opcode table entry.  If that table entry isn't the
one that the user intended to use, then the error can end up being
overly specific.

This is particularly true if an instruction has a typoed register
name, or uses a type of register that is not accepted by any
opcode table entry.  For example, one of the expected error
matches for an attempted SVE2 instruction is:

  Error: operand 1 must be a SIMD scalar register -- `addp z32\.s,p0/m,z32\.s,z0\.s'

even though the hypothetical user was presumably attempting to use
the SVE form of ADDP rather than the Advanced SIMD one.  There are
many other instances of this in the testsuite.

The problem becomes especially acute with SME2, since many SME2
instructions reuse existing mnemonics.  This could lead to us
reporting an SME-related error against a non-SME instruction,
or a non-SME-related error against an SME instruction.

This patch tries to improve things by collecting together all
the register types that an opcode table entry expected for a
given operand.  It also records what kind of register was
actually seen, if any.  It then tries to summarise all this
in a more directed way, falling back to a generic error if
the combination defies a neat summary.

The patch includes tests for all new messages except REG_TYPE_ZA,
which only triggers with SME2.

To test this, I created an assembly file that contained the cross
product of all known mnemonics and one example from each register
class.  I then looked for cases where the new routines fell back on the
generic errors ("expected a register" or "unexpected register type").
I locally added dummy messages for each one until there were no
more hits.  The patch adds a specimen instruction to diagnostics.s
for each of these combinations.  In each case, the combination didn't
seem like something that could be summarised in a natural way, so the
generic messages seemed better.  There's always going to be an element
of personal taste around this kind of thing though.

Adding more register types made 1<<REG_TYPE_MAX exceed the range
of the type, but we don't actually need/want 1<<REG_TYPE_MAX.

aarch64: Try to avoid inappropriate default errors

After parsing a '{' and the first register, parse_typed_reg would
report errors in subsequent registers in the same way as for the
first register.  It used set_default_error, which reports errors
of the form "operand N must be X".

The problem is that if there are multiple opcode entries for the
same mnemonic, there could be several matches that lead to a
default error.  There's no guarantee that the default error for
the register list is the one that will be chosen.

To take an example from the testsuite:

    ext z0.b,{z31.b,z32.b},#0

gave:

    operand 2 must be an SVE vector register

with the error being reported against the single-vector version
of ext, even though the operand is clearly a list.

This patch uses set_fatal_syntax_error to bump the priority of the
error once we're sure that the operand is a list of the right type.

aarch64: Improve errors for malformed register lists

parse_typed_reg is used for parsing both bare registers and
registers that occur in lists.  If it doesn't see a register,
or sees an unexpected kind of register, it queues a default
error to report the problem.  These default errors have the form
"operand N must be an X", where X comes from the operand table.

If there are multiple opcode entries that report default errors,
GAS tries to pick the most appropriate one, using the opcode
table order as a tiebreaker.  But this can lead to cases where
a syntax error in a register list is reported against an opcode
that doesn't accept register lists.  For example, the unlikely
error:

  ext z0.b,{,},#0

is reported as:

  operand 2 must be an SVE vector register -- `ext z0.b,{,},#0'

even though operand 2 can be a register list.

If we've parsed the opening '{' of a register list, and then see
something that isn't remotely register-like, it seems better to
report that directly as a syntax error, rather than rely on the
default error.  The operand won't be a valid list of anything,
so there's no need to pick a specific Y in "operand N must be
a list of Y".