gdb: Add soname to build-id mapping for core files

Since commit aa2d5a422 gdb has been able to read executable and shared
library build-ids within core files.

Expand this functionality so that each core file bfd maintains a map of
soname to build-id for each shared library referenced in the core file.

This feature may be used to verify that gdb has found the correct shared
libraries for core files and to facilitate downloading shared libaries via
debuginfod.

Watchpoint followed by catchpoint misreports watchpoint (PR gdb/28621)

If GDB reports a watchpoint hit, and then the next event is not
TARGET_WAITKIND_STOPPED, but instead some event for which there's a
catchpoint, such that GDB calls bpstat_stop_status, GDB mistakenly
thinks the watchpoint triggered.  Vis, using foll-fork.c:

  (gdb) awatch v
  Hardware access (read/write) watchpoint 2: v
  (gdb) catch fork
  Catchpoint 3 (fork)
  (gdb) c
  Continuing.

  Hardware access (read/write) watchpoint 2: v

  Old value = 0
  New value = 5
  main () at gdb.base/foll-fork.c:16
  16        pid = fork ();
  (gdb)
  Continuing.

  Hardware access (read/write) watchpoint 2: v      <<<<
                                                    <<<< these lines are spurious
  Value = 5                                         <<<<

  Catchpoint 3 (forked process 1712369), arch_fork (ctid=0x7ffff7fa4810) at arch-fork.h:49
  49      arch-fork.h: No such file or directory.
  (gdb)

The problem is that when we handle the fork event, nothing called
watchpoints_triggered before calling bpstat_stop_status.  Thus, each
watchpoint's watchpoint_triggered field was still set to
watch_triggered_yes from the previous (real) watchpoint stop.
watchpoint_triggered is only current called in the handle_signal_stop
path, when handling TARGET_WAITKIND_STOPPED.

This fixes it by adding watchpoint_triggered calls in the other events
paths that call bpstat_stop_status.  But instead of adding them
explicitly, it adds a new function bpstat_stop_status_nowatch that
wraps bpstat_stop_status and calls watchpoint_triggered, and then
replaces most calls to bpstat_stop_status with calls to
bpstat_stop_status_nowatch.

This required constifying watchpoints_triggered.

New test included, which fails without the fix.

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

Change-Id: I282b38c2eee428d25319af3bc842f9feafed461c

gdbserver: Fixup previous patch

The previous prepare_resume_reply change missed updating the 'buf'
reference that overwrites the 'T', so if 'buf' was advanced, we'd
still overwrite the wrong character.  This fixes it.

Change-Id: Ia8ce433366b85af4e268c1c49e7b447da3130a4d

gdbserver: Fix incorrect assertion

While playing with adding a new event kind, I noticed that
prepare_resume_reply TARGET_WAITKIND_FORKED, etc. advance 'buf', so if
we force-disable the T packet, we'd fail the *buf == 'T' assertion.

Fix it by tweaking the assertion to always look at the beginning of
the buffer.

Change-Id: I8c38e32353db115edcde418b3b1e8ba12343c22b

gdb: re-generate config.in

I'm getting this diff when running `autoreconf -vf`.

Change-Id: Id5f009d0f0481935c1ee9df5332cb4bf45fbd32d

gdb/x86: handle stap probe arguments in xmm registers

On x86 machines with xmm register, and with recent versions of
systemtap (and gcc?), it can occur that stap probe arguments will be
placed into xmm registers.

I notice this happening on a current Fedora Rawhide install with the
following package versions installed:

  $ rpm -q glibc systemtap gcc
  glibc-2.35.9000-10.fc37.x86_64
  systemtap-4.7~pre16468670g9f253544-1.fc37.x86_64
  gcc-12.0.1-0.12.fc37.x86_64

If I check the probe data in libc, I see this:

  $ readelf -n /lib64/libc.so.6
  ...
  stapsdt              0x0000004d       NT_STAPSDT (SystemTap probe descriptors)
    Provider: libc
    Name: pthread_start
    Location: 0x0000000000090ac3, Base: 0x00000000001c65c4, Semaphore: 0x0000000000000000
    Arguments: 8@%xmm1 8@1600(%rbx) 8@1608(%rbx)
  stapsdt              0x00000050       NT_STAPSDT (SystemTap probe descriptors)
    Provider: libc
    Name: pthread_create
    Location: 0x00000000000912f1, Base: 0x00000000001c65c4, Semaphore: 0x0000000000000000
    Arguments: 8@%xmm1 8@%r13 8@8(%rsp) 8@16(%rsp)
  ...

Notice that for both of these probes, the first argument is a uint64_t
stored in the xmm1 register.

Unfortunately, if I try to use this probe within GDB, then I can't
view the first argument.  Here's an example session:

  $ gdb $(which gdb)
  (gdb) start
  ...
  (gdb) info probes stap  libc pthread_create
  ...
  (gdb) break *0x00007ffff729e2f1       # Use address of probe.
  (gdb) continue
  ...
  (gdb) p $_probe_arg0
  Invalid cast.

What's going wrong?  If I re-run my session, but this time use 'set
debug stap-expression 1', this is what I see:

  (gdb) set debug stap-expression 1
  (gdb) p $_probe_arg0
  Operation: UNOP_CAST
   Operation: OP_REGISTER
    String: xmm1
   Type: uint64_t
  Operation: UNOP_CAST
   Operation: OP_REGISTER
    String: r13
   Type: uint64_t
  Operation: UNOP_CAST
   Operation: UNOP_IND
    Operation: UNOP_CAST
     Operation: BINOP_ADD
      Operation: OP_LONG
       Type: long
       Constant: 0x0000000000000008
      Operation: OP_REGISTER
       String: rsp
     Type: uint64_t *
   Type: uint64_t
  Operation: UNOP_CAST
   Operation: UNOP_IND
    Operation: UNOP_CAST
     Operation: BINOP_ADD
      Operation: OP_LONG
       Type: long
       Constant: 0x0000000000000010
      Operation: OP_REGISTER
       String: rsp
     Type: uint64_t *
   Type: uint64_t
  Invalid cast.
  (gdb)

The important bit is this:

  Operation: UNOP_CAST
   Operation: OP_REGISTER
    String: xmm1
   Type: uint64_t

Which is where we cast the xmm1 register to uint64_t.  And the final
piece of the puzzle is:

  (gdb) ptype $xmm1
  type = union vec128 {
      v8bf16 v8_bfloat16;
      v4f v4_float;
      v2d v2_double;
      v16i8 v16_int8;
      v8i16 v8_int16;
      v4i32 v4_int32;
      v2i64 v2_int64;
      uint128_t uint128;
  }

So, we are attempting to cast a union type to a scalar type, which is
not supporting in C/C++, and as a consequence GDB's expression
evaluator throws an error when we attempt to do this.

The first approach I considered for solving this problem was to try
and make use of gdbarch_stap_adjust_register.  We already have a
gdbarch method (gdbarch_stap_adjust_register) that allows us to tweak
the name of the register that we access.  Currently only x86
architectures use this to transform things like ax to eax in some
cases.

I wondered, what if we change gdbarch_stap_adjust_register to do more
than just change the register names?  What if this method instead
became gdbarch_stap_read_register.  This new method would return a
operation_up, and would take the register name, and the type we are
trying to read from the register, and return the operation that
actually reads the register.

The default implementation of this method would just use
user_reg_map_name_to_regnum, and then create a register_operation,
like we already do in stap_parse_register_operand.  But, for x86
architectures this method would fist possibly adjust the register
name, then do the default action to read the register.  Finally, for
x86 this method would spot when we were accessing an xmm register,
and, based on the type being pulled from the register, would extract
the correct field from the union.

The benefit of this approach is that it would work with the expression
types that GDB currently supports.  The draw back would be that this
approach would not be very generic.  We'd need code to handle each
sub-field size with an xmm register.  If other architectures started
using vector registers for probe arguments, those architectures would
have to create their own gdbarch_stap_read_register method.  And
finally, the type of the xmm registers comes from the type defined in
the target description, there's a risk that GDB might end up
hard-coding the names of type sub-fields, then if a target uses a
different target description, with different field names for xmm
registers, the stap probes would stop working.

And so, based on all the above draw backs, I rejected this first
approach.

My second plan involves adding a new expression type to GDB called
unop_extract_operation.  This new expression takes a value and a type,
during evaluation the value contents are fetched, and then a new value
is extracted from the value contents (based on type).  This is similar
to the following C expression:

  result_value = *((output_type *) &input_value);

Obviously we can't actually build this expression in this case, as the
input_value is in a register, but hopefully the above makes it clearer
what I'm trying to do.

The benefit of the new expression approach is that this code can be
shared across all architectures, and it doesn't care about sub-field
names within the union type.

The draw-backs that I see are potential future problems if arguments
are not stored within the least significant bytes of the register.
However if/when that becomes an issue we can adapt the
gdbarch_stap_read_register approach to allow architectures to control
how a value is extracted.

For testing, I've extended the existing gdb.base/stap-probe.exp test
to include a function that tries to force an argument into an xmm
register.  Obviously, that will only work on a x86 target, so I've
guarded the new function with an appropriate GCC define.  In the exp
script we use readelf to check if the probe exists, and is using the
xmm register.

If the probe doesn't exist then the associated tests are skipped.

If the probe exists, put isn't using the xmm register (which will
depend on systemtap/gcc versions), then again, the tests are skipped.

Otherwise, we can run the test.  I think the cost of running readelf
is pretty low, so I don't feel too bad making all the non-xmm targets
running this step.

I found that on a Fedora 35 install, with these packages installed, I
was able to run this test and have the probe argument be placed in an
xmm register:

  $ rpm -q systemtap gcc glibc
  systemtap-4.6-4.fc35.x86_64
  gcc-11.2.1-9.fc35.x86_64
  glibc-2.34-7.fc35.x86_64

Finally, as this patch adds a new operation type, then I need to
consider how to generate an agent expression for the new operation
type.

I have kicked the can down the road a bit on this.  In the function
stap_parse_register_operand, I only create a unop_extract_operation in
the case where the register type is non-scalar, this means that in
most cases I don't need to worry about generating an agent expression
at all.

In the xmm register case, when an unop_extract_operation will be
created, I have sketched out how the agent expression could be
handled, however, this code is currently not reached.  When we try to
generate the agent expression to place the xmm register on the stack,
GDB hits this error:

  (gdb) trace -probe-stap test:xmmreg
  Tracepoint 1 at 0x401166
  (gdb) actions
  Enter actions for tracepoint 1, one per line.
  End with a line saying just "end".
  >collect $_probe_arg0
  Value not scalar: cannot be an rvalue.

This is because GDB doesn't currently support placing non-scalar types
on the agent expression evaluation stack.  Solving this is clearly
related to the original problem, but feels a bit like a second
problem.  I'd like to get feedback on whether my approach to solving
the original problem is acceptable or not before I start looking at
how to handle xmm registers within agent expressions.

Reduce O(n2) performance overhead when parsing DWARF unit information.

PR 28978
* dwarf2.c (scan_unit_for_symbols): When performing second pass,
check to see if the function or variable being processed is the
same as the previous one.

x86: don't suppress overflow diagnostics in x32 mode

Unlike in 64-bit mode, where values wrap at the 64-bit boundary anyway,
there's no wrapping at the 32-bit boundary here, and hence overflow
detection shouldn't be suppressed just because rela relocations are
going to be used.

The extra check against NO_RELOC is actually a result of an ilp32 test
otherwise failing. But thinking about it, reporting overflows for
not-really-relocations (typically because of earlier errors) makes
little sense in general. Perhaps this should even be extended to non-
64-bit modes.

gdb/testsuite: reformat gdb.python/pretty-print-call-by-hand.py

Run black on the file.

Change-Id: Ifb576137fb7158a0227173f61c1202f0695b3685

[gdb/testsuite] test a function call by hand from pretty printer

The test case added here is testing the bug gdb/28856, where calling a
function by hand from a pretty printer makes GDB crash. There are 6
mechanisms to trigger this crash in the current test, using the commands
backtrace, up, down, finish, step and continue. Since the failure happens
because of use-after-free (more details below) the tests will always
have a chance of passing through sheer luck, but anecdotally they seem
to fail all of the time.

The reason GDB is crashing is a use-after-free problem. The above
mentioned functions save a pointer to the current frame's information,
then calls the pretty printer, and uses the saved pointer for different
reasons, depending on the function. The issue happens because
call_function_by_hand needs to reset the obstack to get the current
frame, invalidating the saved pointer.

gdb/testsuite: Installed-GDB testing & data-directory

In testsuite/README, we suggest that you can run the testsuite against
some other GDB binary by using:

    make check RUNTESTFLAGS=GDB=/usr/bin/gdb

However, that example isn't fully correct, because with that command
line, the testsuite will still pass

  -data-directory=[pwd]/../data-directory

to /usr/bin/gdb, like e.g.:

  ...
  builtin_spawn /usr/bin/gdb -nw -nx -data-directory /home/pedro/gdb/build/gdb/testsuite/../data-directory -iex set height 0 -iex set width 0
  ...

while if you're testing an installed GDB (the system GDB being the
most usual scenario), then you should normally let it use its own
configured directory, not the just-built GDB's data directory.

This commit improves the status quo with the following two changes:

 - if the user specifies GDB on the command line, then by default,
   don't start GDB with the -data-directory command line option.
   I.e., let the tested GDB use its own configured data directory.

 - let the user override the data directory, via a new
   GDB_DATA_DIRECTORY global.  This replaces the existing
   BUILD_DATA_DIRECTORY variable in testsuite/lib/gdb.exp, which
   wasn't overridable, and was a bit misnamed for the new purpose.

So after this, the following commands I believe behave intuitively:

 # Test the non-installed GDB in some build dir:

    make check \
      RUNTESTFLAGS="GDB=/path/to/other/build/gdb \
                    GDB_DATA_DIRECTORY=/path/to/other/build/gdb/data-directory"

 # Test the GDB installed in some prefix:

    make check \
      RUNTESTFLAGS="GDB=/opt/gdb/bin/gdb"

 # Test the built GDB with some alternative data directory, e.g., the
   system GDB's data directory:

    make check \
      RUNTESTFLAGS="GDB_DATA_DIRECTORY=/usr/share/gdb"

Change-Id: Icdc21c85219155d9564a9900961997e6624b78fb

z80 assembler: Fix new unexpected overflow warning in v2.37

PR 28791
* config/tc-z80.c (emit_data_val): Do not warn about overlarge
constants generated by bit manipulation operators.
* testsuite/gas/z80/pr28791.s: New test source file.
* testsuite/gas/z80/pr28791.d: New test driver file.

Add support for readline 8.2

In readline 8.2 the type of rl_completer_word_break_characters changed to
include const.

Automatic date update in version.in

RISC-V: Fix misplaced @end table

Move the csr-check and arch items inside the table for the .option directive.

PR28979, internal error in demand_empty_rest_of_line

The change in read_a_source_file prevents the particular testcase in
the PR from triggering the assertion in demand_empty_rest_of_line.
I've also removed the assertion.  Nothing much goes wrong with gas if
something else triggers it, so it's not worthy of an abort.

I've also changed my previous patch to ignore_rest_of_line to allow
that function to increment input_line_pointer past buffer_limit, like
demand_empty_rest_of_line:  The two functions ought to behave the
same in that respect.  Finally, demand_empty_rest_of_line gets a
little hardening to prevent accesses past buffer_limit plus one.

PR 28979
* read.c (read_a_source_file): Calculate known size for sbuf
rather than calling strlen.
(demand_empty_rest_of_line): Remove "know" check.  Expand comment.
Don't dereference input_line_pointer when past buffer_limit.
(ignore_rest_of_line): Allow input_line_pointer to increment to
buffer_limit plus one.  Expand comment.

Update gdb/NEWS after GDB 12 branch creation.

This commit a new section for the next release branch, and renames
the section of the current branch, now that it has been cut.

Bump version to 13.0.50.DATE-git.

Now that the GDB 12 branch has been created,
this commit bumps the version number in gdb/version.in to
13.0.50.DATE-git

For the record, the GDB 12 branch was created
from commit 2be64de603f8b3ae359d2d3fbf5db0e79869f32b.

Also, as a result of the version bump, the following changes
have been made in gdb/testsuite:

* gdb.base/default.exp: Change $_gdb_major to 13.

ld:LoongArch: Add test cases to adapt to LoongArch32 and LoongArch64

  ld/testsuite/ld-loongarch-elf

  *  ld-loongarch-elf.exp:  Test LoongArch32 and LoongArch64 testcases respectively.
  *  jmp_op.d: Fix bug in test LoongArch32.
  *  disas-jirl-32.d: New test case for LoongArch32.
  *  disas-jirl-32.s: New test case for LoongArch32.
  *  disas-jirl.d: Skip test case LoongArch32.
  *  macro_op_32.d: New test case for LoongArch32.
  *  macro_op_32.s: New test case for LoongArch32.
  *  macro_op.d: Skip test case LoongArch32.

gas:LoongArch: Fix "make check" pr21884 fail in LoongArch32.

  gas/config/
    * tc-loongarch.c: Add function to select target mach.
    * tc-loongarch.h: Define macro TARGET_MACH.

ld: loongarch: Skip unsupport test cases.

  ld/testsuite/ld-elf/
    * eh5.d Skip loongarch64 target.
    * pr21884.d Skip loongarch* targets.
    * pr26936.d Skip loongarch* targets.

LoongArch: Fix LD check fails.

  Some test cases about ifunc.

  bfd/
    * elfnn-loongarch.c
    * elfxx-loongarch.h

   === ld Summary ===
  of expected passes             1430
  of expected failures           11
  of untested testcases          1
  of unsupported tests           154

LoongArch: Update ABI eflag in elf header.

  Update LoongArch ABI eflag in elf header.
    ilp32s  0x5
    ilp32f  0x6
    ilp32d  0x7
    lp64s   0x1
    lp64f   0x2
    lp64d   0x3

  bfd/
    * elfnn-loongarch.c Check object flags while ld.

  gas/
    * tc-loongarch.c Write eflag to elf header.

  include/elf
        * loongarch.h Define ABI number.

gas:LoongArch: Fix wrong line number in .debug_line

  The dwarf2_emit_insn() can create debuginfo of line. But it is called
  too late in append_fixp_and_insn. It causes extra offs when debuginfo
  of line sets address.

  gas/config/
    * tc-loongarch.c

gas:LoongArch: Fix segment error in compilation due to too long symbol name.

  Change "char buffer[8192];" into "char *buffer =
  (char *) malloc(1000 +  6 * len_str);" in function
  loongarch_expand_macro_with_format_map.

  gas/
    * config/tc-loongarch.c

  include/
    * opcode/loongarch.h

  opcodes/
    * loongarch-coder.c

LoongArch: Use functions instead of magic numbers.

  Replace the magic numbers in gas(tc-loongarch.c) and
  bfd(elfnn-loongarch.c) with the functions defined in
  the howto table(elfxx-loongarch.c).

  gas/
    * config/tc-loongarch.c: use functions.

  bfd/
    * elfnn-loongarch.c: use functions.
    * elfxx-loongarch.c: define functions.
    * elfxx-loongarch.h

ubsan: loongarch : signed integer shift overflow.

   opcodes/
* loongarch-coder.c :
  int32_t ret = 0;
  ret <<= sizeof (ret) * 8 - len;
  ret >>= sizeof (ret) * 8 - len;
  ...
  Avoid ubsan warning.

Automatic date update in version.in

gdb/python: remove gdb._mi_commands dict

The motivation for this patch is the fact that py-micmd.c doesn't build
with Python 2, due to PyDict_GetItemWithError being a Python 3-only
function:

      CXX    python/py-micmd.o
    /home/smarchi/src/binutils-gdb/gdb/python/py-micmd.c: In function â€˜int micmdpy_uninstall_command(micmdpy_object*)’:
    /home/smarchi/src/binutils-gdb/gdb/python/py-micmd.c:430:20: error: â€˜PyDict_GetItemWithError’ was not declared in this scope; did you mean â€˜PyDict_GetItemString’?
      430 |   PyObject *curr = PyDict_GetItemWithError (mi_cmd_dict.get (),
          |                    ^~~~~~~~~~~~~~~~~~~~~~~
          |                    PyDict_GetItemString

A first solution to fix this would be to try to replace
PyDict_GetItemWithError equivalent Python 2 code.  But I looked at why
we are doing this in the first place: it is to maintain the
`gdb._mi_commands` Python dictionary that we use as a `name ->
gdb.MICommand object` map.  Since the `gdb._mi_commands` dictionary is
never actually used in Python, it seems like a lot of trouble to use a
Python object for this.

My first idea was to replace it with a C++ map
(std::unordered_map<std::string, gdbpy_ref<micmdpy_object>>).  While
implementing this, I realized we don't really need this map at all.  The
mi_command_py objects registered in the main MI command table can own
their backing micmdpy_object (that's a gdb.MICommand, but seen from the
C++ code).  To know whether an mi_command is an mi_command_py, we can
use a dynamic cast.  Since there's one less data structure to maintain,
there are less chances of messing things up.

 - Change mi_command_py::m_pyobj to a gdbpy_ref, the mi_command_py is
   now what keeps the MICommand alive.
 - Set micmdpy_object::mi_command in the constructor of mi_command_py.
   If mi_command_py manages setting/clearing that field in
   swap_python_object, I think it makes sense that it also takes care of
   setting it initially.
 - Move a bunch of checks from micmdpy_install_command to
   swap_python_object, and make them gdb_asserts.
 - In micmdpy_install_command, start by doing an mi_cmd_lookup.  This is
   needed to know whether there's a Python MI command already registered
   with that name.  But we can already tell if there's a non-Python
   command registered with that name.  Return an error if that happens,
   rather than waiting for insert_mi_cmd_entry to fail.  Change the
   error message to "name is already in use" rather than "may already be
   in use", since it's more precise.

I asked Andrew about the original intent of using a Python dictionary
object to hold the command objects.  The reason was to make sure the
objects get destroyed when the Python runtime gets finalized, not later.
Holding the objects in global C++ data structures and not doing anything
more means that the held Python objects will be decref'd after the
Python interpreter has been finalized.  That's not desirable.  I tried
it and it indeed segfaults.

Handle this by adding a gdbpy_finalize_micommands function called in
finalize_python.  This is the mirror of gdbpy_initialize_micommands
called in do_start_initialization.  In there, delete all Python MI
commands.  I think it makes sense to do it this way: if it was somehow
possible to unload Python support from GDB in the middle of a session
we'd want to unregister any Python MI command.  Otherwise, these MI
commands would be backed with a stale PyObject or simply nothing.

Delete tests that were related to `gdb._mi_commands`.

Co-Authored-By: Andrew Burgess <aburgess@redhat.com>
Change-Id: I060d5ebc7a096c67487998a8a4ca1e8e56f12cd3

Automatic date update in version.in

Fix crash with stepi, no debug info, and "set debug infrun 1"

A stepi in a function without debug info with "set debug infrun 1"
crashes GDB since commit c8353d682f69 (gdb/infrun: some extra infrun
debug print statements), due to a reference to
"tp->current_symtab->filename" when tp->current_symtab is null.

This commit adds the missing null check.  The output in this case
becomes:

  [infrun] set_step_info: symtab = <null>, line = 0, step_frame_id = {stack=0x7fffffffd980,code=0x0000000000456c30,!special}, step_stack_frame_id = {stack=0x7fffffffd980,code=0x0000000000456c30,!special}

Change-Id: I5171a9d222bc7e15b9dba2feaba7d55c7acd99f8

Implement gdbarch_stack_frame_destroyed_p for aarch64

The internal AdaCore testsuite has a test that checks that an
out-of-scope watchpoint is deleted.  This fails on some aarch64
configurations, reporting an extra stop:

    (gdb) continue
    Continuing.

    Thread 3 hit Watchpoint 2: result

    Old value = 64
    New value = 0
    0x0000000040021648 in pck.get_val (seed=0, off_by_one=false) at [...]/pck.adb:13
    13    end Get_Val;

I believe what is happening here is that the variable is stored at:

    <efa>   DW_AT_location    : 2 byte block: 91 7c  (DW_OP_fbreg: -4)

and the extra stop is reported just before a return, when the ldp
instruction is executed:

   0x0000000040021644 <+204>: ldp x29, x30, [sp], #48
   0x0000000040021648 <+208>: ret

This instruction modifies the frame base calculation, and so the test
picks up whatever memory is pointed to in the callee frame.

Implementing the gdbarch hook gdbarch_stack_frame_destroyed_p fixes
this problem.

As usual with this sort of patch, it has passed internal testing, but
I don't have a good way to try it with dejagnu.  So, I don't know
whether some existing test covers this.  I suspect there must be one,
but it's also worth noting that this test passes for aarch64 in some
configurations -- I don't know what causes one to fail and another to
succeed.

Fix Build issues due to patch "gprofng: a new GNU profiler"

  Find and fix more places where clock_gettime() and CLOCK_MONOTONIC_RAW are used.

gdb: run black to format some Python files

Seems like some leftovers from previous commits.

Change-Id: I7155ccdf7a4fef83bcb3d60320252c3628efdb83

Fix ld-arm bug in encoding of blx calls jumping from thumb to arm instructions

PR 28924
* elf32-arm.c (THM_MAX_FWD_BRANCH_OFFSET): Fix definition.
(THM2_MAX_FWD_BRANCH_OFFSET): Likewise.

x86: also fold remaining multi-vector-size shift insns

By slightly relaxing the checking in operand_type_register_match() we
can fold the vector shift insns with an XMM source as well. While
strictly speaking an overlap in just one size (see the code comment) is
not enough (both operands could have multiple sizes with just a single
common one), this is good enough for all templates we have, or which
could sensibly / usefully appear (within the scope of the present
operand matching model).

Tightening this a little would be possible, but would require broadcast
related information to be passed into the function.

x86: drop stray CheckRegSize from VEXTRACT{F,I}32X4

They have only a single operand allowing multiple sizes, hence there are
no pairs of operands to check for consistent size.

x86: fold certain AVX2 templates into their AVX counterparts

Like for AVX512VL we can make the handling of operand sizes a little
more flexible to allow reducing the number of templates we have.

RISC-V: Cache management instructions

This commit adds 'Zicbom' / 'Zicboz' instructions.

bfd/ChangeLog:

* elfxx-riscv.c (riscv_multi_subset_supports): Add handling for
new instruction classes.

include/ChangeLog:

* opcode/riscv-opc.h (MATCH_CBO_CLEAN, MASK_CBO_CLEAN,
MATCH_CBO_FLUSH, MASK_CBO_FLUSH, MATCH_CBO_INVAL,
MASK_CBO_INVAL, MATCH_CBO_ZERO, MASK_CBO_ZERO): New macros.
* opcode/riscv.h (enum riscv_insn_class): Add new instruction
classes INSN_CLASS_ZICBOM and INSN_CLASS_ZICBOZ.

opcodes/ChangeLog:

* riscv-opc.c (riscv_opcodes): Add cache-block management
instructions.

RISC-V: Prefetch hint instructions and operand set

This commit adds 'Zicbop' hint instructions.

bfd/ChangeLog:

* elfxx-riscv.c (riscv_multi_subset_supports): Add handling for
new instruction class.

gas/ChangeLog:

* config/tc-riscv.c (riscv_ip): Add handling for new operand
type 'f' (32-byte aligned pseudo S-type immediate for prefetch
hints).
(validate_riscv_insn): Likewise.

include/ChangeLog:

* opcode/riscv-opc.h (MATCH_PREFETCH_I, MASK_PREFETCH_I,
MATCH_PREFETCH_R, MASK_PREFETCH_R, MATCH_PREFETCH_W,
MASK_PREFETCH_W): New macros.
* opcode/riscv.h (enum riscv_insn_class): Add new instruction
class INSN_CLASS_ZICBOP.

opcodes/ChangeLog:

* riscv-dis.c (print_insn_args): Add handling for new operand
type.
* riscv-opc.c (riscv_opcodes): Add prefetch hint instructions.

PR28977 tc-i386.c internal error in parse_register

PR 28977
* config/tc-i386.c (parse_register): Handle X_op not O_register
as for a non-reg_section symbol.  Simplify array bounds check.

Tidy gas current_frame before exit

Releases some obstack memory on an error path.

* cond.c (cond_finish_check): Call cond_exit_macro.

ubsan: logical_input_line signed integer overflow

To avoid a completely useless fuzzing ubsan "bug" report, I decided to
make logical_input_line unsigned.

* input-scrub.c (logical_input_line): Make unsigned.
(struct input_save): Here too.
(input_scrub_reinit, input_scrub_close, bump_line_counters),
(as_where): Adjust to suit.

Automatic date update in version.in

gprofng: Skip jsynprog with a broken javac

On CET enabled Linux/x86-64 machines, one can get

$ javac simple.java
Error: dl failure on line 894
Error: failed /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.322.b06-6.fc35.x86_64/jre/lib/amd64/server/libjvm.so, because /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.322.b06-6.fc35.x86_64/jre/lib/amd64/server/libjvm.so: rebuild shared object with SHSTK support enabled

Set GPROFNG_BROKEN_JAVAC to "yes" only with a broken javac and skip the
jsynprog test with a broken javac.

PR gprofng/28965
* Makefile.am (GPROFNG_BROKEN_JAVAC): New.
(check-DEJAGNU): Pass GPROFNG_BROKEN_JAVAC to runtest.
* configure.ac (GPROFNG_BROKEN_JAVAC): New AC_SUBST.  Set to yes
with a broken javac.
* Makefile.in: Regenerate.
* configure: Likewise.
* testsuite/gprofng.display/display.exp: Skip jsynprog with a
broken javac.

Remove fall throughs in core_target::xfer_partial.

The cases for TARGET_OBJECT_LIBRARIES and TARGET_OBJECT_LIBRARIES_AIX
can try to fetch different data objects (such as
TARGET_OBJECT_SIGNAL_INFO) if gdbarch methods for the requested data
aren't present.  Return with TARGET_XFER_E_IO if the gdbarch method
isn't present instead.

gdb: Remove support for S+core

GCC removed support for score back in 2014 already.  Back then, we
basically agreed about removing it from GDB too, but it ended up being
forgotten.  See:

 https://sourceware.org/pipermail/gdb/2014-October/044643.html

Following through this time around.

Change-Id: I5b25a1ff7bce7b150d6f90f4c34047fae4b1f8b4

Add another test for Ada Wide_Wide_String

In an earlier patch, I had written that I wanted to add this test:

      ptype Wide_Wide_String'("literal")

... but that it failed with the distro GNAT.  Further investigation
showed that it could be made to work by adding a function using
Wide_Wide_String to the program -- this caused the type to end up in
the debug info.

This patch adds the test.  I'm checking this in.

ubsan: Null dereference in parse_module

* vms-alpha.c (parse_module): Sanity check that DST__K_RTNBEG
has set module->func_table for DST__K_RTNEND.  Check return
of bfd_zalloc.

asan: Buffer overflow in evax_bfd_print_dst

With "name" a char*, the length at name[0] might be negative, escaping
buffer limit checks.

* vms-alpha.c (evax_bfd_print_dst): Make name an unsigned char*.
(evax_bfd_print_emh): Likewise.

asan: Buffer overflow in som_set_reloc_info

* som.c (som_set_reloc_info): Add symcount parameter.  Don't
access symbols past symcount.  Don't access fixup past end_fixups.
(som_slurp_reloc_table): Adjust som_set_reloc_info calls.

asan: use of uninitialized value in buffer_and_nest

More occurences of the same as commit d12b8d620c6a.

* macro.c (buffer_and_nest): Sanity check length in buffer
before calling strncasecmp.

gprofng configure target tests

${target} in configure.ac should be the canonical target, so that for
example, someone configuring with --target=x86_64-linux will match
x86_64-*-linux*.

* configure.ac: Invoke AC_CANONICAL_TARGET.
* libcollector/configure.ac: Likewise.
* Makefile.in: Regenerate.
* configure: Regenerate.
* doc/Makefile.in: Regenerate.
* gp-display-html/Makefile.in: Regenerate.
* libcollector/Makefile.in: Regenerate.
* libcollector/configure: Regenerate.
* src/Makefile.in: Regenerate.

Re: asan: buffer overflow in peXXigen.c

In the process of fixing a buffer overflow in commit fe69d4fcf0194a,
I managed to introduce a fairly obvious NULL pointer dereference..

* peXXigen.c (_bfd_XX_bfd_copy_private_bfd_data_common): Don't
segfault on not finding section.  Wrap overlong lines.

asan: buffer overflows after calling ignore_rest_of_line

operand() is not a place that should be calling ignore_rest_of_line.
ignore_rest_of_line shouldn't increment input_line_pointer if already
at buffer limit.

* expr.c (operand): Don't call ignore_rest_of_line.
* read.c (s_mri_common): Likewise.
(ignore_rest_of_line): Don't increment input_line_pointer if
already at buffer_limit.

Re: bfd: add AMDGCN architecture

* po/SRC-POTFILES.in: Regenerate.

x86: don't accept base architectures as extensions

The -march= intentions are quite clear: A base architecture may be
followed by any number of extensions. Accepting a base architecture in
place of an extension will at best result in confusion, as the first of
the two (or more) items specified simply would not take effect, due to
being overridden by the later one(s).

x86: never set i386_cpu_flags' "unused" field

Setting this field risks cpu_flags_all_zero() mistakenly returning
"false" when the object passed in was e.g. the result of ANDing together
two objects which had the bit set, or ANDNing together an object with
the field set and one with the field clear.

While there also avoid setting CpuNo64: Like Cpu64 this is driven
differently anyway and hence shouldn't be set anywhere by default.

Note that the moving of the two items in i386-gen.c's cpu_flags[] is
only for documentation purposes (and slight reducing of overhead), as
the fields are sorted anyway upon program start.

x86: unify CPU flag on/off processing

There's no need for the arbitrary special "unknown" token: Simply
recognize the leading ~ and process everything else the same, merely
recording whether to set individual fields to 1 or 0.

While there exclude CpuIAMCU from CPU_UNKNOWN_FLAGS - CPU_IAMCU_FLAGS
override cpu_arch_flags anyway when -march=iamcu is passed, and there's
no reason to have the stray flag set even if no insn actually is keyed
to it.

x86: add another IAMCU testcase

Now that {L,K}1OM support is gone, and with it the brokenness in
check_cpu_arch_compatible(), put in place a test making sure that only
extensions can be enabled via .arch for IAMCU, and that the base
architecture cannot be changed.

x86: drop L1OM/K1OM support from gas

This was only rudimentary support anyway; none of the sub-architecture
specific insns were ever supported.

x86: assorted IAMCU CPU checking fixes

The checks done by check_cpu_arch_compatible() were halfway sensible
only at the time where only L1OM support was there. The purpose,
however, has always been to prevent bad uses of .arch (turning off the
base CPU "feature" flag) while at the same time permitting extensions to
be enabled / disabled. In order to achieve this (and to prevent
regressions when L1OM and K1OM support are removed)
- set CpuIAMCU in CPU_IAMCU_FLAGS,
- adjust the IAMCU check in the function itself (the other two similarly
  broken checks aren't adjusted as they're slated to be removed anyway),
- avoid calling the function for extentions (which would never have the
  base "feature" flag set),
- add a new testcase actually exercising ".arch iamcu" (which would also
  regress with the planned removal).

Automatic date update in version.in

gdb: work around prompt corruption caused by bracketed-paste-mode

In this commit:

  commit b4f26d541aa7224b70d363932e816e6e1a857633
  Date:   Tue Mar 2 13:42:37 2021 -0700

      Import GNU Readline 8.1

We imported readline 8.1 into GDB.  As a consequence bug PR cli/28833
was reported.  This bug spotted that, when the user terminated GDB by
sending EOF (usually bound to Ctrl+d), the last prompt would become
corrupted.  Here's what happens, the user is sat at a prompt like
this:

  (gdb)

And then the user sends EOF (Ctrl+d), we now see this:

  quit)
  ... gdb terminates, and we return to the shell ...

Notice the 'quit' was printed over the prompt.

This problem is a result of readline 8.1 enabling bracketed paste mode
by default.  This problem is present in readline 8.0 too, but in that
version of readline bracketed paste mode is off by default, so a user
will not see the bug unless they specifically enable the feature.

Bracketed paste mode is available in readline 7.0 too, but the bug
is not present in this version of readline, see below for why.

What causes this problem is how readline disables bracketed paste
mode.  Bracketed paste mode is a terminal feature that is enabled and
disabled by readline emitting a specific escape sequence.  The problem
for GDB is that the escape sequence to disable bracketed paste mode
includes a '\r' character at the end, see this thread for more
details:

  https://lists.gnu.org/archive/html/bug-bash/2018-01/msg00097.html

The change to add the '\r' character to the escape sequence used to
disable bracketed paste mode was introduced between readline 7.0 and
readline 8.0, this is why the bug would not occur when using older
versions of readline (note: I don't know if its even possible to build
GDB using readline 7.0.  That really isn't important, I'm just
documenting the history of this issue).

So, the escape sequence to disable bracketed paste mode is emitted
from the readline function rl_deprep_terminal, this is called after
the user has entered a complete command and pressed return, or, if the
user sends EOF.

However, these two cases are slightly different.  In the first case,
when the user has entered a command and pressed return, the cursor
will have moved to the next, empty, line, before readline emits the
escape sequence to leave bracketed paste mode.  The final '\r'
character moves the cursor back to the beginning of this empty line,
which is harmless.

For the EOF case though, this is not what happens.  Instead, the
escape sequence to leave bracketed paste mode is emitted on the same
line as the prompt.  The final '\r' moves the cursor back to the start
of the prompt line.  This leaves us ready to override the prompt.

It is worth noting, that this is not the intended behaviour of
readline, in rl_deprep_terminal, readline should emit a '\n' character
when EOF is seen.  However, due to a bug in readline this does not
happen (the _rl_eof_found flag is never set).  This is the first
readline bug that effects GDB.

GDB prints the 'quit' message from command_line_handler (in
event-top.c), this function is called (indirectly) from readline to
process the complete command line, but also in the EOF case (in which
case the command line is set to nullptr).  As this is part of the
callback to process a complete command, this is called after readline
has disabled bracketed paste mode (by calling rl_deprep_terminal).

And so, when bracketed paste mode is in use, rl_deprep_terminal leaves
the cursor at the start of the prompt line (in the EOF case), and
command_line_handler then prints 'quit', which overwrites the prompt.

The solution to this problem is to print the 'quit' message earlier,
before rl_deprep_terminal is called.  This is easy to do by using the
rl_deprep_term_function hook.  It is this hook that usually calls
rl_deprep_terminal, however, if we replace this with a new function,
we can print the 'quit' string, and then call rl_deprep_terminal
ourselves.  This allows the 'quit' to be printed before
rl_deprep_terminal is called.

The problem here is that there is no way in rl_deprep_terminal to know
if readline is processing EOF or not, and as a result, we don't know
when we should print 'quit'.  This is the second readline bug that
effects GDB.

Both of these readline issues are discussed in this thread:

  https://lists.gnu.org/archive/html/bug-readline/2022-02/msg00021.html

The result of that thread was that readline was patched to address
both of these issues.

Now it should be easy to backport the readline fix to GDB's in tree
copy of readline, and then change GDB to make use of these fixes to
correctly print the 'quit' string.

However, we are just about to branch GDB 12, and there is concern from
some that changing readline this close to a new release is a risky
idea, see this thread:

  https://sourceware.org/pipermail/gdb-patches/2022-March/186391.html

So, this commit doesn't change readline at all.  Instead, this commit
is the smallest possible GDB change in order to avoid the prompt
corruption.

In this commit I change GDB to print the 'quit' string on the line
after the prompt, but only when bracketed paste mode is on.  This
avoids the overwriting issue, the user sees this:

  (gdb)
  quit
  ... gdb terminates, and returns to the shell ...

This isn't ideal, but is better than the existing behaviour.  After
GDB 12 has branched, we can backport the readline fix, and apply a
real fix to GDB.

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

objcopy --weaken-symbol: apply to STB_GNU_UNIQUE symbols

    PR binutils/28926
    * objcopy.c (filter_symbols): Apply weaken to STB_GNU_UNIQUE symbols
    * NEWS: Mention feature.
    * testsuite/binutils-all/objcopy.exp (objcopy_test_symbol_manipulation): New test.
    * testsuite/binutils-all/weaken-gnu-unique.s: New.

Reimplement array concatenation for Ada and D

This started as a patch to implement string concatenation for Ada.
However, while working on this, I looked at how this code could
possibly be called.  It turns out there are only two users of
concat_operation: Ada and D.  So, in addition to implementing this for
Ada, this patch rewrites value_concat, removing the odd "concatenate
or repeat" semantics, which were completely unused.  As Ada and D both
seem to represent strings using TYPE_CODE_ARRAY, this removes the
TYPE_CODE_STRING code from there as well.

Remove eval_op_concat

eval_op_concat has code to search for an operator overload of
BINOP_CONCAT.  However, the operator overloading code is specific to
C++, which does not have this operator.  And,
binop_types_user_defined_p rejects this case right at the start, and
value_x_binop does not handle this case.  I think this code has been
dead for a very long time.  This patch removes it and hoists the
remaining call into concatenation::evaluate, removing eval_op_concat
entirely.

Ada support for wide strings

This adds some basic support for Wide_String and Wide_Wide_String to
the Ada expression evaluator.  In particular, a string literal may be
converted to a wide or wide-wide string depending on context.

The patch updates an existing test case.  Note that another test,
namely something like:

    ptype Wide_Wide_String'("literal")

... would be nice to add, but when tested against a distro GNAT, this
did not work (probably due to lack of debuginfo); so, I haven't
included it here.

Remove eval_op_string

eval_op_string is only used in a single place -- the implementation of
string_operation.  This patch turns it into the
string_operation::evaluate method, removing a bit of extraneous code.

Powerpc fix for gdb.base/ending-run.exp

The last two tests in gdb.base/ending-run.exp case fail on Powerpc when the
system does not have the needed glibc debug-info files loaded.  In this
case, gdb is not able to determine where execution stopped.  This behavior
looks as follows for the test case:

The next to the last test does a next command when the program is stopped
at the closing bracket for main.  The message printed is:

0x00007ffff7d01524 in ?? () from /lib/powerpc64le-linux-gnu/libc.so.6

which fails to match any of the test_multiple options.

The test then does another next command.  On Powerpc, the
message printed it:

Cannot find bounds of current function

The test fails as the output does not match any of the options for the
gdb_test_multiple.

I checked the behavior on Powerpc to see if this is typical.
I ran gdb on the following simple program as shown below.

#include <stdio.h>
int
main(void)
{
  printf("Hello, world!\n");
  return 0;
}

gdb ./hello_world
<snip the gdb start info>

Type "apropos word" to search for commands related to "word"...
Reading symbols from ./hello_world...
(No debugging symbols found in ./hello_world)
(gdb) break main
Breakpoint 1 at 0x818
(gdb) r

Starting program: /home/carll/hello_world
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/powerpc64le-linux-gnu/libthread_db.so.1".

Breakpoint 1, 0x0000000100000818 in main ()
(gdb) n
Single stepping until exit from function main,
which has no line number information.
Hello, world!
0x00007ffff7d01524 in ?? () from /lib/powerpc64le-linux-gnu/libc.so.6
(gdb) n
Cannot find bounds of current function

So it would seem that the messages seen from the test case are
"normal" output for Powerpc when the debug-info is not available.

The following patch adds the output from Powerpc as an option
to the gdb_test_multiple statement, identifying the output as the expected
output on Powerpc without the needed debug-info files installed.

The patch has been tested on a Power 10 system and an Intel
64-bit system.  No additional regression failures were seen on
either platform.

dlltool: Use the output name as basis for deterministic temp prefixes

PR 28885
* dlltool.c (main): use imp_name rather than dll_name when
generating a temporary file name.

gdb/mi: consistently notify user when GDB/MI client uses -thread-select

GDB notifies users about user selected thread changes somewhat
inconsistently as mentioned on gdb-patches mailing list here:

  https://sourceware.org/pipermail/gdb-patches/2022-February/185989.html

Consider GDB debugging a multi-threaded inferior with both CLI and GDB/MI
interfaces connected to separate terminals.

Assuming inferior is stopped and thread 1 is selected, when a thread
2 is selected using '-thread-select 2' command on GDB/MI terminal:

    -thread-select 2
    ^done,new-thread-id="2",frame={level="0",addr="0x00005555555551cd",func="child_sub_function",args=[],file="/home/jv/Projects/gdb/users_jv_patches/gdb/testsuite/gdb.mi/user-selected-context-sync.c",fullname="/home/uuu/gdb/gdb/testsuite/gdb.mi/user-selected-context-sync.c",line="30",arch="i386:x86-64"}
    (gdb)

and on CLI terminal we get the notification (as expected):

    [Switching to thread 2 (Thread 0x7ffff7daa640 (LWP 389659))]
    #0  child_sub_function () at /home/uuu/gdb/gdb/testsuite/gdb.mi/user-selected-context-sync.c:30
    30        volatile int dummy = 0;

However, now that thread 2 is selected, if thread 1 is selected
using 'thread-select --thread 1 1' command on GDB/MI terminal
terminal:

   -thread-select --thread 1 1
   ^done,new-thread-id="1",frame={level="0",addr="0x0000555555555294",func="main",args=[],file="/home/jv/Projects/gdb/users_jv_patches/gdb/testsuite/gdb.mi/user-selected-context-sync.c",fullname="/home/jv/Projects/gdb/users_jv_patches/gdb/testsuite/gdb.mi/user-selected-context-sync.c",line="66",arch="i386:x86-64"}
   (gdb)

but no notification is printed on CLI terminal, despite the fact
that user selected thread has changed.

The problem is that when `-thread-select --thread 1 1` is executed
then thread is switched to thread 1 before mi_cmd_thread_select () is
called, therefore the condition "inferior_ptid != previous_ptid"
there does not hold.

To address this problem, we have to move notification logic up to
mi_cmd_execute () where --thread option is processed and notify
user selected contents observers there if context changes.

However, this in itself breaks GDB/MI because it would cause context
notification to be sent on MI channel. This is because by the time
we notify, MI notification suppression is already restored (done in
mi_command::invoke(). Therefore we had to lift notification suppression
logic also up to mi_cmd_execute (). This change in made distinction
between mi_command::invoke() and mi_command::do_invoke() unnecessary
as all mi_command::invoke() did (after the change) was to call
do_invoke(). So this patches removes do_invoke() and moves the command
execution logic directly to invoke().

With this change, all gdb.mi tests pass, tested on x86_64-linux.

Co-authored-by: Andrew Burgess <aburgess@redhat.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=20631

gprofng: Use symver attribute if available

Use symver attribute if available, instead of asm statement, to support
LTO build.

PR gprof/28962
* libcollector/dispatcher.c (timer_create@@GLIBC_2.3.3): Use
SYMVER_ATTRIBUTE.
(timer_create@GLIBC_2.2): Likewise.
(timer_create@GLIBC_2.2.5): Likewise.
(pthread_create@@GLIBC_2.1): Likewise.
(pthread_create@GLIBC_2.0): Likewise.
* libcollector/iotrace.c (open64@@GLIBC_2.2): Likewise.
(open64@GLIBC_2.1): Likewise.
(fopen@@GLIBC_2.1): Likewise.
(fopen@GLIBC_2.0): Likewise.
(fclose@@GLIBC_2.1): Likewise.
(fclose@GLIBC_2.0): Likewise.
(fdopen@@GLIBC_2.1): Likewise.
(fdopen@GLIBC_2.0): Likewise.
(pread@@GLIBC_2.2): Likewise.
(pread@GLIBC_2.1): Likewise.
(pwrite@@GLIBC_2.2): Likewise.
(pwrite@GLIBC_2.1): Likewise.
(pwrite64@@GLIBC_2.2): Likewise.
(pwrite64@GLIBC_2.1): Likewise.
(fgetpos@@GLIBC_2.2): Likewise.
(fgetpos@GLIBC_2.0): Likewise.
(fgetpos64@@GLIBC_2.2): Likewise.
(fgetpos64@GLIBC_2.1): Likewise.
(fsetpos@@GLIBC_2.2): Likewise.
(fsetpos@GLIBC_2.0): Likewise.
(fsetpos64@@GLIBC_2.2): Likewise.
(fsetpos64@GLIBC_2.1): Likewise.
* libcollector/linetrace.c (posix_spawn@@GLIBC_2.15): Likewise.
(posix_spawn@GLIBC_2.2): Likewise.
(posix_spawn@GLIBC_2.2.5): Likewise.
(posix_spawnp@@GLIBC_2.15): Likewise.
(posix_spawnp@GLIBC_2.2): Likewise.
(posix_spawnp@GLIBC_2.2.5): Likewise.
(popen@@GLIBC_2.1): Likewise.
(popen@GLIBC_2.0): Likewise.
(_popen@@GLIBC_2.1): Likewise.
(_popen@GLIBC_2.0): Likewise.
* libcollector/mmaptrace.c (dlopen@@GLIBC_2.1): Likewise.
(dlopen@GLIBC_2.0): Likewise.
* libcollector/synctrace.c (pthread_cond_wait@@GLIBC_2.3.2):
Likewise.
(pthread_cond_wait@GLIBC_2.0): Likewise.
(pthread_cond_wait@GLIBC_2.2.5): Likewise.
(pthread_cond_wait@GLIBC_2.2): Likewise.
(pthread_cond_timedwait@@GLIBC_2.3.2): Likewise.
(pthread_cond_timedwait@GLIBC_2.0): Likewise.
(pthread_cond_timedwait@GLIBC_2.2.5): Likewise.
(pthread_cond_timedwait@GLIBC_2.2): Likewise.
(sem_wait@@GLIBC_2.1): Likewise.
(sem_wait@GLIBC_2.0): Likewise.
* src/collector_module.h (SYMVER_ATTRIBUTE): New.

gprofng: Don't hardcode -Wno-format-truncation/-Wno-switch

Use -Wno-format-truncation and -Wno-switch only if they are supported.

PR gprof/28969
* configure.ac (GPROFNG_NO_FORMAT_TRUNCATION_CFLAGS): New
AC_SUBST for -Wno-format-truncation.
(GPROFNG_NO_SWITCH_CFLAGS): New AC_SUBST for -Wno-switch.
* Makefile.in: Regenerate.
* configure: Likewise.
* src/Makefile.am (AM_CFLAGS): Replace -Wno-format-truncation
and -Wno-switch with GPROFNG_NO_FORMAT_TRUNCATION_CFLAGS and
GPROFNG_NO_SWITCH_CFLAGS.
* src/Makefile.in: Regenerate.

gprofng: Don't hardcode -Wno-nonnull-compare

Use -Wno-nonnull-compare only if it is supported.

PR gprof/28969
* libcollector/Makefile.am (AM_CFLAGS): Replace
-Wno-nonnull-compare with GPROFNG_NO_NONNULL_COMPARE_CFLAGS.
* libcollector/configure.ac (GPROFNG_NO_NONNULL_COMPARE_CFLAGS):
New AC_SUBST for -Wno-nonnull-compare.
* libcollector/Makefile.in: Regenerate.
* libcollector/aclocal.m4: Likewise.
* libcollector/configure: Likewise.

gprofng: Define ATTRIBUTE_FALLTHROUGH

Define ATTRIBUTE_FALLTHROUGH to __attribute__ ((fallthrough)) only for
GCC 7 or above.

PR gprof/28969
* common/gp-defs.h (ATTRIBUTE_FALLTHROUGH): New.
* src/gp-collect-app.cc (collect::check_args): Replace
/* FALLTHROUGH */ with ATTRIBUTE_FALLTHROUGH.

binutils/readelf: handle AMDGPU relocation types

Make readelf recognize AMDGPU relocation types, as documented here:

  https://llvm.org/docs/AMDGPUUsage.html#amdgpu-relocation-records

The user-visible change looks like:

    -000000000004  000400000001 unrecognized: 1       0000000000000000 SCRATCH_RSRC_DWORD0
    -00000000000c  000500000001 unrecognized: 1       0000000000000000 SCRATCH_RSRC_DWORD1
    -000000000014  000600000007 unrecognized: 7       0000000000000000 global_var0
    -00000000001c  000700000008 unrecognized: 8       0000000000000000 global_var1
    -000000000024  000800000009 unrecognized: 9       0000000000000000 global_var2
    -00000000002c  00090000000a unrecognized: a       0000000000000000 global_var3
    -000000000034  000a0000000b unrecognized: b       0000000000000000 global_var4
    +000000000004  000400000001 R_AMDGPU_ABS32_LO 0000000000000000 SCRATCH_RSRC_DWORD0
    +00000000000c  000500000001 R_AMDGPU_ABS32_LO 0000000000000000 SCRATCH_RSRC_DWORD1
    +000000000014  000600000007 R_AMDGPU_GOTPCREL 0000000000000000 global_var0
    +00000000001c  000700000008 R_AMDGPU_GOTPCREL 0000000000000000 global_var1
    +000000000024  000800000009 R_AMDGPU_GOTPCREL 0000000000000000 global_var2
    +00000000002c  00090000000a R_AMDGPU_REL32_LO 0000000000000000 global_var3
    +000000000034  000a0000000b R_AMDGPU_REL32_HI 0000000000000000 global_var4

binutils/ChangeLog:

* readelf.c (dump_relocations): Handle EM_AMDGPU.

include/ChangeLog:

* elf/amdgpu.h: Add relocation values.

Change-Id: I2ed4589f4cd37ea11ad2e0cb38d4b682271e1334

binutils/readelf: build against msgpack, dump NT_AMDGPU_METADATA note contents

The AMDGPU HSA OS ABI (code object v3 and above) defines the
NT_AMDGPU_METADATA ELF note [1].  The content is a msgpack object
describing, among other things, the kernels present in the code object
and how to call them.

I think it would be useful for readelf to be able to display the content
of those notes.  msgpack is a structured format, a bit like JSON, except
not text-based.  It is therefore possible to dump the contents in
human-readable form without knowledge of the specific layout of the
note.

Add configury to binutils to optionally check for the msgpack C library
[2].  Add There is a new --with{,out}-msgpack configure flag, and the actual
library lookup is done using pkg-config.

If msgpack support is enabled, dumping a NT_AMDGPU_METADATA note looks
like:

    $ readelf --notes amdgpu-code-object
    Displaying notes found in: .note
      Owner                Data size        Description
      AMDGPU               0x0000040d       NT_AMDGPU_METADATA (code object metadata)
        {
          "amdhsa.kernels": [
            {
              ".args": [
                {
                  ".address_space": "global",
                  ".name": "out.coerce",
                  ".offset": 0,
                  ".size": 8,
                  ".value_kind": "global_buffer",
                },
      <snip>

If msgpack support is disabled, dump the contents as hex, as is done
with notes that are not handled in a special way.  This allows one to
decode the contents manually (maybe using a command-line msgpack
decoder) if really needed.

[1] https://llvm.org/docs/AMDGPUUsage.html#code-object-metadata
[2] https://github.com/msgpack/msgpack-c/tree/c_master

binutils/ChangeLog:

* Makefile.am (readelf_CFLAGS): New.
(readelf_LDADD): Add MSGPACK_LIBS.
* Makefile.in: Re-generate.
* config.in: Re-generate.
* configure: Re-generate.
* configure.ac: Add --with-msgpack flag and check for msgpack
using pkg-config.
* readelf.c: Include msgpack.h if HAVE_MSGPACK.
(print_note_contents_hex): New.
(print_indents): New.
(dump_msgpack_obj): New.
(dump_msgpack): New.
(print_amdgpu_note): New.
(process_note): Handle NT_AMDGPU_METADATA note contents.
Use print_note_contents_hex.

Change-Id: Ia60a654e620bc32dfdb1bccd845594e2af328b84

binutils/readelf: handle NT_AMDGPU_METADATA note name

Handle the NT_AMDGPU_METADATA note, which is described here:

  https://llvm.org/docs/AMDGPUUsage.html#code-object-v3-note-records

As of this patch, just print out the name, not the contents, which is in
the msgpack format.

binutils/ChangeLog:

* readelf.c (get_amdgpu_elf_note_type): New.
(process_note): Handle "AMDGPU" notes.

include/ChangeLog:

* elf/amdgcn.h (NT_AMDGPU_METADATA): New.

Change-Id: Id2dba2e2aeaa55ef7464fb35aee9c7d5f96ddb23

binutils/readelf: decode AMDGPU-specific e_flags

Decode and print the AMDGPU-specific fields of e_flags, as documented
here:

  https://llvm.org/docs/AMDGPUUsage.html#header

That is:

 - The specific GPU model
 - Whether the xnack and sramecc features are enabled

The result looks like:

-  Flags:                             0x52f
+  Flags:                             0x52f, gfx906, xnack any, sramecc any

The flags for the "HSA" OS ABI are properly versioned and documented on
that page.  But the NONE, PAL and MESA3D OS ABIs are not well documented
nor versioned.  Taking a peek at the LLVM source code, we see that they
encode their flags the same way as HSA v3.  For example, for PAL:

  https://github.com/llvm/llvm-project/blob/c8b614cd74a92d85936aed5ac7c642af75ffdc29/llvm/lib/Target/AMDGPU/MCTargetDesc/AMDGPUTargetStreamer.cpp#L601

So for those other OS ABIs, we read them the same as HSA v3.

binutils/ChangeLog:

* readelf.c: Include elf/amdgcn.h.
(decode_AMDGPU_machine_flags): New.
(get_machine_flags): Handle flags for EM_AMDGPU machine type.

include/ChangeLog:

* elf/amdgcn.h: Add EF_AMDGPU_MACH_AMDGCN_* and
EF_AMDGPU_FEATURE_* defines.

Change-Id: Ib5b94df7cae0719a22cf4e4fd0629330e9485c12

binutils/readelf: handle AMDGPU OS ABIs

When the machine is EM_AMDGPU, handle the various OS ABIs described
here:

  https://llvm.org/docs/AMDGPUUsage.html#header

For a binary with the HSA OS ABI, the change looks like:

-  OS/ABI:                            <unknown: 40>
+  OS/ABI:                            AMD HSA

binutils/ChangeLog:

* readelf.c (get_osabi_name): Handle EM_AMDGPU OS ABIs.

include/ChangeLog:

* elf/common.h (ELFOSABI_AMDGPU_PAL, ELFOSABI_AMDGPU_MESA3D):
New.

Change-Id: I383590c390f7dc2fe0f902f50038735626d71863

opcodes: handle bfd_amdgcn_arch in configure script

There isn't an actual opcodes implementation for the AMDGCN arch (yet),
this is just the bare minimum to get

  $ ./configure --target=amdgcn-hsa-amdhsa --disable-gas
  $ make all-binutils

working later in this series.

opcodes/ChangeLog:

* configure.ac: Handle bfd_amdgcn_arch.
* configure: Re-generate.

Change-Id: Ib7d7c5533a803ed8b2a293e9275f667ed781ce79

bfd: add AMDGCN architecture

Add support for the AMDGCN architecture to BFD.

This is the bare minimum to get

  $ ./configure --target=amdgcn-hsa-amdhsa --disable-gas
  $ make all-binutils

working later in this series.

The specific AMDGCN models added here are a bit arbitrary, based on
what we intend to initially support in GDB.  This list will need to be
updated in the future anyway.  The complete up-to-date list of existing
AMDGPU models can be found here:

  https://llvm.org/docs/AMDGPUUsage.html#processors

The ELF format for this architecture is documented here:

  https://llvm.org/docs/AMDGPUUsage.html#elf-code-object

The flags for the "HSA" OS ABI are properly versioned and documented on
that page.  But the NONE, PAL and MESA3D OS ABIs are not well documented
nor versioned.  Taking a peek at the LLVM source code, we see that they
encode their flags the same way as HSA v3.  For example, for PAL:

  https://github.com/llvm/llvm-project/blob/c8b614cd74a92d85936aed5ac7c642af75ffdc29/llvm/lib/Target/AMDGPU/MCTargetDesc/AMDGPUTargetStreamer.cpp#L601

So at least, we know that all AMDGPU objects (of which AMDGCN objects
are a subset of) at the time of writing encode the specific GPU model in
the EF_AMDGPU_MACH field of e_flags.

bfd/ChangeLog:

* Makefile.am (ALL_MACHINES, ALL_MACHINES_CFILES):
Add cpu-amdgcn.c.
(BFD64_BACKENDS): Add elf64-amdgcn.lo.
(BFD64_BACKENDS_CFILES): Add elf64-amdgcn.c.
* Makefile.in: Re-generate.
* cpu-amdgcn.c: New.
* elf64-amdgcn.c: New.
* archures.c (bfd_architecture): Add bfd_arch_amdgcn and related
mach defines.
(bfd_amdgcn_arch): New.
(bfd_archures_list): Add bfd_amdgcn_arch.
* bfd-in2.h: Re-generate.
* config.bfd: Handle amdgcn* target.
* configure.ac: Handle amdgcn_elf64_le_vec.
* configure: Re-generate.
* elf-bfd.h (elf_target_id): Add AMDGCN_ELF_DATA.
* targets.c (amdgcn_elf64_le_vec): New.
(_bfd_target_vector): Add amdgcn_elf64_le_vec.

include/ChangeLog:

* elf/amdgpu.h: New.
* elf/common.h (ELFOSABI_AMDGPU_HSA): Add.

Change-Id: I969f7b14960797e88891c308749a6e341eece5b2

Updated Serbian (for binutils/) and Russian (for gprof/) translations

Make gdb.fortran/{array-slices,lbound-ubound} work against gdbserver

gdb.fortran/array-slices.exp and gdb.fortran/lbound-ubound.exp were
recently disabled unless testing with the native target, because they
rely on inferior I/O.  However, when testing against gdbserver using
the native-gdbserver/native-extended-gdbserver boards, we do have
access to inferior I/O.

The right way to check whether the board can do I/O, is via checking
the gdb,noinferiorio board variable.  Switch to using that.

And then, tweak the testcases to expect output to appear in
inferior_spawn_id, instead of gdb_spawn_id.  When testing against the
native target, inferior_spawn_id is the same as gdb_spawn_id.  When
testing against gdbserver, it maps to gdbserver_spawn_id.

This exposed a buglet in gdb.fortran/array-slices.f90's show_1d
subroutine -- it was missing printing newline at the end of the
"Expected GDB Output" text, leading to a test timeout.  All other
subroutines end with advance=yes, except this one.  Fix it by using
advance=yes here too.

Change-Id: I4640729f334431cfc24b0917e7d3977b677c6ca5

Automatic date update in version.in

Delete PowerPC macro insn support

Let's hope this stays dead, but it's here as a patch separate from
those that removed use of powerpc_macros just in case it needs to be
resurrected.

include/
* opcode/ppc.h (struct powerpc_macro): Delete declaration.
(powerpc_macros, powerpc_num_macros): Likewise..
opcodes/
* ppc-opc.c (powerpc_macros, powerpc_num_macros): Delete.
gas/
* config/tc-ppc.c (ppc_macro): Delete function.
(ppc_macro_hash): Delete.
(ppc_setup_opcodes, md_assemble): Delete macro support.

PowerPC SPE/SPE2 aliases in powerpc_macros

* ppc-opc.c (powerpc_macros): Move "evsadd", "evssub", "evsabs",
"evsnabs", "evsneg", "evsmul", "evsdiv", "evscmpgt", "evsgmplt",
"evsgmpeq", "evscfui", "evscfsi", "evscfuf", "evscfsf", "evsctui",
"evsctsi", "evsctuf", "evsctsf", "evsctuiz", "evsctsiz",
"evststgt", "evststlt", "evststeq"..
(powerpc_opcodes): ..to here.
(powerpc_macros): Move "evdotphsssi", "evdotphsssia", "evdotpwsssi",
and "evdotpwsssia"..
(spe2_opcodes): ..to here.

PowerPC VLE extended instructions in powerpc_macros

This moves VLE insn out of the macro table.  "e_slwi" and "e_srwi"
already exist in vle_opcodes as distinct instructions rather than
encodings of e_rlwinm.

opcodes/
* ppc-opc.c (vle_opcodes): Typo fix e_rlwinm operand.
Add "e_inslwi", "e_insrwi", "e_rotlwi", "e_rotrwi", "e_clrlwi",
"e_clrrwi", "e_extlwi", "e_extrwi", and "e_clrlslwi".
(powerpc_macros): Delete same.  Delete "e_slwi" and "e_srwi" too.
gas/
* testsuite/gas/ppc/vle-simple-5.d: Update.

PowerPC32 extended instructions in powerpc_macros

As for PowerPC64, move instructions to the main opcode table.

opcodes/
* ppc-opc.c (insert_crwn, extract_crwn, insert_elwn, extract_elwn),
(insert_erwn, extract_erwn, insert_erwb, extract_erwb),
(insert_cslwn, extract_cslwb, insert_ilwb, extract_ilwn),
(insert_irwb, extract_irwn, insert_rrwn, extract_rrwn),
(insert_slwn, extract_slwn, insert_srwn, extract_srwn): New functions.
(CRWn, ELWn, ERWn, ERWb, CSLWb, CSLWn, ILWn, ILWb, IRWn, IRWb),
(RRWn, SLWn, SRWn): Define and add powerpc_operands entries.
(MMB_MASK, MME_MASK, MSHMB_MASK): Define.
(powerpc_opcodes): Add "inslwi", "insrwi", "rotrwi", "clrrwi",
"slwi", "srwi", "extlwi", "extrwi", "sli", "sri" and corresponding
record (ie. dot suffix) forms.
(powerpc_macros): Delete same.
gas/
* testsuite/gas/ppc/476.d: Update.
* testsuite/gas/ppc/simpshft.d: Update.

PowerPC64 extended instructions in powerpc_macros

The extended instructions implemented in powerpc_macros aren't used by
the disassembler.  That means instructions like "sldi r3,r3,2" appear
in disassembly as "rldicr r3,r3,2,61", which is annoying since many
other extended instructions are shown.

Note that some of the instructions moved out of the macro table to the
opcode table won't appear in disassembly, because they are aliases
rather than a subset of the underlying raw instruction.  If enabled,
rotrdi, extrdi, extldi, clrlsldi, and insrdi would replace all
occurrences of rotldi, rldicl, rldicr, rldic and rldimi.  (Or many
occurrences in the case of clrlsldi if n <= b was added to the extract
functions.)

The patch also fixes a small bug in opcode sanity checking.

include/
* opcode/ppc.h (PPC_OPSHIFT_SH6): Define.
opcodes/
* ppc-opc.c (insert_erdn, extract_erdn, insert_eldn, extract_eldn),
(insert_crdn, extract_crdn, insert_rrdn, extract_rrdn),
(insert_sldn, extract_sldn, insert_srdn, extract_srdn),
(insert_erdb, extract_erdb, insert_csldn, extract_csldb),
(insert_irdb, extract_irdn): New functions.
(ELDn, ERDn, ERDn, RRDn, SRDn, ERDb, CSLDn, CSLDb, IRDn, IRDb):
Define and add associated powerpc_operands entries.
(powerpc_opcodes): Add "rotrdi", "srdi", "extrdi", "clrrdi",
"sldi", "extldi", "clrlsldi", "insrdi" and corresponding record
(ie. dot suffix) forms.
(powerpc_macros): Delete same from here.
gas/
* config/tc-ppc.c (insn_validate): Don't modify value passed
to operand->insert for PPC_OPERAND_PLUS1 when calculating mask.
Handle PPC_OPSHIFT_SH6.
* testsuite/gas/ppc/prefix-reloc.d: Update.
* testsuite/gas/ppc/simpshft.d: Update.
ld/
* testsuite/ld-powerpc/elfv2so.d: Update.
* testsuite/ld-powerpc/notoc.d: Update.
* testsuite/ld-powerpc/notoc3.d: Update.
* testsuite/ld-powerpc/tlsdesc2.d: Update.
* testsuite/ld-powerpc/tlsget.d: Update.
* testsuite/ld-powerpc/tlsget2.d: Update.
* testsuite/ld-powerpc/tlsopt5.d: Update.
* testsuite/ld-powerpc/tlsopt6.d: Update.

Do not capture updated 'pc' in add_local_symbols

Simon pointed out that commit 13835d88 ("Use function view when
iterating over block symbols") caused a regression.  The bug is that
the new closure captures 'pc' by reference, but later code updates
this variable -- but the earlier code did not update the callback
structure with the new value.

This patch restores the old behavior by using a new varible name in an
inner scope.

gprofng: avoid using `fallthrough' attributes

gprofng didn't build with gcc 6.3 due to the usage of __attribute__
((fallthrough)).  This patch uses /* FALLTHROUGH */ instead.

2022-03-15  Jose E. Marchesi  <jose.marchesi@oracle.com>

* gprofng/src/gp-collect-app.cc (collect::check_args): Use
fallthrough comment instead of attribute.

Fix bug in dwarf-mode.el

I noticed that, occasionally, dwarf-mode would think that the objdump
subprocess was still running after it had clearly exited.  I managed
to reliably reproduce this today and learned that a process sentinel
is not guaranteed to be run with the current buffer set to the process
buffer.  This patch fixes the problem.

I've bumped the version number of dwarf-mode.el to make it easier to
install for users who already have an earlier one installed.

I'm checking this in.

2022-03-15  Tom Tromey  <tromey@adacore.com>

* dwarf-mode.el: Now 1.7.
(dwarf--sentinel): Switch to the process buffer.

gdb/testsuite: rename a proc and fix a typo

Rename a proc in gdb.mi/user-selected-context-sync.exp, I think the
old name was most likely a typo.  The old name
match_re_or_ensure_not_output seems (to me) to imply we're in some way
checking that the regexp was not output.  But that's not what we are
doing, we're checking either for the regexp, or for no output, hence
the new name match_re_or_ensure_no_output.

Additionally, I found a definite typo in one of the comments that I've
also fixed.

I also updated some test names.  These tests (probably due to copy &
paste errors) has 'on MI' on their name, when they were actually
checking CLI output.  For these test I changed the name to use 'on
CLI'.

There should be no change in what is tested after this commit.

gprofng: Add a configure test for clock_gettime and a use of the test in getthrtime.c

gprofng: Don't generate gprofng.info in source

Add info-in-builddir to AUTOMAKE_OPTIONS.

PR gprof/28967
* doc/Makefile.am (AUTOMAKE_OPTIONS): Add info-in-builddir.
* doc/Makefile.in: Regenerate.

gdb: LoongArch: fix failed testcases in gdb.base/align-c.exp

When execute the following command on LoongArch:

  make check-gdb TESTS="gdb.base/align-c.exp"

there exist some failed testcases:

  ...
  FAIL: gdb.base/align-c.exp: print _Alignof(struct align_pair_long_double_x_float)
  FAIL: gdb.base/align-c.exp: print _Alignof(struct align_pair_long_double_x_double)
  FAIL: gdb.base/align-c.exp: print _Alignof(struct align_pair_long_double_x_long_double)
  ...

According to LoongArch ELF ABI specification [1], set the target data types
of floating-point to fix the above failed testcases.

[1] https://loongson.github.io/LoongArch-Documentation/LoongArch-ELF-ABI-EN.html

Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>

Automatic date update in version.in

gdb/python/mi: create MI commands using python

This commit allows a user to create custom MI commands using Python
similarly to what is possible for Python CLI commands.

A new subclass of mi_command is defined for Python MI commands,
mi_command_py. A new file, gdb/python/py-micmd.c contains the logic
for Python MI commands.

This commit is based on work linked too from this mailing list thread:

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

Which has also been previously posted to the mailing list here:

  https://sourceware.org/pipermail/gdb-patches/2019-May/158010.html

And was recently reposted here:

  https://sourceware.org/pipermail/gdb-patches/2022-January/185190.html

The version in this patch takes some core code from the previously
posted patches, but also has some significant differences, especially
after the feedback given here:

  https://sourceware.org/pipermail/gdb-patches/2022-February/185767.html

A new MI command can be implemented in Python like this:

  class echo_args(gdb.MICommand):
      def invoke(self, args):
          return { 'args': args }

  echo_args("-echo-args")

The 'args' parameter (to the invoke method) is a list
containing (almost) all command line arguments passed to the MI
command (--thread and --frame are handled before the Python code is
called, and removed from the args list).  This list can be empty if
the MI command was passed no arguments.

When used within gdb the above command produced output like this:

  (gdb)
  -echo-args a b c
  ^done,args=["a","b","c"]
  (gdb)

The 'invoke' method of the new command must return a dictionary.  The
keys of this dictionary are then used as the field names in the mi
command output (e.g. 'args' in the above).

The values of the result returned by invoke can be dictionaries,
lists, iterators, or an object that can be converted to a string.
These are processed recursively to create the mi output.  And so, this
is valid:

  class new_command(gdb.MICommand):
      def invoke(self,args):
          return { 'result_one': { 'abc': 123, 'def': 'Hello' },
                   'result_two': [ { 'a': 1, 'b': 2 },
                                   { 'c': 3, 'd': 4 } ] }

Which produces output like:

  (gdb)
  -new-command
  ^done,result_one={abc="123",def="Hello"},result_two=[{a="1",b="2"},{c="3",d="4"}]
  (gdb)

I have required that the fields names used in mi result output must
match the regexp: "^[a-zA-Z][-_a-zA-Z0-9]*$" (without the quotes).
This restriction was never written down anywhere before, but seems
sensible to me, and we can always loosen this rule later if it proves
to be a problem.  Much harder to try and add a restriction later, once
people are already using the API.

What follows are some details about how this implementation differs
from the original patch that was posted to the mailing list.

In this patch, I have changed how the lifetime of the Python
gdb.MICommand objects is managed.  In the original patch, these object
were kept alive by an owned reference within the mi_command_py object.
As such, the Python object would not be deleted until the
mi_command_py object itself was deleted.

This caused a problem, the mi_command_py were held in the global mi
command table (in mi/mi-cmds.c), which, as a global, was not cleared
until program shutdown.  By this point the Python interpreter has
already been shutdown.  Attempting to delete the mi_command_py object
at this point was causing GDB to try and invoke Python code after
finalising the Python interpreter, and we would crash.

To work around this problem, the original patch added code in
python/python.c that would search the mi command table, and delete the
mi_command_py objects before the Python environment was finalised.

In contrast, in this patch, I have added a new global dictionary to
the gdb module, gdb._mi_commands.  We already have several such global
data stores related to pretty printers, and frame unwinders.

The MICommand objects are placed into the new gdb.mi_commands
dictionary, and it is this reference that keeps the objects alive.
When GDB's Python interpreter is shut down gdb._mi_commands is deleted,
and any MICommand objects within it are deleted at this point.

This change avoids having to make the mi_cmd_table global, and walk
over it from within GDB's python related code.

This patch handles command redefinition entirely within GDB's python
code, though this does impose one small restriction which is not
present in the original code (detailed below), I don't think this is a
big issue.  However, the original patch relied on being able to
finish executing the mi_command::do_invoke member function after the
mi_command object had been deleted.  Though continuing to execute a
member function after an object is deleted is well defined, it is
also (IMHO) risky, its too easy for someone to later add a use of the
object without realising that the object might sometimes, have been
deleted.  The new patch avoids this issue.

The one restriction that is added to avoid this, is that an MICommand
object can't be reinitialised with a different command name, so:

  (gdb) python cmd = MyMICommand("-abc")
  (gdb) python cmd.__init__("-def")
  can't reinitialize object with a different command name

This feels like a pretty weird edge case, and I'm happy to live with
this restriction.

I have also changed how the memory is managed for the command name.
In the most recently posted patch series, the command name is moved
into a subclass of mi_command, the python mi_command_py, which
inherits from mi_command is then free to use a smart pointer to manage
the memory for the name.

In this patch, I leave the mi_command class unchanged, and instead
hold the memory for the name within the Python object, as the lifetime
of the Python object always exceeds the c++ object stored in the
mi_cmd_table.  This adds a little more complexity in py-micmd.c, but
leaves the mi_command class nice and simple.

Next, this patch adds some extra functionality, there's a
MICommand.name read-only attribute containing the name of the command,
and a read-write MICommand.installed attribute that can be used to
install (make the command available for use) and uninstall (remove the
command from the mi_cmd_table so it can't be used) the command.  This
attribute will be automatically updated if a second command replaces
an earlier command.

This patch adds additional error handling, and makes more use the
gdbpy_handle_exception function.

Co-Authored-By: Jan Vrany <jan.vrany@labware.com>