gdb: make extract_integer take an array_view

I think it would make sense for extract_integer, extract_signed_integer
and extract_unsigned_integer to take an array_view.  This way, when we
extract an integer, we can validate that we don't overflow the buffer
passed by the caller (e.g. ask to extract a 4-byte integer but pass a
2-byte buffer).

 - Change extract_integer to take an array_view
 - Add overloads of extract_signed_integer and extract_unsigned_integer
   that take array_views.  Keep the existing versions so we don't
   need to change all callers, but make them call the array_view
   versions.

This shortens some places like:

  result = extract_unsigned_integer (value_contents (result_val).data (),
     TYPE_LENGTH (value_type (result_val)),
     byte_order);

into

  result = extract_unsigned_integer (value_contents (result_val), byte_order);

value_contents returns an array view that is of length
`TYPE_LENGTH (value_type (result_val))` already, so the length is
implicitly communicated through the array view.

Change-Id: Ic1c1f98c88d5c17a8486393af316f982604d6c95

gdbsupport: add array_view copy function

An assertion was recently added to array_view::operator[] to ensure we
don't do out of bounds accesses.  However, when the array_view is copied
to or from using memcpy, it bypasses that safety.

To address this, add a `copy` free function that copies data from an
array view to another, ensuring that the destination and source array
views have the same size.  When copying to or from parts of an
array_view, we are expected to use gdb::array_view::slice, which does
its own bounds check.  With all that, any copy operation that goes out
of bounds should be caught by an assertion at runtime.

copy is implemented using std::copy and std::copy_backward, which, at
least on libstdc++, appears to pick memmove when copying trivial data.
So in the end there shouldn't be much difference vs using a bare memcpy,
as we do right now.  When copying non-trivial data, std::copy and
std::copy_backward assigns each element in a loop.

To properly support overlapping ranges, we must use std::copy or
std::copy_backward, depending on whether the destination is before the
source or vice-versa.  std::copy and std::copy_backward don't support
copying exactly overlapping ranges (where the source range is equal to
the destination range).  But in this case, no copy is needed anyway, so
we do nothing.

The order of parameters of the new copy function is based on std::copy
and std::copy_backward, where the source comes before the destination.

Change a few randomly selected spots to use the new function, to show
how it can be used.

Add a test for the new function, testing both with arrays of a trivial
type (int) and of a non-trivial type (foo).  Test non-overlapping
ranges as well as three kinds of overlapping ranges: source before dest,
dest before source, and dest == source.

Change-Id: Ibeaca04e0028410fd44ce82f72e60058d6230a03

gdb: change store_waitstatus to return a target_waitstatus by value

store_waitstatus is basically a translation function between a status
integer and an equivalent target_waitstatus object.  It would make sense
for it to take the integer as a parameter and return the
target_waitstatus by value.  Do that, and rename to
host_status_to_waitstatus.  Users can then do:

  ws = host_status_to_waitstatus (status)

which does the right thing, given the move constructor of
target_waitstatus.

Change-Id: I7a07d59d3dc19d3ed66929642f82f44f3e85d61b

gdb: return *this in target_waitstatus setters

While playing with some code creating target_waitstatus objects, I was
mildly annoyed by the fact that we can't just return a new
target_waitstatus object.  We have to do:

    target_waitstatus ws;
    ws.set_exited (123);
    return ws;

Make the setters return the "this" object as a reference, such that it's
possible to do:

    return target_waitstatus ().set_exited (123);

I initially thought of adding static creation functions, which you would
use like:

    return target_waitstatus::make_exited (123);

However, making the setters return a reference to the object achieves
pretty much the same thing, with less new code.

Change-Id: I45159b7f9fcd9db5b20603480e323020b14ed147

gdb: make saved_filename an std::string

Make this variable an std::string, avoiding manual memory management.

Change-Id: Ie7a8d7381449ab9c4dfc4cb8b99e63b9ffa8f947

aarch64: Fix uninitialised memory

AARCH64_OPDE_EXPECTED_A_AFTER_B and AARCH64_OPDE_A_SHOULD_FOLLOW_B
are not paired with an error string, but we had an assert that the
error was nonnull.  Previously this assert was testing uninitialised
memory and so could pass or fail arbitrarily.

opcodes/
* aarch64-opc.c (verify_mops_pme_sequence): Initialize the error
field to null for AARCH64_OPDE_EXPECTED_A_AFTER_B and
AARCH64_OPDE_A_SHOULD_FOLLOW_B.
* aarch64-dis.c (print_verifier_notes): Move assert.

gdb: make value_subscripted_rvalue static

The function value_subscripted_rvalue is only used in valarith.c, so
lets make it a static function.

There should be no user visible change after this commit.

gdb/testsuite: give a test a real name

A test in gdb.python/py-send-packet.exp added in this commit:

  commit 24b2de7b776f8f23788d855b1eec290c6e208821
  Date:   Tue Aug 31 14:04:36 2021 +0100

      gdb/python: add gdb.RemoteTargetConnection.send_packet

included a large amount of binary data in the command sent to GDB.  As
this test didn't have a real test name the binary data was included in
the gdb.sum file.  The contents of the binary data could change
between different runs of GDB, and this makes comparing results
harder.

This commit gives the test a real test name.

gdb/remote: fix use after free bug

This commit:

  commit 288712bbaca36bff6578bc839ebcdc3707662f81
  Date:   Mon Nov 22 15:16:27 2021 +0000

      gdb/remote: use scoped_restore to control starting_up flag

introduced a use after free bug.  The scoped restore added in the
above commit resets a flag within a remote_target's remote_state
object.

However, in some situations, the remote_target can be unpushed before
the error is thrown.  If the only reference to the target is the one
in the target stack, then unpushing the target will cause the
remote_target to be deleted, which, in turn, will delete the
remote_state object.  The scoped restore will then try to reset the
flag within a deleted object.

This problem was caught in the gdb.server/server-connect.exp test,
which, when run with the address sanitizer enabled, highlights the
write after free bug described above.

This commit resolves this issue by adding a new class specifically for
the purpose of managing the starting_up flag.  As well as setting, and
then clearing the starting_up flag, this new class increments, and
then decrements the reference count on the remote_target object.  This
prevents the remote_target from being deleted until after the flag has
been reset.

The gdb.server/server-connect.exp now runs cleanly with the address
sanitizer enabled.

libctf: workaround automake bug with conditional info pages

It looks like automake makes assumptions about its ability to build info
pages based on the GNU standard behavior of shipping info pages with the
distributions.  So even though the info pages were conditionalized, and
automake disabled some of the targets, it was still creeping in by way
of unconditional INFO_DEPS settings.

We can workaround this by adding a stub target for the info page when
building info pages are disabled.  This tricks automake into disabling
its own extended generation target.  I'll follow up with the automake
folks to see what they think.

Add myself and Zhensong Liu as the LoongArch port maintainer.

Revert "Re: Don't compile some opcodes files when bfd is 32-bit only"

This reverts commit 7a53275579e7cec9389ccb924f5ecf69e8d89d41.
The bpf sim doesn't work with a 32-bit bfd after all.

Automatic date update in version.in

gdb: remove unexpected xstrdup in _initialize_maint_test_settings

That xstrdup is not correct, since we are assigning an std::string.  The
result of xstrdup is used to initialize the string, and then lost
forever.  Remove it.

Change-Id: Ief7771055e4bfd643ef3b285ec9fb7b1bfd14335

Fix illegal memory access whilst parsing corrupt DWARF debug information.

PR 28645
* dwarf.c (process_cu_tu_index): Add test for overruning section
whilst processing slots.

[gdb/tdep] Fix avx512 -m32 support in gdbserver

PR27257 reports a problem that can be reproduced as follows:
- use x86_64 machine with avx512 support
- compile a hello world with -m32 to a.out
- start a gdbserver session with a.out
- use gdb to connect to the gdbserver session

This makes us run into:
...
Listening on port 2346
Remote debugging from host ::1, port 34940
src/gdbserver/regcache.cc:257: \
  A problem internal to GDBserver has been detected.
Unknown register zmm16h requested
...

The problem is that i387_xsave_to_cache in gdbserver/i387-fp.cc can't find a
register zmm16h in the register cache.

To understand how this happens, first some background.

SSE has 16 128-bit wide xmm registers.

AVX extends the SSE registers set as follows:
- it extends the 16 existing 128-bit wide xmm registers to 256-bit wide ymm
  registers.

AVX512 extends the AVX register set as follows:
- it extends the 16 existing 256-bit wide ymm registers to 512-bit wide zmm
  registers.
- it adds 16 additional 512-bit wide zmm registers (with corresponding ymm and
  xmm subregisters added as well)

However, in 32-bit mode, there are only 8 xmm/ymm/zmm registers.

The problem we're running into is that gdbserver/i387-fp.cc uses these
constants to describe the size of the register file:
...
static const int num_avx512_zmmh_low_registers = 16;
static const int num_avx512_zmmh_high_registers = 16;
static const int num_avx512_ymmh_registers = 16;
static const int num_avx512_xmm_registers = 16;
...
which are all incorrect for the 32-bit case.

Fix this by replacing the constants with variables that have the appropriate
values in 64-bit and 32-bit mode.

Tested on x86_64-linux with native and unix/-m32.

gdb/testsuite: update tests looking for "DWARF 2" debug format

Commit ab557072b8ec ("gdb: use actual DWARF version in compunit's
debugformat field") changes the debug format string in "info source" to
show the actual DWARF version, rather than always show "DWARF 2".

However, it failed to consider that some tests checked for the "DWARF 2"
string to see if the test program is compiled with DWARF debug
information.  Since everything is compiled with DWARF 4 or 5 nowadays,
that changed the behavior of those tests.  Notably, it prevent the
tests using skip_inline_var_tests to run.

Grep through the testsuite for "DWARF 2" and change all occurrences I
could find to use "DWARF [0-9]" instead (that string is passed to TCL's
string match).

Change-Id: Ic7fb0217fb9623880c6f155da6becba0f567a885

(PPC64) fix handling of fixed-point values when using "return" command

In the gdb.ada/fixed_points_function.exp testcase, we have the following
Ada code...

   type FP1_Type is delta 0.1 range -1.0 .. +1.0; --  Ordinary
   function Call_FP1 (F : FP1_Type) return FP1_Type is
   begin
      FP1_Arg := F;
      return FP1_Arg;
   end Call_FP1;

... used as follow:

   F1 : FP1_Type := 1.0;
   F1 := Call_FP1 (F1);

The testcase, among other things, verifies that "return" works
properly as follow:

    | (gdb) return 1.0
    | Make pck.call_fp1 return now? (y or n) y
    | [...]
    | 9          F1 := Call_FP1 (F1);
    | (gdb) next
    | (gdb) print f1
    | $1 = 0.0625

The output of the last command shows that we returned the wrong
value. The value printed gives a clue about the problem, since
it is 1/16th of the value we expected, where 1/16 is FP1_Type's
scaling factor.

The problem, here, comes from the fact that the function
handling return values for base types (ppc64_sysv_abi_return_value_base)
writes the return value using unpack_long which, upon seeing that
the value being unpacked is a fixed point type, applies the scaling
factor, to get the integer-representation of our fixed-point value
(similar to what it does with floats, for instance).

So, the fix consists in teaching ppc64_sysv_abi_return_value_base
about fixed-point types, and to avoid the unwanted application
of the scaling factor.

Note that the "finish" function, on the other hand, does not
suffer from this issue, simply becaue the value returned by
the function is read from register without the use of a type,
thus avoiding an unwanted application of a scaling factor.

No test added, as this change is already tested by
gdb.ada/fixed_points_function.exp.

Co-Authored-By: Tristan Gingold <gingold@adacore.com>

(RISCV) fix handling of fixed-point type return values

This commit adds support for TYPE_CODE_FIXED_POINT types for
"finish" and "return" commands.

Consider the following Ada code...

   type FP1_Type is delta 0.1 range -1.0 .. +1.0; --  Ordinary
   function Call_FP1 (F : FP1_Type) return FP1_Type is
   begin
      FP1_Arg := F;
      return FP1_Arg;
   end Call_FP1;

... used as follow:

   F1 : FP1_Type := 1.0;
   F1 := Call_FP1 (F1);

"finish" currently behaves as follow:

    | (gdb) finish
    | [...]
    | Value returned is $1 = 0

We expect the returned value to be "1".

Similarly, "return" makes the function return the wrong value:

    | (gdb) return 1.0
    | Make pck.call_fp1 return now? (y or n) y
    | [...]
    | 9          F1 := Call_FP1 (F1);
    | (gdb) next
    | (gdb) print f1
    | $1 = 0.0625

(we expect it to print "1" instead).

This problem comes from the handling of integral return values
when the return value is actually fixed point type. Our type
here is actually a range of a fixed point type, but the same
principles should also apply to pure fixed-point types. For
the record, here is what the debugging info looks like:

 <1><238>: Abbrev Number: 2 (DW_TAG_subrange_type)
    <239>   DW_AT_lower_bound : -16
    <23a>   DW_AT_upper_bound : 16
    <23b>   DW_AT_name        : pck__fp1_type
    <23f>   DW_AT_type        : <0x248>

 <1><248>: Abbrev Number: 4 (DW_TAG_base_type)
    <249>   DW_AT_byte_size   : 1
    <24a>   DW_AT_encoding    : 13      (signed_fixed)
    <24b>   DW_AT_binary_scale: -4
    <24c>   DW_AT_name        : pck__Tfp1_typeB
    <250>   DW_AT_artificial  : 1

... where the scaling factor is 1/16.

Looking at the "finish" command, what happens is that riscv_arg_location
determines that our return value should be returned by parameter using
an integral convention (via builtin type long). And then,
riscv_return_value uses a cast to that builtin type long to
store the value of into a buffer with the right register size.
This doesn't work in our case, because the underlying value
returned by the function is unscaled, which means it is 16,
and thus the cast is like doing:

   arg_val = (FP1_Type) 16

... In other words, it is trying to create an FP1_Type enty whose
value is 16. Applying the scaling factor, that's 256, and because
the size of FP1_Type is 1 byte, we overflow and thus it ends up
being zero.

The same happen with the "return" function, but the other way around.

The fix consists in handling fixed-point types separately from
integral types.

(ARM/fixed-point) wrong value shown by "finish" command:

Consider the following Ada code:

   type FP1_Type is delta 0.1 range -1.0 .. +1.0; --  Ordinary
   FP1_Arg : FP1_Type := 0.0;

   function Call_FP1 (F : FP1_Type) return FP1_Type is
   begin
      FP1_Arg := F;
      return FP1_Arg;
   end Call_FP1;

After having stopped inside function Call_FP1 as follow:

    Breakpoint 1, pck.call_fp1 (f=1) at /[...]/pck.adb:5
    5             FP1_Arg := F;

Returning from that function call using "finish" should show
that the function return "1.0" (the same value as was passed
as an argument). However, this is not the case:

    (gdb) finish
    Run till exit from #0  pck.call_fp1 (f=1)
    [...]
    9          F1 := Call_FP1 (F1);
    Value returned is $1 = 0

This patch enhances the extraction of the return value to know about
fixed point types.

(Ada/AArch64) fix fixed point argument passing in inferior funcall

Consider the following code:

   type FP1_Type is delta 0.1 range -1.0 .. +1.0; --  Ordinary

   function Call_FP1 (F : FP1_Type) return FP1_Type is
   begin
      return F;
   end Call_FP1;

When the default in GCC is to generate proper DWARF info for fixed point
types, then in gdb, printing the result of a call to call_fp1 with a
decimal parameter leads to:

  (gdb) p call_fp1(0.5)
  $1 = 0

The displayed value is wrong, and we actually expected:

  (gdb) p call_fp1(0.5)
  $1 = 0.5

What happened is that our fixed point type parameter got promoted to a
32bit integer because we detected that the length of that object was less
than 4 bytes. The compiler does not perform this promotion and therefore
GDB should not either.

This patch fixes the behavior described above.

Implement 'task apply'

This adds a 'task apply' command, which is the Ada tasking analogue of
'thread apply'.  Unlike 'thread apply', it doesn't offer the
'ascending' flag; but otherwise it's essentially the same.

Add "task" keyword to the "watch" command

Breakpoints in gdb can be made specific to an Ada task using the
"task" qualifier.  This patch applies this same idea to watchpoints.

aarch64: Update gas/NEWS for recent changes

gas/
* NEWS: Mention support for Armv8.8-A and for new system registers.

aarch64: Add BC instruction

This patch adds support for the Armv8.8-A BC instruction.
[https://developer.arm.com/documentation/ddi0596/2021-09/Base-Instructions/BC-cond--Branch-Consistent-conditionally-?lang=en]

include/
* opcode/aarch64.h (AARCH64_FEATURE_HBC): New macro.
(AARCH64_ARCH_V8_8): Make armv8.8-a imply AARCH64_FEATURE_HBC.

opcodes/
* aarch64-tbl.h (aarch64_feature_hbc): New variable.
(HBC, HBC_INSN): New macros.
(aarch64_opcode_table): Add BC.C.
* aarch64-dis-2.c: Regenerate.

gas/
* doc/c-aarch64.texi: Document +hbc.
* config/tc-aarch64.c (aarch64_features): Add "hbc".
* testsuite/gas/aarch64/hbc.s, testsuite/gas/aarch64/hbc.d: New test.
* testsuite/gas/aarch64/hbc-invalid.s,
testsuite/gas/aarch64/hbc-invalid.l,
testsuite/gas/aarch64/hbc-invalid.d: New test.

aarch64: Enforce P/M/E order for MOPS instructions

The MOPS instructions should be used as a triple, such as:

       cpyfp [x0]!, [x1]!, x2!
       cpyfm [x0]!, [x1]!, x2!
       cpyfe [x0]!, [x1]!, x2!

The registers should also be the same for each writeback operand.
This patch adds a warning for code that doesn't follow this rule,
along similar lines to the warning that we already emit for
invalid uses of MOVPRFX.

include/
* opcode/aarch64.h (C_SCAN_MOPS_P, C_SCAN_MOPS_M, C_SCAN_MOPS_E)
(C_SCAN_MOPS_PME): New macros.
(AARCH64_OPDE_A_SHOULD_FOLLOW_B): New aarch64_operand_error_kind.
(AARCH64_OPDE_EXPECTED_A_AFTER_B): Likewise.
(aarch64_operand_error): Make each data value a union between
an int and a string.

opcodes/
* aarch64-tbl.h (MOPS_CPY_OP1_OP2_INSN): Add scan flags.
(MOPS_SET_OP1_OP2_INSN): Likewise.
* aarch64-opc.c (set_out_of_range_error): Update after change to
aarch64_operand_error.
(set_unaligned_error, set_reg_list_error): Likewise.
(init_insn_sequence): Use a 3-instruction sequence for
MOPS P instructions.
(verify_mops_pme_sequence): New function.
(verify_constraints): Call it.
* aarch64-dis.c (print_verifier_notes): Handle
AARCH64_OPDE_A_SHOULD_FOLLOW_B and AARCH64_OPDE_EXPECTED_A_AFTER_B.

gas/
* config/tc-aarch64.c (operand_mismatch_kind_names): Add entries
for AARCH64_OPDE_A_SHOULD_FOLLOW_B and AARCH64_OPDE_EXPECTED_A_AFTER_B.
(operand_error_higher_severity_p): Check that
AARCH64_OPDE_A_SHOULD_FOLLOW_B and AARCH64_OPDE_EXPECTED_A_AFTER_B
come between AARCH64_OPDE_RECOVERABLE and AARCH64_OPDE_SYNTAX_ERROR;
their relative order is not significant.
(record_operand_error_with_data): Update after change to
aarch64_operand_error.
(output_operand_error_record): Likewise.  Handle
AARCH64_OPDE_A_SHOULD_FOLLOW_B and AARCH64_OPDE_EXPECTED_A_AFTER_B.
* testsuite/gas/aarch64/mops_invalid_2.s,
testsuite/gas/aarch64/mops_invalid_2.d,
testsuite/gas/aarch64/mops_invalid_2.l: New test.

aarch64: Add support for +mops

This patch adds support for FEAT_MOPS, an Armv8.8-A extension
that provides memcpy and memset acceleration instructions.

I took the perhaps controversial decision to generate the individual
instruction forms using macros rather than list them out individually.
This becomes useful with a follow-on patch to check that code follows
the correct P/M/E sequence.
[https://developer.arm.com/documentation/ddi0596/2021-09/Base-Instructions?lang=en]

include/
* opcode/aarch64.h (AARCH64_FEATURE_MOPS): New macro.
(AARCH64_ARCH_V8_8): Make armv8.8-a imply AARCH64_FEATURE_MOPS.
(AARCH64_OPND_MOPS_ADDR_Rd): New aarch64_opnd.
(AARCH64_OPND_MOPS_ADDR_Rs): Likewise.
(AARCH64_OPND_MOPS_WB_Rn): Likewise.

opcodes/
* aarch64-asm.h (ins_x0_to_x30): New inserter.
* aarch64-asm.c (aarch64_ins_x0_to_x30): New function.
* aarch64-dis.h (ext_x0_to_x30): New extractor.
* aarch64-dis.c (aarch64_ext_x0_to_x30): New function.
* aarch64-tbl.h (aarch64_feature_mops): New feature set.
(aarch64_feature_mops_memtag): Likewise.
(MOPS, MOPS_MEMTAG, MOPS_INSN, MOPS_MEMTAG_INSN)
(MOPS_CPY_OP1_OP2_PME_INSN, MOPS_CPY_OP1_OP2_INSN, MOPS_CPY_OP1_INSN)
(MOPS_CPY_INSN, MOPS_SET_OP1_OP2_PME_INSN, MOPS_SET_OP1_OP2_INSN)
(MOPS_SET_INSN): New macros.
(aarch64_opcode_table): Add MOPS instructions.
(aarch64_opcode_table): Add entries for AARCH64_OPND_MOPS_ADDR_Rd,
AARCH64_OPND_MOPS_ADDR_Rs and AARCH64_OPND_MOPS_WB_Rn.
* aarch64-opc.c (aarch64_print_operand): Handle
AARCH64_OPND_MOPS_ADDR_Rd, AARCH64_OPND_MOPS_ADDR_Rs and
AARCH64_OPND_MOPS_WB_Rn.
(verify_three_different_regs): New function.
* aarch64-asm-2.c: Regenerate.
* aarch64-dis-2.c: Likewise.
* aarch64-opc-2.c: Likewise.

gas/
* doc/c-aarch64.texi: Document +mops.
* config/tc-aarch64.c (parse_x0_to_x30): New function.
(parse_operands): Handle AARCH64_OPND_MOPS_ADDR_Rd,
AARCH64_OPND_MOPS_ADDR_Rs and AARCH64_OPND_MOPS_WB_Rn.
(aarch64_features): Add "mops".
* testsuite/gas/aarch64/mops.s, testsuite/gas/aarch64/mops.d: New test.
* testsuite/gas/aarch64/mops_invalid.s,
* testsuite/gas/aarch64/mops_invalid.d,
* testsuite/gas/aarch64/mops_invalid.l: Likewise.

aarch64: Add Armv8.8-A system registers

Armv8.8-A defines two new system registers: allint and icc_nmiar1_el1.
Both of them were previously unmapped.  allint supports a 0/1 immediate.
[https://developer.arm.com/documentation/ddi0595/2021-09/AArch64-Registers/ALLINT--All-Interrupt-Mask-Bit?lang=en]
[https://developer.arm.com/documentation/ddi0595/2021-09/AArch64-Registers/ICC-NMIAR1-EL1--Interrupt-Controller-Non-maskable-Interrupt-Acknowledge-Register-1?lang=en]

opcodes/
* aarch64-opc.c (SR_V8_8): New macro.
(aarch64_sys_regs): Add allint and icc_nmiar1_el1.
(aarch64_pstatefields): Add allint.

gas/
* testsuite/gas/aarch64/armv8_8-a-sysregs.s,
* testsuite/gas/aarch64/armv8_8-a-sysregs.d: New test.
* testsuite/gas/aarch64/armv8_8-a-sysregs-invalid.s,
* testsuite/gas/aarch64/armv8_8-a-sysregs-invalid.l,
* testsuite/gas/aarch64/armv8_8-a-sysregs-invalid.d: New test.

aarch64: Add id_aa64isar2_el1

Armv8.8-A defines a read-only system register called id_aa64isar2_el1.
The register was previously RES0 and should therefore be accepted
at all architecture levels.
[https://developer.arm.com/documentation/ddi0595/2021-09/AArch64-Registers/ID-AA64ISAR2-EL1--AArch64-Instruction-Set-Attribute-Register-2?lang=en]

opcodes/
* aarch64-opc.c (aarch64_sys_regs): Add id_aa64isar2_el1.

gas/
* testsuite/gas/aarch64/sysreg-diagnostic.s: Test writes to
id_aa64isar2_el1.
* testsuite/gas/aarch64/sysreg-diagnostic.d: Update accordingly.
* testsuite/gas/aarch64/sysreg-diagnostic.l: Likewise.
* testsuite/gas/aarch64/sysreg.s: Test reads from
id_aa64isar2_el1.
* testsuite/gas/aarch64/sysreg.d: Update accordingly.

aarch64: Add support for Armv8.8-A

This patch adds skeleton support for -march=armv8.8-a, testing only
that it correctly inherits from armv8.7-a.

include/
* opcode/aarch64.h (AARCH64_FEATURE_V8_8): New macro.
(AARCH64_ARCH_V8_8): Likewise.

gas/
* doc/c-aarch64.texi: Document armv8.8-a.
* config/tc-aarch64.c (aarch64_archs): Add armv8-8-a
* testsuite/gas/aarch64/v8-8-a.s,
* testsuite/gas/aarch64/v8-8-a.d: New test.

aarch64: Provide line info for unclosed sequences

We warn about MOVPRFX instructions that have no following
instruction.  This patch adds a line number to the message,
which is useful if the assembly code has multiple text sections.

The new code is unconditional since OBJ_ELF is always defined
for aarch64.

gas/
* config/tc-aarch64.h (aarch64_segment_info_type): Add last_file
and last_line.
* config/tc-aarch64.c (now_instr_sequence): Delete.
(force_automatic_sequence_close): Provide a line number when
reporting unclosed sequences.
(md_assemble): Record the location of the instruction in
tc_segment_info.
* testsuite/gas/aarch64/sve-movprfx_4.l: Add line number to error
message.
* testsuite/gas/aarch64/sve-movprfx_7.l: Likewise.
* testsuite/gas/aarch64/sve-movprfx_8.l: Likewise.

aarch64: Tweak insn sequence code

libopcodes has some code to check constraints across sequences
of consecutive instructions.  It was added to support MOVPRFX
sequences but is going to be useful for the Armv8.8-A MOPS
feature as well.

Currently the structure has one field to record the instruction
that started a sequence and another to record the remaining
instructions in the sequence.  It's more convenient for the
MOPS code if we put the instructions into a single array instead.

No functional change intended.

include/
* opcode/aarch64.h (aarch64_instr_sequence): Replace num_insns
and current_insns with num_added_insns and num_allocated_insns.

opcodes/
* aarch64-opc.c (add_insn_to_sequence): New function.
(init_insn_sequence): Update for new aarch64_instr_sequence layout.
Add the first instruction to the inst array.
(verify_constraints): Update for new aarch64_instr_sequence layout.
Don't add the last instruction to the array.

aarch64: Add maximum immediate value to aarch64_sys_reg

The immediate form of MSR has a 4-bit immediate field (in CRm).
However, many forms of MSR require a smaller immediate.  These cases
are identified by value in operand_general_constraint_met_p,
but they're now the common case rather than the exception.

This patch therefore adds the maximum value to the sys_reg
description and gets the range from there.  It also enforces
the minimum of 0, which avoids a situation in which:

  msr dit, #2

would give the expected:

  Error: immediate value out of range 0 to 1

whereas:

  msr dit, #-1

would give:

  Error: immediate value out of range 0 to 15

(from the later UIMM4 checking).

Also:

- we were reporting the first error above against the wrong operand
- TCO takes a single-bit immediate, but we previously allowed
  all 16 values.
  [https://developer.arm.com/documentation/ddi0596/2021-09/Base-Instructions/MSR--immediate---Move-immediate-value-to-Special-Register-?lang=en]

opcodes/
* aarch64-opc.h (F_REG_MAX_VALUE, F_GET_REG_MAX_VALUE): New macros.
* aarch64-opc.c (operand_general_constraint_met_p): Read the
maximum MSR immediate value from aarch64_pstatefields.
(aarch64_pstatefields): Add the maximum immediate value
for each register.

gas/
* testsuite/gas/aarch64/sysreg-4.s: Use an immediate value of 1
rather than 8 for the TCO test.
* testsuite/gas/aarch64/sysreg-4.d: Update accordingly.
* testsuite/gas/aarch64/armv8_2-a-illegal.l: Fix operand number
in MSR immediate error messages.
* testsuite/gas/aarch64/diagnostic.l: Likewise.
* testsuite/gas/aarch64/pan-illegal.l: Likewise.
* testsuite/gas/aarch64/ssbs-illegal1.l: Likewise.
* testsuite/gas/aarch64/illegal-sysreg-4b.s,
* testsuite/gas/aarch64/illegal-sysreg-4b.d,
* testsuite/gas/aarch64/illegal-sysreg-4b.l: New test.

Allow the --visualize-jumps feature to work with the AVR disassembler.

* avr-dis.c (avr_operand); Pass in disassemble_info and fill
in insn_type on branching instructions.

gdb, include: replace pragmas with DIAGNOSTIC macros, fix build with g++ 4.8

When introducing this code, I forgot that we had some macros for this.
Replace some "manual" pragma diagnostic with some DIAGNOSTIC_* macros,
provided by include/diagnostics.h.

In diagnostics.h:

 - Add DIAGNOSTIC_ERROR, to enable a diagnostic at error level.
 - Add DIAGNOSTIC_ERROR_SWITCH, to enable -Wswitch at error level, for
   both gcc and clang.

Additionally, using DIAGNOSTIC_PUSH, DIAGNOSTIC_ERROR_SWITCH and
DIAGNOSTIC_POP seems to misbehave with g++ 4.8, where we see these
errors:

      CXX    ada-tasks.o
    /home/smarchi/src/binutils-gdb/gdb/ada-tasks.c: In function void read_known_tasks():
    /home/smarchi/src/binutils-gdb/gdb/ada-tasks.c:998:10: error: enumeration value ADA_TASKS_UNKNOWN not handled in switch [-Werror=switch]
       switch (data->known_tasks_kind)
              ^

Because of the POP, the diagnostic should go back to being disabled,
since it was disabled in the beginning, but that's not what we see
here.  Versions of GCC >= 5 compile correctly.

Work around this by making DIAGNOSTIC_ERROR_SWITCH a no-op for GCC < 5.

Note that this code (already as it exists in master today) enables
-Wswitch at the error level even if --disable-werror is passed.  It
shouldn't be a problem, as it's not like a new enumerator will appear
out of nowhere and cause a build error if building with future
compilers.  Still, for correctness, we would ideally want to ask the
compiler to enable -Wswitch at its default level (as if the user had
passed -Wswitch on the command-line).  There doesn't seem to be a way to
do this.

Change-Id: Id33ebec3de39bd449409ea0bab59831289ffe82d

gas: re-generate configure

When configuring gas, I get:

  config.status: error: cannot find input file: `doc/Makefile.in'

This is because configure is out-of-date, re-generate it.

Change-Id: Iaa5980c282900d9fd23b90f0df25bf8ba3676498

libctf: re-generate configure

When configuring libctf, I get:

  config.status: error: cannot find input file: `doc/Makefile.in'

This is because configure is out-of-date, re-generate it.

Change-Id: Ie69acd33012211a4620661582c7d24ad6d2cd169

x86: Skip __[start|stop]_SECNAME for --gc-sections -z start-stop-gc

Don't convert memory load to immediate load on __start_SECNAME and
__stop_SECNAME for --gc-sections -z start-stop-gc if all SECNAME
sections been garbage collected.

bfd/

PR ld/27491
* elf32-i386.c (elf_i386_convert_load_reloc): Skip __start_SECNAME
and __stop_SECNAME for --gc-sections -z start-stop-gc if the input
section been garbage collected.
* elf64-x86-64.c (elf_x86_64_convert_load_reloc): Likewise.
* elfxx-x86.h (elf_x86_start_stop_gc_p): New function.

ld/
PR ld/27491
* testsuite/ld-i386/i386.exp: Run PR ld/27491 tests.
* testsuite/ld-x86-64/x86-64.exp: Likewise.
* testsuite/ld-i386/pr27491-1.s: New file.
* testsuite/ld-i386/pr27491-1a.d: Likewise.
* testsuite/ld-i386/pr27491-1b.d: Likewise.
* testsuite/ld-i386/pr27491-1c.d: Likewise.
* testsuite/ld-i386/pr27491-2.d: Likewise.
* testsuite/ld-i386/pr27491-2.s: Likewise.
* testsuite/ld-i386/pr27491-3.d: Likewise.
* testsuite/ld-i386/pr27491-3.s: Likewise.
* testsuite/ld-i386/pr27491-4.d: Likewise.
* testsuite/ld-i386/pr27491-4a.s: Likewise.
* testsuite/ld-i386/pr27491-4b.s: Likewise.
* testsuite/ld-x86-64/pr27491-1.s: Likewise.
* testsuite/ld-x86-64/pr27491-1a.d: Likewise.
* testsuite/ld-x86-64/pr27491-1b.d: Likewise.
* testsuite/ld-x86-64/pr27491-1c.d: Likewise.
* testsuite/ld-x86-64/pr27491-2.d: Likewise.
* testsuite/ld-x86-64/pr27491-2.s: Likewise.
* testsuite/ld-x86-64/pr27491-3.d: Likewise.
* testsuite/ld-x86-64/pr27491-3.s: Likewise.
* testsuite/ld-x86-64/pr27491-4.d: Likewise.
* testsuite/ld-x86-64/pr27491-4a.s: Likewise.
* testsuite/ld-x86-64/pr27491-4b.s: Likewise.

bfd: delete unused proto settings

These have been around for decades but don't appear to be used, and
trying to build them (e.g. `make archive.p archive.ip`) doesn't work,
so just delete it all.

gas: merge doc subdir up a level

This avoids a recursive make into the doc subdir and speeds up the
build slightly.  It also allows for more parallelism.

libctf: merge doc subdir up a level

This avoids a recursive make into the doc subdir and speeds up the
build slightly.  It also allows for more parallelism.

gdb: use actual DWARF version in compunit's debugformat field

The "info source" command, with a DWARF-compile program, always show
that the debug info is "DWARF 2":

    (gdb) info source
    Current source file is test.c
    Compilation directory is /home/smarchi/build/binutils-gdb/gdb
    Located in /home/smarchi/build/binutils-gdb/gdb/test.c
    Contains 2 lines.
    Source language is c.
    Producer is GNU C17 9.3.0 -mtune=generic -march=x86-64 -g3 -gdwarf-5 -O0 -fasynchronous-unwind-tables -fstack-protector-strong -fstack-clash-protection -fcf-protection.
    Compiled with DWARF 2 debugging format.
    Includes preprocessor macro info.

Change it to display the actual DWARF version:

    (gdb) info source
    Current source file is test.c
    Compilation directory is /home/smarchi/build/binutils-gdb/gdb
    Located in /home/smarchi/build/binutils-gdb/gdb/test.c
    Contains 2 lines.
    Source language is c.
    Producer is GNU C17 9.3.0 -mtune=generic -march=x86-64 -g3 -gdwarf-5 -O0 -fasynchronous-unwind-tables -fstack-protector-strong -fstack-clash-protection -fcf-protection.
    Compiled with DWARF 5 debugging format.
    Includes preprocessor macro info.

The comp_unit_head::version field is guaranteed to be between 2 and 5,
thanks to the check in read_comp_unit_head.  So we can still use static
strings to pass to record_debugformat, and keep it efficient.

In the future, when somebody will update GDB to support DWARF 6, they'll
hit this assert and have to update this code.

Change-Id: I3270b7ebf5e9a17b4215405bd2e365662a4d6172

elf: Discard input .note.gnu.build-id sections

1. Discard input .note.gnu.build-id sections.
2. Clear the build ID field before writing.
3. Use bfd_make_section_anyway_with_flags to create the output
.note.gnu.build-id section.

PR ld/28639
* ldelf.c (ldelf_after_open): Discard input .note.gnu.build-id
sections, excluding the first one.
(write_build_id): Clear the build ID field before writing.
(ldelf_setup_build_id): Use bfd_make_section_anyway_with_flags
to create the output .note.gnu.build-id section.
* testsuite/ld-elf/build-id.exp: New file.
* testsuite/ld-elf/pr28639a.rd: Likewise.
* testsuite/ld-elf/pr28639b.rd: Likewise.
* testsuite/ld-elf/pr28639c.rd: Likewise.
* testsuite/ld-elf/pr28639d.rd: Likewise.

Automatic date update in version.in

binutils: add missing prefix for binutils/index.html rule

readelf: recognize FDO Packaging Metadata ELF note.  (Correcting snafu during patch application)

readelf: recognize FDO Packaging Metadata ELF note

As defined on: https://systemd.io/COREDUMP_PACKAGE_METADATA/
this note will be used starting from Fedora 36. Allow
readelf --notes to pretty print it:

Displaying notes found in: .note.package
  Owner                Data size  Description
  FDO                  0x00000039 FDO_PACKAGING_METADATA
    Packaging Metadata: {"type":"deb","name":"fsverity-utils","version":"1.3-1"}

Signed-off-by: Luca Boccassi <luca.boccassi@microsoft.com>

[gdb/testsuite] Fix typo in gdb.multi/multi-arch-exec.exp

With gdb.multi/multi-arch-exec.exp I run into:
...
Running src/gdb/testsuite/gdb.multi/multi-arch-exec.exp ...
ERROR: tcl error sourcing src/gdb/testsuite/gdb.multi/multi-arch-exec.exp.
ERROR: wrong # args: extra words after "else" clause in "if" command
    while executing
"if [istarget "powerpc64*-*-*"] {
        set march "-m64"
    } else if [istarget "s390*-*-*"] {
        set march "-m31"
    } else {
        set march "-m32"
    }"
...

Fix the else if -> elseif typo.

Tested on x86_64-linux.

[gdb/testsuite] Fix gdb.arch/i386-pkru.exp on linux

When running test-case gdb.arch/i386-pkru.exp on a machine with "Memory
Protection Keys for Userspace" support, we run into:
...
(gdb) PASS: gdb.arch/i386-pkru.exp: probe PKRU support
print $pkru^M
$2 = 1431655764^M
(gdb) FAIL: gdb.arch/i386-pkru.exp: pkru register
...

The test-case expects the $pkru register to have the default value 0, matching
the "init state" of 0 defined by the XSAVE hardware.

Since linux kernel version v4.9 containing commit acd547b29880 ("x86/pkeys:
Default to a restrictive init PKRU"), the register is set to 0x55555554 by
default (which matches the printed decimal value above).

Fix the FAIL by accepting this value for linux.

Tested on x86_64-linux.

Fix the fields in the x_n union inside the the x_file structure so that pointers can be stored.

PR 28630
* coff/internal.h (x_n): Use bfd_hostptr_t for the fields in this
structure.

gdb/remote: use scoped_restore to control starting_up flag

This commit makes use of a scoped_restore object to control the
remote_state::starting_up flag within the remote_target::start_remote
method.

Ideally I would have liked to create the scoped_restore inside
start_remote and just leave the restore in place until the end of the
scope, however, I'm worried that doing this would change the behaviour
of GDB.  Specifically, in start_remote, the following code is executed
once the starting_up flag has been restored to its previous value:

  if (breakpoints_should_be_inserted_now ())
    insert_breakpoints ();

I think (but am not 100% sure) that calling install_breakpoints could
end up back inside remote_target::can_download_tracepoint, which does
check the value of remote_state::starting_up.  And so, I'm concerned
that leaving the scoped_restore in place until the end of start_remote
will cause a possible change in behaviour.

To avoid this, and to leave things as close to the current behaviour
as possible, I've split remote_target::start_remote into two, there's
the main function body which moves into remote_target::start_remote_1,
this function uses the scoped_restore to change the ::starting_up
flag, then there's the old remote_target::start_remote, which now just
calls ::start_remote_1, and then does the insert_breakpoints call.

There should be no user visible changes after this commit, unless
there's a situation where the ::starting_up flag could previously have
been left set, if this was the case, then this situation should no
longer be possible.

gdb.base/corefile-buildid.exp: fix DUPLICATEs when failing to generate a core file

When my system isn't properly configured to generate core files in the
local directory, I see these DUPLICATEs:

    DUPLICATE: gdb.base/corefile-buildid.exp: could not generate core file

Fix that by having a single with_test_prefix around that message and
what follows.

Change-Id: I4ac245fcce1c666db56e3bad3582aa17f183dcba

gold: enable silent build rules

Automatic date update in version.in

gdb: Powerpc fix gdb.multi/multi-arch-exec.exp test

The expect file has a procedure append_arch_options which sets march based
the istarget.  The current if / else statement does not check for
powerpc64.  The else statement is hit which sets march to -m32.  This
results in compilation errors on 64-bit PowerPC.

This patch adds an if statement to check for powerpc64 and if true sets mach
to -m64.

The patch was tested on a Power 10 system.  No compile errors were generated.
The test completes with 1 expected pass and no failures.

binutils: regenerate Makefile.in after doc/ changes

Fix missing build dependency for binutils man pages

binutils/
* doc/local.mk: Give each man page target its missing dependency on
doc/$(am__dirstamp).

aarch64: Add missing system registers [PR27145]

This patch adds support for various system registers, up to Armv8.7-A.
This includes all the registers that were mentioned in the PR and that
hadn't become supported since.

opcodes/
PR aarch64/27145
* aarch64-opc.c (SR_V8_4): Remove duplicate definition.
(SR_V8_6, SR_V8_7, SR_GIC, SR_AMU): New macros.
(aarch64_sys_regs): Add missing entries (up to Armv8.7-A).

gas/
PR aarch64/27145
* testsuite/gas/aarch64/sysreg-8.s,
* testsuite/gas/aarch64/sysreg-8.d,
* testsuite/gas/aarch64/illegal-sysreg-8.s,
* testsuite/gas/aarch64/illegal-sysreg-8.d,
* testsuite/gas/aarch64/illegal-sysreg-8.l,
* testsuite/gas/aarch64/illegal-sysreg-8b.s,
* testsuite/gas/aarch64/illegal-sysreg-8b.d,
* testsuite/gas/aarch64/illegal-sysreg-8b.l: New tests.
* testsuite/gas/aarch64/sysreg.s: Change system register numbers
to ones that are still unallocated.
* testsuite/gas/aarch64/sysreg.d: Update accordingly.

aarch64: Make LOR registers conditional on +lor

We have a +lor feature flag for the Limited Ordering Regions
extension, but the associated registers didn't use it.

opcodes/
* aarch64-opc.c (SR_LOR): New macro.
(aarch64_sys_regs): Use it for lorc_el1, lorea_el1, lorn_el1 and
lorsa_el1.

gas/
* testsuite/gas/aarch64/sysreg-7.s: Enable +lor.
* testsuite/gas/aarch64/illegal-sysreg-7.s: Test for LOR registers
without +lor.
* testsuite/gas/aarch64/illegal-sysreg-7.d: Update accordingly.
* testsuite/gas/aarch64/illegal-sysreg-7.l: Likewise.

aarch64: Remove ZIDR_EL1

ZIDR_EL1 was part of an early version of SVE, but didn't make
it to the final release.

opcodes/
* aarch64-opc.c (aarch64_sys_regs): Remove zidr_el1 entry.

gas/
* testsuite/gas/aarch64/sve-sysreg.s: Remove zidr_el1.
* testsuite/gas/aarch64/sve-sysreg.d: Update accordingly.
* testsuite/gas/aarch64/sve-sysreg-invalid.l: Likewise.

aarch64: Allow writes to MFAR_EL3

MFAR_EL3 is a read/write register, but was incorrectly marked as
read-only
[https://developer.arm.com/documentation/ddi0601/2021-09/AArch64-Registers/MFAR-EL3--PA-Fault-Address-Register?lang=en]

opcodes/
* aarch64-opc.c (aarch64_sys_regs): Mark mfar_el3 as read-write.

gas/
* testsuite/gas/aarch64/rme.s: Test writing to mfar_el3.
* testsuite/gas/aarch64/rme.d: Update accordingly.
* testsuite/gas/aarch64/rme-invalid.s: Delete.
* testsuite/gas/aarch64/rme-invalid.l: Likewise.
* testsuite/gas/aarch64/rme-invalid.d: Likewise.

aarch64: Mark PMSIDR_EL1 as read-only

We were incorrectly allowing writes to PMSIDR_EL1, which is
a read-only register.
[https://developer.arm.com/documentation/ddi0595/2021-09/AArch64-Registers/PMSIDR-EL1--Sampling-Profiling-ID-Register?lang=en]

opcodes/
* aarch64-opc.c (aarch64_sys_regs): Make pmsidr_el1 as F_REG_READ.

gas/
* testsuite/gas/aarch64/msr.s: Remove write to pmsidr_el1.
* testsuite/gas/aarch64/msr.d: Update accordingly.
* testsuite/gas/aarch64/illegal-sysreg-2.s,
* testsuite/gas/aarch64/illegal-sysreg-2.d,
* testsuite/gas/aarch64/illegal-sysreg-2.l: New test.

aarch64: Remove duplicate system register entries

There is a lot of overlap between the ETM and ETE system registers,
so some registers were listed twice.

Already tested by etm.[sd] and ete.[sd].

opcodes/
* aarch64-opc.c (aarch64_sys_regs): Combine ETE and ETM blocks
and remove redundant entries.

gas/
* testsuite/gas/aarch64/etm.s: Remove duplicated test.
* testsuite/gas/aarch64/etm.d: Update accordingly.

aarch64: Check for register aliases before mnemonics

Previously we would not accept:

A .req B

if A happened to be the name of an instruction.  Adding new
instructions could therefore invalidate existing register aliases.

I noticed this with a test that used "zero" as a register alias
for "xzr", where "zero" is now also the name of an SME instruction.
I don't have any evidence that "real" code is doing this, but it
seems at least plausible.

This patch switches things so that we check for register aliases
first.  It might slow down parsing slightly, but the difference
is unlikely to be noticeable.

Things like:

b .req + 0

still work, since create_register_alias checks for " .req ",
and with the input scrubber, we'll only keep whitespace after
.req if it's followed by another name.  If there's some valid
expression that I haven't thought about that is scrubbed to
" .req ", users could avoid the ambiguity by wrapping .req
in parentheses.

The new test for invalid aliases already passed.  I just wanted
something to exercise the !dot condition.

I can't find a way of exercising the (existing) p == base condition,
but I'm not brave enough to say that it can never happen.  If it does
happen, get_mnemonic_name would return an empty string.

gas/
* config/tc-aarch64.c (opcode_lookup): Move mnemonic extraction
code to...
(md_assemble): ...here.  Check for register aliases first.
* testsuite/gas/aarch64/register_aliases.d,
testsuite/gas/aarch64/register_aliases.s: Test for a register
alias called "zero".
* testsuite/gas/aarch64/register_aliases_invalid.d,
testsuite/gas/aarch64/register_aliases_invalid.l,
testsuite/gas/aarch64/register_aliases_invalid.s: New test.

gdb/python: don't use the 'p' format for parsing args

When running the gdb.python/py-arch.exp tests on a GDB built
against Python 2 I ran into some errors.  The problem is that this
test script exercises the gdb.Architecture.integer_type method, and
this method uses 'p' as an argument format specifier in a call to
gdb_PyArg_ParseTupleAndKeywords.

Unfortunately this specified was only added in Python 3.3, so will
cause an error for earlier versions of Python.

This commit switches to use the 'O' specifier to collect a PyObject,
and then uses PyObject_IsTrue to convert the object to a boolean.

An earlier version of this patch incorrectly switched from using 'p'
to use 'i', however, it was pointed out during review that this would
cause some changes in behaviour, for example both of these will work
with 'p', but not with 'i':

  gdb.selected_inferior().architecture().integer_type(32, None)
  gdb.selected_inferior().architecture().integer_type(32, "foo")

The new approach of using 'O' works fine with these cases.  I've added
some new tests to cover both of the above.

There should be no user visible changes after this commit.

[gdb/testsuite] Fix gdb.base/style.exp with stub-termcap

When running test-case gdb.base/style.exp with a gdb build using
stub-termcap.c, we run into:
...
(gdb) PASS: gdb.base/style.exp: all styles enabled: frame when width=20
^M<et width 30^M
(gdb) FAIL: gdb.base/style.exp: all styles enabled: set width 30
...

The problem is that we're trying to issue the command "set width 30" while
width is set to 20, which causes horizontal scrolling.

Fix this by resetting the width to 0 before issuing the "set width 30"
command.

Tested on x86_64-linux.

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

Use dwarf_vma type for offsets, ranges and section sizes in DWARF decoder.

* dwarf.c (find_debug_info_for_offset): Use dwarf_vma type for
offsets, sizes and ranges.
(display_loc_list): Likewise.  Also use print_dwarf_vma to print
the offset.
(display_loclists_list): Likewise.
(display_loc_list_dwo): Likewise.
(display_debug_str): Likewise.
(display_debug_aranges): Likewise.
(display_debug_ranges_list): Likewise.
(display_debug_rnglists_list): Likewise.
(display_debug_ranges): Likewise.

ld: pru: Add pru_irq_map output section

* scripttempl/pru.sc (.pru_irq_map): Define output section.
* testsuite/ld-pru/pru_irq_map-1.d: New test.
* testsuite/ld-pru/pru_irq_map-2.d: New test.
* testsuite/ld-pru/pru_irq_map.s: New test.

gdb/testsuite: check the python module is available before using it

The gdb.python/py-inferior-leak.exp test makes use of the tracemalloc
module.  When running the Python tests with a GDB built against Python
2 I ran into a test failure due to the tracemalloc module not being
available.

This commit adds a new helper function to lib/gdb-python.exp that
checks if a named module is available.  Using this we can then skip
the py-inferior-leak.exp test when the tracemalloc module is not
available.

gdb: fix disassembler regressions for 32-bit arm

After this commit:

  commit 76b43c9b5c2b275cbf4f927bfc25984410cb5dd5
  Date:   Tue Oct 5 15:10:12 2021 +0100

      gdb: improve error reporting from the disassembler

We started seeing FAILs in the gdb.base/all-architectures*.exp tests,
when running on a 32-bit ARM target, though I suspect running on any
target that compiles such that bfd_vma is 32-bits would also trigger
the failures.

The problem is that the test is expected GDB's disassembler to print
an error like this:

  Cannot access memory at address 0x0

However, after the above commit we see an error like:

  unknown disassembler error (error = -1)

The reason for this is this code in opcodes/i386-dis.c (in the
print_insn function):

  if (address_mode == mode_64bit && sizeof (bfd_vma) < 8)
    {
      (*info->fprintf_func) (info->stream,
                             _("64-bit address is disabled"));
      return -1;
    }

This code effectively disallows us from ever disassembling 64-bit x86
code if we compiled GDB with a 32-bit bfd_vma.  Notice we return
-1 (indicating a failure to disassemble), but never call the
memory_error_func callback.

Prior to the above commit GDB, when it received the -1 return value
would assume that a memory error had occurred and just print whatever
value happened to be in the memory error address variable, the default
value of 0 just happened to be fine because the test had asked GDB to
do this 'disassemble 0x0,+4'.

If we instead change the test to do 'disassemble 0x100,+4' then GDB
would (previously) have still reported:

  Cannot access memory at address 0x0

which makes far less sense.

In this commit I propose to fix this issue by changing the test to
accept either the "Cannot access memory ..." string, or the newer
"unknown disassembler error ..." string.  With this change done the
test now passes.

However, there is one weakness with this strategy; if GDB broke such
that we _always_ reported "unknown disassembler error ..." we would
never notice.  This clearly would be bad.  To avoid this issue I have
adjusted the all-architectures*.exp tests so that, when we disassemble
for the default architecture (the one selected by "auto") we _only_
expect to get the "Cannot access memory ..." error string.

[ Note: In an ideal world we should be able to disassemble any
  architecture at all times.  There's no reason why the 64-bit x86
  disassembler requires a 64-bit bfd_vma, other than the code happens
  to be written that way.  We could rewrite the disassemble to not
  have this requirement, but, I don't plan to do that any time soon. ]

Further, I have changed the all-architectures*.exp test so that we now
disassemble at address 0x100, this should avoid us being able to pass
by printing a default address of 0x0.  I did originally change the
address we disassembled at to 0x4, however, some architectures,
e.g. ia64, have a default instruction alignment that is greater than
4, so would still round down to 0x0.  I could have just picked 0x8 as
an address, but I figured that 0x100 was likely to satisfy most
architectures alignment requirements.

gdb/python: add gdb.RemoteTargetConnection.send_packet

This commits adds a new sub-class of gdb.TargetConnection,
gdb.RemoteTargetConnection.  This sub-class is created for all
'remote' and 'extended-remote' targets.

This new sub-class has one additional method over its base class,
'send_packet'.  This new method is equivalent to the 'maint
packet' CLI command, it allows a custom packet to be sent to a remote
target.

The outgoing packet can either be a bytes object, or a Unicode string,
so long as the Unicode string contains only ASCII characters.

The result of calling RemoteTargetConnection.send_packet is a bytes
object containing the reply that came from the remote.

gdb: make packet_command function available outside remote.c

In a later commit I will add a Python API to access the 'maint packet'
functionality, that is, sending a user specified packet to the target.

To make implementing this easier, this commit refactors how this
command is currently implemented so that the packet_command function
is now global.

The new global send_remote_packet function takes an object that is an
implementation of an abstract interface.  Two functions within this
interface are then called, one just before a packet is sent to the
remote target, and one when the reply has been received from the
remote target.  Using an interface object in this way allows (1) for
the error checking to be done before the first callback is made, this
means we only print out what packet it being sent once we know we are
going to actually send it, and (2) we don't need to make a copy of the
reply if all we want to do is print it.

One user visible changes after this commit are the error
messages, which I've changed to be less 'maint packet' command
focused, this will make them (I hope) better for when
send_remote_packet can be called from Python code.

So:      "command can only be used with remote target"
Becomes: "packets can only be sent to a remote target"

And:     "remote-packet command requires packet text as argument"
Becomes: "a remote packet must not be empty"

Additionally, in this commit, I've added support for packet replies
that contain binary data.  Before this commit, the code that printed
the reply treated the reply as a C string, it assumed that the string
only contained printable characters, and had a null character only at
the end.

One way to show the problem with this is if we try to read the auxv
data from a remote target, the auxv data is binary, so, before this
commit:

  (gdb) target remote :54321
  ...
  (gdb) maint packet qXfer:auxv:read::0,1000
  sending: "qXfer:auxv:read::0,1000"
  received: "l!"
  (gdb)

And after this commit:

  (gdb) target remote :54321
  ...
  (gdb) maint packet qXfer:auxv:read::0,1000
  sending: "qXfer:auxv:read::0,1000"
  received: "l!\x00\x00\x00\x00\x00\x00\x00\x00\xf0\xfc\xf7\xff\x7f\x00\x00\x10\x00\x00\x00\x00\x00\x00\x00\xff\xf>
  (gdb)

The binary contents of the reply are now printed as escaped hex.

gdb/python: introduce gdb.TargetConnection object type

This commit adds a new object type gdb.TargetConnection.  This new
type represents a connection within GDB (a connection as displayed by
'info connections').

There's three ways to find a gdb.TargetConnection, there's a new
'gdb.connections()' function, which returns a list of all currently
active connections.

Or you can read the new 'connection' property on the gdb.Inferior
object type, this contains the connection for that inferior (or None
if the inferior has no connection, for example, it is exited).

Finally, there's a new gdb.events.connection_removed event registry,
this emits a new gdb.ConnectionEvent whenever a connection is removed
from GDB (this can happen when all inferiors using a connection exit,
though this is not always the case, depending on the connection type).
The gdb.ConnectionEvent has a 'connection' property, which is the
gdb.TargetConnection being removed from GDB.

The gdb.TargetConnection has an 'is_valid()' method.  A connection
object becomes invalid when the underlying connection is removed from
GDB (as discussed above, this might be when all inferiors using a
connection exit, or it might be when the user explicitly replaces a
connection in GDB by issuing another 'target' command).

The gdb.TargetConnection has the following read-only properties:

  'num': The number for this connection,

  'type': e.g. 'native', 'remote', 'sim', etc

  'description': The longer description as seen in the 'info
                 connections' command output.

  'details': A string or None.  Extra details for the connection, for
             example, a remote connection's details might be
             'hostname:port'.

RISC-V: The vtype immediate with more than the defined 8 bits are preserved.

According the rvv spec,
https://github.com/riscv/riscv-v-spec/blob/master/vtype-format.adoc

The bits of vtype immediate from 8 to (xlen - 1) should be reserved.
Therefore, we should also dump the vtype immediate as numbers, when
they are set over 8-bits.  I think this is a bug that we used to support
vediv extension and use the bit 8 and 9 of vtype, but forgot to update
the behavior when removing the vediv.

Consider the testcases,

vsetvli  a0, a1,  0x700    # the reserved bit 10, 9 and 8 are used.
vsetvli  a0, a1,  0x400    # the reserved bit 10 is used.
vsetvli  a0, a1,  0x300    # the reserved bit 9 and 8 are used.
vsetvli  a0, a1,  0x100    # the reserved bit 8 is used.
vsetivli a0, 0xb, 0x300    # the reserved bit 9 and 8 are used.
vsetivli a0, 0xb, 0x100    # the reserved bit 8 is used.

The original objdump shows the following result,

0000000000000000 <.text>:
   0:   7005f557                vsetvli a0,a1,1792
   4:   4005f557                vsetvli a0,a1,1024
   8:   3005f557                vsetvli a0,a1,e8,m1,tu,mu
   c:   1005f557                vsetvli a0,a1,e8,m1,tu,mu
  10:   f005f557                vsetivli        a0,11,e8,m1,tu,mu
  14:   d005f557                vsetivli        a0,11,e8,m1,tu,mu

But in fact the correct result should be,

0000000000000000 <.text>:
   0:   7005f557                vsetvli a0,a1,1792
   4:   4005f557                vsetvli a0,a1,1024
   8:   3005f557                vsetvli a0,a1,768
   c:   1005f557                vsetvli a0,a1,256
  10:   f005f557                vsetivli        a0,11,768
  14:   d005f557                vsetivli        a0,11,256

gas/
* testsuite/gas/riscv/vector-insns.d: Added testcases to
test the reserved bit 8 to (xlen-1) of vtype.
* testsuite/gas/riscv/vector-insns.s: Likewise.
include/
* opcode/riscv.h: Removed OP_MASK_VTYPE_RES and OP_SH_VTYPE_RES,
since they are different for operand Vc and Vb.
opcodes/
* riscv-dis.c (print_insn_args): Updated imm_vtype_res to
extract the reserved immediate of vtype correctly.

RISC-V: Dump vset[i]vli immediate as numbers once vsew or vlmul is reserved.

Consider the following case,

vsetvli  a0, a1,  0x4           # unrecognized vlmul
vsetvli  a0, a1,  0x20          # unrecognized vsew
vsetivli a0, 0xb, 0x4           # unrecognized vlmul
vsetivli a0, 0xb, 0x20          # unrecognized vsew

For the current dis-assembler, we get the result,

0000000000000000 <.text>:
   0:   0045f557                vsetvli a0,a1,e8,(null),tu,mu
   4:   0205f557                vsetvli a0,a1,e128,m1,tu,mu
   8:   c045f557                vsetivli        a0,11,e8,(null),tu,mu
   c:   c205f557                vsetivli        a0,11,e128,m1,tu,mu

The vsew e128 and vlmul (null) are preserved according to the spec,
so dump these fields looks wrong.  Consider that we are used to dump
the unrecognized csr as csr numbers directly, we should also dump
the whole vset[i]vli immediates as numbers, once the vsew or vlmul
is reserved.  Therefore, following is what I expected,

0000000000000000 <.text>:
   0:   0045f557                vsetvli a0,a1,4
   4:   0205f557                vsetvli a0,a1,32
   8:   c045f557                vsetivli        a0,11,4
   c:   c205f557                vsetivli        a0,11,32

gas/
* testsuite/gas/riscv/vector-insns.d: Rewrite the vset[i]vli
testcases since we should dump the immediate as numbers once
the vsew or vlmul is reserved.
* testsuite/gas/riscv/vector-insns.s: Likewise.
opcodes/
* riscv-dis.c (print_insn_args): The reserved vsew and vlmul
are NULL string in the riscv_vsew and riscv_vlmul, so dump the
whole imm as numbers once one of them is NULL.
* riscv-opc.c (riscv_vsew): Set the reserved vsew to NULL.
(riscv_vlmul): Set the reserved vlmul to NULL.

zlib: enable silent build rules

ld: enable silent build rules

Also add $(AM_V_xxx) to various manual rules in here.

libctf: enable silent build rules

Also add $(AM_V_xxx) to various manual rules in here.

gprof: enable silent build rules

Also add $(AM_V_xxx) to various manual rules in here.

binutils: merge doc subdir up a level

This avoids a recursive make into the doc subdir and speeds up the
build slightly.  It also allows for more parallelism.

binutils: enable silent build rules

Also add $(AM_V_xxx) to various manual rules in here.

bfd: enable silent build rules

Also add $(AM_V_xxx) to various manual rules in here.

opcodes: enable silent build rules

Also add $(AM_V_xxx) to various manual rules in here.

Automatic date update in version.in

Allow DW_ATE_UTF for Rust characters

The Rust compiler plans to change the encoding of a Rust 'char' type
to use DW_ATE_UTF.  You can see the discussion here:

    https://github.com/rust-lang/rust/pull/89887

However, this fails in gdb.  I looked into this, and it turns out that
the handling of DW_ATE_UTF is currently fairly specific to C++.  In
particular, the code here assumes the C++ type names, and it creates
an integer type.

This comes from commit 53e710acd ("GDB thinks char16_t and char32_t
are signed in C++").  The message says:

    Both places need fixing.  But since I couldn't tell why dwarf2read.c
    needs to create a new type, I've made it use the per-arch built-in
    types instead, so that the types are only created once per arch
    instead of once per objfile.  That seems to work fine.

... which is fine, but it seems to me that it's also correct to make a
new character type; and this approach is better because it preserves
the type name as well.  This does use more memory, but first we
shouldn't be too concerned about the memory use of types coming from
debuginfo; and second, if we are, we should implement type interning
anyway.

Changing this code to use a character type revealed a couple of
oddities in the C/C++ handling of TYPE_CODE_CHAR.  This patch fixes
these as well.

I filed PR rust/28637 for this issue, so that this patch can be
backported to the gdb 11 branch.

[PR gdb/27026] CTRL-C is ignored when debug info is downloaded

During debuginfod downloads, ctrl-c should result in the download
being cancelled and skipped.  However in some cases, ctrl-c fails to
get delivered to gdb during downloading.  This can result in downloads
being unskippable.

Fix this by ensuring that target_terminal::ours is in effect for the
duration of each download.

Co-authored-by: Tom de Vries <tdevries@suse.de>
https://sourceware.org/bugzilla/show_bug.cgi?id=27026#c3

strings: Replace references to -u option with references to -U.

PR 28632

[gdb/symtab] Fix segfault in search_one_symtab

PR28539 describes a segfault in lambda function search_one_symtab due to
psymbol_functions::expand_symtabs_matching calling expansion_notify with a
nullptr symtab:
...
          struct compunit_symtab *symtab =
            psymtab_to_symtab (objfile, ps);

          if (expansion_notify != NULL)
            if (!expansion_notify (symtab))
              return false;
...

This happens as follows.  The partial symtab ps is a dwarf2_include_psymtab
for some header file:
...
(gdb) p ps.filename
$5 = 0x64fcf80 "/usr/include/c++/11/bits/stl_construct.h"
...

The includer of ps is a shared symtab for a partial unit, with as user:
...
(gdb) p ps.includer().user.filename
$11 = 0x64fc9f0 \
  "/usr/src/debug/llvm13-13.0.0-1.2.x86_64/tools/clang/lib/AST/Decl.cpp"
...

The call to psymtab_to_symtab expands the Decl.cpp symtab (and consequently
the shared symtab), but returns nullptr because:
...
struct dwarf2_include_psymtab : public partial_symtab
{
  ...
  compunit_symtab *get_compunit_symtab (struct objfile *objfile) const override
  {
    return nullptr;
  }
...

Fix this by returning the Decl.cpp symtab instead, which fixes the segfault
in the PR.

Tested on x86_64-linux.

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

Update description of string's -n option.

PR 28632
* strings.c (usage): Update desciption of -n option.
* doc/binutils.texi: Likewise.

[gdb/testsuite] Fix typo in proc lines

Proc lines contains a typo:
...
  string_form { set $_line_string_form $value }
...

Remove the incorrect '$' in '$_line_string_form'.

Tested on x86_64-linux.

[gdb/testsuite] Use unique files in gdb.dwarf2/dw2-lines.exp

While debugging a problem in gdb.dwarf2/dw2-lines.exp, I realized that the
test-case generates all executables and associated temporary files using the
same filenames.

Fix this by adding a new proc prefix_id in lib/gdb.exp, and using it in the
test-case.

Tested on x86_64-linux.

[gdb/testsuite] Fix gdb.dwarf2/dw2-lines.exp with -m32

When running test-case gdb.dwarf2/dw2-lines.exp with target board -unix/-m32,
we run into another instance of PR28383, where the dwarf assembler generates
64-bit relocations which are not supported by the 32-bit assembler:
...
dw2-lines-dw.S: Assembler messages:^M
outputs/gdb.dwarf2/dw2-lines/dw2-lines-dw.S:76: Error: \
  cannot represent relocation type BFD_RELOC_64^M
...

Fix this by using _op_offset in _line_finalize_header.

Tested on x86_64-linux.

sim: testsuite: drop most specific istarget checks

We'll rely on the toolchain probing to determine whether each arch's
tests can be run rather the current configure target.  This allows
testing all of the ports in a multitarget configuration.

For now, we don't reformat the files entirely to make it easier to
review, and in case we need to make adjustments.  Once this feels
like it's stable, we can flatten the code a bit by removing the if
statement entirely.

sim: testsuite: support parallel execution

Break up the dejagnu logic so that we can parallelize the testsuite.
This takes a page from gcc & gdb where each .exp is run in isolation
instead of in serial.

For most targets, this doesn't make much of a difference as they only
have a single .exp.  A few (like cris & frv) have multiple .exp though
and will see a bit of a speed up.

The real gain is when testing a multitarget build.  This way we can
run all the targets in parallel and cut the execution time a bit.
On my system, it goes from ~155sec to ~100sec.

We can gain further speedups by splitting up some of the larger .exp
files into smaller groups.  We'll do that in a followup though.

sim: testsuite: expand arch specific toolchain settings

Leverage the new per-port toolchain settings to initialize the env
for eeach set of tests.  This allows us to run all the tests in a
multitarget build if the user sets up the vars.  If they don't, we
can still skip all the tests.

sim: testsuite: setup per-port toolchain settings for multitarget build

Gas does not support multitarget builds -- it still only supports
a single input & output format.  ld is a bit better, but requires
manual flags to select the right output.  This makes it impossible
to run the complete testsuite in a multitarget build.

To address this limitation, create a suite of FOR_TARGET variables
so these can be set to precompiled as & ld programs.  It requires
a bit of setup ahead of time, but it's a one-time cost, and makes
running the full testsuite at once much easier.

Automatic date update in version.in

PR28629 NIOS2 fallout

The test exactly matched wrong output.

PR 28629
* testsuite/gas/nios2/relax.d: Update expected output.

sim: add checks to core headers to prevent incorrect common building

Some of the core sim headers rely on the SIM_AC_OPTION_BITSIZE macro
which can change the size of core types.  Since these haven't been
unified across ports, add checks to make sure they aren't accidentally
included when building for all ports.  This caught the sim-load file
using poisoned headers that it didn't actually need.

sim: unify syscall.o building

Now that we've unified all the syscall tables, this file does not rely
on any port-specific settings, so move it up to building as part of the
common step so we only do it once in a multibuild.