sim: cris: drop custom "dynamic" test field

This tag is used to force tests to be built dynamically (i.e. without
-static linking).  This is because cris-sim.exp in dejagnu turns on
static linking in ldflags.

The default configs and runtest flags shouldn't load these boards.
If these settings are still needed, we should figure out a different
way of suppressing the stock settings wholesale.  We want these to
all pass out of the box with little to no configuration so that they
can run in a multitarget build.

With dropping "dynamic", it'll be easier to merge the custom cris
test logic with the common sim test logic.

sim: testsuite: add more silent build rules

site.exp is still verbose, but that comes from automake, so have
to get it fixed upstream.

Automatic date update in version.in

sim: cr16: fix build on gcc-12 (NULL comparison)

On gcc-12 build fails as:

    sim/cr16/interp.c: In function 'lookup_hash':
    sim/cr16/interp.c:89:25: error:
      the comparison will always evaluate as 'true'
      for the address of 'mnimonic' will never be NULL [-Werror=address]
       89 |   if ((h->ops->mnimonic != NULL) &&
          |                         ^~

'mnimonic' is a sharr array within ops. It can never be NULL.

While at it renamed 'mnimonic' to 'mnemonic'.

gdb: fix length of array view returned by some value_contents functions

In commit 50888e42dcd3 ("gdb: change functions returning value contents
to use gdb::array_view"), I believe I made a mistake with the length of
the array views returned by some functions.  All functions return a view
of `TYPE_LENGTH (value_type (type))` length.  This is not correct when
the value's enclosing type is larger than the value's type.  In that
case, the value's contents buffer is of the size of the enclosing type,
and the value's actual contents is a slice of that (as returned by
value_contents).  So, functions value_contents_all_raw,
value_contents_for_printing and value_contents_for_printing_const are
not correct.  Since they are meant to return the value's contents buffer
as a whole, they should have the size of the enclosing type.

There is nothing that uses the returned array view size at the moment,
so this didn't cause a problem.  But it became apparent when trying to
adjust some callers.

Change-Id: Ib4e8837e1069111d2b2784d3253d5f3002419e68

readelf: Support SHT_RELR/DT_RELR for -r

The -r output for SHT_RELR looks like:

Relocation section '.relr.dyn' at offset 0x530 contains 4 entries:
  7 offsets
00000000000028c0
00000000000028c8
0000000000003ad0
0000000000003ad8
0000000000003ae0
0000000000003ae8
0000000000003af0

For --use-dynamic, the header looks like

    'RELR' relocation section at offset 0x530 contains 32 bytes:

include/
    * elf/common.h (DT_ENCODING): Bump to 38.
    * elf/external.h (Elf32_External_Relr): New.
    (Elf64_External_Relr): New.
binutils/
    * readelf.c (enum relocation_type): New.
    (slurp_relr_relocs): New.
    (dump_relocations): Change is_rela to rel_type.
    Dump RELR.
    (dynamic_relocations): Add DT_RELR.
    (process_relocs): Check SHT_RELR and DT_RELR.
    (process_dynamic_section): Store into dynamic_info for
    DT_RELR/DT_RELRENT/DT_RELRSZ.

gdbsupport: remove FUNCTION_NAME

__func__ is standard C++11:

    https://en.cppreference.com/w/cpp/language/function

Also, in C++11, __func__ expands to the demangled function name, so the
mention in the comment above FUNCTION_NAME doesn't apply anymore.
Finally, in places where FUNCTION_NAME is used, I think it's enough to
print the function name, no need to print the whole signature.
Therefore, I propose to just remove FUNCTION_NAME and update users to
use the standard __func__.

Change-Id: I778f28155422b044402442dc18d42d0cded1017d

gdb/gdbsupport: make xstrprintf and xstrvprintf return a unique_ptr

The motivation is to reduce the number of places where unmanaged
pointers are returned from allocation type routines.  All of the
callers are updated.

There should be no user visible changes after this commit.

gdbsupport: move xfree into its own file

In the next commit I'd like to reference gdb_unique_ptr within the
common-utils.h file.  However, this requires that I include
gdb_unique_ptr.h, which requires that xfree be defined.

Interestingly, gdb_unique_ptr.h doesn't actually include anything that
defines xfree, but I was finding that when I added a gdb_unique_ptr.h
include to common-utils.h I was getting a dependency cycle; before my
change xfree was defined when gdb_unique_ptr.h was processed, while
after my change it was not, and this made g++ unhappy.

To break this cycle, I propose to move xfree into its own header file,
gdb-xfree.h, which I'll then include into gdb_unique_ptr.h and
common-utils.cc.

gdb: throw OPTIMIZED_OUT_ERROR rather than GENERIC_ERROR

While reviewing this patch:

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

I spotted that the patch could be improved if we threw
OPTIMIZED_OUT_ERROR rather than GENERIC_ERROR in a few places.

This commit updates error_value_optimized_out and
require_not_optimized_out to throw OPTIMIZED_OUT_ERROR.

I ran the testsuite and saw no regressions.  This doesn't really
surprise me, we don't usually write code like:

  catch (const gdb_exception_error &ex)
    {
      (if ex.error == GENERIC_ERROR)
        ...
      else
        ...
    }

There are a three places where we write something like:

  catch (const gdb_exception_error &ex)
    {
      (if ex.error == OPTIMIZED_OUT_ERROR)
        ...
    }

In frame.c:unwind_pc, stack.c:info_frame_command_core, and
value.c:value_optimized_out, but if we are hitting these cases then
it's not significantly changing GDB's behaviour.

Remove config.cache in gdbserver's "distclean"

PR gdb/28586 points out that "make distclean" fails to delete
config.cache from gdbserver/.  This patch fixes the bug, and removes a
duplicate "Makefile" deletion that was also pointed out in the PR.

[gdb/testsuite] Remove inferior output in gdb.base/foll-vfork.exp

Test-case gdb.base/foll-vfork.exp has inferior output that is not needed, but
which makes the regexp matching more difficult (see commit 1f28b70def1
"[gdb/testsuite] Fix regexp in gdb.base/foll-vfork.exp").

Remove the inferior output, and revert commit 1f28b70def1 to make the matching
more restrictive.

Tested on x86_64-linux.

x86: Don't allow KMOV in TLS code sequences

Don't allow KMOV in TLS code sequences which require integer MOV
instructions.

PR target/28595
* config/tc-i386.c (match_template): Don't allow KMOV in TLS
code sequences.
* testsuite/gas/i386/i386.exp: Run inval-tls and x86-64-inval-tls
tests.
* testsuite/gas/i386/inval-tls.l: New file.
* testsuite/gas/i386/inval-tls.s: Likewise.
* testsuite/gas/i386/x86-64-inval-tls.l: Likewise.
* testsuite/gas/i386/x86-64-inval-tls.s: Likewise.

sim: run: support concise env var settings

Support the same syntax as other common utilities where env vars can
be specified before the program to be run without an explicit option.

This behavior can be suppressed by using the -- marker.

sim: nrun: add --env-{set,unset,clear} command line options

Provide explicit control over the program's environment with the
basic set/unset/clear options.  These are a bit clunky to use,
but they're functional.

The env set operation is split out into a separate function as it'll
be used in the next commit.

With these in place, we can adjust the custom cris testsuite to use
the now standard options and not its one-off hack.

sim: syscall: hoist argc/argn/argnlen to common code

Now that the callback framework supports argv & envp, we can move
the Blackfin implementation of these syscalls to the common code.

sim: syscall: fix argvlen & argv implementation

Now that we have access to the argv & envp strings, finish implementing
these syscalls.  Delete unused variables, fix tbuf by incrementing the
pointer instead of setting to the length, and make sure we don't write
more data than the bufsize says is available.

sim: callback: expose argv & environ

Pass the existing strings data to the callbacks so that common
libgloss syscalls can be implemented (which we'll do shortly).

sim: keep track of program environment strings

We've been passing the environment strings to sim_create_inferior,
but most ports don't do anything with them.  A few will use ad-hoc
logic to stuff the stack for user-mode programs, but that's it.

Let's formalize this across the board by storing the strings in the
normal sim state.  This will allow (in future commits) supporting
more functionality in the run interface, and to unify some of the
libgloss syscalls.

sim: iq2000: fix some missing prototypes warnings

Turns out some of these were hiding real bugs like not passing the
pc variable down.

RISC-V: Scalar crypto instruction and entropy source CSR testcases.

Add testcases for Scalar Crypto extension, with total testcase contain all
instructions in k-ext/k-ext-64 and sub-extension testcase for zbk* zk*. Also
add testcase for new CSR name 'seed' which is the Entropy Source in zkr.

In fact these whole testcases can be combined into one file, after we have
supported the .option arch +-= directives.

gas/
* testsuite/gas/riscv/k-ext-64.d: New testcase for crypto instructions.
* testsuite/gas/riscv/k-ext-64.s: Likewise.
* testsuite/gas/riscv/k-ext.d: Likewise.
* testsuite/gas/riscv/k-ext.s: Likewise.
* testsuite/gas/riscv/zbkb-32.d: Likewise.
* testsuite/gas/riscv/zbkb-32.s: Likewise.
* testsuite/gas/riscv/zbkb-64.d: Likewise.
* testsuite/gas/riscv/zbkb-64.s: Likewise.
* testsuite/gas/riscv/zbkc-32.d: Likewise.
* testsuite/gas/riscv/zbkc-64.d: Likewise.
* testsuite/gas/riscv/zbkc.s: Likewise.
* testsuite/gas/riscv/zbkx-32.d: Likewise.
* testsuite/gas/riscv/zbkx-64.d: Likewise.
* testsuite/gas/riscv/zbkx.s: Likewise.
* testsuite/gas/riscv/zknd-32.d: Likewise.
* testsuite/gas/riscv/zknd-32.s: Likewise.
* testsuite/gas/riscv/zknd-64.d: Likewise.
* testsuite/gas/riscv/zknd-64.s: Likewise.
* testsuite/gas/riscv/zkne-32.d: Likewise.
* testsuite/gas/riscv/zkne-32.s: Likewise.
* testsuite/gas/riscv/zkne-64.d: Likewise.
* testsuite/gas/riscv/zkne-64.s: Likewise.
* testsuite/gas/riscv/zknh-32.d: Likewise.
* testsuite/gas/riscv/zknh-32.s: Likewise.
* testsuite/gas/riscv/zknh-64.d: Likewise.
* testsuite/gas/riscv/zknh-64.s: Likewise.
* testsuite/gas/riscv/zksed-32.d: Likewise.
* testsuite/gas/riscv/zksed-64.d: Likewise.
* testsuite/gas/riscv/zksed.s: Likewise.
* testsuite/gas/riscv/zksh-32.d: Likewise.
* testsuite/gas/riscv/zksh-64.d: Likewise.
* testsuite/gas/riscv/zksh.s: Likewise.
* testsuite/gas/riscv/priv-reg-fail-zkr.d: New testcase for zkr
csr check.
* testsuite/gas/riscv/priv-reg-fail-zkr.l: Likewise.
* testsuite/gas/riscv/priv-reg-fail-version-1p10.d: Updated march to
rv32if_zkr.
* testsuite/gas/riscv/priv-reg-fail-version-1p11.d: Likewise.
* testsuite/gas/riscv/priv-reg-fail-version-1p9p1.d: Likewise.
* testsuite/gas/riscv/priv-reg-version-1p10.d: Added Crypto seed csr.
* testsuite/gas/riscv/priv-reg-version-1p11.d: Likewise.
* testsuite/gas/riscv/priv-reg-version-1p9p1.d: Likewise.
* testsuite/gas/riscv/priv-reg.s: Likewise.

RISC-V: Scalar crypto instructions and operand set.

Add instructions in k-ext, some instruction in zbkb, zbkc is reuse from
zbb,zbc, we just change the class attribute to make them both support.
The 'aes64ks1i' and 'aes64ks2' instructions are present in both the Zknd
and Zkne extensions on rv64.  Add new operand letter 'y' to present 'bs'
symbol and 'Y' to present 'rnum' symbolc  for zkn instructions.  Also add
a new Entropy Source CSR define 'seed' located at address 0x015.

bfd/
* elfxx-riscv.c (riscv_multi_subset_supports): Added support for
crypto extension.
gas/
*config/tc-riscv.c (enum riscv_csr_class): Added CSR_CLASS_ZKR.
(riscv_csr_address): Checked for CSR_CLASS_ZKR.
(validate_riscv_insn): Added y and Y for bs and rnum operands.
(riscv_ip): Handle y and Y operands.
include/
* opcode/riscv-opc.h: Added encodings of crypto instructions.
Also defined new csr seed, which address is 0x15.
* opcode/riscv.h: Defined OP_* and INSN_CLASS_* for crypto.
opcodes/
* riscv-dis.c (print_insn_args): Recognized new y and Y operands.
* riscv-opc.c (riscv_opcodes): Added crypto instructions.

RISC-V: Minimal support of scalar crypto extension.

Minimal support of scalar crypto extension, add "k" in the
riscv_supported_std_ext, to make the order check right with
"zk" behind "zb".

bfd/
* elfxx-riscv.c (riscv_implicit_subsets): Added implicit
rules for zk* extensions.
(riscv_supported_std_ext): Added entry for k.
(riscv_supported_std_z_ext): Added entries for zk*.

gdb: rework "set debuginfod" commands

As discussed here [1], do some re-work in the "set debuginfod commands".

First, use "set debuginfod enabled on/off/ask" instead of "set
debuginfod on/off/ask".  This is more MI-friendly, and it gives an
output that makes more sense in "info set", for example.

Then, make the show commands not call "error" when debuginfod support is
not compiled in.  This makes the commands "show" and "show debuginfod"
stop early, breaking gdb.base/default.exp:

    Running /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.base/default.exp ...
    FAIL: gdb.base/default.exp: info set
    FAIL: gdb.base/default.exp: show

 - Make the "debuginfod enabled" setting default to "off" when debuginfod
   support is not compiled in, and "ask" otherwise.
 - Make the setter of "debuginfod enabled" error out when debuginfod
   support is not compiled in, so that "debuginfod enabled" will always
   remain "off" in that case.
 - Make the setter of "debuginfod verbose" work in any case.  I don't
   see the harm in letting the user change that setting, since the user will
   hit an error if they try to enable the use of debuginfod.
 - I would do the same for the "debuginfod urls" setter, but because
   this one needs to see the DEBUGINFOD_URLS_ENV_VAR macro, provided by
   libdebuginfod, I made that one error out as well if debuginfod
   support is not compiled it (otherwise, I would have left it like
   "debuginfod verbose".  Alternatively, we could hard-code
   "DEBUGINFOD_URLS" in the code (in fact, it was prior to this patch,
   but I think it was an oversight, as other spots use
   DEBUGINFOD_URLS_ENV_VAR), or use a dummy string to store the setting,
   but I don't really see the value in that.

Rename debuginfod_enable to debuginfod_enabled, just so it matches the
setting name.

[1] https://sourceware.org/pipermail/gdb-patches/2021-October/182937.html

Change-Id: I45fdb2993f668226a5639228951362b7800f09d5
Co-Authored-By: Aaron Merey <amerey@redhat.com>

gdb: adjust gdbarch_tdep calls in nat files

Commit 345bd07cce33 ("gdb: fix gdbarch_tdep ODR violation") forgot to
update the gdbarch_tdep calls in the native files other than x86-64
Linux.  This patch updates them all (to the best of my knowledge).
These are the files I was able to build-test:

  aarch64-linux-nat.c
  amd64-bsd-nat.c
  arm-linux-nat.c
  ppc-linux-nat.c
  windows-nat.c
  xtensa-linux-nat.c

And these are the ones I could not build-test:

  aix-thread.c
  arm-netbsd-nat.c
  ppc-fbsd-nat.c
  ppc-netbsd-nat.c
  ia64-tdep.c (the part that needs libunwind)
  ppc-obsd-nat.c
  rs6000-nat.c

If there are still some build problems related to gdbarch_tdep in them,
they should be pretty obvious to fix.

Change-Id: Iaa3d791a850e4432973757598e634e3da6061428

gdb: remove unused variables in xtensa-linux-nat.c

While build-testing this file, the compiler complained about these two
unused variables, remove them.

Change-Id: I3c54f779f12c16ef6184af58aca75eaad042ce4e

gdb: add arc-newlib-tdep.c to ALL_TARGET_OBS

This file is currently not compiled in an --enable-targets=all build,
but it should be.  Add it to ALL_TARGET_OBS.

Update the gdbarch_tdep call that commit 345bd07cce33 ("gdb: fix
gdbarch_tdep ODR violation") forgot to update.

Change-Id: I86248a01493eea5e70186e9c46a298ad3994b034

Update my email address.

I've left SiFive and have a new gmail account because it is convenient
to use with git send-email.  I'm planning to use this for my RISC-V
work.  My tuliptree address still works, it just isn't as convenient.

binutils:
* MAINTAINERS (RISC-V): Update my address.

Automatic date update in version.in

[gdb] Don't use gdb_stdlog for inferior-events

The test-case gdb.base/foll-vfork.exp contains:
...
if [gdb_debug_enabled] {
    untested "debug is enabled"
    return 0
}
...

To understand what it does, I disabled this bit and ran with GDB_DEBUG=infrun,
like so:
...
$ cd $build/gdb/testsuite
$ make check GDB_DEBUG=infrun RUNTESTFLAGS=gdb.base/foll-vfork.exp
...
and ran into:
...
(gdb) PASS: gdb.base/foll-vfork.exp: exec: \
  vfork parent follow, through step: set follow-fork parent
next^M
33        if (pid == 0) {^M
(gdb) FAIL: gdb.base/foll-vfork.exp: exec: \
  vfork parent follow, through step: step
...

The problem is that the test-case expects:
...
(gdb) PASS: gdb.base/foll-vfork.exp: exec: \
  vfork parent follow, through step: set follow-fork parent
next^M
[Detaching after vfork from child process 28169]^M
33        if (pid == 0) {^M
(gdb) PASS: gdb.base/foll-vfork.exp: exec: \
  vfork parent follow, through step: step
...
but the "Detaching" line has been redirected to
$outputs/gdb.base/foll-vfork/gdb.debug.

I looked at the documentation of "set logging debugredirect [on|off]":
...
  By default, GDB debug output will go to both the terminal and the logfile.
  Set debugredirect if you want debug output to go only to the log file.
...
and my interpretation of it was that "debug output" did not match the
"messages" description of inferior-events:
...
The set print inferior-events command allows you to enable or disable printing
of messages when GDB notices that new inferiors have started or that inferiors
have exited or have been detached.
...

Fix the discrepancy by not using gdb_stdlog for inferior-events.

Update the gdb.base/foll-vfork.exp test-case to not require
gdb_debug_enabled == 0.

Tested on x86_64-linux.

Tested test-case gdb.base/foll-vfork.exp with and without GDB_DEBUG=infrun.

ld: Fix testsuite failures under --enable-textrel-check=error

ld/
* testsuite/ld-aarch64/dt_textrel.d: Pass explicit -z notext in
case ld was configured with --enable-textrel-check=error.
* testsuite/ld-aarch64/pr22764.d: Likewise.
* testsuite/ld-aarch64/pr20402.d: Likewise.

Extend the prologue analyzer to handle the bti instruction

Handle the BTI instruction in the prologue analyzer. The patch handles all
the variations of the BTI instruction.

gdb: fix gdbarch_tdep ODR violation

I would like to be able to use non-trivial types in gdbarch_tdep types.
This is not possible at the moment (in theory), because of the one
definition rule.

To allow it, rename all gdbarch_tdep types to <arch>_gdbarch_tdep, and
make them inherit from a gdbarch_tdep base class.  The inheritance is
necessary to be able to pass pointers to all these <arch>_gdbarch_tdep
objects to gdbarch_alloc, which takes a pointer to gdbarch_tdep.

These objects are never deleted through a base class pointer, so I
didn't include a virtual destructor.  In the future, if gdbarch objects
deletable, I could imagine that the gdbarch_tdep objects could become
owned by the gdbarch objects, and then it would become useful to have a
virtual destructor (so that the gdbarch object can delete the owned
gdbarch_tdep object).  But that's not necessary right now.

It turns out that RISC-V already has a gdbarch_tdep that is
non-default-constructible, so that provides a good motivation for this
change.

Most changes are fairly straightforward, mostly needing to add some
casts all over the place.  There is however the xtensa architecture,
doing its own little weird thing to define its gdbarch_tdep.  I did my
best to adapt it, but I can't test those changes.

Change-Id: Ic001903f91ddd106bd6ca09a79dabe8df2d69f3b

COFF: avoid modifications over C_FILE filename aux entries.

Commit e86fc4a5bc37 ("PR 28447: implement multiple parameters for .file
on XCOFF") introduces C_FILE entries which can store additional
information.
However, some modifications are needed by them but not by the original
C_FILE entries, usually representing the filename.
This patch ensures that filename entries are kept as is, in order to
protect targets not supporting the additional entries.

* coffgen.c (coff_write_symbol): Protect filename entries
(coff_write_symbols): Likewise.
(coff_print_symbol): Likewise.

Deal with full path in .file 0 directive

Gas uses the directory part, if present, of the .file 0 directive to set
entry 0 of the directory table in DWARF 5, which represents the "current
directory".

Now Gas also uses the file part of the same directive to set entry 0 of the
file table, which represents the "current compilation file".  But the latter
need not be located in the former so GCC will use a full path in the file
part when it is passed a full path:

gcc -c /full/path/test.c -save-temps

yields:

 .file 0 "/current/directory" "/full/path/test.c"

in the assembly file and:

 The Directory Table (offset 0x22, lines 2, columns 1):
  Entry Name
  0     (indirect line string, offset: 0x25): /current/directory
  1     (indirect line string, offset: 0x38): /full/path

 The File Name Table (offset 0x30, lines 2, columns 2):
  Entry Dir     Name
  0     0       (indirect line string, offset: 0x43): /full/path/test.c

in the object file.  Note the full path and the questionable Dir value in
the 0 entry of the file table.

sim: cris: make error message test a little more flexible

The point of this test is to just make sure the usage text is shown,
not the exact details of the usage text.  So shorten the output test
to match the beginning.  This fixes breakage when the output changed
slightly to include [--].

sim: run: fix crash in argc==0 error situation

The new argv processing code assumed that we were always passed a
command line.  If we weren't, make sure we don't crash before we
get a chance to output an error message about incorrect usage.

sim: cris: touch up rvdummy handling

Add quiet build support and make sure it's removed with `make clean`.

sim: cris: replace custom "dest" test field with new --argv0

The #dest field used in the cris testsuite is a bit of hack to set the
argv[0] for the tests to read out later on.  Now that the sim has an
option to set argv[0] explicitly, we don't need this custom field, so
let's drop it to harmonize the testsuites a little.

sim: run: add --argv0 option to control argv[0]

We default argv[0] to the program we run which is a standard *NIX
convention, but sometimes we want to be able to control the argv[0]
setting independently (especially for programs that inspect argv[0]
to change their behavior or output).  Add an option to control it.

sim: split program path out of argv vector

We use the program argv to both find the program to run (argv[0]) and
to hold the arguments to the program.  Most of the time this is fine,
but if we want to let programs specify argv[0] independently (which is
possible in standard *NIX programs), this double duty doesn't work.

So let's split the path to the program to run out into a separate
field by itself.  This simplifies the various sim_open funcs too.

By itself, this code is more of a logical cleanup than something that
is super useful.  But it will open up customization of argv[0] in a
follow up commit.  Split the changes to make it easier to review.

sim: bfin: fix mach/xfail usage in tests

Set the mach to the right value all the time, and update xfail to
say the test fails on all targets.  WIth multitarget testing, the
idea of target here doesn't make much sense.

-Waddress fixes for gold testsuite

Current mainline gcc.
common_test_1.c: In function 'main':
common_test_1.c:56:14: error: comparison between two arrays [-Werror=array-compare]
   56 |   assert (c5 > c4);
      |              ^
common_test_1.c:56:14: note: use '&c5[0] > &c4[0]' to compare the addresses

* testsuite/common_test_1.c: Avoid -Waddress warnings.
* testsuite/common_test_1_v1.c: Likewise.
* testsuite/common_test_1_v2.c: Likewise.
* testsuite/script_test_2.cc: Likewise.

PowerPC64 @notoc in non-power10 code

R_PPC64_REL24_P9NOTOC is a variant of R_PPC64_REL24_NOTOC for use on
@notoc cals from non-power10 code in the rare case that using such a
construct is useful.  R_PPC64_REL24_P9NOTOC will be emitted by gas
rather than R_PPC64_REL24_NOTOC when @notoc is used in a branch
instruction if power10 instructions are not enabled at that point.
The new relocation tells the linker to not use power10 instructions on
any stub emitted for that branch, unless overridden by
--power10-stubs=yes.

The current linker heuristic of only generating power10 instructions
for stubs if power10-only relocations are detected, continues to be
used.

include/
* elf/ppc64.h (R_PPC64_REL24_P9NOTOC): Define.
bfd/
* reloc.c (BFD_RELOC_PPC64_REL24_P9NOTOC): Define.
* elf64-ppc.c (ppc64_elf_howto_raw): Add entry for new reloc.
(ppc64_elf_reloc_type_lookup): Handle it.
(enum ppc_stub_type): Delete.
(enum ppc_stub_main_type, ppc_stub_sub_type): New.
(struct ppc_stub_type): New.
(struct ppc_stub_hash_entry): Use the above new type.
(struct ppc_link_hash_table): Update stub_count.
(is_branch_reloc, ppc64_elf_check_relocs),
(toc_adjusting_stub_needed): Handle new reloc.
(stub_hash_newfunc, select_alt_stub, ppc_merge_stub),
(ppc_type_of_stub, plt_stub_size, build_plt_stub),
(build_tls_get_addr_head, build_tls_get_addr_tail),
(ppc_build_one_stub, ppc_size_one_stub, ppc64_elf_size_stubs),
(ppc64_elf_build_stubs, ppc64_elf_relocate_section): Handle new
reloc.  Modify stub handling to suit new scheme.
* bfd-in2.h: Regenerate.
* libbfd.h: Regenerate.
gas/
* config/tc-ppc.c (ppc_elf_suffix): When power10 is not enabled
return BFD_RELOC_PPC64_REL24_P9NOTOC for @notoc.
(fixup_size, ppc_force_relocation, ppc_fix_adjustable): Handle
BFD_RELOC_PPC64_REL24_P9NOTOC.
ld/
* testsuite/ld-powerpc/callstub-2.s: Add .machine power10.

Regenerate a couple of files

A couple of files changed on my latest --enable-maintainer-mode
build.  ld/Makefile.in had a missing dependency but better sorting of
the loongson entries.

intl/
* configure: Regenerate.
ld/
* Makefile.am: Sort loongson entries.
* Makefile.in: Regenerate.

Fix build with current GCC: EL_EXPLICIT(location) always non-NULL

Compiling GDB with current GCC (1b4a63593b) runs into this:

  src/gdb/location.c: In function 'int event_location_empty_p(const event_location*)':
  src/gdb/location.c:963:38: error: the address of 'event_location::<unnamed union>::explicit_loc' will never be NULL [-Werror=address]
    963 |       return (EL_EXPLICIT (location) == NULL
|                                      ^
  src/gdb/location.c:57:30: note: 'event_location::<unnamed union>::explicit_loc' declared here
     57 |     struct explicit_location explicit_loc;
|                              ^~~~~~~~~~~~

GCC is right, EL_EXPLICIT is defined as returning the address of an
union field:

      /* An explicit location.  */
      struct explicit_location explicit_loc;
  #define EL_EXPLICIT(P) (&((P)->u.explicit_loc))

and thus must always be non-NULL.

Change-Id: Ie74fee7834495a93affcefce03c06e4d83ad8191

Automatic date update in version.in

[PR gdb/16238] Add completer for the show user command

The 'show user' command (which shows the definition of non-python/scheme
user defined commands) is currently missing a completer. This is
mentioned in PR 16238.  Having one can improve the user experience.

In this commit I propose an implementation for such completer as well as
the associated tests.

Tested on x86_64 GNU/Linux.

All feedbacks are welcome.

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

sync libbacktrace from gcc

Automatic date update in version.in

Sync Makefile.tpl with GCC

* Makefile.tpl: Sync with GCC.
* Makefile.in: Regenerate.

sim: sh: fix switch-bool warnings

This code triggers -Werror=switch-bool warnings with <=gcc-5 versions.
Rework it to use if statements instead as it also simplifies a bit.

sim: sh: rework carry checks to not rely on integer overflows

In <=gcc-7 versions, -fstrict-overflow is enabled by default, and that
triggers warnings in this code that relies on integer overflows to test
for carries.  Change the logic to test against the limit directly.

Automatic date update in version.in

Fix gdb.base/sigstep.exp test for ppc

The test stops at <signal_handler called> which is the call to the handler
rather than in the handler as intended.  This patch replaces the
gdb_test "$enter_cmd to handler" with a gdb_test_multiple test.  The multiple
test looks for the stop at <signal_handler called>.  If found, the command
is issued again.  The test passes if gdb stops in the handler as expected.

(gdb) PASS: gdb.base/sigstep.exp: stepi to handler, nothing in handler, step
from handler: continue to signal
stepi
<signal handler called>
1: x/i $pc
=> 0x7ffff7f80440 <__kernel_start_sigtramp_rt64>:       bctrl
(gdb) stepi
handler (sig=551) at sigstep.c:32
32      {
1: x/i $pc
=> 0x10000097c <handler>:       addis   r2,r12,2
(gdb) PASS: gdb.base/sigstep.exp: stepi to handler, nothing in handler,
step from handler: stepi to handler

Patch has been tested on x86_64-linux and ppc64le-linux with no test failures.

[gdb/testsuite] Fix regexp in gdb.base/foll-vfork.exp

On OBS I ran into:
...
(gdb) PASS: gdb.base/foll-vfork.exp: exit: \
  vfork relations in info inferiors: continue to child exit
info inferiors^M
  Num  Description       Connection           Executable        ^M
  1    <null>                                 foll-vfork-exit ^M
* 2    <null>                                 foll-vfork-exit ^M
(gdb) I'm the proud parent of child #5044!^M
FAIL: gdb.base/foll-vfork.exp: exit: vfork relations in info inferiors: \
  vfork relation no longer appears in info inferiors (timeout)
...

Fix this by removing the '$' anchor in the corresponding '$gdb_prompt $'
regexps.

Tested on x86_64-linux.

Don't compile some opcodes files when bfd is 32-bit only

* Makefile.am (TARGET_LIBOPCODES_CFILES): Split into..
(TARGET64_LIBOPCODES_CFILES): ..this and..
(TARGET32_LIBOPCODES_CFILES): ..this.
(ALL_MACHINES): Likewise split to
(ALL64_MACHINES, ALL32_MACHINES): ..this.
* disassemble.c: Define some ARCH_* when ARCH_all only if BFD64.
* configure.ac (BFD_MACHINES): Defined depending on BFD_ARCH_SIZE.
* Makefile.in: Regenerate.
* configure: Regenerate.

Import Makefile.def from gcc

* Makefile.def: Import from gcc.
* Makefile.in: Regenerate.

Fix demangle style usage info

Extract allowed styles from libiberty, so we don't have to worry about
our help messages getting out of date.  The function probably belongs
in libiberty/cplus-dem.c but it can be here for a while to iron out
bugs.

PR 28581
* demanguse.c: New file.
* demanguse.h: New file.
* nm.c (usage): Break up output.  Use display_demangler_styles.
* objdump.c (usage): Use display_demangler_styles.
* readelf.c (usage): Likewise.
* Makefile.am: Add demanguse.c and demanguse.h.
* Makefile.in: Regenerate.
* po/POTFILESin: Regenerate.

Automatic date update in version.in

gdb: fix "set scheduler-locking" thread exit hang

GDB hangs when doing this:

 - launch inferior with multiple threads
 - multiple threads hit some breakpoint(s)
 - one breakpoint hit is presented as a stop, the rest are saved as
   pending wait statuses
 - "set scheduler-locking on"
 - resume the currently selected thread (because of scheduler-locking,
   it's the only one resumed), let it execute until exit
 - GDB hangs, not showing the prompt, impossible to interrupt with ^C

When the resumed thread exits, we expect the target to return a
TARGET_WAITKIND_NO_RESUMED event, and that's what we see:

    [infrun] fetch_inferior_event: enter
      [infrun] scoped_disable_commit_resumed: reason=handling event
      [infrun] random_pending_event_thread: None found.
    [Thread 0x7ffff7d9c700 (LWP 309357) exited]
      [infrun] print_target_wait_results: target_wait (-1.0.0 [process -1], status) =
      [infrun] print_target_wait_results:   -1.0.0 [process -1],
      [infrun] print_target_wait_results:   status->kind = no-resumed
      [infrun] handle_inferior_event: status->kind = no-resumed
      [infrun] handle_no_resumed: TARGET_WAITKIND_NO_RESUMED (ignoring: found resumed)
      [infrun] prepare_to_wait: prepare_to_wait
      [infrun] reset: reason=handling event
      [infrun] maybe_set_commit_resumed_all_targets: not requesting commit-resumed for target native, no resumed threads
    [infrun] fetch_inferior_event: exit

The problem is in handle_no_resumed: we check if some other thread is
actually resumed, to see if we should ignore that event (see comments in
that function for more info).  If this condition is true:

    (thread->executing () || thread->has_pending_waitstatus ())

... then we ignore the event.  The problem is that there are some non-resumed
threads with a pending event, which makes us ignore the event.  But these
threads are not resumed, so we end up waiting while nothing executes, hence
waiting for ever.

My first fix was to change the condition to:

    (thread->executing ()
     || (thread->resumed () && thread->has_pending_waitstatus ()))

... but then it occured to me that we could simply check for:

    (thread->resumed ())

Since "executing" implies "resumed", checking simply for "resumed"
covers threads that are resumed and executing, as well as threads that
are resumed with a pending status, which is what we want.

Change-Id: Ie796290f8ae7f34c026ca3a8fcef7397414f4780

[gdb/build] Fix Wimplicit-exception-spec-mismatch in clang build

When building with clang 13 (and -std=gnu++17 to work around an issue in
string_view-selftests.c), we run into a few Wimplicit-exception-spec-mismatch
warnings:
...
src/gdbsupport/new-op.cc:102:1: error: function previously declared with an \
  explicit exception specification redeclared with an implicit exception \
  specification [-Werror,-Wimplicit-exception-spec-mismatch]
operator delete (void *p)
^
/usr/include/c++/11/new:130:6: note: previous declaration is here
void operator delete(void*) _GLIBCXX_USE_NOEXCEPT
     ^
...

These are due to recent commit 5fff6115fea "Fix
LD_PRELOAD=/usr/lib64/libasan.so.6 gdb".

Fix this by adding the missing noexcept.

Build on x86_64-linux, using gcc 7.5.0 and clang 13.0.0.

[gdb/build] Fix build with -std=c++11

When building with -std=c++11, we run into two Werror=missing-declarations:
...
new-op.cc: In function 'void operator delete(void*, std::size_t)':
new-op.cc:114:1: error: no previous declaration for \
  'void operator delete(void*, std::size_t)' [-Werror=missing-declarations]
 operator delete (void *p, std::size_t) noexcept
 ^~~~~~~~
new-op.cc: In function 'void operator delete [](void*, std::size_t)':
new-op.cc:132:1: error: no previous declaration for \
  'void operator delete [](void*, std::size_t)' [-Werror=missing-declarations]
 operator delete[] (void *p, std::size_t) noexcept
 ^~~~~~~~
...

These are due to recent commit 5fff6115fea "Fix
LD_PRELOAD=/usr/lib64/libasan.so.6 gdb".

The declarations are provided by <new> (which is included) for c++14 onwards,
but they are missing for c++11.

Fix this by adding the missing declarations.

Tested on x86_64-linux, with gcc 7.5.0, both without (implying -std=gnu++14) and
with -std=c++11.

[gdb/testsuite] Add gdb.arch/ppc64-break-on-_exit.exp

Add a regression test-case for commit a50bdb99afe "[gdb/tdep, rs6000] Don't
skip system call in skip_prologue":
- set a breakpoint on a local copy of glibc's _exit, and
- verify that it triggers.

The test-case uses an assembly file by default, but also has the possibility
to use a C source file instead.

Tested on ppc64le-linux.  Verified that the test-case fails without
aforementioned commit, and passes with the commit.  Both with assembly
and C source.

RISC-V: Dump objects according to the elf architecture attribute.

For now we should always generate the elf architecture attribute both for
elf and linux toolchains, so that we could dump the objects correctly
according to the generated architecture string.  This patch resolves the
problem that we probably dump an object with c.nop instructions, but
in fact the c extension isn't allowed.  Consider the following case,

nelson@LAPTOP-QFSGI1F2:~/test$ cat temp.s
.option norvc
.option norelax
.text
add     a0, a0, a0
.byte   0x1
.balign 16
nelson@LAPTOP-QFSGI1F2:~/test$ ~/binutils-dev/build-elf32-upstream/build-install/bin/riscv32-unknown-elf-as temp.s -o temp.o
nelson@LAPTOP-QFSGI1F2:~/test$ ~/binutils-dev/build-elf32-upstream/build-install/bin/riscv32-unknown-elf-objdump -d temp.o

temp.o:     file format elf32-littleriscv

Disassembly of section .text:

00000000 <.text>:
   0:   00a50533                add     a0,a0,a0
   4:   01                      .byte   0x01
   5:   00                      .byte   0x00
   6:   0001                    nop
   8:   00000013                nop
   c:   00000013                nop
nelson@LAPTOP-QFSGI1F2:~/test$ ~/binutils-dev/build-elf32-upstream/build-install/bin/riscv32-unknown-elf-readelf -A temp.o
Attribute Section: riscv
File Attributes
  Tag_RISCV_arch: "rv32i2p0_m2p0_a2p0_f2p0_d2p0"

The c.nop at address 0x6 is generated for alignment, but since the rvc isn't
allowed for this object, dump it as a c.nop instruction looks wrong.  After
applying this patch, I get the following result,

nelson@LAPTOP-QFSGI1F2:~/test$ ~/binutils-dev/build-elf32-upstream/build-install/bin/riscv32-unknown-elf-objdump -d temp.o

temp.o:     file format elf32-littleriscv

Disassembly of section .text:

00000000 <.text>:
   0:   00a50533                add     a0,a0,a0
   4:   01                      .byte   0x01
   5:   00                      .byte   0x00
   6:   0001                    .2byte  0x1
   8:   00000013                nop
   c:   00000013                nop

For the current objdump, we dump data to .byte/.short/.word/.dword, and
dump the unknown or unsupported instructions to .2byte/.4byte/.8byte, which
respectively are 2, 4 and 8 bytes instructions.  Therefore, we shouldn't
dump the 0x0001 as a c.nop instruction in the above case, we should dump
it to .2byte 0x1 as a unknown instruction, since the rvc is disabled.

However, consider that some people may use the new objdump to dump the old
objects, which don't have any elf attributes.  We usually set the default
architecture string to rv64g by bfd/elfxx-riscv.c:riscv_set_default_arch.
But this will cause rvc instructions to be unrecognized.  Therefore, we
set the default architecture string to rv64gc for disassembler, to keep
the previous behavior.

This patch pass the riscv-gnu-toolchain gcc/binutils regressions for
rv32emc-elf, rv32gc-linux, rv32i-elf, rv64gc-elf and rv64gc-linux
toolchains.  Also, tested by --enable-targets=all and can build
riscv-gdb successfully.

bfd/
* elfnn-riscv.c (riscv_merge_arch_attr_info): Tidy the
codes for riscv_parse_subset_t setting.
* elfxx-riscv.c (riscv_get_default_ext_version): Updated.
(riscv_subset_supports): Moved from gas/config/tc-riscv.c.
(riscv_multi_subset_supports): Likewise.
* elfxx-riscv.h: Added extern for riscv_subset_supports and
riscv_multi_subset_supports.
gas/
* config/tc-riscv.c (riscv_subset_supports): Moved to
bfd/elfxx-riscv.c.
(riscv_multi_subset_supports): Likewise.
(riscv_rps_as): Defined for architectrue parser.
(riscv_set_arch): Updated.
(riscv_set_abi_by_arch): Likewise.
(riscv_csr_address): Likewise.
(reg_lookup_internal): Likewise.
(riscv_ip): Likewise.
(s_riscv_option): Updated.
* testsuite/gas/riscv/mapping-04b.d: Updated.
* testsuite/gas/riscv/mapping-norelax-03b.d: Likewise.
* testsuite/gas/riscv/mapping-norelax-04b.d: Likewise.
opcodes/
* riscv-dis.c: Include elfxx-riscv.h since we need the
architecture parser.  Also removed the cpu-riscv.h, it
is already included in elfxx-riscv.h.
(default_isa_spec): Defined since the parser need this
to set the default architecture string.
(xlen): Moved out from riscv_disassemble_insn as a global
variable, it is more convenient to initialize riscv_rps_dis.
(riscv_subsets): Defined to recoed the supported
extensions.
(riscv_rps_dis): Defined for architectrue parser.
(riscv_disassemble_insn): Call riscv_multi_subset_supports
to make sure if the instructions are valid or not.
(print_insn_riscv): Initialize the riscv_subsets by parsing
the elf architectrue attribute.  Otherwise, set the default
architectrue string to rv64gc.

sim: testsuite: drop sim_compile cover function

Most code isn't using this, and the only call site (in one cris file)
can use target_compile directly.  So switch it over to simplify.

sim: cris: stop testing a.out explicitly [ld/13900]

Since gcc dropped support for a.out starting with 4.4.0 in 2009, it's
been impossible to verify this code actually still works.  Since it
crashes in ld, and it uses a config option that no other tests uses
and we want to remove, drop the test to avoid all the trouble.

sim: io: tweak compiler workaround with error output

Outputting an extra space broke a cris test.  Change the workaround
to use %s with an empty string to avoid the compiler warning but not
output an extra space.

sim: testsuite: delete unused arm remote host logic

There's no need to sync testutils.inc with remote hosts.  The one
we have in the source tree is all we need and only thing we test.
Delete it to simplify.

sim: synacor: simplify test generation

Objcopy was used to create a binary file of just the executable code
since the environment requires code to based at address 0.  We can
accomplish the same thing with the -Ttext=0 flag, so switch to that
to get rid of custom logic.

Automatic date update in version.in

Handle PIE in .debug_loclists

Simon pointed out that my recent patches to .debug_loclists caused
some regressions.  After a brief discussion we realized it was because
his system compiler defaults to PIE.

This patch changes this code to unconditionally apply the text offset
here.  It also changes loclist_describe_location to work more like
dwarf2_find_location_expression.

I tested this by running the gdb.dwarf2 tests both with and without
-pie.

arm: enable Cortex-A710 CPU

This patch is adding support for Cortex-A710 CPU in Arm.

bfd/

* cpu-arm.c (processors): Add cortex-a710.

gas/

* NEWS: Update docs.
* config/tc-arm.c (arm_cpus): Add cortex-a710 to -mcpu.
* doc/c-arm.texi: Update docs.
* testsuite/gas/arm/cpu-cortex-a710.d: New test.

gdb: adjust x_file fields on COFF readers

Commit e86fc4a5bc37 ("PR 28447: implement multiple parameters for .file
on XCOFF") changes the structure associated to the internal
representation of files in COFF formats.  However, gdb directory update
has been forgotten, leading to compilation errors of this kind:

      CXX    coffread.o
    /home/simark/src/binutils-gdb/gdb/coffread.c: In function 'const char* coff_getfilename(internal_auxent*)':
    /home/simark/src/binutils-gdb/gdb/coffread.c:1343:29: error: 'union internal_auxent::<unnamed struct>::<unnamed>' has no member named 'x_zeroes'
     1343 |   if (aux_entry->x_file.x_n.x_zeroes == 0)
          |                             ^~~~~~~~

Fix it by adjusting the COFF code in GDB.

Change-Id: I703fa134bc722d47515efbd72b88fa5650af6c3c

[gdb/testsuite] Add gdb.opt/break-on-_exit.exp

Add a test-case to excercise the problem scenario reported in PR28527 and
fixed in commit a50bdb99afe "[gdb/tdep, rs6000] Don't skip system call in
skip_prologue":
- set a breakpoint on _exit, and
- verify that it triggers.

Note that this is not a regression test for that commit.  Since the actual
code in _exit may vary across os instances, we cannot guarantee that the
problem will always trigger with this test-case.

Rather, this test-case is a version of the original test-case
(gdb.threads/process-dies-while-detaching.exp) that is minimal while still
reproducing the problem reported in PR28527, in that same setting.

The benefit of this test-case is that it exercise real-life code and may
expose similar problems in other settings.  Also, it provides a much easier
test-case to investigate in case a similar problem occurs.

Tested on x86_64-linux and ppc64le-linux.

sim: frv: flip trapdump default back to off

When I refactored this by scoping it to sim-frv-xxx in commit
e7954ef5e5ed90fb7d28c013518f4c2e6bcd20a1 ("sim: frv: scope the
unique configure flag"), I changed the default from off to on.
While the feature is nice for developers, it breaks a bunch of
tests which aren't expecting this extra output.  So flip it back
to off by default.

PR28575, readelf.c and strings.c use undefined type uint

Since --unicode support (commit b3aa80b45c4) both binutils/readelf.c
and binutils/strings.c use 'uint' in a few locations.  It likely
should be 'unsigned int' since there isn't anything defining 'uint'
within binutils (besides zlib) and AFAIK it isn't a standard type.

* readelf.c (print_symbol): Replace uint with unsigned int.
* strings.c (string_min, display_utf8_char): Likewise.
(print_unicode_stream_body, print_unicode_stream): Likewise.
(print_strings): Likewise.
(get_unicode_byte): Wrap long line.

ld: set correct flags for AIX shared tests

Previous flags were aimed to be run with XLC.
Nowadays, only GCC is being tested with GNU toolchain. Moreover,
recent XLC versions might also accept "-shared".

* testsuite/ld-shared/shared.exp: Adjust shared flags.

PR 28447: implement multiple parameters for .file on XCOFF

On XCOFF, ".file" pseudo-op allows 3 extras parameters to provide
additional information to AIX linker, or its debugger. These are
stored in auxiliary entries of the C_FILE symbol.

bfd/
PR 28447
* coffcode.h (combined_entry_type): Add extrap field.
(coff_bigobj_swap_aux_in): Adjust names of x_file fields.
(coff_bigobj_swap_aux_out): Likewise.
* coffgen.c (coff_write_auxent_fname): New function.
(coff_fix_symbol_name): Write x_file using
 coff_write_auxent_fname.
(coff_write_symbol): Likewise.
(coff_write_symbols): Add C_FILE auxiliary entries to
string table if needed.
(coff_get_normalized_symtab): Adjust names of x_file fields.
Normalize C_FILE auxiliary entries.
(coff_print_symbol): Print C_FILE auxiliary entries.
* coff-rs6000.c (_bfd_xcoff_swap_aux_in): Adjust names of
x_file fields.
(_bfd_xcoff_swap_aux_out): Likewise.
* coff64-rs6000.c (_bfd_xcoff64_swap_aux_in): Likewise.
(_bfd_xcoff64_swap_aux_out): Likewise.
* cofflink.c (_bfd_coff_final_link): Likewise.
(_bfd_coff_link_input_bfd): Likewise.
* coffswap.h (coff_swap_aux_in): Likewise.
* peXXigen.c (_bfd_XXi_swap_aux_in): Likewise.
(_bfd_XXi_swap_aux_out): Likewise.
* xcofflink.c (xcoff_link_input_bfd): Likewise.
* libcoff.h: Regenerate.
gas/
* config/tc-ppc.c (ppc_file): New function.
* config/tc-ppc.h (OBJ_COFF_MAX_AUXENTRIES): Change to 4.
* testsuite/gas/ppc/aix.exp: Add tests.
* testsuite/gas/ppc/xcoff-file-32.d: New test.
* testsuite/gas/ppc/xcoff-file-64.d: New test.
* testsuite/gas/ppc/xcoff-file.s: New test.
include/
* coff/internal.h (union internal_auxent): Change x_file to be a
  struct instead of a union. Add x_ftype field.
* coff/rs6000.h (union external_auxent): Add x_resv field.
* coff/xcoff.h (XFT_FN): New define.
(XFT_CT): Likewise.
(XFT_CV): Likewise.
(XFT_CD): Likewise.

Test case for Bug 28308

The purpose of this test is described in the comments in
dprintf-execution-x-script.exp.

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

The name of this new test was based on that of an existing test,
bp-cmds-execution-x-script.exp.  I started off by copying that test,
adding to it, and then rewriting almost all of it.  It's different
enough that I decided that listing the copyright year as 2021
was sufficient.

Fix PR 28308 - dprintf breakpoints not working when run from script

This commit fixes Bug 28308, titled "Strange interactions with
dprintf and break/commands":

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

Since creating that bug report, I've found a somewhat simpler way of
reproducing the problem.  I've encapsulated it into the GDB test case
which I've created along with this bug fix.  The name of the new test
is gdb.base/dprintf-execution-x-script.exp, I'll demonstrate the
problem using this test case, though for brevity, I've placed all
relevant files in the same directory and have renamed the files to all
start with 'dp-bug' instead of 'dprintf-execution-x-script'.

The script file, named dp-bug.gdb, consists of the following commands:

dprintf increment, "dprintf in increment(), vi=%d\n", vi
break inc_vi
commands
  continue
end
run

Note that the final command in this script is 'run'.  When 'run' is
instead issued interactively, the  bug does not occur.  So, let's look
at the interactive case first in order to see the correct/expected
output:

$ gdb -q -x dp-bug.gdb dp-bug
... eliding buggy output which I'll discuss later ...
(gdb) run
Starting program: /mesquite2/sourceware-git/f34-master/bld/gdb/tmp/dp-bug
vi=0
dprintf in increment(), vi=0

Breakpoint 2, inc_vi () at dprintf-execution-x-script.c:26
26 in dprintf-execution-x-script.c
vi=1
dprintf in increment(), vi=1

Breakpoint 2, inc_vi () at dprintf-execution-x-script.c:26
26 in dprintf-execution-x-script.c
vi=2
dprintf in increment(), vi=2

Breakpoint 2, inc_vi () at dprintf-execution-x-script.c:26
26 in dprintf-execution-x-script.c
vi=3
[Inferior 1 (process 1539210) exited normally]

In this run, in which 'run' was issued from the gdb prompt (instead
of at the end of the script), there are three dprintf messages along
with three 'Breakpoint 2' messages.  This is the correct output.

Now let's look at the output that I snipped above; this is the output
when 'run' is issued from the script loaded via GDB's -x switch:

$ gdb -q -x dp-bug.gdb dp-bug
Reading symbols from dp-bug...
Dprintf 1 at 0x40116e: file dprintf-execution-x-script.c, line 38.
Breakpoint 2 at 0x40113a: file dprintf-execution-x-script.c, line 26.
vi=0
dprintf in increment(), vi=0

Breakpoint 2, inc_vi () at dprintf-execution-x-script.c:26
26 dprintf-execution-x-script.c: No such file or directory.
vi=1

Breakpoint 2, inc_vi () at dprintf-execution-x-script.c:26
26 in dprintf-execution-x-script.c
vi=2

Breakpoint 2, inc_vi () at dprintf-execution-x-script.c:26
26 in dprintf-execution-x-script.c
vi=3
[Inferior 1 (process 1539175) exited normally]

In the output shown above, only the first dprintf message is printed.
The 2nd and 3rd dprintf messages are missing!  However, all three
'Breakpoint 2...' messages are still printed.

Why does this happen?

bpstat_do_actions_1() in gdb/breakpoint.c contains the following
comment and code near the start of the function:

  /* Avoid endless recursion if a `source' command is contained
     in bs->commands.  */
  if (executing_breakpoint_commands)
    return 0;

  scoped_restore save_executing
    = make_scoped_restore (&executing_breakpoint_commands, 1);

Also, as described by this comment prior to the 'async' field
in 'struct ui' in top.h, the main UI starts off in sync mode
when processing command line arguments:

  /* True if the UI is in async mode, false if in sync mode.  If in
     sync mode, a synchronous execution command (e.g, "next") does not
     return until the command is finished.  If in async mode, then
     running a synchronous command returns right after resuming the
     target.  Waiting for the command's completion is later done on
     the top event loop.  For the main UI, this starts out disabled,
     until all the explicit command line arguments (e.g., `gdb -ex
     "start" -ex "next"') are processed.  */

This combination of things, the state of the static global
'executing_breakpoint_commands' plus the state of the async
field in the main UI causes this behavior.

This is a backtrace after hitting the dprintf breakpoint for
the second time when doing 'run' from the script file, i.e.
non-interactively:

Thread 1 "gdb" hit Breakpoint 3, bpstat_do_actions_1 (bsp=0x7fffffffc2b8)
    at /ironwood1/sourceware-git/f34-master/bld/../../worktree-master/gdb/breakpoint.c:4431
4431   if (executing_breakpoint_commands)

 #0  bpstat_do_actions_1 (bsp=0x7fffffffc2b8)
     at gdb/breakpoint.c:4431
 #1  0x00000000004d8bc6 in dprintf_after_condition_true (bs=0x1538090)
     at gdb/breakpoint.c:13048
 #2  0x00000000004c5caa in bpstat_stop_status (aspace=0x116dbc0, bp_addr=0x40116e, thread=0x137f450, ws=0x7fffffffc718,
     stop_chain=0x1538090) at gdb/breakpoint.c:5498
 #3  0x0000000000768d98 in handle_signal_stop (ecs=0x7fffffffc6f0)
     at gdb/infrun.c:6172
 #4  0x00000000007678d3 in handle_inferior_event (ecs=0x7fffffffc6f0)
     at gdb/infrun.c:5662
 #5  0x0000000000763cd5 in fetch_inferior_event ()
     at gdb/infrun.c:4060
 #6  0x0000000000746d7d in inferior_event_handler (event_type=INF_REG_EVENT)
     at gdb/inf-loop.c:41
 #7  0x00000000007a702f in handle_target_event (error=0, client_data=0x0)
     at gdb/linux-nat.c:4207
 #8  0x0000000000b8cd6e in gdb_wait_for_event (block=block@entry=0)
     at gdbsupport/event-loop.cc:701
 #9  0x0000000000b8d032 in gdb_wait_for_event (block=0)
     at gdbsupport/event-loop.cc:597
 #10 gdb_do_one_event () at gdbsupport/event-loop.cc:212
 #11 0x00000000009d19b6 in wait_sync_command_done ()
     at gdb/top.c:528
 #12 0x00000000009d1a3f in maybe_wait_sync_command_done (was_sync=0)
     at gdb/top.c:545
 #13 0x00000000009d2033 in execute_command (p=0x7fffffffcb18 "", from_tty=0)
     at gdb/top.c:676
 #14 0x0000000000560d5b in execute_control_command_1 (cmd=0x13b9bb0, from_tty=0)
     at gdb/cli/cli-script.c:547
 #15 0x000000000056134a in execute_control_command (cmd=0x13b9bb0, from_tty=0)
     at gdb/cli/cli-script.c:717
 #16 0x00000000004c3bbe in bpstat_do_actions_1 (bsp=0x137f530)
     at gdb/breakpoint.c:4469
 #17 0x00000000004c3d40 in bpstat_do_actions ()
     at gdb/breakpoint.c:4533
 #18 0x00000000006a473a in command_handler (command=0x1399ad0 "run")
     at gdb/event-top.c:624
 #19 0x00000000009d182e in read_command_file (stream=0x113e540)
     at gdb/top.c:443
 #20 0x0000000000563697 in script_from_file (stream=0x113e540, file=0x13bb0b0 "dp-bug.gdb")
     at gdb/cli/cli-script.c:1642
 #21 0x00000000006abd63 in source_gdb_script (extlang=0xc44e80 <extension_language_gdb>, stream=0x113e540,
     file=0x13bb0b0 "dp-bug.gdb") at gdb/extension.c:188
 #22 0x0000000000544400 in source_script_from_stream (stream=0x113e540, file=0x7fffffffd91a "dp-bug.gdb",
     file_to_open=0x13bb0b0 "dp-bug.gdb")
     at gdb/cli/cli-cmds.c:692
 #23 0x0000000000544557 in source_script_with_search (file=0x7fffffffd91a "dp-bug.gdb", from_tty=1, search_path=0)
     at gdb/cli/cli-cmds.c:750
 #24 0x00000000005445cf in source_script (file=0x7fffffffd91a "dp-bug.gdb", from_tty=1)
     at gdb/cli/cli-cmds.c:759
 #25 0x00000000007cf6d9 in catch_command_errors (command=0x5445aa <source_script(char const*, int)>,
     arg=0x7fffffffd91a "dp-bug.gdb", from_tty=1, do_bp_actions=false)
     at gdb/main.c:523
 #26 0x00000000007cf85d in execute_cmdargs (cmdarg_vec=0x7fffffffd1b0, file_type=CMDARG_FILE, cmd_type=CMDARG_COMMAND,
     ret=0x7fffffffd18c) at gdb/main.c:615
 #27 0x00000000007d0c8e in captured_main_1 (context=0x7fffffffd3f0)
     at gdb/main.c:1322
 #28 0x00000000007d0eba in captured_main (data=0x7fffffffd3f0)
     at gdb/main.c:1343
 #29 0x00000000007d0f25 in gdb_main (args=0x7fffffffd3f0)
     at gdb/main.c:1368
 #30 0x00000000004186dd in main (argc=5, argv=0x7fffffffd508)
     at gdb/gdb.c:32

There are two frames for bpstat_do_actions_1(), one at frame #16 and
the other at frame #0.  The one at frame #16 is processing the actions
for Breakpoint 2, which is a 'continue'.  The one at frame #0 is attempting
to process the dprintf breakpoint action.  However, at this point,
the value of 'executing_breakpoint_commands' is 1, forcing an early
return, i.e. prior to executing the command(s) associated with the dprintf
breakpoint.

For the sake of comparison, this is what the stack looks like when hitting
the dprintf breakpoint for the second time when issuing the 'run'
command from the GDB prompt.

Thread 1 "gdb" hit Breakpoint 3, bpstat_do_actions_1 (bsp=0x7fffffffccd8)
    at /ironwood1/sourceware-git/f34-master/bld/../../worktree-master/gdb/breakpoint.c:4431
4431   if (executing_breakpoint_commands)

 #0  bpstat_do_actions_1 (bsp=0x7fffffffccd8)
     at gdb/breakpoint.c:4431
 #1  0x00000000004d8bc6 in dprintf_after_condition_true (bs=0x16b0290)
     at gdb/breakpoint.c:13048
 #2  0x00000000004c5caa in bpstat_stop_status (aspace=0x116dbc0, bp_addr=0x40116e, thread=0x13f0e60, ws=0x7fffffffd138,
     stop_chain=0x16b0290) at gdb/breakpoint.c:5498
 #3  0x0000000000768d98 in handle_signal_stop (ecs=0x7fffffffd110)
     at gdb/infrun.c:6172
 #4  0x00000000007678d3 in handle_inferior_event (ecs=0x7fffffffd110)
     at gdb/infrun.c:5662
 #5  0x0000000000763cd5 in fetch_inferior_event ()
     at gdb/infrun.c:4060
 #6  0x0000000000746d7d in inferior_event_handler (event_type=INF_REG_EVENT)
     at gdb/inf-loop.c:41
 #7  0x00000000007a702f in handle_target_event (error=0, client_data=0x0)
     at gdb/linux-nat.c:4207
 #8  0x0000000000b8cd6e in gdb_wait_for_event (block=block@entry=0)
     at gdbsupport/event-loop.cc:701
 #9  0x0000000000b8d032 in gdb_wait_for_event (block=0)
     at gdbsupport/event-loop.cc:597
 #10 gdb_do_one_event () at gdbsupport/event-loop.cc:212
 #11 0x00000000007cf512 in start_event_loop ()
     at gdb/main.c:421
 #12 0x00000000007cf631 in captured_command_loop ()
     at gdb/main.c:481
 #13 0x00000000007d0ebf in captured_main (data=0x7fffffffd3f0)
     at gdb/main.c:1353
 #14 0x00000000007d0f25 in gdb_main (args=0x7fffffffd3f0)
     at gdb/main.c:1368
 #15 0x00000000004186dd in main (argc=5, argv=0x7fffffffd508)
     at gdb/gdb.c:32

This relatively short backtrace is due to the current UI's async field
being set to 1.

Yet another thing to be aware of regarding this problem is the
difference in the way that commands associated to dprintf breakpoints
versus regular breakpoints are handled.  While they both use a command
list associated with the breakpoint, regular breakpoints will place
the commands to be run on the bpstat chain constructed in
bp_stop_status().  These commands are run later on.  For dprintf
breakpoints, commands are run via the 'after_condition_true' function
pointer directly from bpstat_stop_status().  (The 'commands' field in
the bpstat is cleared in dprintf_after_condition_true().  This
prevents the dprintf commands from being run again later on when other
commands on the bpstat chain are processed.)

Another thing that I noticed is that dprintf breakpoints are the only
type of breakpoint which use 'after_condition_true'.  This suggests
that one possible way of fixing this problem, that of making dprintf
breakpoints work more like regular breakpoints, probably won't work.
(I must admit, however, that my understanding of this code isn't
complete enough to say why.  I'll trust that whoever implemented it
had a good reason for doing it this way.)

The comment referenced earlier regarding 'executing_breakpoint_commands'
states that the reason for checking this variable is to avoid
potential endless recursion when a 'source' command appears in
bs->commands.  We know that a dprintf command is constrained to either
1) execution of a GDB printf command, 2) an inferior function call of
a printf-like function, or 3) execution of an agent-printf command.
Therefore, infinite recursion due to a 'source' command cannot happen
when executing commands upon hitting a dprintf breakpoint.

I chose to fix this problem by having dprintf_after_condition_true()
directly call execute_control_commands().  This means that it no
longer attempts to go through bpstat_do_actions_1() avoiding the
infinite recursion check for potential 'source' commands on the
command chain.  I think it simplifies this code a little bit too, a
definite bonus.

Summary:

* breakpoint.c (dprintf_after_condition_true): Don't call
bpstat_do_actions_1().  Call execute_control_commands()
instead.

Re: Add --unicode option

* objdump: Whitespace fixes.
(long_options): Correct "ctf" entry.

Re: Add --unicode option

At low optimisation levels gcc may warn.

* strings.c (print_unicode_stream_body): Avoid bogus "may be
used unitialised" warning.

Automatic date update in version.in

PR28543, readelf entered an infinite loop

This little tweak terminates fuzzed binary readelf output a little
quicker.

PR 28543
* dwarf.c (read_and_display_attr_value): Consume a byte when
form is unrecognized.

PR28542, Undefined behaviours in readelf.c

PR 28542
* readelf.c (dump_relocations): Check that section headers have
been read before attempting to access section name.
(print_dynamic_symbol): Likewise.
(process_mips_specific): Delete dead code.

gdb::array_view slicing/container selftest - test std::array too

Change-Id: I2141b0b8a09f6521a59908599eb5ba1a19b18dc6

gdb.debuginfod/fetch_src_and_symbols.exp: fix when GDB is built with AddressSanitizer

This test fails for me, showing:

    ERROR: tcl error sourcing /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.debuginfod/fetch_src_and_symbols.exp.
    ERROR: This GDB was configured as follows:
       configure --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu
                 --with-auto-load-dir=$debugdir:$datadir/auto-load
                 --with-auto-load-safe-path=$debugdir:$datadir/auto-load
    ... and much more ...

The problem is that TCL's exec throws an error as soon as the exec'ed
process outputs on stderr.  When GDB is built with ASan, it prints some
warnings about pre-existing signal handlers:

    warning: Found custom handler for signal 7 (Bus error) preinstalled.
    warning: Found custom handler for signal 8 (Floating point exception) preinstalled.
    warning: Found custom handler for signal 11 (Segmentation fault) preinstalled.

Pass --quiet to GDB to avoid these warnings.

Change-Id: I3751d89b9b1df646da19149d7cb86775e2d3e80f

Correctly handle DW_LLE_start_end

When the code to handle DW_LLE_start_end was added (as part of some
DWARF 5 work), it was written to add the base address.  However, this
seems incorrect -- the DWARF standard describes this as an address,
not an offset from the base address.

This patch changes a couple of spots in dwarf2/loc.c to fix this
problem.  It then changes decode_debug_loc_addresses to return
DEBUG_LOC_OFFSET_PAIR instead, which preserves the previous semantics.

This only showed up on the RISC-V target internally, due to the
combination of DWARF 5 and a newer version of GCC.  I've updated a
couple of existing loclists test cases to demonstrate the bug.

Fix build on rhES5

The rhES5 build failed due to an upstream import a while back.  The
bug here is that, while the 'personality' function exists,
ADDR_NO_RANDOMIZE is only defined in <linux/personality.h>, not
<sys/personality.h>.

However, <linux/personality.h> does not declare the 'personality'
function, and <sys/personality.h> and <linux/personality.h> cannot
both be included.

This patch restores one of the removed configure checks and updates
the code to check it.

We had this as a local patch at AdaCore, because it seemed like there
was no interest upstream.  However, now it turns out that this fixes
PR build/28555, so I'm sending it now.

doc/ctf-spec.texi: Remove "@validatemenus off"

Remove @validatemenus from ctf-spec.texi, which has been removed from
texinfo by

commit a16dd1a9ece08568a1980b9a65a3a9090717997f
Author: Gavin Smith <gavinsmith0123@gmail.com>
Date:   Mon Oct 12 16:32:37 2020 +0100

    * doc/texinfo.texi
    (Writing a Menu, Customization Variables for @-Commands)
    (Command List),
    * doc/refcard/txirefcard.tex
    Remove @validatemenus.
    * tp/Texinfo/XS/Makefile.am (command_ids.h): Use gawk instead
    of awk.  Avoid discouraged "$p" usage, using "$(p)" instead.
    * tp/Texinfo/XS/configure.ac: Check for gawk.

commit 128acab3889b51809dc3bd3c6c74b61d13f7f5f4
Author: Gavin Smith <gavinsmith0123@gmail.com>
Date:   Thu Jan 3 14:51:53 2019 +0000

    Update refcard.

    * doc/refcard/txirefcard.tex: @setfilename is no longer
    mandatory.  Do not mention @validatemenus or explicitly giving
    @node pointers, as these are not very important features.

PR libctf/28567
* doc/ctf-spec.texi: Remove "@validatemenus off".

Add --unicode option to control how unicode characters are handled by display tools.

* nm.c: Add --unicode option to control how unicode characters are
handled.
* objdump.c: Likewise.
* readelf.c: Likewise.
* strings.c: Likewise.
* binutils.texi: Document the new feature.
* NEWS: Document the new feature.
* testsuite/binutils-all/unicode.exp: New file.
* testsuite/binutils-all/nm.hex.unicode
* testsuite/binutils-all/strings.escape.unicode
* testsuite/binutils-all/objdump.highlight.unicode
* testsuite/binutils-all/readelf.invalid.unicode

sim: sh: simplify testsuite a bit

Switch from the centralized list in the exp file to each test declaring
its own requirements which they're already (mostly) doing.  This will
increase coverage slightly by running more tests in more configurations
since the hardcoded exp list was a little out of date.

We have to mark the psh* tests as shdsp only (to match what the exp
file was doing), mark the fsca & fsrra tests as failing (since they
weren't even being run by the exp file), and to fix the expected
output & status of the fail test.

sim: cris: clean up missing func prototype warnings

Move some unused funcs under existing #if 0 protection, mark a few
local funcs as static, and add missing prototypes for the rest which
are used from other files.  This fixes all the fatal warnings in the
mloop files so we can turn -Werror on here fully.

Automatic date update in version.in

Improve gdb::array_view ctor from contiguous containers

While reading the interface of gdb::array_view, I realized that the
constructor that builds an array_view on top of a contiguous container
(such as std::vector, std::array or even gdb::array_view) can be
missused.

Lets consider the following code sample:

struct Parent
{
  Parent (int a): a { a } {}
  int a;
};

std::ostream &operator<< (std::ostream& os, const Parent & p)
{ os << "Parent {a=" << p.a << "}"; return os; }

struct Child : public Parent
{
  Child (int a, int b): Parent { a }, b { b } {}
  int b;
};

std::ostream &operator<< (std::ostream& os, const Child & p)
{ os << "Child {a=" << p.a << ", b=" << p.b << "}"; return os; }

template <typename T>
void print (const gdb::array_view<const T> &p)
{
  std::for_each (p.begin (), p.end (), [](const T &p) { std::cout << p << '\n'; });
}

Then with the current interface nothinng prevents this usage of
array_view to be done:

const std::array<Child, 3> elts = {
  Child {1, 2},
  Child {3, 4},
  Child {5, 6}
};
print_all<Parent> (elts);

This compiles fine and produces the following output:

Parent {a=1}
Parent {a=2}
Parent {a=3}

which is obviously wrong.  There is nowhere in memory a Parent-like
object for which the A member is 2 and this call to print_all<Parent>
shold not compile at all (calling print_all<Child> is however fine).

This comes down to the fact that a Child* is convertible into a Parent*,
and that an array view is constructed to a pointer to the first element
and a size.  The valid type pointed to that can be used with this
constructor are restricted using SFINAE, which requires that a
pointer to a member into the underlying container can be converted into a
pointer the array_view's data type.

This patch proposes to change the constraints on the gdb::array_view
ctor which accepts a container now requires that the (decayed) type of
the elements in the container match the (decayed) type of the array_view
being constructed.

Applying this change required minimum adjustment in GDB codebase, which
are also included in this patch.

Tested by rebuilding.

Add a const version of gdb_argv:as_array_view

This commits adds const versions for the GET and AS_ARRAX_VIEW methods
of gdb_argv.  Those methods will be required in the following patch of
the series.

gdb: fix nulltr -> nullptr typo

Change-Id: I04403bd85ec3fa75ea14130d68daba675a2a8aeb

gdb: tweak scoped_disable_commit_resumed uses when resuming all threads in non-stop

When doing "continue -a" in non-stop mode, each thread is individually
resumed while the commit resumed state is enabled.  This forces the
target to commit each resumption immediately, instead of being able to
batch things.

The reason is that there is no scoped_disable_commit_resumed around the
loop over threads in continue_1, when "non_stop && all_threads" is true.
Since the proceed function is called once for each thread, the
scoped_disable_commit_resumed in proceed therefore forces commit-resumed
between each thread resumption.  Add the necessary
scoped_disable_commit_resumed in continue_1 to avoid that.

I looked at the MI side of things, the function exec_continue, and found
that it was correct.  There is a similar iteration over threads, and
there is a scoped_disable_commit_resumed at the function scope.  This is
not wrong, but a bit more than we need.  The branches that just call
continue_1 do not need it, as continue_1 takes care of disabling commit
resumed.  So, move the scoped_disable_commit_resumed to the inner scope
where we iterate on threads and proceed them individually.

Here's an example debugging a multi-threaded program attached by
gdbserver (debug output trimmed for brevity):

    $ ./gdb -nx -q --data-directory=data-directory -ex "set non-stop" -ex "tar rem :1234"
    (gdb) set debug remote
    (gdb) set debug infrun
    (gdb) c -a
    Continuing.
    [infrun] proceed: enter
      [infrun] scoped_disable_commit_resumed: reason=proceeding
      [remote] Sending packet: $vCont;c:p14388.14388#90
      [infrun] reset: reason=proceeding
      [infrun] maybe_set_commit_resumed_all_targets: enabling commit-resumed for target remote
      [infrun] maybe_call_commit_resumed_all_targets: calling commit_resumed for target remote
    [infrun] proceed: exit
    [infrun] proceed: enter
      [infrun] scoped_disable_commit_resumed: reason=proceeding
      [remote] Sending packet: $vCont;c:p14388.1438a#b9
      [infrun] reset: reason=proceeding
      [infrun] maybe_set_commit_resumed_all_targets: enabling commit-resumed for target remote
      [infrun] maybe_call_commit_resumed_all_targets: calling commit_resumed for target remote
    [infrun] proceed: exit
    ... and so on for each thread ...

Notice how we send one vCont;c for each thread.  With the patch applied, we
send a single vCont;c at the end:

    [infrun] scoped_disable_commit_resumed: reason=continue all threads in non-stop
    [infrun] proceed: enter
      [infrun] scoped_disable_commit_resumed: reason=proceeding
      [infrun] reset: reason=proceeding
    [infrun] proceed: exit
    [infrun] clear_proceed_status_thread: Thread 85790.85792
    [infrun] proceed: enter
      [infrun] scoped_disable_commit_resumed: reason=proceeding
      [infrun] reset: reason=proceeding
    [infrun] proceed: exit
    ... proceeding threads individually ...
    [infrun] reset: reason=continue all threads in non-stop
    [infrun] maybe_set_commit_resumed_all_targets: enabling commit-resumed for target remote
    [infrun] maybe_call_commit_resumed_all_targets: calling commit_resumed for target remote
    [remote] Sending packet: $vCont;c#a8

Change-Id: I331dd2473c5aa5114f89854196fed2a8fdd122bb

gdb: make dwarf2_find_containing_comp_unit take a dwarf2_per_bfd

While reading another patch, I saw that this function didn't need to
take a dwarf2_per_objfile, but could take a dwarf2_per_bfd instead.
It doesn't change the behavior, but doing this shows that this function
is objfile-independent (can work with only the shared per-bfd data).

Change-Id: I58f9c9cef6688902e95226480285da2d0005d77f