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>

gdb/gdbarch: compare some fields against 0 verify_gdbarch

After the previous commit, which removes the predicate function
gdbarch_register_type_p, I noticed that the gdbarch->register_type
field was not checked at in the verify_gdbarch function.

More than not being checked, the field wasn't mentioned at all.

I find this strange, I would expect that every field would at least be
mentioned - we already generate comments for some fields saying that
this field is _not_ being checked, so the fact that this field isn't
being checked looks (to me), like this field is somehow slipping
through the cracks.

The comment at the top of gdbarch-components.py tries to explain how
the validation is done.  I didn't understand this comment completely,
but, I think this final sentence:

  "Otherwise, the check is done against 0 (really NULL for function
  pointers, but same idea)."

Means that, if non of the other cases apply, then the field should be
checked against 0, with 0 indicating that the field is invalid (was
not set by the tdep code).  However, this is clearly not being done.

Looking in gdbarch.py at the code to generate verify_gdbarch we do
find that there is a case that is not handled, the case where the
'invalid' field is set true True, but non of the other cases apply.

In this commit I propose two changes:

 1. Handle the case where the 'invalid' field of a property is set to
 True, this should perform a check for the field of gdbarch still
 being set to 0, and

 2. If the if/else series that generates verify_gdbarch doesn't handle
 a property then we should raise an exception.  This means that if a
 property is added which isn't handled, we should no longer silently
 ignore it.

After doing this, I re-generated the gdbarch files and saw that the
following gdbarch fields now had new validation checks:

  register_type
  believe_pcc_promotion
  register_to_value
  value_to_register
  frame_red_zone_size
  displaced_step_restore_all_in_ptid
  solib_symbols_extension

Looking at how these are currently set in the various -tdep.c files, I
believe the only one of these that is required to be set for all
architectures is the register_type field.

And so, for all of the other fields, I've changed the property
definition on gdbarch-components.py, setting the 'invalid' field to
False.

Now, after re-generation, the register_type field is checked against
0, thus an architecture that doesn't set_gdbarch_register_type will
now fail during validation.  For all the other fields we skip the
validation, in which case, it is find for an architecture to not set
this field.

My expectation is that there should be no user visible changes after
this commit.  Certainly for all fields except register_type, all I've
really done is cause some extra comments to be generated, so I think
that's clearly fine.

For the register_type field, my claim is that any architecture that
didn't provide this would fail when creating its register cache, and I
couldn't spot an architecture that doesn't provide this hook.  As
such, I think this change should be fine too.

gdb/gdbarch: remove the predicate function for gdbarch_register_type

I don't believe that the gdbarch_register_type_p predicate is called
anywhere in GDB, and the gdbarch_register_type function is called
without checking the gdbarch_register_type_p predicate function
everywhere it is used, for example in
init_regcache_descr (regcache.c).

My claim is that the gdbarch_register_type function is required for
every architecture, and GDB will not work if this function is not
supplied.

And so, in this commit, I remove the 'predicate=True' from
gdbarch-components.py for the 'register_type' field, and regenerate
the gdbarch files.

There should be no user visible changes after this commit.

Replace deprecated_target_wait_hook by observers

Commit b60cea7 (Make target_wait options use enum flags) broke
deprecated_target_wait_hook usage: there's a commit comment telling
this hook has not been converted.

Rather than trying to mend it, this patch replaces the hook by two
target_wait observers:

target_pre_wait (ptid_t ptid)
target_post_wait (ptid_t event_ptid)

Upon target_wait entry, target_pre_wait is notified with the ptid
passed to target_wait. Upon exit, target_post_wait is notified with
the event ptid returned by target_wait. Should an exception occur,
event_ptid is null_ptid.

This change benefits to Insight (out-of-tree): there's no real use of the
late hook in gdb itself.

Correctly print subrange types in generic_value_print

I noticed that generic_value_print assumes that a subrange type is
always a subrange of an integer type.  However, this isn't necessarily
the case.  In Ada, for example, one has subranges of character and
enumeration types.

This code isn't often exercised, I think, because languages with real
subrange types tend to implement their own printers.  However, it
still seemed worth fixing.

[aarch64/arm] Properly extract the return value returned in memory

When running gdb.cp/non-trivial-retval.exp, the following shows up for
both aarch64-linux and armhf-linux:

Breakpoint 3, f1 (i1=23, i2=100) at src/gdb/testsuite/gdb.cp/non-trivial-retval.cc:35
35        A a;
(gdb) finish
Run till exit from #0  f1 (i1=23, i2=100) at src/gdb/testsuite/gdb.cp/non-trivial-retval.cc:35
main () at /src/gdb/testsuite/gdb.cp/non-trivial-retval.cc:163
163       B b = f2 (i1, i2);
Value returned is $6 = {a = -11952}
(gdb)

The return value should be {a = 123} instead. This happens because the
backends don't extract the return value from the correct location. GDB should
fetch a pointer to the memory location from X8 for aarch64 and r0 for armhf.

With the patch, gdb.cp/non-trivial-retval.exp has full passes on
aarch64-linux and armhf-linux on Ubuntu 20.04/18.04.

The problem only shows up with the "finish" command. The "call" command
works correctly and displays the correct return value.

This is also related to PR gdb/28681
(https://sourceware.org/bugzilla/show_bug.cgi?id=28681) and fixes FAIL's in
gdb.ada/mi_var_array.exp.

A new testcase is provided, and it exercises GDB's ability to "finish" a
function that returns a large struct (> 16 bytes) and display the
contents of this struct correctly. This has always been incorrect for
these backends, but no testcase exercised this particular scenario.

Automatic date update in version.in

PR28959, obdump doesn't disassemble mftb instruction

Without a -M cpu option given, powerpc objdump defaults currently to
-Mpower10 but -Many is also given.  Commit 1ff6a3b8e562 regressed
-Many disassembly of instructions that are encoded differently
depending on cpu, such as mftb which has pre- and post-power4
encodings.

PR 28959
* ppc-dis.c (lookup_powerpc): Revert 2021-05-28 change.  Instead
only look at deprecated PPC_OPCODE_RAW bit when -Many.

Automatic date update in version.in

Relax regexp in gdb.rust/unsized.exp

With nightly rustc, gdb.rust/unsized.exp fails:

    (gdb) ptype *us
    Structure has no component named operator*.

rustc changed to emit a bit more debug info for unsized types.
Because the original test is just to make sure that ptype of an
unsized array looks right, this patch relaxes the regexp and changes
the expression.  I think this keeps the original test meaning, but
also works with nightly.  I also tested stable and 1.48.

Automatic date update in version.in

Avoid crash with cross-linux core file

An internal test case creates a core file using gcore, then restarts
gdb with that core.  When run with a cross-linux gdb (in this case,
x86-64 host with ppc64-linux target), the test fails:

    | (gdb) core core
    | [New LWP 18437]
    | warning: `/lib64/libc.so.6': Shared library architecture unknown is not compatible with target architecture powerpc:common64.
    | warning: Could not load shared library symbols for /lib64/ld64.so.1.
    | Do you need "set solib-search-path" or "set sysroot"?
    | ../../src/gdb/gdbarch.c:3388: internal-error: int gdbarch_elf_make_msymbol_special_p(gdbarch*): Assertion `gdbarch != NULL' failed.
    | A problem internal to GDB has been detected,
    | further debugging may prove unreliable.
    | Quit this debugging session? (y or n) y

What's happening here is that the core file lists some shared
libraries.  These aren't available via the solib search path, and so
gdb finds the local (x86-64) libraries.  This is not ideal, but on the
other hand, it is what was asked for -- while the test does set
solib-search-path, it does not set the sysroot.

But, because gdb isn't configured to handle these libraries, it
crashes.

It seems to me that it's better to avoid the crash by having
solib_bfd_open fail in the case where a library is incompatible.  That
is what this patch does.  Now it looks like:

    | [New LWP 15488]
    | Error while mapping shared library sections:
    | `/lib64/libc.so.6': Shared library architecture unknown is not compatible with target architecture powerpc:common64.

... and does not crash gdb.

I don't have a good setup for testing this using dejagnu, so I don't
know whether an existing gdb test covers this scenario.

gdb/testsuite: remove duplicates from gdb.base/stap-probe.exp

Remove the duplicate test names from gdb.base/stap-probe.exp, this is
done by actually passing a unique test name in a couple of
places (rather than using the command as the test name), and in
another couple of places, a test has a duplicate name due to a cut &
paste error, which I've fixed.

There's no change in what is actually being tested after this commit.

gprofng: a new GNU profiler

top-level
* Makefile.def: Add gprofng module.
* configure.ac: Add --enable-gprofng option.
* src-release.sh: Add gprofng.
* Makefile.in: Regenerate.
* configure: Regenerate.
* gprofng: New directory.

binutils
* MAINTAINERS: Add gprofng maintainer.
* README-how-to-make-a-release: Add gprofng.

include.
* collectorAPI.h: New file.
* libcollector.h: New file.
* libfcollector.h: New file.

Automatic date update in version.in

gdb/auto-load: Remove repeating "auto-load" from debug message

Remove "auto-load:" from a format string passed to auto_load_debug_printf.
It is unnecessary since this function will prefix the string with "[auto-load]"
when printing it.

Change how "print/x" displays floating-point value

Currently, "print/x" will display a floating-point value by first
casting it to an integer type.  This yields weird results like:

    (gdb) print/x 1.5
    $1 = 0x1

This has confused users multiple times -- see PR gdb/16242, where
there are several dups.  I've also seen some confusion from this
internally at AdaCore.

The manual says:

    'x'
 Regard the bits of the value as an integer, and print the integer
 in hexadecimal.

... which seems more useful.  So, perhaps what happened is that this
was incorrectly implemented (or maybe correctly implemented and then
regressed, as there don't seem to be any tests).

This patch fixes the bug.

There was a previous discussion where we agreed to preserve the old
behavior:

    https://sourceware.org/legacy-ml/gdb-patches/2017-06/msg00314.html

However, I think it makes more sense to follow the manual.

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

Simplify the ui-out progress API

I noticed that 'progress' is a method on ui-out, but it seems to me
that it would be better if the only API were via the progress_meter
class.  This patch makes this change, changing progress to be a method
on the meter itself.

gdb/gdbarch: fix typo in gdbarch-components.py

Fixes a minor typo, in a comment, in the gdbarch-components.py script.

There should be no user visible changes after this commit.

Process exit status is leader exit status testcase

This adds a multi-threaded testcase that has all threads in the
process exit with a different exit code, and ensures that GDB reports
the thread group leader's exit status as the whole-process exit
status.  Before this set of patches, this would randomly report the
exit code of some other thread, and thus fail.

Tested on Linux-x86_64, native and gdbserver.

Co-Authored-By: Pedro Alves <pedro@palves.net>
Change-Id: I30cba2ff4576fb01b5169cc72667f3268d919557

Re-add zombie leader on exit, gdbserver/linux

Same as the previous patch, but for GDBserver.

In summary, the current zombie leader detection code in linux-low.cc
has a race -- if a multi-threaded inferior exits just before
check_zombie_leaders finds that the leader is now zombie via checking
/proc/PID/status, check_zombie_leaders deletes the leader, assuming we
won't get an event for that exit (which we won't in some scenarios,
but not in this one), which is a false-positive scenario, where the
whole process is simply exiting.  Later when we see the last LWP in
our list exit, we report that LWP's exit status as exit code, even
though for the (real) parent process, the exit code that counts is the
child's leader thread's exit code.

Like for GDB, the solution here is to:

   - only report whole-process exit events for the leader.
   - re-add the leader back to the LWP list when we finally see it
     exit.

Change-Id: Id2d7bbb51a415534e1294fff1d555b7ecaa87f1d

Re-add zombie leader on exit, gdb/linux

The current zombie leader detection code in linux-nat.c has a race --
if a multi-threaded inferior exits just before check_zombie_leaders
finds that the leader is now zombie via checking /proc/PID/status,
check_zombie_leaders deletes the leader, assuming we won't get an
event for that exit (which we won't in some scenarios, but not in this
one).  That might seem mostly harmless, but it has some downsides:

 - later when we continue pulling events out of the kernel, we will
   collect the exit event of the non-leader threads, and once we see
   the last lwp in our list exit, we return _that_ lwp's exit code as
   whole-process exit code to infrun, instead of the leader's exit
   code.

 - this can cause a hang in stop_all_threads in infrun.c.  Say there
   are 2 threads in the process.  stop_all_threads stops each of those
   threads, and then waits for two stop or exit events, one for each
   thread.  If the whole process exits, and check_zombie_leaders hits
   the false-positive case, linux-nat.c will only return one event to
   GDB (the whole-process exit returned when we see the last thread,
   the non-leader thread, exit), making stop_all_threads hang forever
   waiting for a second event that will never come.

However, in this false-positive scenario, where the whole process is
exiting, as opposed to just the leader (with pthread_exit(), for
example), we _will_ get an exit event shortly for the leader, after we
collect the exit event of all the other non-leader threads.  Or put
another way, we _always_ get an event for the leader after we see it
become zombie.

I tried a number of approaches to fix this:

#1 - My first thought to address the race was to make GDB always
report the whole-process exit status for the leader thread, not for
whatever is the last lwp in the list.  We _always_ get a final exit
(or exec) event for the leader, and when the race triggers, we're not
collecting it.

#2 - My second thought was to try to plug the race in the first place.

I thought of making GDB call waitpid/WNOHANG for all non-leader
threads immediately when the zombie leader is detected, assuming there
would be an exit event pending for each of them waiting to be
collected.  Turns out that that doesn't work -- you can see the leader
become zombie _before_ the kernel kills all other threads.  Waitpid in
that small time window returns 0, indicating no-event.  Thankfully we
hit that race window all the time, which avoided trading one race for
another.  Looking at the non-leader thread's status in /proc doesn't
help either, the threads are still in running state for a bit, for the
same reason.

#3 - My next attempt, which seemed promising, was to synchronously
stop and wait for the stop for each of the non-leader threads.  For
the scenario in question, this will collect all the exit statuses of
the non-leader threads.  Then, if we are left with only the zombie
leader in the lwp list, it means we either have a normal while-process
exit or an exec, in which case we should not delete the leader.  If
_only_ the leader exited, like in gdb.threads/leader-exit.exp, then
after pausing threads, we will still have at least one live non-leader
thread in the list, and so we delete the leader lwp.  I got this
working and polished, and it was only after staring at the kernel code
to convince myself that this would really work (and it would, for the
scenario I considered), that I realized I had failed to account for
one scenario -- if any non-leader thread is _already_ stopped when
some thread triggers a group exit, like e.g., if you have some threads
stopped and then resume just one thread with scheduler-locking or
non-stop, and that thread exits the process.  I also played with
PTRACE_EVENT_EXIT, see if it would help in any way to plug the race,
and I couldn't find a way that it would result in any practical
difference compared to looking at /proc/PID/status, with respect to
having a race.

So I concluded that there's no way to plug the race, we just have to
deal with it.  Which means, going back to approach #1.  That is the
approach taken by this patch.

Change-Id: I6309fd4727da8c67951f9cea557724b77e8ee979

gdbserver: Reindent check_zombie_leaders

This fixes the indentation of
linux_process_target::check_zombie_leaders, which will help with
keeping its comments in sync with the gdb/linux-nat.c counterpart.

Change-Id: I37332343bd80423d934249e3de2d04feefad1891

gdbserver: Reorganize linux_process_target::filter_event

Reorganize linux-low.cc:linux_process_target::filter_event such that
all the handling for events for LWPs not in the LWP list is together.
This helps make a following patch clearer.  The comments and debug
messages have also been tweaked to have them synchronized with the GDB
counterpart.

Change-Id: If9019635f63a846607cfda44b454b4254a404019

gdb: Reorganize linux_nat_filter_event

Reorganize linux-nat.c:linux_nat_filter_event such that all the
handling for events for LWPs not in the LWP list is together.  This
helps make a following patch clearer.  The comments and debug messages
have also been tweaked - the end goal is to have them synchronized
with the gdbserver counterpart.

Change-Id: I8586d8dcd76d8bd3795145e3056fc660e3b2cd22

Fix gdb.threads/current-lwp-dead.exp race

If we make GDB report the process EXIT event for the leader thread, as
will be done in a latter patch of this series, then
gdb.threads/current-lwp-dead.exp starts failing:

 (gdb) break fn_return
 Breakpoint 2 at 0x5555555551b5: file /home/pedro/rocm/gdb/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.threads/current-lwp-dead.c, line 45.
 (gdb) continue
 Continuing.
 [New LWP 2138466]
 [Inferior 1 (process 2138459) exited normally]
 (gdb) FAIL: gdb.threads/current-lwp-dead.exp: continue to breakpoint: fn_return (the program exited)

The inferior exit reported is actually correct.  The main thread has
indeed exited, and that's the thread that has the right exit code to
report to the user, as that's the exit code that is reported to the
program's parent.  In this case, GDB managed to collect the exit code
for the leader thread before reaping the other thread, because in
reality, the testcase isn't creating standard threads, it is using raw
clone, and the new clones are put in their own thread group.

Fix it by making the main "thread" not exit until the scenario we're
exercising plays out.  Also, run the program to completion for
completeness.

The original program really wanted the leader thread to exit before
the fn_return function was reached -- it was important that the
current thread as pointed by inferior_ptid was gone when infrun got
the breakpoint event.  I've tweaked the testcase to ensure that that
condition is still held, though it is no longer the main thread that
exits.  This required a bit of synchronization between the threads,
which required using CLONE_VM unconditionally.  The #ifdef guards were
added as a fix for
https://sourceware.org/bugzilla/show_bug.cgi?id=11214, though I don't
think they were necessary because the program is not using TLS.  If it
turns out they were necessary, we can link the testcase with "-z now"
instead, which was mentioned as an alternative workaround in that
Bugzilla.

Change-Id: I7be2f0da4c2fe8f80a60bdde5e6c623d8bd5a0aa

Fix gdb.threads/clone-new-thread-event.exp race

If we make GDB report the process EXIT event for the leader thread,
instead of whatever is the last thread in the LWP list, as will be
done in a latter patch of this series, then
gdb.threads/current-lwp-dead.exp starts failing:

 (gdb) FAIL: gdb.threads/clone-new-thread-event.exp: catch SIGUSR1 (the program exited)

This is a testcase race -- the main thread does not wait for the
spawned clone "thread" to finish before exiting, so the main program
may exit before the second thread is scheduled and reports its
SIGUSR1.  With the change to make GDB report the EXIT for the leader,
the race is 100% reproducible by adding a sleep(), like so:

 --- c/gdb/testsuite/gdb.threads/clone-new-thread-event.c
 +++ w/gdb/testsuite/gdb.threads/clone-new-thread-event.c
 @@ -51,6 +51,7 @@ local_gettid (void)
  static int
  fn (void *unused)
  {
 +  sleep (1);
    tkill (local_gettid (), SIGUSR1);
    return 0;
  }

Resulting in:

 Breakpoint 1, main (argc=1, argv=0x7fffffffd418) at gdb.threads/clone-new-thread-event.c:65
 65        stack = malloc (STACK_SIZE);
 (gdb) continue
 Continuing.
 [New LWP 3715562]
 [Inferior 1 (process 3715555) exited normally]
 (gdb) FAIL: gdb.threads/clone-new-thread-event.exp: catch SIGUSR1 (the program exited)

That inferior exit reported is actually correct.  The main thread has
indeed exited, and that's the thread that has the right exit code to
report to the user, as that's the exit code that is reported to the
program's parent.  In this case, GDB managed to collect the exit code
for the leader thread before reaping the other thread, because in
reality, the testcase isn't creating standard threads, it is using raw
clone, and the new clones are put in their own thread group.

Fix it by making the main thread wait for the child to exit.  Also,
run the program to completion for completeness.

Change-Id: I315cd3dc2b9e860395dcab9658341ea868d7a6bf

Fix gdbserver/linux target_waitstatus logging assert

Turning on debug output in gdbserver leads to an assertion failure if
gdbserver reports a non-signal event:

    [threads] wait_1: LWP 3273770: extended event with waitstatus status->kind = EXECD, execd_pathname = gdb.threads/non-ldr-exc-1/non-ldr-exc-1
    [threads] wait_1: Hit a non-gdbserver trap event.
  ../../src/gdbserver/../gdb/target/waitstatus.h:365: A problem internal to GDBserver has been detected.
  sig: Assertion `m_kind == TARGET_WAITKIND_STOPPED || m_kind == TARGET_WAITKIND_SIGNALLED' failed.

Fix it in the obvious way, using target_waitstatus::to_string(),
resulting in, for example:

  [threads] wait_1: ret = LWP 1542412.1542412, status->kind = STOPPED, sig = GDB_SIGNAL_TRAP

Change-Id: Ia4832f9b4fa39f4af67fcaf21fd4d909a285a645

Add option to objdump/readelf to disable access to debuginfod servers.

* dwarf.c (use_debuginfod): New variable.  Set to 1.
(load_separate_debug_info): Only call
debuginfod_fetch_separate_debug_info is use_debuginfod is true.
(dwarf_select_sections_by_names): Add do-not-use-debuginfod and
use-debuginfod options.
(dwarf_select_sections_by_letters): Add D and E options.
* dwarf.h (use_debuginfod): New extern.
* objdump.c (usage): Mention the new options.
* readelf.c (usage): Likewise.
* doc/binutils.texi: Document the new options.
* doc/debug-options.texi: Describe the new options.
* NEWS: Mention the new feature.
* testsuite/binutils-all/debuginfod.exp: Add tests of the new
options.

Re: ld: Add a before_plugin_all_symbols_read hook

* testsuite/ld-plugin/pr28849.d: Adjust for powerpc64 function
descriptors.

ld: Add a before_plugin_all_symbols_read hook

Add a before_plugin_all_symbols_read hook to load symbol references from
DT_NEEDED entries, included from --copy-dt-needed-entries, before reading
plugin symbols to properly resolve plugin symbol references.

bfd/

PR ld/28849
* elf-bfd.h (elf_link_hash_table): Add handling_dt_needed.
* elflink.c (_bfd_elf_merge_symbol): Don't set non_ir_ref_dynamic
before plugin 'all symbols read' hook is called.

ld/

PR ld/28849
* ldelf.c (ldelf_handle_dt_needed): New function.
(ldelf_before_plugin_all_symbols_read): Likewise.
(ldelf_after_open): Call ldelf_handle_dt_needed.
* ldelf.h (ldelf_before_plugin_all_symbols_read): New.
* ldemul.c (ldemul_before_plugin_all_symbols_read): Likewise.
* ldemul.h (ldemul_before_plugin_all_symbols_read): Likewise.
(ld_emulation_xfer_struct): Add before_plugin_all_symbols_read.
* ldlang.c (lang_process): Call
ldemul_before_plugin_all_symbols_read before calling
plugin_call_all_symbols_read.
* emultempl/elf.em
(gld${EMULATION_NAME}_before_plugin_all_symbols_read): New.
(LDEMUL_BEFORE_PLUGIN_ALL_SYMBOLS_READ): New.
* emultempl/emulation.em (ld_${EMULATION_NAME}_emulation):
Initialize the before_plugin_all_symbols_read field.
* testsuite/ld-plugin/lto.exp: Run PR ld/28849 tests.
* testsuite/ld-plugin/pr28849.d: New file.
* testsuite/ld-plugin/pr28849a.c: Likewise.
* testsuite/ld-plugin/pr28849b.c: Likewise.

Automatic date update in version.in

toplevel: Makefile.def: Make configure-sim depend on all-readline

Without this, a "make all-sim" without the equivalent of
libreadline-dev installed on the build system, won't
properly pick up the in-tree readline build, and you'll see:

mkdir -p -- ./sim
Configuring in ./sim
configure: creating cache ./config.cache
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
checking target system type... cris-axis-elf
checking for x86_64-pc-linux-gnu-gcc... gcc
checking whether the C compiler works... yes
...
checking for library containing tgetent... -ltermcap
checking for readline in -lreadline... no
configure: error: the required "readline" library is missing
make[1]: *** [Makefile:11188: configure-sim] Error 1
make[1]: Leaving directory '/home/hp/sim/b'

The sim dependency on readline is apparently (nominally)
valid as there's a readline call in sim/erc32/sis.c.

2022-02-21  Hans-Peter Nilsson  <hp@axis.com>

* Makefile.def (dependencies): Make configure-sim depend on
all-readline.

GDB/testsuite: Fix a "displayed" typo in gdb.base/default.exp

Fix a typo, s/dislayed/displayed/ in default.exp at the top level.

GDB/testsuite: Remove a stray backslash from gdb.base/settings.exp

Remove a stray trailing backslash from `test-integer' in settings.exp.
It is harmless as only white space follows in the next line before the
closing brace, so it merely swallows the newline character, but it may
look confusing to the reader.

* gdb/doc/gdb.texinfo (Requirements): Fix a typo.

Copyright-paperwork-exempt: yes

Constant fold view increment expressions

The idea here is to replace expressions like v + 1 + 1 + 1 with v + 3.

* dwarf2dbg.c (set_or_check_view): Remove useless assertion.
Resolve multiple view increments.
* testsuite/gas/elf/dwarf2-18.d: Don't xfail mep.

Reduce duplicated symbol_clone_if_forward_ref work

* symbol.c (struct symbol_flags): Add forward_resolved.
(symbol_entry_find): Update needle initialisation.
(symbol_clone_if_forward_ref): Do no work when forward_resolved
is already set.  Set forward_resolved.

gdb: Try searching for auto-load script using .gnu_debuglink

If an auto-load script cannot be found and objfile is a separate
debuginfo whose filename does not match the name found in the parent
file's .gnu_debuglink section, then repeat the search using the
parent's filename where the last component is replaced with the
.gnu_debuglink name.

For example if the parent's filename is "/usr/lib/libxyz.so" and the
name in its .gnu_debuglink section is "libxyz.so.debug", then
if no auto-load script is otherwise found the search will be
repeated with the filename "/usr/lib/libxyz.so.debug".

This helps gdb locate auto-load scripts when debuginfo files do not have
the expected filename, such as when they are aquired from debuginfod.

Automatic date update in version.in

PR gdb/27876 - debuginfod-downloaded source files don't pass proper fullname across mi / (gdb)info source

Source files downloaded from debuginfod currently use their original DWARF
filename as their "fullname".  This causes a mismatch between the fullname
and the actual location of the source file in the debuginfod client cache.

MI consumers such as VSCode will fail to open debuginfod-downloaded
source files due to this.  Also 'info source' will fail to include the
true paths of these files.

To fix this, use the debuginfod cache path as the fullname for debuginfod-
downloaded source files.

gdb/mi: preserve user selected thread and frame when invoking MI commands

Fix for PR gdb/20684.  When invoking MI commands with --thread and/or
--frame, the user selected thread and frame was not preserved:

  (gdb)
  info thread
  &"info thread\n"
  ~"  Id   Target Id                                           Frame \n"
  ~"* 1    Thread 0x7ffff7c30740 (LWP 19302) \"user-selected-c\" main () at /home/uuu/gdb/gdb/testsuite/gdb.mi/user-selected-context-sync.c:60\n"
  ~"  2    Thread 0x7ffff7c2f700 (LWP 19306) \"user-selected-c\" child_sub_function () at /home/uuu/gdb/gdb/testsuite/gdb.mi/user-selected-context-sync.c:30\n"
  ~"  3    Thread 0x7ffff742e700 (LWP 19307) \"user-selected-c\" child_sub_function () at /home/uuu/gdb/gdb/testsuite/gdb.mi/user-selected-context-sync.c:30\n"
  ^done
  (gdb)
  info frame
  &"info frame\n"
  ~"Stack level 0, frame at 0x7fffffffdf90:\n"
  ~" rip = 0x555555555207 in main (/home/uuu/gdb/gdb/testsuite/gdb.mi/user-selected-context-sync.c:60); saved rip = 0x7ffff7c5709b\n"
  ~" source language c.\n"
  ~" Arglist at 0x7fffffffdf80, args: \n"
  ~" Locals at 0x7fffffffdf80, Previous frame's sp is 0x7fffffffdf90\n"
  ~" Saved registers:\n "
  ~" rbp at 0x7fffffffdf80, rip at 0x7fffffffdf88\n"
  ^done
  (gdb)
  -stack-info-depth --thread 3
  ^done,depth="4"
  (gdb)
  info thread
  &"info thread\n"
  ~"  Id   Target Id                                           Frame \n"
  ~"  1    Thread 0x7ffff7c30740 (LWP 19302) \"user-selected-c\" main () at /home/uuu/gdb/gdb/testsuite/gdb.mi/user-selected-context-sync.c:60\n"
  ~"  2    Thread 0x7ffff7c2f700 (LWP 19306) \"user-selected-c\" child_sub_function () at /home/uuu/gdb/gdb/testsuite/gdb.mi/user-selected-context-sync.c:30\n"
  ~"* 3    Thread 0x7ffff742e700 (LWP 19307) \"user-selected-c\" child_sub_function () at /home/uuu/gdb/gdb/testsuite/gdb.mi/user-selected-context-sync.c:30\n"
  ^done
  (gdb)
  info frame
  &"info frame\n"
  ~"Stack level 0, frame at 0x7ffff742dee0:\n"
  ~" rip = 0x555555555169 in child_sub_function (/home/uuu/gdb/gdb/testsuite/gdb.mi/user-selected-context-sync.c:30); saved rip = 0x555555555188\n"
  ~" called by frame at 0x7ffff742df00\n"
  ~" source language c.\n"
  ~" Arglist at 0x7ffff742ded0, args: \n"
  ~" Locals at 0x7ffff742ded0, Previous frame's sp is 0x7ffff742dee0\n"
  ~" Saved registers:\n "
  ~" rbp at 0x7ffff742ded0, rip at 0x7ffff742ded8\n"
  ^done
  (gdb)

This caused problems for frontends that provide access to CLI because UI
may silently change the context for CLI commands (as demonstrated above).

This commit fixes the problem by restoring thread and frame in
mi_cmd_execute (). With this change, there are only two GDB/MI commands
that can change user selected context: -thread-select and -stack-select-frame.
This allows us to remove all and rather complicated logic of notifying
about user selected context change from mi_execute_command (), leaving it
to these two commands themselves to notify.

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

gdb: announce upcoming removal of Python 2 support from gdb

As has been discussed here:

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

Python 2 support will be removed from GDB after GDB 12 has branched.
This commit places an entry in the NEWS file to inform users of this
decision.

Automatic date update in version.in

gdb/testsuite: add new test for comparing char types in Python

There's an interesting property of the 'char' type in C and C++, the
three types 'char', 'unsigned char', and 'signed char', are all
considered distinct.

In contrast, and 'int' is signed by default, and so 'int' and 'signed
int' are considered the same type.

This commit adds a test to ensure that this edge case is visible to a
user from Python.

It is worth noting that for any particular compiler implementation (or
the flags a compiler was invoked with), a 'char' will be either signed
or unsigned; it has to be one or the other, and a user can access this
information by using the Type.is_signed property.  However, for
something like function overload resolution, the 'char' type is
considered distinct from the signed and unsigned variants.

There's no change to GDB with this commit, this is just adding a new
test to guard some existing functionality.

gdb/python: add Type.is_signed property

Add a new read-only property, Type.is_signed, which is True for signed
types, and False otherwise.

This property should only be read on types for which Type.is_scalar is
true, attempting to read this property for non-scalar types will raise
a ValueError.

I chose 'is_signed' rather than 'is_unsigned' in order to match the
existing Architecture.integer_type method, which takes a 'signed'
parameter.  As far as I could find, that was the only existing
signed/unsigned selector in the Python API, so it seemed reasonable to
stay consistent.

gdb/python: add Type.is_scalar property

Add a new read-only property which is True for scalar types,
otherwise, it's False.

gdb/mi: add --no-connection to MI -add-inferior command

Following on from the previous commit, where the -add-inferior command
now uses the same connection as the current inferior, this commit adds
a --no-connection option to -add-inferior.

This new option matches the existing option of the same name for the
CLI version of add-inferior; the new inferior is created with no
connection.

I've added a new 'connection' field to the MI output of -add-inferior,
which includes the connection number and short name.  I haven't
included the longer description field, this is the MI after all.  My
expectation would be that if the frontend wanted to display all the
connection details then this would be looked up from 'info
connection' (or the MI equivalent if/when such a command is added).

The existing -add-inferior tests are updated, as are the docs.

gdb/mi: fix regression in mi -add-inferior command

Prior to the multi-target support commit:

  commit 5b6d1e4fa4fc6827c7b3f0e99ff120dfa14d65d2
  Date:   Fri Jan 10 20:06:08 2020 +0000

      Multi-target support

When a new inferior was added using the MI -add-inferior command, the
new inferior would be using the same target as all the other
inferiors.  This makes sense, GDB only supported a single target stack
at a time.

After the above commit, each inferior has its own target stack.

To maintain backward compatibility, for the CLI add-inferior command,
when a new inferior is added the above commit has the new inferior
inherit a copy of the target stack from the current inferior.

Unfortunately, this same backward compatibility is missing for the MI.

This commit fixes this oversight.

Now, when the -add-inferior MI command is used, the new inferior will
inherit a copy of the target stack from the current inferior.

Deprecate dbx mode

GDB has a dbx emulation mode that adds a few aliases and helper
commands.  This mode is barely documented and is very superficial
besides.  I suspect it is rarely used, and I would like to propose
deprecating it for GDB 12, and then removing it in GDB 13.

Remove unnecessary inferior lookup in infrun:handle_one

infrun.c:handle_one calls find_inferior_ptid unnecessarily, since we
already have a thread pointer handy, and the thread has a pointer to
the inferior.  This commit removes the unnecessary lookup.

Change-Id: I2ae18601dd75346c6c91068e9a4f9a6484fb3339

Fix bug in ada_print_floating

ada_print_floating rewrites a floating-point string representation to
conform to Ada syntax.  However, if you managed to get a floating
point error, you might see:

    (gdb) print whatever
    $2 = <invalid float valu.0e>

What's happening here is that ada_print_floating doesn't recognize
this error case, and proceeds to modify the error text.

This patch fixes this problem.

Implement real literal extension for Ada

Sometimes it is convenient to be able to specify the exact bits of a
floating-point literal.  For example, you may want to set a
floating-point register to a denormalized value, or to a particular
NaN.

In C, you can do this by combining the "{}" cast with an array
literal, like:

    (gdb) p {double}{0x576488BDD2AE9FFE}
    $1 = 9.8765449999999996e+112

This patch adds a somewhat similar idea to Ada.  It extends the lexer
to allow "l" and "f" suffixes in a based literal.  The "f" indicates a
floating-point literal, and the "l"s control the size of the
floating-point type.

Note that this differs from Ada's based real literals.  I believe
those can also be used to control the bits of a floating-point value,
but they are a bit more cumbersome to use (simplest is binary but
that's also very lengthy).  Also, these aren't implemented in GDB.

I chose not to allow this extension to work with based integer
literals with exponents.  That didn't seem very useful.

Fix Ada integer literals with exponents

While working on another patch, I noticed that Ada integer literals
with exponents did not work.  For example, with one form you get an
error:

    (gdb) print 8e2
    Invalid digit `e' in based literal

And with another form you get an incorrect value:

    (gdb) print 16#8#e2
    $2 = 8

This patch fixes the bugs and adds tests.

Fix gdb.ada/arrayptr.exp results

PR ada/28115 points out that gdb.ada/arrayptr.exp works with GNAT 12,
but fails with minimal encodings in earlier versions.

This patch updates the test to try to report the results correctly.  I
tried this with the Fedora 34 system gcc (GCC 11) and with a GCC 12
built from git trunk sometime relatively recently.

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

Handle non-ASCII identifiers in Ada

Ada allows non-ASCII identifiers, and GNAT supports several such
encodings.  This patch adds the corresponding support to gdb.

GNAT encodes non-ASCII characters using special symbol names.

For character sets like Latin-1, where all characters are a single
byte, it uses a "U" followed by the hex for the character.  So, for
example, thorn would be encoded as "Ufe" (0xFE being lower case
thorn).

For wider characters, despite what the manual says (it claims
Shift-JIS and EUC can be used), in practice recent versions only
support Unicode.  Here, characters in the base plane are represented
using "Wxxxx" and characters outside the base plane using
"WWxxxxxxxx".

GNAT has some further quirks here.  Ada is case-insensitive, and GNAT
emits symbols that have been case-folded.  For characters in ASCII,
and for all characters in non-Unicode character sets, lower case is
used.  For Unicode, however, characters that fit in a single byte are
converted to lower case, but all others are converted to upper case.

Furthermore, there is a bug in GNAT where two symbols that differ only
in the case of "Y WITH DIAERESIS" (and potentially others, I did not
check exhaustively) can be used in one program.  I chose to omit
handling this case from gdb, on the theory that it is hard to figure
out the logic, and anyway if the bug is ever fixed, we'll regret
having a heuristic.

This patch introduces a new "ada source-charset" setting.  It defaults
to Latin-1, as that is GNAT's default.  This setting controls how "U"
characters are decoded -- W/WW are always handled as UTF-32.

The ada_tag_name_from_tsd change is needed because this function will
read memory from the inferior and interpret it -- and this caused an
encoding failure on PPC when running a test that tries to read
uninitialized memory.

This patch implements its own UTF-32-based case folder.  This avoids
host platform quirks, and is relatively simple.  A short Python
program to generate the case-folding table is included.  It simply
relies on whatever version of Unicode is used by the host Python,
which seems basically acceptable.

Test cases for UTF-8, Latin-1, and Latin-3 are included.  This
exercises most of the new code paths, aside from Y WITH DIAERESIS as
noted above.

Define HOST_UTF32 in charset.h

rust-parse.c has a #define for the host-specific UTF-32 charset name.
A later patch needs the same thing, so this patch moves the definition
to charset.h for easier reuse.

Let phex and phex_nz handle sizeof_l==1

Currently, neither phex nor phex_nz handle sizeof_l==1 -- they let
this case fall through to the default case.  However, a subsequent
patch in this series needs this case to work correctly.

I looked at all calls to these functions that pass a 1 for the
sizeof_l parameter.  The only such case seems to be correct with this
change.

Don't pre-size result string in ada_decode

Currently, ada_decode pre-sizes the output string, filling it with 'X'
characters.  However, it's a bit simpler and more flexible to let
std::string do the work here, and simply append characters to the
string as we go.  This turns out to be useful for a subsequent patch.

Simplify a regular expression in ada-lex.l

ada-lex.l uses "%option case-insensitive", so there is no need for
regular expressions to match upper case.

Automatic date update in version.in

MIPS/opcodes: Fix alias annotation for branch instructions

Correct issues with INSN2_ALIAS annotation for branch instructions:

- regular MIPS BEQZ/L and BNEZ/L assembly instructions are idioms for
  BEQ/L and BNE/L respectively with the `rs' operand equal to $0,

- microMIPS 32-bit BEQZ and BNEZ assembly instructions are idioms for
  BEQ and BNE respectively with the `rt' operand equal to $0,

- regular MIPS BAL assembly instruction is an idiom for architecture
  levels of up to the MIPSr5 ISA and a machine instruction on its own
  from the MIPSr6 ISA up.

Add missing annotation to BEQZ/L and BNEZ/L accordingly then and add a
new entry for BAL for the MIPSr6 ISA, correcting a disassembly bug:

$ mips-linux-gnu-objdump -m mips:isa64r6 -M no-aliases -d bal.o

bal.o:     file format elf32-tradlittlemips

Disassembly of section .text:

00000000 <foo>:
   0: 04110000  0x4110000
...
$

Add test cases accordingly.

Parts for regular MIPS BEQZ/L and BNEZ/L instructions from Sagar Patel.

2022-03-06  Maciej W. Rozycki  <macro@orcam.me.uk>

binutils/
* testsuite/binutils-all/mips/mips1-branch-alias.d: New test.
* testsuite/binutils-all/mips/mips1-branch-noalias.d: New test.
* testsuite/binutils-all/mips/mips2-branch-alias.d: New test.
* testsuite/binutils-all/mips/mips2-branch-noalias.d: New test.
* testsuite/binutils-all/mips/mips32r6-branch-alias.d: New test.
* testsuite/binutils-all/mips/mips32r6-branch-noalias.d: New
test.
* testsuite/binutils-all/mips/micromips-branch-alias.d: New
test.
* testsuite/binutils-all/mips/micromips-branch-noalias.d: New
test.
* testsuite/binutils-all/mips/mips-branch-alias.s: New test
source.
* testsuite/binutils-all/mips/micromips-branch-alias.s: New test
source.
* testsuite/binutils-all/mips/mips.exp: Run the new tests.

2022-03-06  Sagar Patel  <sagarmp@cs.unc.edu>
    Maciej W. Rozycki  <macro@orcam.me.uk>

opcodes/
* mips-opc.c (mips_builtin_opcodes): Fix INSN2_ALIAS annotation
for "bal", "beqz", "beqzl", "bnez" and "bnezl" instructions.
* micromips-opc.c (micromips_opcodes): Likewise for "beqz" and
"bnez" instructions.

Use function view when iterating over block symbols

This changes iterate_over_block_local_vars and
iterate_over_block_arg_vars to take a gdb::function_view rather than a
function pointer and a user-data.  In one spot, this allows us to
remove a helper structure and helper function.  In another spot, this
looked more complicated, so I changed the helper function to be an
"operator()" -- also a simplification, just not as big.

Simplify hppa-tdep.c use of objfile_key

I happened to notice a couple of unnecessary casts in hppa-tdep.c, and
then I saw that the use of objfile_key could be simplified -- removing
some code and using the default deleter rather than noop_deleter.

Tested by rebuilding.  Let me know what you think.