Remove gdb_print_host_address

gdb_print_host_address is just a simple wrapper around
fprintf_filtered.  However, it is readily replaced in all callers by a
combination of %s and call to host_address_to_string.  This also
simplifies the code, so I think it's worthwhile to remove this
function.

Regression tested on x86-64 Fedora 64.

Move gdb_bfd_errmsg to gdb_bfd.c

gdb_bfd.c contains most of gdb's BFD-related utility functions.
However, gdb_bfd_errmsg is in utils.c.  It seemed better to me to move
this out of util.[ch] and into the BFD-related file instead.

Tested by rebuilding.

RISC-V: Rewrite the csr testcases.

Maskray (Fangrui Song) had suggested me before that we should combine
multiple testcases into one file as possible as we can.  So that we can
more easily understand what these test cases are testing, and easier to
maintain.  Therefore, this patch rewrites all csr testcases, to make them
more clean.

gas/
* testsuite/gas/riscv/csr-fail-nonexistent.d: Renamed from
priv-reg-fail-nonexistent testcase.
* testsuite/gas/riscv/csr-fail-nonexistent.: Likewise.
* testsuite/gas/riscv/csr-fail-nonexistent.s: Likewise.
* testsuite/gas/riscv/csr-insns-pseudo-noalias.d: Renamed from
priv-reg-pseudo testcase.
* testsuite/gas/riscv/csr-insns-pseudo.d: Likewise.
* testsuite/gas/riscv/csr-insns-pseudo.s: Likewise.
* testsuite/gas/riscv/csr-insns-read-only.d: Renamed from
priv-reg-fail-read-only-02 testcase.
* testsuite/gas/riscv/csr-insns-read-only.l: Likewise.
* testsuite/gas/riscv/csr-insns-read-only.s: Likewise.
* testsuite/gas/riscv/h-ext-32.d: Moved hypervisor csrs to csr.s.
* testsuite/gas/riscv/h-ext-32.s: Likewise.
* testsuite/gas/riscv/h-ext-64.d: Likewise.
* testsuite/gas/riscv/h-ext-64.s: Likewise.
* testsuite/gas/riscv/csr.s: Renamed from priv-reg.s, and then
added the hypervisor csrs.
* testsuite/gas/riscv/csr-version-1p9p1.d: The csr testcase when
the privileged spec is 1.9.1.  Also tested all invalid csr warnings
when -mcsr-check is enabled.
* testsuite/gas/riscv/csr-version-1p9p1.l: Likewise.
* testsuite/gas/riscv/csr-version-1p10.d: Likewise, but the
privileged spec is 1.10..
* testsuite/gas/riscv/csr-version-1p10.l: Likewise.
* testsuite/gas/riscv/csr-version-1p11.d: Likewise, but the
privileged spec is 1.11.
* testsuite/gas/riscv/csr-version-1p11.l: Likewise.
* testsuite/gas/riscv/csr-version-1p12.d: Likewise, but the
privileged spec is 1.12.
* testsuite/gas/riscv/csr-version-1p12.l: Likewise.
* testsuite/gas/riscv/priv-reg*: Removed or Renamed.

RISC-V: Hypervisor ext: support Privileged Spec 1.12

This is the Hypervisor Extension 1.0

 - Hypervisor Memory-Management Instructions
   HFENCE.VVMA, HFENCE.GVMA,

 - Hypervisor Virtual Machine Load and Store Instructions
   HLV.B, HLV.BU,          HSV.B,
   HLV.H, HLV.HU, HLVX.HU, HSB.H,
   HLV.W, HLV.WU, HLVX.WU, HSV.W,
   HLV.D,                  HSV.D

 - Hypervisor CSRs (some new, some address changed)
   hstatus, hedeleg, hideleg, hie, hcounteren, hgeie, htval, hip, hvip,
   htinst, hgeip, henvcfg, henvcfgh, hgatp, hcontext, htimedelta, htimedeltah,
   vsstatus, vsie, vstvec, vsscratch, vsepc, vscause, vstval, vsip, vsatp,

Note that following were added already as part of svinval extension
support:
   HINVAL.GVMA, HINVAL.VVMA

Signed-off-by: Vineet Gupta <vineetg@rivosinc.com>
Reviewed-by: Palmer Dabbelt <palmer@rivosinc.com>
Reviewed-by: Nelson Chu <nelson.chu@sifive.com>
bfd/
* cpu-riscv.c (riscv_priv_specs): Added entry for 1.12.
* cpu-riscv.h (enum riscv_spec_class): Added PRIV_SPEC_CLASS_1P12.
gas/
* config/tc-riscv.c (abort_version): Updated comment.
(validate_riscv_insn): Annotate switch-break.
* testsuite/gas/riscv/h-ext-32.d: New testcase for hypervisor.
* testsuite/gas/riscv/h-ext-32.s: Likewise.
* testsuite/gas/riscv/h-ext-64.d: Likewise.
* testsuite/gas/riscv/h-ext-64.s: Likewise.
include/
* opcode/riscv-opc.h: Added encodings for hypervisor csrs and
instrcutions.
opcodes/
* riscv-opc.c (riscv_opcodes): Added hypervisor instrcutions.

RISC-V: Hypervisor ext: drop Privileged Spec 1.9.1 implementation/tests

This makes way for a clean 1.12 based Hypervisor Ext support.

There are no known implementors of 1.9.1 H-ext. (Per Jim, kendryte k210
is based on priv spec 1.9.1, but it seems unlikely that they implemented
H-ext).

Signed-off-by: Vineet Gupta <vineetg@rivosinc.com>
Reviewed-by: Palmer Dabbelt <palmer@rivosinc.com>
Reviewed-by: Nelson Chu <nelson.chu@sifive.com>
gas/
* testsuite/gas/riscv/csr-dw-regnums.d: Drop the hypervisor csrs
defined in the privileged spec 1.9.1.
* testsuite/gas/riscv/csr-dw-regnums.s: Likewise.
* testsuite/gas/riscv/priv-reg-fail-read-only-01.s: Likewise.
* testsuite/gas/riscv/priv-reg-fail-version-1p10.l: Likewise.
* testsuite/gas/riscv/priv-reg-fail-version-1p11.l: Likewise.
* testsuite/gas/riscv/priv-reg-version-1p10.d: Likewise.
* testsuite/gas/riscv/priv-reg-version-1p11.d: Likewise.
* testsuite/gas/riscv/priv-reg-version-1p9p1.d: Likewise.
* testsuite/gas/riscv/priv-reg.s: Likewise.
include/
* opcode/riscv-opc.h: Drop the hypervisor csrs defined in the
privileged spec 1.9.1.

Automatic date update in version.in

gdb/testsuite: resolve some duplicate testnames in gdb.mi

Set of fixes to resolve some duplicate test names in the gdb.mi/
directory.  There should be no real test changes after this set of
fixes, they are all either:

  - Adding with_test_prefix type constructs to make test names unique,
    or

  - Changing the test name to be more descriptive, or better reflect
    the test being run.

gdb/remote: handle attach when stop packet lacks thread-id

Bug PR gdb/28405 reports a regression when using attach with an
extended-remote target.  In this case the target is not including a
thread-id in the stop packet it sends back after the attach.

The regression was introduced with this commit:

  commit 8f66807b98f7634c43149ea62e454ea8f877691d
  Date:   Wed Jan 13 20:26:58 2021 -0500

      gdb: better handling of 'S' packets

The problem is that when GDB processes the stop packet, it sees that
there is no thread-id and so has to "guess" which thread the stop
should apply to.

In this case the target only has one thread, so really, there's no
guessing needed, but GDB still runs through the same process, this
shouldn't cause us any problems.

However, after the above commit, GDB now expects itself to be more
internally consistent, specifically, only a thread that GDB thinks is
resumed, can be a candidate for having stopped.

It turns out that, when GDB attaches to a process through an
extended-remote target, the threads of the process being attached too,
are not, initially, marked as resumed.

And so, when GDB tries to figure out which thread the stop might apply
too, it finds no threads in the processes marked resumed, and so an
assert triggers.

In extended_remote_target::attach we create a new thread with a call
to add_thread_silent, rather than remote_target::remote_add_thread,
the reason is that calling the latter will result in a call to
'add_thread' rather than 'add_thread_silent'.  However,
remote_target::remote_add_thread includes additional
actions (i.e. calling remote_thread_info::set_resumed and set_running)
which are missing from extended_remote_target::attach.  These missing
calls are what would serve to mark the new thread as resumed.

In this commit I propose that we add an extra parameter to
remote_target::remote_add_thread.  This new parameter will force the
new thread to be added with a call to add_thread_silent.  We can now
call remote_add_thread from the ::attach method, the extra
actions (listed above) will now be performed, and the thread will be
left in the correct state.

Additionally, in PR gdb/28405, a segfault is reported.  This segfault
triggers when 'set debug remote 1' is used before trying to reproduce
the original assertion failure.  The cause of this is in
remote_target::select_thread_for_ambiguous_stop_reply, where we do
this:

  remote_debug_printf ("first resumed thread is %s",
       pid_to_str (first_resumed_thread->ptid).c_str ());
  remote_debug_printf ("is this guess ambiguous? = %d", ambiguous);

  gdb_assert (first_resumed_thread != nullptr);

Notice that when debug printing is on we dereference
first_resumed_thread before we assert that the pointer is not
nullptr.  This is the cause of the segfault, and is resolved by moving
the assert before the debug printing code.

I've extended an existing test, ext-attach.exp, so that the original
test is run multiple times; we run in the original mode, as normal,
but also, we now run with different packets disabled in gdbserver.  In
particular, disabling Tthread would trigger the assertion as it was
reported in the original bug.  I also run the test in all-stop and
non-stop modes now for extra coverage, we also run the tests with
target-async enabled, and disabled.

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

gdb: on x86-64 non-trivial C++ objects are returned in memory

Fixes PR gdb/28681.  It was observed that after using the `finish`
command an incorrect value was displayed in some cases.  Specifically,
this behaviour was observed on an x86-64 target.

Consider this test program:

  struct A
  {
    int i;

    A ()
    { this->i = 0; }
    A (const A& a)
    { this->i = a.i; }
  };

  A
  func (int i)
  {
    A a;
    a.i = i;
    return a;
  }

  int
  main ()
  {
    A a = func (3);
    return a.i;
  }

And this GDB session:

  $ gdb -q ex.x
  Reading symbols from ex.x...
  (gdb) b func
  Breakpoint 1 at 0x401115: file ex.cc, line 14.
  (gdb) r
  Starting program: /home/andrew/tmp/ex.x

  Breakpoint 1, func (i=3) at ex.cc:14
  14   A a;
  (gdb) finish
  Run till exit from #0  func (i=3) at ex.cc:14
  main () at ex.cc:23
  23   return a.i;
  Value returned is $1 = {
    i = -19044
  }
  (gdb) p a
  $2 = {
    i = 3
  }
  (gdb)

Notice how after the `finish` the contents of $1 are junk, but, when I
immediately ask for the value of `a`, I get back the correct value.

The problem here is that after the finish command GDB calls the
function amd64_return_value to figure out where the return value can
be found (on x86-64 targets anyway).

This function makes the wrong choice for the struct A in our case, as
sizeof(A) <= 8, then amd64_return_value decides that A will be
returned in a register.  GDB then reads the return value register an
interprets the contents as an instance of A.

Unfortunately, A is not trivially copyable (due to its copy
constructor), and the sys-v specification for argument and return
value passing, says that any non-trivial C++ object should have space
allocated for it by the caller, and the address of this space is
passed to the callee as a hidden first argument.  The callee should
then return the address of this space as the return value.

And so, the register that GDB is treating as containing an instance of
A, actually contains the address of an instance of A (in this case on
the stack), this is why GDB shows the incorrect result.

The call stack within GDB for where we actually go wrong is this:

  amd64_return_value
    amd64_classify
      amd64_classify_aggregate

And it is in amd64_classify_aggregate that we should be classifying
the type as AMD64_MEMORY, instead of as AMD64_INTEGER as we currently
do (via a call to amd64_classify_aggregate_field).

At the top of amd64_classify_aggregate we already have this logic:

  if (TYPE_LENGTH (type) > 16 || amd64_has_unaligned_fields (type))
    {
      theclass[0] = theclass[1] = AMD64_MEMORY;
      return;
    }

Which handles some easy cases where we know a struct will be placed
into memory, that is (a) the struct is more than 16-bytes in size,
or (b) the struct has any unaligned fields.

All we need then, is to add a check here to see if the struct is
trivially copyable.  If it is not then we know the struct will be
passed in memory.

I originally structured the code like this:

  if (TYPE_LENGTH (type) > 16
      || amd64_has_unaligned_fields (type)
      || !language_pass_by_reference (type).trivially_copyable)
    {
      theclass[0] = theclass[1] = AMD64_MEMORY;
      return;
    }

This solved the example from the bug, and my small example above.  So
then I started adding some more extensive tests to the GDB testsuite,
and I ran into a problem.  I hit this error:

  gdbtypes.h:676: internal-error: loc_bitpos: Assertion `m_loc_kind == FIELD_LOC_KIND_BITPOS' failed.

This problem is triggered from:

  amd64_classify_aggregate
    amd64_has_unaligned_fields
      field::loc_bitpos

Inside the unaligned field check we try to get the bit position of
each field.  Unfortunately, in some cases the field location is not
FIELD_LOC_KIND_BITPOS, but is FIELD_LOC_KIND_DWARF_BLOCK.

An example that shows this bug is:

  struct B
  {
    short j;
  };

  struct A : virtual public B
  {
    short i;

    A ()
    { this->i = 0; }
    A (const A& a)
    { this->i = a.i; }
  };

  A
  func (int i)
  {
    A a;
    a.i = i;
    return a;
  }

  int
  main ()
  {
    A a = func (3);
    return a.i;
  }

It is the virtual base class, B, that causes the problem.  The base
class is represented, within GDB, as a field within A.  However, the
location type for this field is a DWARF_BLOCK.

I spent a little time trying to figure out how to convert the
DWARF_BLOCK to a BITPOS, however, I realised that, in this case at
least, conversion is not needed.

The C++ standard says that a class is not trivially copyable if it has
any virtual base classes.  And so, in this case, even if I could
figure out the BITPOS for the virtual base class fields, I know for
sure that I would immediately fail the trivially_copyable check.  So,
lets just reorder the checks in amd64_classify_aggregate to:

  if (TYPE_LENGTH (type) > 16
      || !language_pass_by_reference (type).trivially_copyable
      || amd64_has_unaligned_fields (type))
    {
      theclass[0] = theclass[1] = AMD64_MEMORY;
      return;
    }

Now, if we have a class with virtual bases we will fail quicker, and
avoid the unaligned fields check completely.

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

gdb: make use of SCOPE_EXIT to manage thread executing state

While working on another patch relating to how GDB manages threads
executing and resumed state, I spotted the following code in
record-btrace.c:

  executing = tp->executing ();
  set_executing (proc_target, inferior_ptid, false);

  id = null_frame_id;
  try
    {
      id = get_frame_id (get_current_frame ());
    }
  catch (const gdb_exception &except)
    {
      /* Restore the previous execution state.  */
      set_executing (proc_target, inferior_ptid, executing);

      throw;
    }

  /* Restore the previous execution state.  */
  set_executing (proc_target, inferior_ptid, executing);

  return id;

I notice that we only catch the exception so we can call
set_executing, and this is the same call to set_executing that we need
to perform in the non-exception return path.

This would be much cleaner if we could use SCOPE_EXIT to avoid the
try/catch, so lets do that.

While cleaning this up, I also applied a similar patch to
record-full.c, though there's no try/catch in that case, but using
SCOPE_EXIT makes the code safe if, in the future, we do start throwing
exceptions.

There should be no user visible changes after this commit.

Automatic date update in version.in

gdb/doc: add some index entries relating to mi-async setting

I noticed that the mi-async setting was not referenced from the index
in any way, this commit tries to rectify that a bit.

The @cindex lines I think are not controversial, these same index
entries are used elsewhere in the manual for async related topics (see
@node Background Execution).

The only bit that might be controversial is that I've added a @kindex
entry for 'set mi-async' when the command is documented as '-gdb-set
mi-async' (with a similar difference for the show/-gdb-show).

My reasoning here is that nothing else is indexed under -gdb-set or
-gdb-show, and as -gdb-set/-gdb-show are just the MI equivalent for
set/show anything that is documented under set/show can be adjusted
using -gdb-set/-gdbshow, and so, I've tried to keep the index
consistent for mi-async.

gdb: convert 'set debug lin-lwp' to a boolean command

Convert the 'set debug lin-lwp' command to a boolean.  Adds a new
LINUX_NAT_SCOPED_DEBUG_ENTER_EXIT macro, and makes use of it in one
place (linux_nat_target::stop).

The manual entry for 'set debug lin-lwp' is already vague about
exactly what arguments this command takes, and the description talks
about turning debug on and off, so I don't think there's any updates
required there.

I have updated the doc strings shown when the users enters 'help show
debug lin-lwp' or 'help show debug lin-lwp'.  The old title lines used
to talk about the 'GNU/Linux lwp module', but this debug flag is now
used for any native linux target debug, so we now talk about
'GNU/Linux native target'.  The body string for this setting has been
changed from 'Enables printf debugging output.' to 'When on, print
debug messages relating to the GNU/Linux native target.', the old
value looks like a cut&paste error to me.

gdb: add threads debugging switch

Add new commands:

  set debug threads on|off
  show debug threads

Prints additional debug information relating to thread creation and
deletion.

GDB already announces when threads are created of course.... most of
the time, but sometimes threads are added silently, in which case this
debug message is the only mechanism to see the thread being added.
Also, though GDB does announce when a thread exits, it doesn't
announce when the thread object is deleted, I've added a debug message
for that.

Additionally, having message printed through the debug system will
cause the messages to be nested to an appropriate depth when other
debug sub-systems are turned on (especially things like `infrun` and
`lin-lwp`).

RISC-V: Update Scalar Crypto testcases.

Add opcodes in testcases to make sure every instruction generate
right opcode after disassemble.

gas/ChangeLog:

        * testsuite/gas/riscv/k-ext-64.d: Add opcode detect.
        * testsuite/gas/riscv/k-ext.d: Ditto.
        * testsuite/gas/riscv/zbkb-32.d: Ditto.
        * testsuite/gas/riscv/zbkb-64.d: Ditto.
        * testsuite/gas/riscv/zbkc-32.d: Ditto.
        * testsuite/gas/riscv/zbkc-64.d: Ditto.
        * testsuite/gas/riscv/zbkx-32.d: Ditto.
        * testsuite/gas/riscv/zbkx-64.d: Ditto.
        * testsuite/gas/riscv/zknd-32.d: Ditto.
        * testsuite/gas/riscv/zknd-64.d: Ditto.
        * testsuite/gas/riscv/zkne-32.d: Ditto.
        * testsuite/gas/riscv/zkne-64.d: Ditto.
        * testsuite/gas/riscv/zknh-32.d: Ditto.
        * testsuite/gas/riscv/zknh-64.d: Ditto.
        * testsuite/gas/riscv/zksed-32.d: Ditto.
        * testsuite/gas/riscv/zksed-64.d: Ditto.
        * testsuite/gas/riscv/zksh-32.d: Ditto.
        * testsuite/gas/riscv/zksh-64.d: Ditto.

gdbarch-components.py: change empty "params" tuples to empty lists

During review, it was suggested to change the "params" parameter from a
tuple to a list, for esthetic reasons.  The empty ones are still tuples
though, they should probably be changed to be empty lists, for
consistency.  It does not change anything in the script result.

Change-Id: If13c6c527aa167a5ee5b45740e5f1bda1e9517e4

Automatic date update in version.in

[AArch64] Fix typo in error messages

Fix mispelling of PROT_ME to PROT_MTE in the error messages.

Obsolete m32c-rtems and m32r-rtems

2020-12-20  Joel Sherrill <joel@rtems.org>

bfd/
* config.bfd (m32c-*-rtems*): Remove target.

ld/
* configure.tgt (m32c-*-rtems*): Remove target.
* configure.tgt (m32r-*-rtems*): Remove target.

x86: -mfence-as-lock-add=yes doesn't work for 16-bit mode

Rather than trying to fix this (which would require making an assumption
on the upper half of %esp being zero), simply issue an error. While at
it, since the generated code is in conflict with -momit-lock-prefix=yes,
issue an error in that case as well.

gas/ELF: avoid below-base ref in obj_elf_parse_section_letters()

We would better be prepared for 'm' being the first character of the
incoming string.

Typo fixes in binutils doc

* doc/binutils.texi: Fix typos.

Automatic date update in version.in

Remove print_spaces

This removes the print_spaces helper function, in favor of using the
"*%s" idiom that's already used in many places in gdb.  One spot (in
symmisc.c) is changed to use print_spaces_filtered, because the rest
of that function is using filtered output.  (This highlights one way
that the printf idiom is better -- this error is harder to make when
using that.)

Regression tested on x86-64 Fedora 34.

Remove puts_debug

I noticed that puts_debug isn't used in the tree.  git log tells me
that the last use was removed in 2015:

    commit 40e0b27177e747600d3ec186458fe0e482a1cf77
    Author: Pedro Alves <palves@redhat.com>
    Date:   Mon Aug 24 15:40:26 2015 +0100

Delete the remaining ROM monitor targets

... and this commit mentions that the code being removed here probably
hadn't worked for 6 years prior to that.

Based on this, I'm removing puts_debug.  I don't think it's useful.
Tested by rebuilding.

Make n_spaces return a const char *

n_spaces keeps the spaces in a static buffer.  If a caller overwrites
these, it may give an incorrect result to a subsequent caller.  So,
make the return type const to help avoid this outcome.

Add Enze Li to gdb/MAINTAINERS

gdb/ada-exp.y: Reformat comment to follow GDB's coding standards

This commit reformats a comment in gdb/ada-exp.y to avoid
the leading '*' at the beginning of each line of the comment.

gdb/ada-lang.h: Reformat comment to follow coding standards

This commit reformats a comment in gdb/ada-lang.h to avoid
the leading '*' at the beginning of each line of the comment.

Automatic date update in version.in

Obsolete m32c-rtems

readelf: avoid a possible divide by zero

* readelf.c (process_section_headers): Check SHT_RELR entsize.

Automatic date update in version.in

gdb: add "exit" command as an alias for "quit"

This command adds the "exit" command as an alias for the "quit"
command, as requested in PR gdb/28406.

The documentation is also updated to mention this new command.

Tested on x86_64-linux.

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

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/remote: some fixes for 'maint set target-async off'

While working on another patch relating to remote targets, I wanted to
test with 'maint set target-async off' in place.  Unfortunately I ran
into some problems.  This commit is an attempt to fix one of the
issues I hit.

In my particular case I was actually running with:

  maint set target-async off
  maint set target-non-stop off

that is, we're telling GDB to force the targets to operate in
non-async mode, and in all-stop mode.  Here's my GDB session showing
the problem:

  (gdb) maintenance set target-async off
  (gdb) maintenance set target-non-stop off
  (gdb) target extended-remote :54321
  Remote debugging using :54321
  (gdb) attach 2365960
  Attaching to process 2365960
  No unwaited-for children left.
  (gdb)

Notice the 'No unwaited-for children left.' error, this is the
problem.  There's no reason why GDB should not be able to attach to
the process.

The problem is this:

  1. The user runs 'attach PID' and this sends GDB into attach_command
  in infcmd.c.  From here we call the ::attach method on the attach
  target, which will be the extended_remote_target.

  2. In extended_remote_target::attach, we attach to the remote target
  and get the first reply (which is a stop packet).  We put off
  processing the stop packet until the end of ::attach.  We setup the
  inferior and thread to represent the process we attached to, and
  download the target description.  Finally, we process the initial
  stop packet.

  If '!target_is_non_stop_p ()' and '!target_can_async_p ()', which is
  the case for us given the maintenance commands we used, we cache the
  stop packet within the remote_state::buf for later processing.

  3. Back in attach_command, if 'target_is_non_stop_p ()' then we
  request that the target stops.  This will either process any cached
  stop replies, or request that the target stops, and process the stop
  replies.  However, this code is not what we use due to non-stop mode
  being disabled.  So, we skip to the next step which is to call
  validate_exec_file.

  4. Calling validate_exec_file can cause packets to be sent to the
  remote target, and replies received, the first path I hit is the
  call to target_pid_to_exec_file, which calls
  remote_target::pid_to_exec_file, which can then try to read the
  executable from the remote.  Sending an receiving packets will make
  use of the remote_state::buf object.

  5. The attempt to attach continues, but the damage is already done...

So, the problem is that, in step #2 we cache a stop reply in the
remote_state::buf, and then in step #4 we reuse the remote_state::buf
object, discarding any cached stop reply.  As a result, the initial
stop, which is sent when GDB first attaches to the target, is lost.

This problem can clearly be seen, I feel, by looking at the
remote_state::cached_wait_status flag.  This flag tells GDB if there
is a wait status cached in remote_state::buf.  However, in
remote_target::putpkt_binary and remote_target::getpkt_or_notif_sane_1
this flag is just set back to 0, doing this immediately discards any
cached data.

I don't know if this scheme ever made sense,  looking at commit
2d717e4f8a54, where the cached_wait_status flag was added, it appears
that there was nothing between where the stop was cached, and where
the stop was consumed, so, I suspect, there never was a situation
where we ended up in putpkt_binary or getpkt_or_notif_sane_1 and
needed to clear to the flag, maybe the clearing was added "just in
case".  Whatever the history, I claim that this clearing this flag is
no longer a good idea.

So, my first step toward fixing this issue was to replace the two
instances of 'rs->cached_wait_status = 0;' in ::putpkt_binary and
::getpkt_or_notif_sane_1 with 'gdb_assert (rs->cached_wait_status ==
0);', this, at least would show me when GDB was doing something
dangerous, and indeed, this assert is now hit in my test case above.

I did play with using some kind of scoped restore to backup, and
restore the remote_state::buf object in all the places within remote.c
that I was hitting where the ::buf was being corrupted.  The first
problem with this is that, where the ::cached_wait_status flag is
reset is _not_ where ::buf is corrupted.  For the ::putpkt_binary
case, by the time we get to the method the buffer has already been
corrupted in many cases, so we end up needing to add the scoped
save/restore within the callers, which means we need the save/restore
in _lots_ of places.

Plus, using this save/restore model feels like the wrong solution.  I
don't think that it's obvious that the buffer might be holding cached
data, and I think it would be too easy for new corruptions of the
buffer to be introduced, which could easily go unnoticed for a long
time.

So, I really wanted a solution that didn't require us to cache data in
the ::buf object.

Luckily, I think we already have such a solution in place, the
remote_state::stop_reply_queue, it seems like this does exactly the
same task, just in a slightly different way.  With the
::stop_reply_queue, the stop packets are processed upon receipt and
the stop_reply object is added to the queue.  With the ::buf cache
solution, the unprocessed stop reply is cached in the ::buf, and
processed later.

So, finally, in this commit, I propose to remove the
remote_state::cached_wait_status flag and to stop using the ::buf to
cache stop replies.  Instead, stop replies will now always be stored
in the ::stop_reply_queue.

There are two places where we use the ::buf to hold a cached stop
reply, the first is in the ::attach method, and the second is in
remote_target::start_remote, however, the second of these cases is far
less problematic, as after caching the stop reply in ::buf we call the
global start_remote function, which does very little work before
calling normal_stop, which processes the cached stop reply.  However,
my plan is to switch both users over to using ::stop_reply_queue so
that the old (unsafe) ::cached_wait_status mechanism can be completely
removed.

The next problem is that the ::stop_reply_queue is currently only used
for async-mode, and so, in remote_target::push_stop_reply, where we
push stop_reply objects into the ::stop_reply_queue, we currently also
mark the async event token.  I've modified this so we only mark the
async event token if 'target_is_async_p ()' - note, _is_, not _can_
here. The ::push_stop_reply method is called in places where async
mode has been temporarily disabled, but, when async mode is switched
back on (see remote_target::async) we will mark the event token if
there are events in the queue.

Another change of interest is in remote_target::remote_interrupt_as.
Previously this code checked ::cached_wait_status, but didn't check
for events in the ::stop_reply_queue.  Now that ::cached_wait_status
has been removed we now check the queue length instead, which should
have the same result.

Finally, in remote_target::wait_as, I've tried to merge the processing
of the ::stop_reply_queue with how we used to handle the
::cached_wait_status flag.

Currently, when processing the ::stop_reply_queue we call
process_stop_reply and immediately return.  However, when handling
::cached_wait_status we run through the whole of ::wait_as, and return
at the end of the function.

If we consider a standard stop packet, the two differences I see are:

  1. Resetting of the remote_state::waiting_for_stop_reply, flag; this
  is not currently done when processing a stop from the
  ::stop_reply_queue.

  2. The final return value has the possibility of being adjusted at
  the end of ::wait_as, as well as there being calls to
  record_currthread, non of which are done if we process a stop from
  the ::stop_reply_queue.

After discussion on the mailing list:

  https://sourceware.org/pipermail/gdb-patches/2021-December/184535.html

it was suggested that, when an event is pushed into the
::stop_reply_queue, the ::waiting_for_stop_reply flag is never going
to be set.  As a result, we don't need to worry about the first
difference.  I have however, added a gdb_assert to validate the
assumption that the flag is never going to be set.  If in future the
situation ever changes, then we should find out pretty quickly.

As for the second difference, I have resolved this by having all stop
packets taken from the ::stop_reply_queue, pass through the return
value adjustment code at the end of ::wait_as.

An example of a test that reveals the benefits of this commit is:

  make check-gdb \
    RUNTESTFLAGS="--target_board=native-extended-gdbserver \
                  GDBFLAGS='-ex maint\ set\ target-async\ off \
                            -ex maint\ set\ target-non-stop\ off' \
                  gdb.base/attach.exp"

For testing I've been running test on x86-64/GNU Linux, and run with
target boards unix, native-gdbserver, and native-extended-gdbserver.
For each board I've run with the default GDBFLAGS, as well as with:

  GDBFLAGS='-ex maint\ set\ target-async\ off \
            -ex maint\ set\ target-non-stop\ off' \

Though running with the above GDBFLAGS is clearly a lot more unstable
both before and after my patch, I'm not seeing any consistent new
failures with my patch, except, with the native-extended-gdbserver
board, where I am seeing new failures, but only because more tests are
now running.  For that configuration alone I see the number of
unresolved go down by 49, the number of passes goes up by 446, and the
number of failures also increases by 144.  All of the failures are new
tests as far as I can tell.

x86: Terminate mnemonicendp in swap_operand()

Tested on x86_64-pc-linux-gnu.

opcodes/ChangeLog:
2021-12-17 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>

* i386-dis.c (swap_operand): Terminate mnemonicendp.

gas/ChangeLog:
2021-12-17 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>

* testsuite/gas/i386/opts-intel.d: Updated expected disassembly.
* testsuite/gas/i386/opts.d: Likewise.
* testsuite/gas/i386/sse2avx-opts-intel.d: Likewise.
* testsuite/gas/i386/sse2avx-opts.d: Likewise.
* testsuite/gas/i386/x86-64-opts-intel.d: Likewise.
* testsuite/gas/i386/x86-64-opts.d: Likewise.
* testsuite/gas/i386/x86-64-sse2avx-opts-intel.d: Likewise.
* testsuite/gas/i386/x86-64-sse2avx-opts.d: Likewise.

Automatic date update in version.in

Document gdbarch-components.py

This adds a comment to document how to update gdbarch.

Remove gdbarch.sh

This patch runs gdbarch.py and removes gdbarch.sh.

Add new gdbarch generator

The new gdbarch generator is a Python program.  It reads the
"components.py" that was created in the previous patch, and generates
gdbarch.c and gdbarch-gen.h.

This is a relatively straightforward translation of the existing .sh
code.  It doesn't try very hard to be idiomatic Python or to be
especially smart.

It is, however, incredibly faster:

    $ time ./gdbarch.sh

    real 0m8.197s
    user 0m5.779s
    sys 0m3.384s

    $ time ./gdbarch.py

    real 0m0.065s
    user 0m0.053s
    sys 0m0.011s

Co-Authored-By: Tom Tromey <tom@tromey.com>

Generate new gdbarch-components.py from gdbarch.sh

The new gdbarch.sh approach will be to edit a Python file, rather than
adding a line to a certain part of gdbarch.sh.  We use the existing sh
code, though, to generate the first draft of this .py file.

Documentation on the format will come in a subsequent patch.

Note that some info (like "staticdefault") in the current code is
actually unused, and so is ignored by this new generator.

Do not sort the fields in gdbarch_dump

This changes gdbarch.sh so that it no longer sorts the fields in
gdbarch_dump.  This sorting isn't done anywhere else by gdbarch.sh,
and this simplifies the new generator a little bit.

Do not generate gdbarch.h

Now that gdbarch.h has been split, we no longer need the generator
code in gdbarch.sh, so remove it.

Split gdbarch.h into two files

This patch splits gdbarch.h into two files -- gdbarch.h now is
editable and hand-maintained, and the new gdbarch-gen.h file is the
only thing generated by gdbarch.sh.  This lets us avoid maintaining
boilerplate in the gdbarch.sh file.

Note that gdbarch.sh still generates gdbarch.h after this patch.  This
makes it easier to re-run when rebasing.  This code is removed in a
subsequent patch.

Move ordinary gdbarch code to arch-utils

While I think it makes sense to generate gdbarch.c, at the same time I
think it is better for ordinary code to be editable in a C file -- not
as a hunk of C code embedded in the generator.

This patch moves this sort of code out of gdbarch.sh and gdbarch.c and
into arch-utils.c, then has arch-utils.c include gdbarch.c.

Avoid redundant operations in `fortran_array_walker'

Move inner dimension's element type determination outside the respective
loops in `fortran_array_walker'.  The operation is exactly the same with
each iteration, so there is no point in redoing it for each element and
while a smart compiler might be able to move it outside the loop it is
regardless a bad coding style.  No functional change.

Initialize `m_ndimensions' in the member initializer list

Following our coding convention initialize the `m_ndimensions' member in
the member initializer list rather than in the body of the constructor
of the `fortran_array_walker' class.  No functional change.

gdb/tui: install SIGWINCH only when connected to a TTY

PR26056 reports that when GDB is connected to non-TTY stdin/stdout, it
crashes when it receives a SIGWINCH signal.

This can be reproduced as follows:

    $ gdb/gdb -nx -batch -ex 'run' --args sleep 60 </dev/null 2>&1 | cat

    # from another terminal:
    $ kill -WINCH %(pidof gdb)

When doing so, the process crashes in a call to rl_resize_terminal:

    void
    rl_resize_terminal (void)
    {
      _rl_get_screen_size (fileno (rl_instream), 1);
      ...
    }

The problem is that at this point rl_instream has the value NULL.

The rl_instream variable is supposed to be initialized during a call to
readline_initialize_everything, which in a normal startup sequence is
called under this call chain:

    tui_interp::init
      tui_ensure_readline_initialized
        rl_initialize
          readline_initialize_everything

In tui_interp::init, we have the following sequence:

    tui_initialize_io ();
    tui_initialize_win ();                // <- Installs SIGWINCH
    if (gdb_stdout->isatty ())
      tui_ensure_readline_initialized (); // <- Initializes rl_instream

This function unconditionally installs the SIGWINCH signal handler (this
is done by tui_initialize_win), and then if gdb_stdout is a TTY it
initializes readline.  Therefore, if stdout is not a TTY, SIGWINCH is
installed but readline is not initialized.  In such situation
rl_instream stays NULL, and when GDB receives a SIGWINCH it calls its
handler and in fine tries to access rl_instream leading to the crash.

This patch proposes to fix this issue by installing the SIGWINCH signal
handler only if GDB is connected to a TTY.  Given that this
initialization it the only task of tui_initialize_win, this patch moves
tui_initialize_win just after the call to
tui_ensure_readline_initialized.

Tested on x86_64-linux.

Co-authored-by: Pedro Alves <pedro@palves.net>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=26056
Change-Id: I6458acef7b0d9beda2a10715d0345f02361076d9

asan: NULL dereference in bfd_elf_set_group_contents

* elf-bfd.h (struct output_elf_obj_tdata): Make num_section_syms
unsigned.
* elf.c (bfd_elf_set_group_contents): Bounds check sec->index
and check that entry in elf_section_syms for sec is non-NULL.
(_bfd_elf_symbol_from_bfd_symbol): Adjust.

asan: use after free in _bfd_elf_mips_get_relocated_section_contents

Leaving entries on mips_hi16_list from a previous pass over relocs
leads to confusing bugs.

* elfxx-mips.c (_bfd_elf_mips_get_relocated_section_contents):
Free mips_hi16_list entries on error exit.

asan: abort in wasm_scan_name_function_section

Macros like READ_LEB128 in wasm-module.c that alter control flow are
evil.  Maintainers will break your code if you have hidden ways to
reach labels.

* wasm-module.c (wasm_scan_name_function_section): Don't
attempt to bfd_release NULL.

asan: heap-buffer-overflow in bpf_elf_generic_reloc

The bpf reloc howtos are a bit weird, using bitpos to specify an
offset from r_offset that is outside the size of the reloc as given by
howto.size.  That means bfd_get_reloc_size gives the wrong answer for
range checking, and thus bfd_reloc_offset_in_range can't be used.

* elf64-bpf.c (bpf_elf_generic_reloc): Handle bitpos offset reloc
range checking.

ubsan: bfd.c:2519:8: shift exponent 34 is too large

* bfd.c (bfd_update_compression_header): Avoid integer overflow.

asan: buffer overflow in mmo_get_symbols

* mmo.c (mmo_get_symbols): Error on symbol name exceeding max length.

asan: buffer overflow in elfnn-aarch64.c get_plt_type

We can't assume .dynamic is a multiple of ElfNN_External_Dyn, at least
not when presented with fuzzed object files.

* elfnn-aarch64.c (get_plt_type): Don't access past end of
improperly sized .dynamic.

try_build_id_prefix gcc-10 -Wformat-security errors

dwarf.c:11300:3: error: format not a string literal and no format arguments [-Werror=format-security]
11300 |   f += sprintf (f, prefix);

PR 28697
* dwarf.c (try_build_id_prefix): Avoid -Wformat-security error.

Automatic date update in version.in

Fix AVR assembler so that it creates relocs that will work with linker relaxation.

PR 28686
gas * config/tc-avr.h (tc_fix_adjustable): Define.
* config/tc-avr.c (avr_fix_adjustable): New function.
* testsuite/gas/all/gas.exp: Skip tests that need adjustable fixups.
* testsuite/gas/elf/elf.exp: Likewise.
* testsuite/gas/avr/diffreloc_withrelax.d: Adjust expected output.
* testsuite/gas/avr/pc-relative-reloc.d: Adjust expected output.

ld * testsuite/ld-avr/avr-prop-7.d: Adjust expected output.
* testsuite/ld-avr/avr-prop-8.d: Likewise.
* testsuite/ld-avr/pr13402.d: Likewise.

When loading separate debug info files, also attempt to locate a file based upon the build-id.

PR 28697
* dwarf.c (load_build_id_debug_file): New function.
(try_build_id_prefix): New function.
(check_for_and_load_links): Call load_build_id_debug_file.
(debug_displays): Add entry for .note.gnu.build-id.
* dwarf.h (enum dwarf_section_display_enum): Add
note_gnu_build_id.
* testsuite/binutils-all/debuginfod.exp (test_fetch_debuglink):
Fix regexp for loads via debuglink section.

arm: Add support for Armv9.1-A to Armv9.3-A

This patch adds AArch32 support for -march=armv9.[123]-a.
The behaviour of the new options can be expressed using a
combination of existing feature flags and tables.

The cpu_arch_ver entries for ARM_ARCH_V9_2A and ARM_ARCH_V9_3A
are technically redundant but it seemed less surprising to include
them anyway.

include/
* opcode/arm.h (ARM_ARCH_V9_1A, ARM_ARCH_V9_2A): New macros.
(ARM_ARCH_V9_3A): Likewise.

gas/
* doc/c-arm.texi: Add armv9.1-a, armv9.2-a and armv9.3-a.
* config/tc-arm.c (armv91a_ext_table, armv92a_ext_table): New macros.
(armv93a_ext_table): Likewise.
(arm_archs): Add armv9.1-a, armv9.2-a and armv9.3-a.
(cpu_arch_ver): Add ARM_ARCH_V9_1A, ARM_ARCH_V9_2A and ARM_ARCH_V9_3A.
* NEWS: Mention the above.
* testsuite/gas/arm/attr-march-armv9_1-a.d: New test.
* testsuite/gas/arm/attr-march-armv9_2-a.d: Likewise.
* testsuite/gas/arm/attr-march-armv9_3-a.d: Likewise.
* testsuite/gas/arm/bfloat16-armv9.1-a.d: Likewise.
* testsuite/gas/arm/bfloat16-armv9.2-a.d: Likewise.
* testsuite/gas/arm/bfloat16-armv9.3-a.d: Likewise.
* testsuite/gas/arm/i8mm-armv9.1-a.d: Likewise.
* testsuite/gas/arm/i8mm-armv9.2-a.d: Likewise.
* testsuite/gas/arm/i8mm-armv9.3-a.d: Likewise.

arm: Add support for Armv8.7-A and Armv8.8-A

This patch adds AArch32 support for -march=armv8.[78]-a.
The behaviour of the new options can be expressed using a
combination of existing feature flags and tables.

The cpu_arch_ver entries are technically redundant but
it seemed less surprising to include them anyway.

include/
* opcode/arm.h (ARM_ARCH_V8_7A, ARM_ARCH_V8_8A): New macros.

gas/
* doc/c-arm.texi: Add armv8.7-a and armv8.8-a.
* config/tc-arm.c (armv87a_ext_table, armv88a_ext_table): New macros.
(arm_archs): Add armv8.7-a and armv8.8-a.
(cpu_arch_ver): Add ARM_ARCH_V8_7A and ARM_ARCH_V8_8A.
* NEWS: Mention the above.
* testsuite/gas/arm/attr-march-armv8_7-a.d: New test.
* testsuite/gas/arm/attr-march-armv8_8-a.d: Likewise.
* testsuite/gas/arm/bfloat16-armv8.7-a.d: Likewise.
* testsuite/gas/arm/bfloat16-armv8.8-a.d: Likewise.
* testsuite/gas/arm/i8mm-armv8.7-a.d: Likewise.
* testsuite/gas/arm/i8mm-armv8.8-a.d: Likewise.

aarch64: Add support for Armv9.1-A to Armv9.3-A

This patch adds AArch64 support for -march=armv9.[123]-a.
The behaviour of the new options can be expressed using a
combination of existing feature flags, so we don't need to
eat into the vanishing number of spare AARCH64_FEATURE_* bits.
Hoewver, it was more convenient to separate out the |s of
feature flags so that Armv9.1-A could reuse the set for
Armv8.6-A, and so on.

include/
* opcode/aarch64.h (AARCH64_ARCH_V8_FEATURES): New macro,
split out from...
(AARCH64_ARCH_V8): ...here.
(AARCH64_ARCH_V8_1_FEATURES): New macro, split out from...
(AARCH64_ARCH_V8_1): ...here.
(AARCH64_ARCH_V8_2_FEATURES): New macro, split out from...
(AARCH64_ARCH_V8_2): ...here.
(AARCH64_ARCH_V8_3_FEATURES): New macro, split out from...
(AARCH64_ARCH_V8_3): ...here.
(AARCH64_ARCH_V8_4_FEATURES): New macro, split out from...
(AARCH64_ARCH_V8_4): ...here.
(AARCH64_ARCH_V8_5_FEATURES): New macro, split out from...
(AARCH64_ARCH_V8_5): ...here.
(AARCH64_ARCH_V8_6_FEATURES): New macro, split out from...
(AARCH64_ARCH_V8_6): ...here.
(AARCH64_ARCH_V8_7_FEATURES): New macro, split out from...
(AARCH64_ARCH_V8_7): ...here.
(AARCH64_ARCH_V8_8_FEATURES): New macro, split out from...
(AARCH64_ARCH_V8_8): ...here.
(AARCH64_ARCH_V9_FEATURES): New macro, split out from...
(AARCH64_ARCH_V9): ...here.
(AARCH64_ARCH_V9_1_FEATURES, AARCH64_ARCH_V9_1): New macros.
(AARCH64_ARCH_V9_2_FEATURES, AARCH64_ARCH_V9_2): New macros.
(AARCH64_ARCH_V9_3_FEATURES, AARCH64_ARCH_V9_3): New macros.

gas/
* doc/c-aarch64.texi: Add armv9.1-a, armv9-2-a and armv9.3-a.
* config/tc-aarch64.c (aarch64_archs): Likewise.
* NEWS: Mention the above.
* testsuite/gas/aarch64/armv9_invalid.d,
testsuite/gas/aarch64/armv9_invalid.s,
testsuite/gas/aarch64/armv9_invalid.l: New test.
* testsuite/gas/aarch64/armv9_1.d,
testsuite/gas/aarch64/armv9_1.s: Likewise.
* testsuite/gas/aarch64/armv9_1_invalid.d,
testsuite/gas/aarch64/armv9_1_invalid.s,
testsuite/gas/aarch64/armv9_1_invalid.l: Likewise.
* testsuite/gas/aarch64/armv9_2.d,
testsuite/gas/aarch64/armv9_2.s: Likewise.
* testsuite/gas/aarch64/armv9_2_invalid.d,
testsuite/gas/aarch64/armv9_2_invalid.s,
testsuite/gas/aarch64/armv9_2_invalid.l: Likewise.
* testsuite/gas/aarch64/armv9_3.d,
testsuite/gas/aarch64/armv9_3.s: Likewise.

RISC-V: Support svinval extension with frozen version 1.0.

According to the privileged spec, there are five new instructions for
svinval extension.  Two of them (HINVAL.VVMA and HINVAL.GVMA) need to
enable the hypervisor extension.  But there is no implementation of
hypervisor extension in mainline for now, so let's consider the related
issues later.

                31..25  24..20 19..15 14..12 11...7 6..2  1..0
sinval.vma      0001011 rs2    rs1    000    00000  11100 11
sfence.w.inval  0001100 00000  00000  000    00000  11100 11
sfence.inval.ir 0001100 00001  00000  000    00000  11100 11
hinval.vvma     0010011 rs2    rs1    000    00000  11100 11
hinval.gvma     0110011 rs2    rs1    000    00000  11100 11

This patch is cherry-picked from the riscv integration branch since the
svinval extension is frozen for now.  Besides, we fix the funct7 encodings
of hinval.vvma and hinval.gvma, from 0x0011011 and 0x0111011 to 0x0010011
and 0x0110011.

bfd/
* elfxx-riscv.c (riscv_supported_std_s_ext): Added svinval.
(riscv_multi_subset_supports): Handle INSN_CLASS_SVINVAL.
gas/
* testsuite/gas/riscv/svinval.d: New testcase.
* testsuite/gas/riscv/svinval.s: Likewise.
include/
* opcode/riscv-opc.h: Added encodings for svinval.
* opcode/riscv.h (enum riscv_insn_class): Added INSN_CLASS_SVINVAL.
opcodes/
* riscv-opc.c (riscv_opcodes): Added svinval instructions.

sim: mips/or1k: drop redundant arg to bitsize macro

These are just using the default behavior for the 3rd arg, so drop
it to make it more clear.  This also makes them match all other
ports that only use the first 2 arguments.

bfd: unify texi generation rules

The logic between these rules are extremely similar, so unify them
into a single variable by leveraging make $@ and $< variables.

Also add automake silent rule support while we're here.

sim: fix mingw builds with replacement gnulib open

The header shuffling in here broke the workaround for gnulib defining
"open".  Move it back before the sim-specific includes to fix.  This
is because the callback struct in the headers has an "open" member and
this file tries to call that.

Adjust compare_link_order for unstable qsort

In a cross toolchain for nios2-elf target and x86_64-w64-mingw32 host
using binutils 2.37, we observed a failure that didn't show up on
x86_64-linux-gnu host:  testcase pr25490-5.s was failing with

C:\path\to\nios2-elf-ld.exe: looping in map_segments
FAIL: __patchable_function_entries section 5

     * ldelfgen.c (compare_link_order): Don't use section id in
sorting.  Keep original ordering instead.  Update comments.

Re: Fix an undefined behaviour in the BFD library's DWARF parser

Using an unsigned int cast (to 32 bits) on a pointer difference (of
possibly 64 bits) is wrong.  Even though it will work on all real
object files, the fuzzers will eventually find this hole.

PR 28687
* dwarf1.c (parse_die): Cast pointer difference to size_t.
Catch another possible pointer overflow.

gdb: re-format with black 21.12b0

Run black 21.12b0 on gdb/, there is a single whitespace change.  I will
update the wiki [1] in parallel to bump the version of black to 21.12b0.

[1] https://sourceware.org/gdb/wiki/Internals%20GDB-Python-Coding-Standards

Change-Id: Ib3b859e3506c74a4f15d16f1e44ef402de3b98e2

gdb: re-format with black 21.9b0

Run black 21.9b0 on gdb/ (this is the version currently mentioned on the
wiki [1], the subsequent commit will bump that version).

[1] https://sourceware.org/gdb/wiki/Internals%20GDB-Python-Coding-Standards

Change-Id: I5ceaab42c42428e053e2572df172aa42a88f0f86

Automatic date update in version.in

PR28691, validate dwarf attribute form

PR28691 is a fuzzing PR that triggers a non-problem of "output changes
per run" with PIEs and/or different compilers.  I've closed similar
PRs before as wontfix, but I guess there will be no end of this type
of PR.  The trigger is an attribute that usually takes one of the
offset/constant reference DW_FORMs being given an indexed string
DW_FORM.  The bfd reader doesn't support indexed strings and returns
an error string instead.  The address of the string varies with PIE
runs and/or compiler, and we allow that address to appear in output.
Fix this by validating integer attribute forms, as we do for string
form attributes.

PR 28691
* dwarf2.c (is_str_attr): Rename to..
(is_str_form): ..this.  Change param type.  Update calls.
(is_int_form): New function.
(read_attribute_value): Handle DW_FORM_addrx2.
(find_abstract_instance): Validate form when using attr.u.val.
(scan_unit_for_symbols, parse_comp_unit): Likewise.

New --enable-threading configure option to control use of threads in GDB/GDBserver

Add the --enable-threading configure option so multithreading can be disabled
at configure time. This is useful for statically-linked builds of
GDB/GDBserver, since the thread library doesn't play well with that setup.

If you try to run a statically-linked GDB built with threading, it will crash
when setting up the number of worker threads.

This new option is also convenient when debugging GDB in a system with lots of
threads, where the thread discovery code in GDB will emit too many messages,
like so:

[New Thread 0xfffff74d3a50 (LWP 2625599)]

If you have X threads, that message will be repeated X times.

The default for --enable-threading is "yes".

Fix an undefined behaviour in the BFD library's DWARF parser.

PR 28687
* dwarf1.c (parse_die): Fix undefined behaviour in range tests.

PR28694, Out-of-bounds write in stab_xcoff_builtin_type

PR 28694
* stabs.c (stab_xcoff_builtin_type): Make typenum unsigned.
Negate typenum earlier, simplifying bounds checking.  Correct
off-by-one indexing.  Adjust switch cases.

Automatic date update in version.in

loongarch32 build failure on 32-bit host

gas/config/tc-loongarch.c: In function ‘assember_macro_helper’:
gas/config/tc-loongarch.c:915:28: error: right shift count >= width of type [-Werror=shift-count-overflow]
  915 |       hi32 = insn->args[1] >> 32;
      |                            ^~

One possible fix is to make offsetT a 64-bit type for loongarch32.
This also makes bfd/targmatch.h (generated from bfd/config.bfd)
consistent since the loongarch32 match is inside #ifdef BFD64.

* config.bfd (loongarch32-*): Set want64.

loongarch64 build failure on 32-bit host

gas/config/tc-loongarch.c: In function ‘loongarch_args_parser_can_match_arg_helper’:
gas/config/tc-loongarch.c:661:13: error: cast from pointer to integer of different size [-Werror=pointer
-to-int-cast]
  661 |       imm = (offsetT) str_hash_find (r_htab, arg);
      |             ^

Cast it to the correct size int, relying on normal integer promotions
if offsetT is larger than a pointer.

* config/tc-loongarch.c (loongarch_args_parser_can_match_arg_helper):
Cast return from str_hash_find to intptr_t, not offsetT.

XCOFF C_STSYM test failure on 32-bit host

This test was failing here and on another similar symbol:
[  4](sec  1)(fl 0x00)(ty   0)(scl 143) (nx 0) 0x05d1745d11745d21 .bs
where correct output is
[  4](sec  1)(fl 0x00)(ty   0)(scl 143) (nx 0) 0x000000000000000a .bs

The problem is caused by a 32-bit host pointer being sign-extended
when stored into a 64-bit bfd_vma, and then that value not being
trimmed back to 32 bits when used.  The following belt-and-braces
patch fixes both the store and subsequent reads.

* coffcode.h (coff_slurp_symbol_table): Do not sign extend
when storing a host pointer to syment.n_value.
* coffgen.c (coff_get_symbol_info): Cast syment.n_value to a
bfd_hostptr_t before using in arithmetic.
(coff_print_symbol): Likewise.

gdbserver/tracepoint.cc: use snprintf in gdb_agent_socket_init

If we modify tracepoint.cc to try to use a too long unix socket name,
for example by modifying SOCK_DIR to be:

    #define SOCK_DIR "/tmp/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut"

... trying to start an application with libinproctrace.so loaded
crashes:

    $ LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libasan.so.6:./libinproctrace.so /bin/ls
    /home/smarchi/src/binutils-gdb/gdbserver/../gdbsupport/common-utils.cc:69: A problem internal to GDBserver in-process agent has been detected.
    xsnprintf: Assertion `ret < size' failed.

Looking at the rest of the socket initialization code, the intent seems
to be that if something goes wrong, we warn but let the program
execute.  So crashing on this failed assertions seems against the intent.

Commit 6cebaf6e1ae4 ("use xsnprintf instead of snprintf.") changed this
code to use xsnprintf instead of snprintf, introducing this assertion.
Before that, snprintf would return a value bigger that UNIX_PATH_MAX and
the "if" after would catch it and emit a warning, which is exactly what
we want.  That change was done because LynxOS didn't have snprintf.
Since LynxOS isn't supported anymore, we can simply revert to use
snprintf there.

With this patch, we get a warning (printed by the caller of
gdb_agent_socket_init), but the program keeps executing:

    $ LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libasan.so.6:./libinproctrace.so /bin/ls
    ipa: could not create sync socket
    ...

Change-Id: I78bca52d5dc3145335abeae45a42052701e3f5dd

gdbserver/tracepoint.cc: work around -Wstringop-truncation error

When building gdb with  on AArch64 with g++ 11.1.0 (and some preceding
versions too), -O2 and -fsanitize=address, I get this error.

      CXX    tracepoint-ipa.o
    cc1plus: warning: command-line option ‘-Wmissing-prototypes’ is valid for C/ObjC but not for C++
    In file included from /usr/include/string.h:519,
                     from ../gnulib/import/string.h:41,
                     from /home/simark/src/binutils-gdb/gdbserver/../gdbsupport/common-defs.h:95,
                     from /home/simark/src/binutils-gdb/gdbserver/server.h:22,
                     from /home/simark/src/binutils-gdb/gdbserver/tracepoint.cc:19:
    In function ‘char* strncpy(char*, const char*, size_t)’,
        inlined from ‘int init_named_socket(const char*)’ at /home/simark/src/binutils-gdb/gdbserver/tracepoint.cc:6902:11,
        inlined from ‘int gdb_agent_socket_init()’ at /home/simark/src/binutils-gdb/gdbserver/tracepoint.cc:6953:26,
        inlined from ‘void* gdb_agent_helper_thread(void*)’ at /home/simark/src/binutils-gdb/gdbserver/tracepoint.cc:7204:41:
    /usr/include/bits/string_fortified.h:95:34: error: ‘char* __builtin_strncpy(char*, const char*, long unsigned int)’ output may be truncated copying 107 bytes from a string of length 107 [-Werror=stringop-truncation]
       95 |   return __builtin___strncpy_chk (__dest, __src, __len,
          |          ~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~
       96 |                                   __glibc_objsize (__dest));
          |                                   ~~~~~~~~~~~~~~~~~~~~~~~~~

Note that _FORTIFY_SOURCE changes the message a bit, but I get a similar
error if I use -D_FORTIFY_SOURCE=0.

I am pretty sure it's spurious and might be related to this GCC bug:

  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88780

From what I can see, we are copying from a static 108 bytes long buffer
(the global array agent_socket_name) to a 108 bytes long array,
sockaddr_un::sun_path.  I don't see anything wrong.

Still, it would make things easier if we didn't see this error.  Change
the code to check that the source string length is smaller than the
destination buffer (including space for the NULL byte) and use strcpy.

For anybody who would like to try to reproduce, the full command line
is:

    g++     -I. -I/home/simark/src/binutils-gdb/gdbserver -I/home/simark/src/binutils-gdb/gdbserver/../gdb/regformats -I/home/simark/src/binutils-gdb/gdbserver/.. -I/home/simark/src/binutils-gdb/gdbserver/../include -I/home/simark/src/binutils-gdb/gdbserver/../gdb -I/home/simark/src/binutils-gdb/gdbserver/../gnulib/import -I../gnulib/import -I/home/simark/src/binutils-gdb/gdbserver/.. -I..   -pthread -Wall -Wpointer-arith -Wno-unused -Wunused-value -Wunused-variable -Wunused-function -Wno-switch -Wno-char-subscripts -Wempty-body -Wunused-but-set-parameter -Wunused-but-set-variable -Wno-sign-compare -Wno-error=maybe-uninitialized -Wno-mismatched-tags -Wsuggest-override -Wimplicit-fallthrough=3 -Wduplicated-cond -Wshadow=local -Wdeprecated-copy -Wdeprecated-copy-dtor -Wredundant-move -Wmissing-declarations -Wmissing-prototypes -Wstrict-null-sentinel -Wformat -Wformat-nonliteral -Werror -DGDBSERVER  -DCONFIG_UST_GDB_INTEGRATION -Drpl_strerror_r=strerror_r -Drpl_free=free -fPIC -DIN_PROCESS_AGENT -fvisibility=hidden -g3 -O2 -fsanitize=address   -c -o tracepoint-ipa.o -MT tracepoint-ipa.o -MMD -MP -MF ./.deps/tracepoint-ipa.Tpo /home/simark/src/binutils-gdb/gdbserver/tracepoint.cc

Change-Id: I18e86c0487feead7e7677e69398405e7057cf464

bfd: fix -Wunused errors with clang 13+

Clang 13 and 14 produce some -Wunused-but-set-{variable,parameter} for
situations where gcc doesn't.  In particular, when a variable is set and
then used in a way to update its own value.  For example, if `i` is only
used in this way:

  int i = 2;
  i++;
  i = i + 1;

gcc won't warn, but clang will.

Fix all such errors found in an --enable-targets=all build.  It would be
important for somebody who knows what they're doing to just make sure
that these variables can indeed be deleted, and that there a no cases
where it's a bug, and the variable should actually be used.

The first instance of this error fix by this patch is:

      CC       elf32-score.lo
    /home/simark/src/binutils-gdb/bfd/elf32-score.c:450:11: error: variable 'relocation' set but not used [-Werror,-Wunused-but-set-variable]
      bfd_vma relocation;
              ^

Change-Id: I2f233ce20352645cf388aff3dfa08a651d21a6b6

gdb/mi: rename build_table to add_builtin_mi_commands

Just give the function build_table a more descriptive name.  There
should be no user visible changes after this commit.

gdb/mi: rename mi_cmd to mi_command

Just give this class a new name, more inline with the name of the
sub-classes.  I've also updated mi_cmd_up to mi_command_up in
mi-cmds.c inline with this new naming scheme.

There should be no user visible changes after this commit.

gdb/mi: use separate classes for different types of MI command

This commit changes the infrastructure in mi-cmds.{c,h} to add new
sub-classes for the different types of MI command.  Instances of these
sub-classes are then created and added into mi_cmd_table.

The existing mi_cmd class becomes the abstract base class, this has an
invoke method and takes care of the suppress notifications handling,
before calling a do_invoke virtual method which is implemented by all
of the sub-classes.

There's currently two different sub-classes, one of pure MI commands,
and a second for MI commands that delegate to CLI commands.

There should be no user visible changes after this commit.

gdb/mi: int to bool conversion in mi_execute_cli_command

Change an argument of mi_execute_cli_command from int to bool.  Update
the callers to take this into account.  Within mi_execute_cli_command,
update a comparison of a pointer to 0 with a comparison to nullptr,
and add an assert, if we are not using the argument string then the
string should be nullptr.  Also removed a cryptic 'gdb_????' comment,
which isn't really helpful.

There should be no user visible changes after this commit.

gdb/mi: use std::map for MI commands in mi-cmds.c

This changes the hashmap used in mi-cmds.c from a custom structure to
std::map.  Not only is replacing a custom container with a standard
one an improvement, but using std::map will make it easier to
dynamically add commands; which is something that is planned for a
later series, where we will allow MI commands to be implemented in
Python.

There should be no user visible changes after this commit.

gdb/mi: rename mi_lookup to mi_cmd_lookup

Lets give this function a more descriptive name.  I've also improved
the comments in the header and source files.

There should be no user visible changes after this commit.

RISC-V: Added ld testcases for the medlow and medany code models.

There are two linker scripts, code-model-01.ld and code-model-02.ld,
which are corresponding to the two different memory layouts,

* code-model-01.ld: the text section is in the 32-bit address range, but
  the data section is far away from the text section, which means the data
  section is over the 32-bit address range.

* code-model-02.ld: the text section is over the 32-bit address range, but
  the data section is placed nearly zero address.

We use the two linker scripts, to test the current medlow and medany behaviors
of GNU ld, including the weak symbol references and the relaxations behaviors.
Besides, these testcases also show the limits of the current medlow and medany
code models, that is - we may get the truncated to fit errors when linking
with the above two linker scripts.

ld/
* testsuite/ld-riscv-elf/code-model-01.ld: New testcases to test the
behaviors of the current medlow and medany code models.
* testsuite/ld-riscv-elf/code-model-02.ld: Likewise.
* testsuite/ld-riscv-elf/code-model-medany-01.d: Likewise.
* testsuite/ld-riscv-elf/code-model-medany-02.d: Likewise.
* testsuite/ld-riscv-elf/code-model-medany-weakref-01.d: Likewise.
* testsuite/ld-riscv-elf/code-model-medany-weakref-02.d: Likewise.
* testsuite/ld-riscv-elf/code-model-medlow-01.d: Likewise.
* testsuite/ld-riscv-elf/code-model-medlow-02.d: Likewise.
* testsuite/ld-riscv-elf/code-model-medlow-weakref-01.d: Likewise.
* testsuite/ld-riscv-elf/code-model-medlow-weakref-02.d: Likewise.
* testsuite/ld-riscv-elf/code-model-relax-medany-01.d: Likewise.
* testsuite/ld-riscv-elf/code-model-relax-medany-02.d: Likewise.
* testsuite/ld-riscv-elf/code-model-relax-medany-weakref-01.d: Likewise.
* testsuite/ld-riscv-elf/code-model-relax-medany-weakref-02.d: Likewise.
* testsuite/ld-riscv-elf/code-model-relax-medlow-01.d: Likewise.
* testsuite/ld-riscv-elf/code-model-relax-medlow-02.d: Likewise.
* testsuite/ld-riscv-elf/code-model-relax-medlow-weakref-01.d: Likewise.
* testsuite/ld-riscv-elf/code-model-relax-medlow-weakref-02.d: Likewise.
* testsuite/ld-riscv-elf/code-model.s: Likewise.
* testsuite/ld-riscv-elf/ld-riscv-elf.exp: Updated.

Automatic date update in version.in

x86: Adjust linker tests for --disable-separate-code

Adjust linker tests for linker configured with --disable-separate-code:

1. Update expected outputs.
2. Pass -z max-page-size=0x1000 -z separate-code" to linker.

* testsuite/ld-i386/report-reloc-1.l: Updated.
* testsuite/ld-x86-64/report-reloc-1.l: Likewise.
* testsuite/ld-x86-64/pe-x86-64.exp: Pass
"-z max-page-size=0x1000 -z separate-code" to linker.
* testsuite/ld-x86-64/pr19609-4e.d: Likewise.
* testsuite/ld-x86-64/pr19609-6a.d: Likewise.
* testsuite/ld-x86-64/pr19609-6b.d: Likewise.
* testsuite/ld-x86-64/pr19609-7b.d: Likewise.
* testsuite/ld-x86-64/pr19609-7d.d: Likewise.

gdb: Powerpc mark xfail in gdb.base/catch-syscall.exp

Powerpc is not reporting the

  Catchpoint 1 (returned from syscall execve),  ....

as expected.  The issue appears to be with the kernel not returning the
expected result.  This patch marks the test failure as an xfail.

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

gdb: improve reuse of value contents when fetching array elements

While working on a Python script, which was interacting with a remote
target, I noticed some weird slowness in GDB.  In my program I had a
structure something like this:

  struct foo_t
  {
    int array[5];
  };

  struct foo_t global_foo;

Then in the Python script I was fetching a complete copy of global
foo, like:

  val = gdb.parse_and_eval('global_foo')
  val.fetch_lazy()

Then I would work with items in foo_t.array, like:

  print(val['array'][1])

I called the fetch_lazy method specifically because I knew I was going
to end up accessing almost all of the contents of val, and so I wanted
GDB to do a single remote protocol call to fetch all the contents in
one go, rather than trying to do lazy fetches for a couple of bytes at
a time.

What I observed was that, after the fetch_lazy call, GDB does,
correctly, fetch the entire contents of global_foo, including all of
the contents of array, however, when I access val.array[1], GDB still
goes and fetches the value of this element from the remote target.

What's going on is that in valarith.c, in value_subscript, for C like
languages, we always end up treating the array value as a pointer, and
then doing value_ptradd, and value_ind, the second of these calls
always returns a lazy value.

My guess is that this approach allows us to handle indexing off the
end of an array, when working with zero element arrays, or when
indexing a raw pointer as an array.  And, I agree, that in these
cases, where, even when the original value is non-lazy, we still will
not have the content of the array loaded, we should be using the
value_ind approach.

However, for cases where we do have the array contents loaded, and we
do know the bounds of the array, I think we should be using
value_subscripted_rvalue, which is what we use for non C like
languages.

One problem I did run into, exposed by gdb.base/charset.exp, was that
value_subscripted_rvalue stripped typedefs from the element type of
the array, which means the value returned will not have the same type
as an element of the array, but would be the raw, non-typedefed,
type.  In charset.exp we got back an 'int' instead of a
'wchar_t' (which is a typedef of 'int'), and this impacts how we print
the value.  Removing typedefs from the resulting value just seems
wrong, so I got rid of that, and I don't see any test regressions.

With this change in place, my original Python script is now doing no
additional memory accesses, and its performance increases about 10x!

gdb: update gdb-gdb.py.in for latest changes to struct field

This commit updates uses of 'loc' and 'loc_kind' to 'm_loc' and
'm_loc_kind' respectively, in gdb-gdb.py.in, which is required after
this commit:

  commit cd3f655cc7a55437a05aa8e7b1fcc9051b5fe404
  Date:   Thu Sep 30 22:38:29 2021 -0400

      gdb: add accessors for field (and call site) location

I have also incorporated this change:

  https://sourceware.org/pipermail/gdb-patches/2021-September/182171.html

Which means we print 'm_name' instead of 'name' when displaying the
'm_name' member variable.

Finally, I have also added support for the new TYPE_SPECIFIC_INT
fields, which were added with this commit:

  commit 20a5fcbd5b28cca88511ac5a9ad5e54251e8fa6d
  Date:   Wed Sep 23 09:39:24 2020 -0600

      Handle bit offset and bit size in base types

I updated the gdb.gdb/python-helper.exp test to cover all of these
changes.

gdbserver/linux-low: replace direct assignment to current_thread

Use scoped_restore_current_thread and switch_to_thread in
linux_process_target::wait_for_sigstop.

gdbserver: replace direct assignments to current_thread

Replace the direct assignments to current_thread with
switch_to_thread.  Use scoped_restore_current_thread when appropriate.
There is one instance remaining in linux-low.cc's wait_for_sigstop.
This will be handled in a separate patch.

Regression-tested on X86-64 Linux using the native-gdbserver and
native-extended-gdbserver board files.

gdbserver: introduce scoped_restore_current_thread and switch_to_thread

Introduce a class for restoring the current thread and a function to
switch to the given thread.  This is a preparation for a refactoring
that aims to remove direct assignments to 'current_thread'.

gdb: make post_startup_inferior a virtual method on inf_ptrace_target

While working on a later patch that required me to understand how GDB
starts up inferiors, I was confused by the
target_ops::post_startup_inferior method.

The post_startup_inferior target function is only called from
inf_ptrace_target::create_inferior.

Part of the target class hierarchy looks like this:

  inf_child_target
     |
     '-- inf_ptrace_target
            |
            |-- linux_nat_target
            |
            |-- fbsd_nat_target
            |
            |-- nbsd_nat_target
            |
            |-- obsd_nat_target
            |
            '-- rs6000_nat_target

Every sub-class of inf_ptrace_target, except rs6000_nat_target,
implements ::post_startup_inferior.  The rs6000_nat_target picks up
the implementation of ::post_startup_inferior not from
inf_ptrace_target, but from inf_child_target.

No descendent of inf_child_target, outside the inf_ptrace_target
sub-tree, implements ::post_startup_inferior, which isn't really
surprising, as they would never see the method called (remember, the
method is only called from inf_ptrace_target::create_inferior).

What I find confusing is the role inf_child_target plays in
implementing, what is really a helper function for just one of its
descendents.

In this commit I propose that we formally make ::post_startup_inferior
a helper function of inf_ptrace_target.  To do this I will remove the
::post_startup_inferior from the target_ops API, and instead make this
a protected, pure virtual function on inf_ptrace_target.

I'll remove the empty implementation of ::post_startup_inferior from
the inf_child_target class, and add a new empty implementation to the
rs6000_nat_target class.

All the other descendents of inf_ptrace_target already provide an
implementation of this method and so don't need to change beyond
making the method protected within their class declarations.

To me, this makes much more sense now.  The helper function, which is
only called from within the inf_ptrace_target class, is now a part of
the inf_ptrace_target class.

The only way in which this change is visible to a user is if the user
turns on 'set debug target 1'.  With this debug flag on, prior to this
patch the user would see something like:

  -> native->post_startup_inferior (...)
  <- native->post_startup_inferior (2588939)

After this patch these lines are no longer present, as the
post_startup_inferior is no longer a top level target method.  For me,
this is an acceptable change.

gdb: have mips_nbsd_nat_target inherit from nbsd_nat_target

While working on another patch I had reason to look at
mips-netbsd-nat.c, and noticed that the class mips_nbsd_nat_target
inherits directly from inf_ptrace_target.

This is a little strange as alpha_bsd_nat_target,
arm_netbsd_nat_target, hppa_nbsd_nat_target, m68k_bsd_nat_target,
ppc_nbsd_nat_target, sh_nbsd_nat_target, and vax_bsd_nat_target all
inherit from nbsd_nat_target.

Originally, in this commit:

  commit f6ac5f3d63e03a81c4ff3749aba234961cc9090e
  Date:   Thu May 3 00:37:22 2018 +0100

      Convert struct target_ops to C++

When the target tree was converted to C++, all of the above classes
inherited from inf_ptrace_target except for hppa_nbsd_nat_target,
which was the only class that originally inherited from
nbsd_nat_target.

Later on all the remaining targets (except mips) were converted to
inherit from nbsd_nat_target, these are the commits:

  commit 4fed520be264b60893aa674071947890f8172915
  Date:   Sat Mar 14 16:05:24 2020 +0100

      Inherit alpha_netbsd_nat_target from nbsd_nat_target

  commit 6018d381a00515933016c539d2fdc18ad0d304b8
  Date:   Sat Mar 14 14:50:51 2020 +0100

      Inherit arm_netbsd_nat_target from nbsd_nat_target

  commit 01a801176ea15ddfc988cade2e3d84c3b0abfec3
  Date:   Sat Mar 14 16:54:42 2020 +0100

      Inherit m68k_bsd_nat_target from nbsd_nat_target

  commit 9faa006d11a5e08264a007463435f84b77864c9c
  Date:   Thu Mar 19 14:52:57 2020 +0100

      Inherit ppc_nbsd_nat_target from nbsd_nat_target

  commit 9809762324491b851332ce600ae9bde8dd34f601
  Date:   Tue Mar 17 15:07:39 2020 +0100

      Inherit sh_nbsd_nat_target from nbsd_nat_target

  commit d5be5fa4207da00d039a1d5a040ba316e7092cbd
  Date:   Sat Mar 14 13:21:58 2020 +0100

      Inherit vax_bsd_nat_target from nbsd_nat_target

I could only find mailing list threads for ppc and sh in the archive ,
and unfortunately, none of the commits has any real detail that might
explain why mips was missed out, the only extra context I could find
was this message:

  https://sourceware.org/pipermail/gdb-patches/2020-March/166853.html

Which says that "proper" OS support is going to be added to
nbsd_nat_target, hence the need to inherit from that class.

My guess is that leaving mips_nbsd_nat_target unchanged was an
oversight, so, in this commit, I propose changing mips_nbsd_nat_target
to inherit from nbsd_nat_target just like all the other nbsd targets.

My motivation for this patch relates to the post_startup_inferior
target method.  In a future commit I want to change how this method is
handled.  Currently the mips_nbsd_nat_target will pick up the empty
implementation of inf_child_target::post_startup_inferior rather than
the version in netbsd-nat.c.  This feels like a bug to me, as surely,
enabling of proc events is something that would need to be done for
all netbsd targets, regardless of architecture.

In my future patch I have a choice then, either (a) add a new, empty
implementation of post_startup_inferior to mips_nbsd_nat_target,
or (b) this commit, have mips_nbsd_nat_target inherit from
nbsd_nat_target.  Option (b) seems like the right way to go, hence,
this commit.

I've done absolutely no testing for this change, not even building it,
as that would require at least an environment in which I can x-build
mips-netbsd applications, which I have no idea how to set up.