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.

sim: drop unused gentmap & nltvals.def logic

Now that all ports have switched to target-newlib-* files, there's
no need for these files & generating things at build time.  So punt
the logic and make target-newlib-syscall a hard requirement.

sim: mcore: switch to new target-newlib-syscall

Use the new target-newlib-syscall module.  This is needed to merge all
the architectures into a single build, and mcore has a custom syscall
table for its newlib/libgloss port.

sim: riscv: switch to new target-newlib-syscall

Use the new target-newlib-syscall module.  This is needed to merge all
the architectures into a single build, and riscv has a custom syscall
table for its newlib/libgloss port.

sim: cr16: switch to new target-newlib-syscall

Use the new target-newlib-syscall module.  This is needed to merge all
the architectures into a single build, and cr16 has a custom syscall
table for its newlib/libgloss port.

This allows cleaning up the syscall ifdef logic.  We know these will
always exist now.

sim: d10v: switch to new target-newlib-syscall

Use the new target-newlib-syscall module.  This is needed to merge all
the architectures into a single build, and d10v has a custom syscall
table for its newlib/libgloss port.

This allows cleaning up the syscall ifdef logic.  We know these will
always exist now.

sim: sh: switch to new target-newlib-syscall

Use the new target-newlib-syscall module.  This is needed to merge all
the architectures into a single build, and sh has a custom syscall
table for its newlib/libgloss port.

sim: v850: switch to new target-newlib-syscall

Use the new target-newlib-syscall module.  This is needed to merge all
the architectures into a single build, and v850 has a custom syscall
table for its newlib/libgloss port.

This allows cleaning up the syscall ifdef logic.  We know these will
always exist now.

sim: iq2000/lm32/m32c/moxie/rx: switch to new target-newlib-syscall.h

Use the new target-newlib-syscall.h to provide the target syscall
defines.  These code paths are written specifically for the newlib
ABI rather than being generalized, so switching them to the defines
rather than trying to go through the dynamic callback conversion
seems like the best trade-off for now.  Might have to reconsider
this in the future.

sim: nltvals: pull target syscalls out into a dedicated source file

Like we just did for pulling out the errno map, pull out the syscall
maps into a dedicated common file.  Most newlib ports are using the
same syscall map, but not all, which means we have to do a bit more
work to migrate.

This commit adds the maps and switches the ports using the common
default syscall table over to it.  Ports using unique syscall tables
are still using the old targ-map.c logic.

Switching common ports over is easy by checking NL_TARGET, but the
ppc code needs a bit more cleanup here hence its larger diff.

sim: frv: resolve syscalls dynamically

Avoid use of TARGET_<syscall> defines and rely on the callback layers
to resolve these dynamically so we can support multiple syscall layers
instead of assuming the newlib/libgloss numbers all the time.

sim: mn10300: resolve syscalls dynamically

Avoid use of TARGET_<syscall> defines and rely on the callback layers
to resolve these dynamically so we can support multiple syscall layers
instead of assuming the newlib/libgloss numbers all the time.

sim: nltvals: drop i960

This port was dropped from gdb/bfd/sim years ago, so stop including
its syscall constants too.

sim: moxie: fix datadir handling

Expand the value at `make` time rather than configure generation time
so that we handle $(datarootdir) setting properly.

Automatic date update in version.in

gdb: fix typos in configure

The variable names used to restore CFLAGS and LDFLAGS here don't quite
match the names used above, resulting in losing the original CFLAGS and
LDFLAGS.  Fix that.

Change-Id: I9cc2c3b48b1dc30c31a7143563c893fd6f426a0a

sim: hw: mark hw_descriptors const

sim: testsuite: add dedicated flag for init toolchain tests

As we setup more reliable CC_FOR_TARGET variables for each target, the
bfin way of overriding it to stuff custom CFLAGS doesn't scale well.
Add a dedicated CFLAGS_FOR_TARGET_init setting that each set of tests
can setup if they want to add custom options.

sim: testsuite: clean up arch specific toolchain settings

In a multitarget build, we process all targets in order, so make sure
the toolchain settings from one don't leak into the next.

sim: cris: always search for local rvdummy tool

If the board info sets the sim to a basename that is found via $PATH
(which is the default dejagnu behavior), the logic here to use its
dirname to find rvdummy fails because it looks for `./rvdummy`.  So
switch it to always use the local build of rvdummy which is the one
we want to be testing against in the first place.

If we get a request for testing against a different setup, we can
figure out & document the needs at that point, and then setup some
config knobs to control it.

[gdb/testsuite] Fix FAIL in gdb.base/list-missing-source.exp

In commit f8080fb7a44 "[gdb/testsuite] Add gdb.base/include-main.exp" a
file gdb.base/main.c was added, which caused the following regression:
...
(gdb) list^M
<gdb.base/main.c>
(gdb) FAIL: gdb.base/list-missing-source.exp: list
...

The problem is that the test-case does not expect to find a file main.c, but
now it finds gdb.base/main.c.

Fix this by using the more specific file name list-missing-source.c.

Tested on x86_64-linux.

sim: testsuite: fix bits-gen EXEEXT handling

Add missing $(EXEEXT) to dependencies on bits-gen.  These are actually
build-only tools, but automake doesn't allow for build & host tools, so
the rules are re-using EXEEXT.

sim: testsuite: initial support for OS-specific tests

We usually test against the newlib/libgloss environment, but for a
few ports that also support Linux apps, we want to test that logic
too.  A lot of the C code is written such that it works with either
newlib/libgloss or glibc/linux toolchains, but we have some tests
that end up being Linux-specific.  Cris has been using the target
tuple as a rough proxy for this (where cris*-*-elf is assumed to be
newlib/libgloss, and everything else is glibc/linux), but that is a
bit too rough, and it doesn't work in a multitarget build.

So lets create a few stub files that we can do compile tests with
to detect the different setups, and then let tests declare which
one they require (if they require any at all).

sim: testsuite: unify basic C compiler checks

Both bfin & cris ports test the C compiler to see if it works, but in
their own way.  Unify the checks in the common code so we can leverage
them in more ports in the future, and collapse the bfin & cris code.

sim: testsuite: rework sim_init usage

The sim_init function was called by runtest for each test when --tool
was set to sim.  When we changed to --tool '' to collapse the testsuite
dir, the init function was no longer called on every test.  However, it
was still being called explicitly by config/default.exp.  It's not clear
why that explicit call ever existed since, in the past, it meant it was
redundant.

Lets drop the single sim_init call in config/default.exp and move it out
to all our tests.  This replicates the runtest behavior so we can setup
variables on a per-test basis which allows us to recollapse the sim_path
logic back.  We'll also leverage this in the future for toolchain setup.

Also add a few comments clarifying the overall runtime behavior.

sim: cris: fix testsuite hang when sim is missing

If the cris sim hasn't been built yet, trying to run its testsuite
will hang indefinitely.  The common sim APIs already have this, so
copy it over to the cris forks of the test+run functions.

sim: testsuite: fix objdir handling

The tests assume that the cwd is the objdir directory and write its
intermediates to there all the time.  When using runtest's --objdir
setting though, this puts the files in the wrong place.  This isn't
a big problem currently as we never change --objdir, but in order to
support parallel test execution, we're going to start setting that
option, so clean up the code ahead of time.

We also have to tweak some of the cris tests which were making
assumptions about the argv[0] value.

sim: testsuite: rename global_sim_options to SIMFLAGS_FOR_TARGET

Now that all the other toolchain settings have been renamed to match
the dejagnu settings of XXX_FOR_TARGET, rename global_sim_options to
SIMFLAGS_FOR_TARGET too.

sim: testsuite: replace global_ld_options with LDFLAGS_FOR_TARGET

Only a few tests actually use global_ld_options, but we can replace the
sim-specific settings with the dejagnu common LDFLAGS_FOR_TARGET and get
the same result.

Automatic date update in version.in

Fix ifunc test fails on hppa*-*-*

2021-11-26  John David Anglin  <danglin@gcc.gnu.org>

PR ld/27442

ld/ChangeLog:

* ld/testsuite/ld-ifunc/ifunc.exp (contains_irelative_reloc): Adjust
regexp.
Skip static ifunc-using executable test on hppa*-*-*.

gas: Update commit 4780e5e4933

Update

commit 4780e5e4933a2497a5aecc4ceabbbb8e82aaf822
Author: Tom de Vries <tdevries@suse.de>
Date:   Fri Nov 26 09:59:45 2021 +0100

    [gas] Fix file 0 dir with -gdwarf-5

1. Replace i with j in

  for (j = 0; i < NUM_MD5_BYTES; ++j)

2. Pass -W to readelf to force CU: in output due to:

      if (do_wide || strlen (directory) < 76)
printf (_("CU: %s/%s:\n"), directory, file_table[0].name);
      else
printf ("%s:\n", file_table[0].name);

PR gas/28629
* dwarf2dbg.c (out_dir_and_file_list): Fix a typo in commit
4780e5e4933.
* testsuite/gas/elf/dwarf-5-nop-for-line-table.d: Pass -W to
readelf.

sim: testsuite: replace global_as_options with ASFLAGS_FOR_TARGET

Only a few tests actually use global_as_options, but we can replace the
sim-specific settings with the dejagnu common ASFLAGS_FOR_TARGET and get
the same result.

[gdb/testsuite] Add gdb.base/include-main.exp

The test-case gdb.ada/dgopt.exp uses the -gnatD switch, in combination with
-gnatG.

This causes the source file $src/gdb/testsuite/gdb.ada/dgopt/x.adb to be
expanded into $build/gdb/testsuite/outputs/gdb.ada/dgopt/x.adb.dg, and the
debug information should refer to the x.adb.dg file.

That is the case for the .debug_line part:
...
The Directory Table is empty.

 The File Name Table (offset 0x1c):
  Entry Dir     Time    Size    Name
  1     0       0       0       x.adb.dg
...
but not for the .debug_info part:
...
    <11>   DW_AT_name        : $src/gdb/testsuite/gdb.ada/dgopt/x.adb
    <15>   DW_AT_comp_dir    : $build/gdb/testsuite/outputs/gdb.ada/dgopt
...

Filed as PR gcc/103436.

In C we can generate similar debug information, using a source file that does
not contain any code, but includes another one that does:
...
 $ cat gdb/testsuite/gdb.base/include-main.c
 #include "main.c"
...
such that in the .debug_line part we have:
...
 The Directory Table (offset 0x1c):
  1     /home/vries/gdb_versions/devel/src/gdb/testsuite/gdb.base

 The File Name Table (offset 0x57):
  Entry Dir     Time    Size    Name
  1     1       0       0       main.c
...
and in the .debug_info part:
...
    <11>   DW_AT_name        : $src/gdb/testsuite/gdb.base/include-main.c
    <15>   DW_AT_comp_dir    : $build/gdb/testsuite
...

Add a C test-case that mimics gdb.ada/dgopt.exp, that is:
- generate debug info as described above,
- issue a list of a line in include-main.c, while the corresponding
  CU is not expanded yet.

Tested on x86_64-linux.

sim: testsuite: drop unused global_cc_options

Nothing in the testsuite is using this setting, so let's drop it.
Any code that wants to set compiler flags can use CFLAGS_FOR_TARGET
instead to get the same effect.

sim: testsuite: punt unused toolchain variables

These haven't been used in over 20 years.  The sim testsuite used to
run these tools itself directly, but back in ~1999 it switched to the
dejagnu helpers (e.g. target_assemble & target_link), and the dejagnu
logic only utilizes XXX_FOR_TARGET variables.  Punt them here to avoid
confusion with dead code.

gdb: add risc-v disassembler options support

This commit adds support for RISC-V disassembler options to GDB.  This
commit is based on this patch which was never committed:

  https://sourceware.org/pipermail/binutils/2021-January/114944.html

All of the binutils refactoring has been moved to a separate, earlier,
commit, so this commit is pretty straight forward, just registering
the required gdbarch hooks.

Co-authored-by: Simon Cook <simon.cook@embecosm.com>

opcodes/riscv: add disassembler options support to libopcodes

In preparation for the next commit, which will add GDB support for
RISC-V disassembler options, this commit restructures how the
disassembler options are managed within libopcodes.

The implementation provided here is based on this mailing list patch
which was never committed:

  https://sourceware.org/pipermail/binutils/2021-January/114944.html

which in turn took inspiration from the MIPS implementation of the
same feature.

The biggest changes from the original mailing list post are:

  1. The GDB changes have been split into a separate patch, and

  2. The `riscv_option_args_privspec` variable, which held the valid
  priv-spec values is now gone, instead we use the `riscv_priv_specs`
  array from bfd/cpu-riscv.c instead.

Co-authored-by: Simon Cook <simon.cook@embecosm.com>
include/ChangeLog:

* dis-asm.h (disassembler_options_riscv): Declare.

opcodes/ChangeLog:

* riscv-dis.c (enum riscv_option_arg_t): New enum typedef.
(riscv_options): New static global.
(disassembler_options_riscv): New function.
(print_riscv_disassembler_options): Rewrite to use
disassembler_options_riscv.

[gas] Fix file 0 dir with -gdwarf-5

In out_dir_and_file_list, if file 0 is copied from file 1, only the filename
is copied, and the dir and md5 fields are left to their default values.

Fix this by adding the copy of the dir and md5 fields.

gas/ChangeLog:

2021-11-26  Tom de Vries  <tdevries@suse.de>

PR 28629
* dwarf2dbg.c (out_dir_and_file_list): When copying file 1 to file 0,
also copy dir and md5 fields.
* testsuite/gas/i386/dwarf5-line-4.d: Adjust expected output.

sim: mips: avoid _ namespace

Some C libraries export _P symbols in their headers (like older
newlib and its ctype.h), so use P_ instead to avoid conflicts.

ld: fix POSIX shell test usage

POSIX test uses = for compares, not == which is a bashism.

gas: enable silent build rules

ld: fix --disable-multiple-abs-defs alignment in help

Automatic date update in version.in

gdb: ensure extension_language_python is always defined

In this commit:

  commit c6a6aad52d9e839d6a84ac31cabe2b7e1a2a31a0
  Date:   Mon Oct 25 17:25:45 2021 +0100

      gdb/python: make some global variables static

building without Python was broken.  The extension_language_python
global was moved from being always defined, to only being defined when
the HAVE_PYTHON macro was defined.  As a consequence, building without
Python support would result in errors like:

  /usr/bin/ld: extension.o:(.rodata+0x120): undefined reference to `extension_language_python'

This commit fixes the problem by moving the definition of
extension_language_python outside of the HAVE_PYTHON macro protection.

Revert "gdb: add assert in remote_target::wait relating to async being off"

This commit introduced a test failure in gdb.server/attach-flag.exp.
I didn't spot this failure originally as the problem is fixed by this,
as yet unpushed patch:

  https://sourceware.org/pipermail/gdb-patches/2021-November/183768.html

I unfortunately didn't test each patch in the original series
independently.  I'll repost this patch after the above patch has been
merged.

This reverts commit 32b1f5e8d6b8ddd3be6e471c26dd85a1dac31dda.

Fix building the AArch64 assembler and disassembler when assertions are disabled.

PR 28614
* aarch64-asm.c: Replace assert(0) with real code.
* aarch64-dis.c: Likewise.
* aarch64-opc.c: Likewise.

PR gdb/28480: Improve ambiguous member detection

Basic ambiguity detection assumes that when 2 fields with the same name
have the same byte offset, it must be an unambiguous request. This is not
always correct. Consider the following code:

class empty { };

class A {
public:
  [[no_unique_address]] empty e;
};

class B {
public:
  int e;
};

class C: public A, public B { };

if we tried to use c.e in code, the compiler would warn of an ambiguity,
however, since A::e does not demand an unique address, it gets the same
address (and thus byte offset) of the members, making A::e and B::e have the
same address. however, "print c.e" would fail to report the ambiguity,
and would instead print it as an empty class (first path found).

The new code solves this by checking for other found_fields that have
different m_struct_path.back() (final class that the member was found
in), despite having the same byte offset.

The testcase gdb.cp/ambiguous.exp was also changed to test for this
behavior.

coff-go32: consistent 16-byte section alignment

Section alignment for coff-go32 is inconsistent - The '.text' and
'.data' sections are 16-byte aligned, but named sections '.text.*' and
'.data.*' are only 4-byte aligned.  '.gnu.linkonce.r.*' is aligned to
16 bytes, yet '.rodata' and '.rodata.*' are aligned to 4 bytes.  For
'.bss' all input sections are only aligned to 4 bytes.

This primarily can cause trouble when using SSE instructions, which
require their memory operands to be aligned to 16-byte boundaries.

This patch solves the issue simply by setting the section alignment
to 16 bytes, for all code and data sections referenced in the default
linker script.

* coff-go32.c (COFF_SECTION_ALIGNMENT_ENTRIES):  Use partial
name match for .text, .data.  Add entries for .const, .rodata,
.bss, .gnu.linkonce.b.

Re: AArch64: Add support for AArch64 EFI (efi-*-aarch64)

Commit b69c9d41e8 edited bfd/Makefile.in rather than using automake,
which meant a typo in Makefile.am was not discovered and other
differences in Makefile.in are seen with a proper regeneration.  One
difference was lack of an empty line between the pe-aarch64igen.c rule
and the following $(BFD32_LIBS) etc. dependency rule, in the
regenerated file.  Not that it matters for proper "make" behaviour,
but it's nicer with a line between those rules.  Moving the rule
earlier seems to cure the missing empty line.

* Makefile.am (BFD64_BACKENDS): Correct typo.
(BFD_H_DEPS, LOCAL_H_DEPS): Move earlier.  Move rule using these
deps earlier too.
* Makefile.in: Regenerate.
* po/BLD-POTFILES.in: Regenerate.
* po/SRC-POTFILES.in: Regenerate.

Updated French translation for the opcodes directory.

* po/fr.po; Updated French translation.

gdb: rename source_styling_changed observer

In a later commit I plan to add disassembler styling.  In the same way
that we have a source_styling_changed observer I would need to add a
disassembler_styling_changed observer.

However, currently, these observers would only be notified from
cli-style.c:set_style_enabled, and observed in tui-winsource.c,
tui_source_window::style_changed, as a result, having two observers
seems unnecessary right now, so, in this commit, I plan to rename
source_styling_changed to just styling_changed, then, in the later
commit, when disassembler styling is added, I can use the same
observer for both source styling, and disassembler styling.

There should be no user visible changes after this commit.

gdb/python: make some global variables static

Make a couple of global variables static in python/python.c.  To do
this I had to move the definition of extension_language_python to
later in the file.

There should be no user visible changes after this commit.

gdb: add assert in remote_target::wait relating to async being off

While working on another patch I ended up in a situation where I had
async mode disabled (with 'maint set target-async off'), but the async
event token got marked anyway.

In this situation GDB was continually calling into
remote_target::wait, however, the async token would never become
unmarked as the unmarking is guarded by target_is_async_p.

We could just unconditionally unmark the token, but that would feel
like just ignoring a bug, so, instead, lets assert that if
!target_is_async_p, then the async token should not be marked.

This assertion would have caught my earlier mistake.

There should be no user visible changes with this commit.

gdb: simplify remote_target::is_async_p

This commit simplifies remote_target::is_async_p by removing the
target_async_permitted check.

In previous commits I have added additional assertions around the
target_async_permitted flag into target.c, as a result we should now
be confident that if target_can_async_p returns false, a target will
never have async mode enabled.  Given this, it should not be necessary
to check target_async_permitted in remote_target::is_async_p, if this
flag is false ::is_async_p should return false anyway.  There is an
assert to this effect in target_is_async_p.

There should be no user visible change after this commit.

gdb: add asserts in target.c for target_async_permitted

The target_async_permitted flag allows a user to override whether a
target can act in async mode or not.  In previous commits I have moved
the checking of this flag out of the various ::can_async_p methods and
into the common target.c code.

In this commit I will add some additional assertions into
target_is_async_p and target_async.  The rules these assertions are
checking are:

  1. A target that returns false for target_can_async_p should never
  become "async enabled", and so ::is_async_p should always return
  false.  This is being checked in target_is_async_p.

  2. GDB should never try to enable async mode for a target that
  returns false for target_can_async_p, this is checked in
  target_async.

There are a few places where we call the ::is_async_p method directly,
in these cases we will obviously not pass through the assert in
target_is_async_p, however, there are also plenty of places where we
do call target_is_async_p so if GDB starts to misbehave we should
catch it quickly enough.

There should be no user visible changes after this commit.

gdb: hoist target_async_permitted checks into target.c

This commit moves the target_async_permitted check out of each targets
::can_async_p method and into the target_can_async_p wrapper function.

I've left some asserts in the two ::can_async_p methods that I
changed, which will hopefully catch any direct calls to these methods
that might be added in the future.

There should be no user visible changes after this commit.

gdb: introduce a new overload of target_can_async_p

There are a few places where we call the target_ops::can_async_p
member function directly, instead of using the target_can_async_p
wrapper.

In some of these places this is because we need to ask before the
target has been pushed, and in another location (in target.c) it seems
unnecessary to go through the wrapper when we are already in target.c
code.

However, in the next commit I'd like to hoist some common checks out
of target specific code into target.c.  To achieve this, in this
commit, I introduce a new overload of target_can_async_p which takes a
target_ops pointer, and calls the ::can_async_p method directly.  I
then make use of the new overload where appropriate.

There should be no user visible changes after this commit.

ld/testsuite/ld-elfvsb: correctly test "weak hidden symbol DSO last"

The test must be done with the shared object and not with the object
file which is already being tested above.

ld/
* testsuite/ld-elfvsb/elfvsb.exp: use .so file in "weak hidden
  symbol DSO last"