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

gdb: remove bpstat typedef, rename bpstats to bpstat

I don't find that the bpstat typedef, which hides a pointer, is
particularly useful.  In fact, it confused me many times, and I just see
it as something to remember that adds cognitive load.  Also, with C++,
we might want to be able to pass bpstats objects by const-reference, not
necessarily by pointer.

So, remove the bpstat typedef and rename struct bpstats to bpstat (since
it represents one bpstat, it makes sense that it is singular).

Change-Id: I52e763b6e54ee666a9e045785f686d37b4f5f849

libctf: add CTF format specification

It's been a long time since most of this was written: it's long past
time to put it in the binutils source tree.  It's believed correct and
complete insofar as it goes: it documents format v3 (the current
version) but not the libctf API or any earlier versions.  (The
earlier versions can be read by libctf but not generated by it, and you
are highly unlikely ever to see an example of any of them.)

libctf/ChangeLog
2021-11-08  Nick Alcock  <nick.alcock@oracle.com>

* doc/ctf-spec.texi: New file.
* configure.ac (MAKEINFO): Add.
(BUILD_INFO): Likewise.
(AC_CONFIG_FILES) [doc/Makefile]: Add.
* Makefile.am [BUILD_INFO] (SUBDIRS): Add doc/.
* doc/Makefile.am: New file.
* doc/Makefile.in: Likewise.
* configure: Regenerated.
* Makefile.in: Likewise.

Automatic date update in version.in

Correct ld script wildcard matching description

Goes with commit 68bbb9f788d0

* ld.texi (Input Section Wildcards): Delete paragraph incorrectly
saying '*' does not match '/'.

sim: sh: fix conversion of PC to an integer

On LLP64 targets where sizeof(long) != sizeof(void*), this code fails:
sim/sh/interp.c:704:24: error: cast from pointer to integer of different size  -Werror=pointer-to-int-cast]
  704 |   do { memstalls += ((((long) PC & 3) != 0) ? (n) : ((n) - 1)); } while (0)
      |                        ^

Since this code simply needs to check alignment, cast it using uintptr_t
which is the right type for this.

sim: sh: clean up time(NULL) call

Casting 0 to a pointer via (long *) doesn't work on LLP64 targets:
error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]

It's also unnecessary here.  We can simply pass NULL like every other
bit of code does.

sim: sh: break utime logic out of _WIN32 check

Some _WIN32 targets provide utime (like mingw), so move the header
include out from _WIN32 and under the specific HAVE_UTIME_H check.

sim: sh: drop errno extern

This isn't needed on any reasonable target nowadays, and no other
source does this, and breaks with some mingw targets, so punt the
extern entirely.

sim: sh: fix isnan redefinition with mingw targets

The code assumes that all _WIN32 targets are the same and can
define isnan to _isnan.  For mingw targets, they provide an isnan
define already, so no need for the fallback here.

sim: arm/bfin/rx: undefine page size from system headers

Some targets (like cygwin) will export page size defines that clash
with our local usage here.  Undefine the system one to fix building
for these targets.

sim: ppc: switch to libiberty environ.h

Drop our compat code and assume environ exists to simplify.
We did this for all other targets already, but ppc was missed.

sim: sh: enable -Werror everywhere

With most of the warnings fixed in interp.c, we can enable -Werror
here too now.  There are some -Wmaybe-uninitialized warnings still
lurking that look legitimate, but we don't flag those are fatal,
and I don't have the expertise to dive into each opcode to figure
out the right way to clean them up.

sim: sh: fix uninitialized variable usage with pdmsb

This block of code relies on i to control which bits to test and how
many times to run through the loop, but it never actually initialized
it.  There is another chunk of code that handles the pdmsb instruction
that sets i to 16, so use that here too assuming it's correct.  The
programming manual suggests this is the right value too, but I am by
no means a SuperH DSP expert.  The tests are still passing though ...

sim: sh: constify a few read-only lookup tables

sim: sh: fix various parentheses warnings

Add parentheses to a bunch of places where the compiler suggests we
do to avoid confusion to most readers.

sim: sh: fix unused-value warnings

These macro expansions are deliberate in not using the computed value
so that they trigger side-effects (possible invalid memory accesses)
but while otherwise being noops.  Add a (void) cast so the compiler
knows these are intentional.

sim: sh: rework register layout with anonymous unions & structs

Now that we require C11, we can leverage anonymous unions & structs
to fix a long standing issue with the SH register layout.  The use
of sregs.i for sh-dsp has generated a lot of compiler warnings about
the access being out of bounds -- it only has 7 elements declared,
but code goes beyond that to reach into the fregs that follow.  But
now that we have anonymous unions, we can reduce the nested names
and have sregs cover all of these registers.

Automatic date update in version.in

sim: mips: use sim_fpu_to{32,64}u to fix build warnings

Since the first argument type is unsigned32 or unsigned64, just use
sim_fpu_to{32,64}u instead of sim_fpu_to{32,64}i to fix the following
build warnings:

  CC     cp1.o
.../sim/mips/cp1.c: In function 'convert':
.../sim/mips/cp1.c:1425:32: warning: pointer targets in passing argument 1 of 'sim_fpu_to32i' differ in signedness [-Wpointer-sign]
       status |= sim_fpu_to32i (&result32, &wop, round);
                                ^~~~~~~~~
In file included from .../sim/mips/sim-main.h:67,
                 from .../sim/mips/cp1.c:46:
.../sim/mips/../common/sim-fpu.h:270:22: note: expected 'signed32 *' {aka 'int *'} but argument is of type 'unsigned32 *' {aka 'unsigned int *'}
 INLINE_SIM_FPU (int) sim_fpu_to32i (signed32 *i, const sim_fpu *f,
                      ^~~~~~~~~~~~~
.../sim/mips/cp1.c:1429:32: warning: pointer targets in passing argument 1 of 'sim_fpu_to64i' differ in signedness [-Wpointer-sign]
       status |= sim_fpu_to64i (&result64, &wop, round);
                                ^~~~~~~~~
In file included from .../sim/mips/sim-main.h:67,
                 from .../sim/mips/cp1.c:46:
.../sim/mips/../common/sim-fpu.h:274:22: note: expected 'signed64 *' {aka 'long int *'} but argument is of type 'unsigned64 *' {aka 'long unsigned int *'}
 INLINE_SIM_FPU (int) sim_fpu_to64i (signed64 *i, const sim_fpu *f,
                      ^~~~~~~~~~~~~
.../sim/mips/cp1.c: In function 'convert_ps':
.../sim/mips/cp1.c:1528:34: warning: pointer targets in passing argument 1 of 'sim_fpu_to32i' differ in signedness [-Wpointer-sign]
       status_u |= sim_fpu_to32i (&res_u, &wop_u, round);
                                  ^~~~~~
In file included from .../sim/mips/sim-main.h:67,
                 from .../sim/mips/cp1.c:46:
.../sim/mips/../common/sim-fpu.h:270:22: note: expected 'signed32 *' {aka 'int *'} but argument is of type 'unsigned32 *' {aka 'unsigned int *'}
 INLINE_SIM_FPU (int) sim_fpu_to32i (signed32 *i, const sim_fpu *f,
                      ^~~~~~~~~~~~~
.../sim/mips/cp1.c:1529:34: warning: pointer targets in passing argument 1 of 'sim_fpu_to32i' differ in signedness [-Wpointer-sign]
       status_l |= sim_fpu_to32i (&res_l, &wop_l, round);
                                  ^~~~~~
In file included from .../sim/mips/sim-main.h:67,
                 from .../sim/mips/cp1.c:46:
.../sim/mips/../common/sim-fpu.h:270:22: note: expected 'signed32 *' {aka 'int *'} but argument is of type 'unsigned32 *' {aka 'unsigned int *'}
 INLINE_SIM_FPU (int) sim_fpu_to32i (signed32 *i, const sim_fpu *f,
                      ^~~~~~~~~~~~~

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

Modernise yyerror

Newer versions of bison emit a prototype for yyerror
void yyerror (const char *);
This clashes with some of our old code that declares yyerror to return
an int.  Fix that in most cases by modernizing yyerror.  bfin-parse.y
uses the return value all over the place, so for there disable
generation of the prototype as specified by posix.

binutils/
* arparse.y (yyerror): Return void.
* dlltool.c (yyerror): Likewise.
* dlltool.h (yyerror): Likewise.
* sysinfo.y (yyerror): Likewise.
* windmc.h (yyerror): Likewise.
* mclex.c (mc_error): Extract from ..
(yyerror): ..here, both now returning void.
gas/
* config/bfin-parse.y (yyerror): Define.
(yyerror): Make static.
* itbl-parse.y (yyerror): Return void.
ld/
* deffilep.y (def_error): Return void.

ubsan: undefined shift in mach-o.c

This one was logically wrong too.  If file_ptr was 64 bits, then -1U
is extended to 0x00000000ffffffff, probably not what was intended
here.

* mach-o.c (FILE_ALIGN): Correct expression.

readelf: Support RELR in -S and -d and output

readelf -r dumping support is not added in this patch.

include/
* elf/common.h: Add SHT_RELR, DT_RELR{,SZ,ENT}
bfd/
* elf.c (_bfd_elf_print_private_bfd_data): Add DT_RELR{,SZ,ENT}.
binutils/
* readelf.c (get_dynamic_type): Add DT_RELR{,SZ,ENT}.
(get_section_type_name): Add SHT_RELR.

readelf: Make DT_PREINIT_ARRAYSZ's output style match DT_INIT_ARRAYSZ

The output now looks like:

- 0x0000000000000021 (PREINIT_ARRAYSZ)    0x10
+ 0x0000000000000021 (PREINIT_ARRAYSZ)    16 (bytes)
  0x0000000000000019 (INIT_ARRAY)         0xbefc90
  0x000000000000001b (INIT_ARRAYSZ)       536 (bytes)

* readelf.c (process_dynamic_section): Handle DT_PREINIT_ARRAYSZ.

sim: clarify license text via COPYING file

The project has been using GPL v3 for a while now in the source files,
and the arm & ppc ports have carried a copy of the COPYING file.  Lets
move those up to the top sim dir like other projects to make it clear.

Also drop the ppc/COPYING.LIB as it's not really referenced by any
source as everything is GPL v3.

Automatic date update in version.in

Introduce make_unique_xstrndup

This adds a new make_unique_xstrndup function, which is the "n"
analogue of make_unique_xstrdup.  It also updates a couple existing
places to use this function.

Avoid /proc/pid/mem races (PR 28065)

PR 28065 (gdb.threads/access-mem-running-thread-exit.exp intermittent
failure) shows that GDB can hit an unexpected scenario -- it can
happen that the kernel manages to open a /proc/PID/task/LWP/mem file,
but then reading from the file returns 0/EOF, even though the process
hasn't exited or execed.

"0" out of read/write is normally what you get when the address space
of the process the file was open for is gone, because the process
execed or exited.  So when GDB gets the 0, it returns memory access
failure.  In the bad case in question, the process hasn't execed or
exited, so GDB fails a memory access when the access should have
worked.

GDB has code in place to gracefully handle the case of opening the
/proc/PID/task/LWP/mem just while the LWP is exiting -- most often the
open fails with EACCES or ENOENT.  When it happens, GDB just tries
opening the file for a different thread of the process.  The testcase
is written such that it stresses GDB's logic of closing/reopening the
/proc/PID/task/LWP/mem file, by constantly spawning short lived
threads.

However, there's a window where the kernel manages to find the thread,
but the thread exits just after and clears its address space pointer.
In this case, the kernel creates a file successfully, but the file
ends up with no address space associated, so a subsequent read/write
returns 0/EOF too, just like if the whole process had execed or
exited.  This is the case in question that GDB does not handle.

Oleg Nesterov gave this suggestion as workaround for that race:

    gdb can open(/proc/pid/mem) and then read (say) /proc/pid/statm.
    If statm reports something non-zero, then open() was "successfull".

I think that might work.  However, I didn't try it, because I realized
we have another nasty race that that wouldn't fix.

The other race I realized is that because we close/reopen the
/proc/PID/task/LWP/mem file when GDB switches to a different inferior,
then it can happen that GDB reopens /proc/PID/task/LWP/mem just after
a thread execs, and before GDB has seen the corresponding exec event.
I.e., we can open a /proc/PID/task/LWP/mem file accessing the
post-exec address space thinking we're accessing the pre-exec address
space.

A few months back, Simon, Oleg and I discussed a similar race:

  [Bug gdb/26754] Race condition when resuming threads and one does an exec
  https://sourceware.org/bugzilla/show_bug.cgi?id=26754

The solution back then was to make the kernel fail any ptrace
operation until the exec event is consumed, with this kernel commit:

 commit dbb5afad100a828c97e012c6106566d99f041db6
 Author:     Oleg Nesterov <oleg@redhat.com>
 AuthorDate: Wed May 12 15:33:08 2021 +0200
 Commit:     Linus Torvalds <torvalds@linux-foundation.org>
 CommitDate: Wed May 12 10:45:22 2021 -0700

     ptrace: make ptrace() fail if the tracee changed its pid unexpectedly

This however, only applies to ptrace, not to the /proc/pid/mem file
opening case.  Also, even if it did apply to the file open case, we
would want to support current kernels until such a fix is more wide
spread anyhow.

So all in all, this commit gives up on the idea of only ever keeping
one /proc/pid/mem file descriptor open.  Instead, make GDB open a
/proc/pid/mem per inferior, and keep it open until the inferior exits,
is detached or execs.  Make GDB open the file right after the inferior
is created or is attached to or forks, at which point we know the
inferior is stable and stopped and isn't thus going to exec, or have a
thread exit, and so the file open won't fail (unless the whole process
is SIGKILLed from outside GDB, at which point it doesn't matter
whether we open the file).

This way, we avoid both races described above, at the expense of using
more file descriptors (one per inferior).

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28065
Change-Id: Iff943b95126d0f98a7973a07e989e4f020c29419

gdb/testsuite: use gdb_get_line_number

Replaces a hard coded line number with a use of gdb_get_line_number.

I suspect that the line number has, over time, come adrift from where
it was supposed to be stopping.  When the test was first added, line
770 pointed at the final 'return 0' in function main.  Over time, as
things have been added, line 770 now points at some random location in
the middle of main.

So, I've marked the 'return 0' with a comment, and now the test will
always stop there.

I also removed an old comment from 1997 talking about how these tests
will only pass with the HP compiler, followed by an additional comment
from 2000 saying that the tests now pass with GCC.

I get the same results before and after this change.

PR28541, unstable cie offset in the output of readelf

Calculating "0 - pointer" can indeed result in seeming randomness as
the pointer address varies.

PR 28541
* dwarf.c (display_debug_frames): Don't print cie offset when
invalid, print "invalid" instead.  Remove now redundant warning.

Missing va_end in aarch64-dis.c

* aarch64-dis.c (extract_fields): Invoke va_end.

PR28530, Hang in objdump on machine with 196GB RAM

Investigating the PR28530 testcase, which has a fuzzed compression
header with an enormous size, I noticed that decompress_contents is
broken when the size doesn't fit in strm.avail_out.  It wouldn't be
too hard to support larger sizes (patches welcome!) but for now just
stop decompress_contents from returning rubbish.

PR 28530
* compress.c (decompress_contents): Fail when uncompressed_size
is too big.
(bfd_init_section_decompress_status): Likewise.

asan: alpha-vms: objdump buffer overflows

* vms-alpha.c (evax_bfd_print_desc): Sanity check buffer access.
(evax_bfd_print_valspec, evax_bfd_print_typspec): Likewise.
(evax_bfd_print_dst): Likewise.

Automatic date update in version.in

gdb: introduce "set index-cache enabled", deprecate "set index-cache on/off"

The "set index-cache" command is used at the same time as a prefix
command (prefix for "set index-cache directory", for example), and a
boolean setting for turning the index-cache on and off.  Even though I
did introduce that, I now don't think it's a good idea to do something
non-standard like this.

First, there's no dedicated CLI command to show whether the index-cache
is enabled, so it has to be custom output in the "show index-cache
handler".  Also, it means there's no good way a MI frontend can find out
if the index-cache is enabled.  "-gdb-show index-cache" doesn't show it
in the MI output record:

    (gdb) interpreter-exec mi "-gdb-show index-cache"
    ~"\n"
    ~"The index cache is currently disabled.\n"
    ^done,showlist={option={name="directory",value="/home/simark/.cache/gdb"}}

Fix this by introducing "set/show index-cache enabled on/off", regular
boolean setting commands.  Keep commands "set index-cache on" and "set
index-cache off" as deprecated aliases of "set index-cache enabled",
with respectively the default arguments "on" and "off".

Update tests using "set index-cache on/off" to use the new command.
Update the regexps in gdb.base/maint.exp to figure out whether the
index-cache is enabled or not.  Update the doc to mention the new
commands.

Change-Id: I7d5aaaf7fd22bf47bd03e0023ef4fbb4023b37b3

gdb: pass/return setting setter/getter scalar values by value

The getter and setter in struct setting always receive and return values
by const reference.  This is not necessary for scalar values (like bool
and int), but more importantly it makes it a bit annoying to write a
getter, you have to use a scratch static variable or something similar
that you can refer to:

  const bool &
  my_getter ()
  {
    static bool value;
    value = function_returning_bool ();
    return value;
  }

Change the getter and setter function signatures to receive and return
value by value instead of by reference, when the underlying data type is
scalar.  This means that string-based settings will still use
references, but all others will be by value.  The getter above would
then be re-written as:

  bool
  my_getter ()
  {
    return function_returning_bool ();
  }

This is useful for a patch later in this series that defines a boolean
setting with a getter and a setter.

Change-Id: Ieca3a2419fcdb75a6f75948b2c920b548a0af0fd

gdb: remove command_class enum class_deprecated

The class_deprecated enumerator isn't assigned anywhere, so remove it.
Commands that are deprecated have cmd_list_element::cmd_deprecated set
instead.

Change-Id: Ib35e540915c52aa65f13bfe9b8e4e22e6007903c

gdb: remove unnecessary cmd_list_element::aliases nullptr checks

Remove two unnecessary nullptr checks.  If aliases is nullptr, then the
for loops will simply be skipped.

Change-Id: I9132063bb17798391f8d019af305383fa8e0229f

gdbserver: re-generate configure

I get some diffs when running autoconf in gdbserver, probably leftovers
from commit 5dfe4bfcb969 ("Fix format_pieces selftest on Windows").
Re-generate configure in that directory.

Change-Id: Icdc9906af95fbaf1047a579914b2983f8ec5db08

Revert "bfd: Always check sections with the corrupt size"

This reverts commit e0f7ea91436dd308a094c4c101fd4169e8245a91.

bfd: Always check sections with the corrupt size

Always check sections with the corrupt size for non-MMO files.  Skip MMO
files for compress_status == COMPRESS_SECTION_NONE since MMO has special
handling for COMPRESS_SECTION_NONE.

PR binutils/28530
* compress.c (bfd_get_full_section_contents): Always check
sections with the corrupt size.

RISC-V: Clarify the behavior of .option rvc or norvc.

Add/Remove the rvc extension to/from the riscv_subsets once the
.option rvc/norvc is set.  So that we don't need to always check
the riscv_opts.rvc in the riscv_subset_supports, just call the
riscv_lookup_subset to search the subset list is enough.

Besides, we will need to dump the instructions according to the
elf architecture attributes.  That means the dis-assembler needs
to parse the architecture string from the elf attribute before
dumping any instructions, and also needs to recognized the
INSN_CLASS* classes from riscv_opcodes.  Therefore, I suppose
some functions will need to be moved from gas/config/tc-riscv.c
to bfd/elfxx-riscv.c, including riscv_multi_subset_supports and
riscv_subset_supports.  This is one of the reasons why we need
this patch.

This patch passes the gcc/binutils regressions of rv32emc-elf,
rv32i-elf, rv64gc-elf and rv64gc-linux toolchains.

bfd/
* elfxx-riscv.c (riscv_remove_subset): Remove the extension
from the subset list.
(riscv_update_subset): Add/Remove an extension to/from the
subset list.  This is used for the .option rvc or norvc.
* elfxx-riscv.h: Added the extern bool riscv_update_subset.
gas/
* config/tc-riscv.c (riscv_set_options): Removed the unused
rve flag.
(riscv_opts): Likewise.
(riscv_set_rve): Removed.
(riscv_subset_supports): Removed the riscv_opts.rvc check.
(riscv_set_arch): Don't need to call riscv_set_rve.
(reg_lookup_internal): Call riscv_subset_supports to check
whether the rve is supported.
(s_riscv_option): Add/Remove the rvc extension to/from the
subset list once the .option rvc/norvc is set.

sim: mips: fix missing prototype in multi-run generation

The multi-run logic for mips involves a bit of codegen and rewriting
of files to include per-architecture prefixes.  That can result in
files with missing prototypes which cause compiler errors.  In the
case of mips-sde-elf targets, we have:
$srcdir/m16run.c -> $builddir/m16mips64r2_run.c
  sim_engine_run -> m16mips64r2_engine_run
$srcdir/micromipsrun.c -> micromipsmicromips_run.c
  sim_engine_run -> micromips64micromips_engine_run

micromipsmicromips_run.c:80:1: error: no previous prototype for 'micromips64micromips_engine_run' [-Werror=missing-prototypes]
   80 | micromips64micromips_engine_run (SIM_DESC sd, int next_cpu_nr, int nr_cpus,

We generate headers for those prototypes in the configure script,
but only include them in the generated multi-run.c file.  Update the
rewrite logic to turn the sim-engine.h include into the relevant
generated engine include so these files also have their prototypes.
$srcdir/m16run.c -> $builddir/m16mips64r2_run.c
  sim-engine.h -> m16mips64r2_engine.h
$srcdir/micromipsrun.c -> micromipsmicromips_run.c
  sim-engine.h -> micromips64micromips_engine.h

PR28540, segmentation fault on NULL byte_get

PR 28540
* objdump.c (dump_bfd): Don't attempt load_separate_debug_files
when byte_get is NULL.

Automatic date update in version.in

sim: ppc: inline common sim-fpu.c logic

We will never bother building w/out a ../common/ sim directory,
so drop ancient logic supporting that method.

sim: ppc: switch to common builds for callback objects

We don't need to build this anymore ourselves since the common build
includes it and produces the same object code.  We also need to pull
in the split constant modules after the refactoring and pulling them
out of nltvals.def & targ-map.o.  This doesn't matter for the sim
directly, but does for gdb and other users of libsim.

We also delete some conditional source tree logic since we already
require this be the "new" combined tree with a ../common/ dir.  This
has been the case for decades at this point.

gdb: fix gnu-nat build

When building gnu-nat.c, we get:

      CXX    gnu-nat.o
    gnu-nat.c: In member function 'virtual void gnu_nat_target::create_inferior(const char*, const string&, char**, int)':
    gnu-nat.c:2117:13: error: 'struct inf' has no member named 'target_is_pushed'
     2117 |   if (!inf->target_is_pushed (this))
          |             ^~~~~~~~~~~~~~~~
    gnu-nat.c:2118:10: error: 'struct inf' has no member named 'push_target'
     2118 |     inf->push_target (this);
          |          ^~~~~~~~~~~

This is because of a confusion between the generic `struct inferior`
variable and the gnu-nat-specific `struct inf` variable.  Fix by
referring to `inferior`, not `inf`.

Adjust the comment on top of `struct inf` to clarify the purpose of that
type.

Co-Authored-By: Andrea Monaco <andrea.monaco@autistici.org>
Change-Id: I2fe2f7f6ef61a38d79860fd262b08835c963fc77

gdb/testsuite: set ASAN_OPTIONS=detect_leaks=0 while running tests

We see some additional failures when running the testsuite against a GDB
compiled with ASan, compared to a GDB compiled without ASan.  Some of
them are caused by the memory leak report shown by the GDB process when
it exits, and the fact that it makes it exit with a non-zero exit code.

I generally try to remember to set ASAN_OPTIONS=detect_leaks=0 in my
environment when running the tests, but I don't always do it.  I think
it would be nice if the testsuite did it.  I don't see any use to have
leak detection when running the tests.  That is, unless we ever have a
test that ensures GDB doesn't leak memory, which isn't going to happen
any time soon.

Here are some tests I found that were affected by this:

    gdb.base/batch-exit-status.exp
    gdb.base/many-headers.exp
    gdb.base/quit.exp
    gdb.base/with-mf.exp
    gdb.dwarf2/gdb-add-index.exp
    gdb.dwarf2/gdb-add-index-symlink.exp
    gdb.dwarf2/imported-unit-runto-main.exp

Change-Id: I784c7df8a13979eb96587f735c1d33ba2cc6e0ca

Use section name in warnings in display_debug_loc

While looking at an apparently malformed executable with
"readelf --debug-dump=loc", I got this warning:

    readelf: ./main: Warning: There is a hole [0x89 - 0x95] in .debug_loc section.

However, the executable only has a .debug_loclists section.

This patch fixes the warning messages in display_debug_loc to use the
name of the section that is being processed.

binutils/ChangeLog
2021-11-03  Tom Tromey  <tromey@adacore.com>

* dwarf.c (display_debug_loc): Use section name in warnings.

[AArch64] Make gdbserver register set selection dynamic

The current register set selection mechanism for AArch64 is static, based
on a pre-populated array of register sets.

This means that we might potentially probe register sets that are not
available. This is OK if the kernel errors out during ptrace, but probing the
tag_ctl register, for example, does not result in a ptrace error if the kernel
supports the tagged address ABI but not MTE (PR 28355).

Making the register set selection dynamic, based on feature checks, solves
this and simplifies the code a bit. It allows us to list all of the register
sets only once, and pick and choose based on HWCAP/HWCAP2 or other properties.

I plan to backport this fix to GDB 11 as well.

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

Fix LD_PRELOAD=/usr/lib64/libasan.so.6 gdb

Currently for a binary compiled normally (without -fsanitize=address) but with
LD_PRELOAD of ASAN one gets:

$ ASAN_OPTIONS=detect_leaks=0:alloc_dealloc_mismatch=1:abort_on_error=1:fast_unwind_on_malloc=0 LD_PRELOAD=/usr/lib64/libasan.so.6 gdb
=================================================================
==1909567==ERROR: AddressSanitizer: alloc-dealloc-mismatch (malloc vs operator delete []) on 0x602000001570
    #0 0x7f1c98e5efa7 in operator delete[](void*) (/usr/lib64/libasan.so.6+0xb0fa7)
...
0x602000001570 is located 0 bytes inside of 2-byte region [0x602000001570,0x602000001572)
allocated by thread T0 here:
    #0 0x7f1c98e5cd1f in __interceptor_malloc (/usr/lib64/libasan.so.6+0xaed1f)
    #1 0x557ee4a42e81 in operator new(unsigned long) (/usr/libexec/gdb+0x74ce81)
SUMMARY: AddressSanitizer: alloc-dealloc-mismatch (/usr/lib64/libasan.so.6+0xb0fa7) in operator delete[](void*)
==1909567==HINT: if you don't care about these errors you may set ASAN_OPTIONS=alloc_dealloc_mismatch=0
==1909567==ABORTING

Despite the code called properly operator new[] and operator delete[].
But GDB's new-op.cc provides its own operator new[] which gets translated into
malloc() (which gets recogized as operatore new(size_t)) but as it does not
translate also operators delete[] Address Sanitizer gets confused.

The question is how many variants of the delete operator need to be provided.
There could be 14 operators new but there are only 4, GDB uses 3 of them.
There could be 16 operators delete but there are only 6, GDB uses 2 of them.
It depends on libraries and compiler which of the operators will get used.
Currently being used:
                 U operator new[](unsigned long)
                 U operator new(unsigned long)
                 U operator new(unsigned long, std::nothrow_t const&)
                 U operator delete[](void*)
                 U operator delete(void*, unsigned long)

Tested on x86_64-linux.

asan: dlltool buffer overflow: embedded NUL in string

yyleng gives the pattern length, xstrdup just copies up to the NUL.
So it is quite possible writing at an index of yyleng-2 overflows
the xstrdup allocated string buffer.  xmemdup quite handily avoids
this problem, even writing the terminating NUL over the trailing
quote.  Use it in ldlex.l too where we'd already had a report of this
problem and fixed it by hand, and to implement xmemdup0 in gas.

binutils/
* deflex.l (single and double quote strings): Use xmemdup.
gas/
* as.h (xmemdup0): Use xmemdup.
ld/
PR 20906
* ldlex.l (double quote string): Use xmemdup.

sim: mloop: mark a few conditionally used funcs as unused

These are marked inline, so building w/gcc at higher optimization
levels will automatically discard them.  But building with -O0 will
trigger unused function warnings, so fix that.

The common before/after cover functions in the common mloop generator
are not used by all architecture ports.  Doesn't seem to be a hard
requirement, so marking them optional (i.e. unused) is fine.

The cris execute function is conditionally used depending on the
fast-build mode settings, so mark it unused too.

asan: assert (addr_ranges) <= (start)

That assert would be more obvious if it were reported as
"addr_ranges <= end_ranges".  Fix that by using the obvious variable
in the final loop.  Stop the assertion by using a signed comparison:
It's possible for the rounding up of the arange pointer to exceed the
end of the block when the block size is fuzzed.

* dwarf.c (display_debug_aranges): Use "end_ranges" in loop
displaying ranges rather that "start".  Simplify rounding up
to 2*address_size boundary.  Use signed comparison in loop.

sim: hoist cgen mloop rules up to common builds

These rules don't depend on the target compiler settings, so hoist
the build logic up to the common builds for better parallelization.

We have to extend the genmloop.sh logic a bit to allow outputting
to a subdir since it always assumed cwd was the right place.

We leave the cgen maintainer rules in the subdirs for now as they
aren't normally run, and they rely on cgen logic that has not yet
been generalized.

sim: hoist mn10300 & v850 igen rules up to common builds

These rules don't depend on the target compiler settings, so hoist
the build logic up to the common builds for better parallelization.

We leave the mips rules in place as they depend on complicated
arch-specific configure logic that needs to be untangled first.

sim: hoist gencode & opc2c build rules up to common builds

These rules don't depend on the target compiler settings, so hoist
the build logic up to the common builds for better parallelization.

opcodes: d10v: simplify header includes

This file doesn't use anything from bfd (sysdep.h), so drop that
include.  This avoids an implicit dependency on the generated
config.h which can be problematic for build-time tools.

Also swap stdio.h for stddef.h.  This file isn't doing or using
any I/O structures, but it does need NULL.

PR28523, ld.bfd created undefined symbols on ppc64

This patch removes any fake (linker created) function descriptor
symbol if its code entry symbol isn't dynamic, to ensure bogus dynamic
symbols are not created.  The change to func_desc_adjust requires that
it be run only once, which means ppc64_elf_tls_setup can't call it for
just a few selected symbols.

PR 28523
* elf64-ppc.c (func_desc_adjust): If a function entry sym is
not dynamic and has no plt entry, hide any associated fake
function descriptor symbol.
(ppc64_elf_edit): Move func_desc_adjust iteration over syms to..
(ppc64_elf_tls_setup): ..here.

Automatic date update in version.in

[gdb/tdep, rs6000] Don't skip system call in skip_prologue

I ran into a case where a breakpoint on _exit never triggered, because it was
set past the end of the _exit prologue, past the end of the exit_group system
call (which does not return).

More concretely, the breakpoint was set at the last insn show here:
...
Dump of assembler code for function _exit:
   0x00007ffff7e42ea0 <+0>:     12 00 4c 3c     addis   r2,r12,18
   0x00007ffff7e42ea4 <+4>:     60 43 42 38     addi    r2,r2,17248
   0x00007ffff7e42ea8 <+8>:     00 00 00 60     nop
   0x00007ffff7e42eac <+12>:    f8 ff e1 fb     std     r31,-8(r1)
   0x00007ffff7e42eb0 <+16>:    78 1b 7f 7c     mr      r31,r3
   0x00007ffff7e42eb4 <+20>:    f0 ff c1 fb     std     r30,-16(r1)
   0x00007ffff7e42eb8 <+24>:    ea 00 00 38     li      r0,234
   0x00007ffff7e42ebc <+28>:    a0 8b 22 e9     ld      r9,-29792(r2)
   0x00007ffff7e42ec0 <+32>:    78 fb e3 7f     mr      r3,r31
   0x00007ffff7e42ec4 <+36>:    14 6a c9 7f     add     r30,r9,r13
   0x00007ffff7e42ec8 <+40>:    02 00 00 44     sc
   0x00007ffff7e42ecc <+44>:    26 00 00 7c     mfcr    r0
   0x00007ffff7e42ed0 <+48>:    00 10 09 74     andis.  r9,r0,4096
...

Fix this by treating system calls the same as branches in skip_prologue:
by default, don't skip, such that the breakpoint is set at 0x00007ffff7e42eb8
instead.

Tested on ppc64le-linux, on a power 8 machine.

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

[gdb/testsuite] Handle SIGILL in two gdb.arch powerpc test-cases

On powerpc64le-linux, with test-case gdb.arch/powerpc-addpcis.exp I run into
SIGILL:
...
(gdb) PASS: gdb.arch/powerpc-addpcis.exp: get hexadecimal valueof "$r3"
stepi^M
^M
Program terminated with signal SIGILL, Illegal instruction.^M
The program no longer exists.^M
(gdb) PASS: gdb.arch/powerpc-addpcis.exp: set r4
...
because it's a power9 insn, and I'm running on a power8 machine.

Fix this by handling the SIGILL.  Likewise in gdb.arch/powerpc-lnia.exp.

Tested on powerpc64le-linux.

gdb/sim: update my email address

gdb:

* MAINTAINERS (Global Maintainers): Update my address.
(Responsible Maintainers): Likewise.
(Write After Approval): Likewise.

sim:

* MAINTAINERS (Global Maintainers): Update my address.

[gdb/testsuite] Fix stepi test-cases with unix/-m32/-fPIE/-pie

When running test-case gdb.base/step-indirect-call-thunk.exp with target board
unix/-m32/-fPIE/-pie, I run into:
...
(gdb) stepi^M
0x5655552e      22      {                /* inc.1 */^M
(gdb) stepi^M
0x56555530      22      {                /* inc.1 */^M
(gdb) stepi^M
0x565555f7 in __x86.get_pc_thunk.ax ()^M
(gdb) FAIL: gdb.base/step-indirect-call-thunk.exp: stepi into return thunk
...

In contrast, with unix/-m32 we have instead:
...
(gdb) stepi^M
0x08048407      22      {                /* inc.1 */^M
(gdb) stepi^M
23        return x + 1;  /* inc.2 */^M
(gdb) stepi^M
0x0804840c      23        return x + 1;  /* inc.2 */^M
(gdb) stepi^M
24      }                /* inc.3 */^M
(gdb) stepi^M
0x08048410      24      }                /* inc.3 */^M
(gdb) stepi^M
0x0804848f in __x86_return_thunk ()^M
(gdb) PASS: gdb.base/step-indirect-call-thunk.exp: stepi into return thunk
...

The test-case doesn't expect to run into __x86.get_pc_thunk.ax, which is a
PIC helper function for x86_64-linux.

Fix this by insn-stepping through it.

Likewise in a few other test-cases.

Tested on x86_64-linux.

Automatic date update in version.in

ARM: match armeb output for unwind-pacbti-m test

* testsuite/gas/arm/unwind-pacbti-m.d: Match armeb output.

[gdb/doc]: Updated manpages to be consistent with help

Updated manpages to be consistent with help information provided by the
binary. The main changes are:

* Making all long-form options have '--', instead of a single '-';
* added most of the missing options to the manpage;
* removed the information about using '+' instead of '-', since it
  doesn't seem to be supported anymore.

This also fixes 2 upstream bugs:
* https://sourceware.org/bugzilla/show_bug.cgi?id=23965; by adding
--args to the manpage
* https://sourceware.org/bugzilla/show_bug.cgi?id=10619; by adding the
double dashes

macho-o archive sanity checks

Anti-fuzzing checks.

* mach-o.c (bfd_mach_o_fat_archive_p): Sanity check entry offset
and size against file size.

objcopy buffer overflow

"tocopy" in this code was an int, which when the size to be copied was
larger than MAXINT could result in tocopy being negative.  A negative
value of course is less than BUFSIZE, but when converted to
bfd_size_type is extremely large.

PR 995
* objcopy.c (copy_unknown_object): Correct calculation of "tocopy".
Use better variable types.

arm: add armv9-a architecture to -march

Update also include:
+ New value of Tag_CPU_arch EABI attribute (22) is added.
+ Updated missing Tag_CPU_arch EABI attributes.
+ Updated how we combine archs 'v4t_plus_v6_m' as this mechanism
  have to handle new Armv9 as well.

Regression tested on `arm-none-eabi` cross Binutils and no issues.

bfd/

* archures.c: Define bfd_mach_arm_9.
* bfd-in2.h (bfd_mach_arm_9): Define bfd_mach_arm_9.
* cpu-arm.c: Add 'armv9-a' option to -march.
* elf32-arm.c (using_thumb2_bl): Update assert check.
(arch_has_arm_nop): Add TAG_CPU_ARCH_V9.
(bfd_arm_get_mach_from_attributes): Add case for TAG_CPU_ARCH_V9.
Update assert.
(tag_cpu_arch_combine): Updated table.
(v9): New table..

binutils/

* readelf.c (arm_attr_tag_CPU_arch): Update with

elfcpp/

* arm.h: Update TAG_CPU_ARCH_ enums with correct values.

gas/

* NEWS: Update docs.
* config/tc-arm.c (get_aeabi_cpu_arch_from_fset): Return Armv9-a
for -amarch=all.
(aeabi_set_public_attributes): Update assert.
* doc/c-arm.texi: Update docs.
* testsuite/gas/arm/armv9-a_arch.d: New test.
* testsuite/gas/arm/attr-march-all.d: Update test with v9.

include/

* elf/arm.h Update TAG_CPU_ARCH_ defines with correct values.
* opcode/arm.h (ARM_EXT3_V9A): New macro.
(ARM_ARCH_NONE): Updated with arm_feature_set.core size.
(FPU_NONE): Updated.
(ARM_ANY): Updated.
(ARM_ARCH_UNKNOWN): New macro.
(ARM_FEATURE_LOW): Updated.
(ARM_FEATURE_CORE): Updated.
(ARM_FEATURE_CORE_LOW): Updated.
(ARM_FEATURE_CORE_HIGH): Updated.
(ARM_FEATURE_COPROC): Updated.
(ARM_FEATURE): Updated.
(ARM_FEATURE_ALL): New macro.

opcodes/

* arm-dis.c (select_arm_features): Support bfd_mach_arm_9.
Also Update bfd_mach_arm_unknown to use new macro ARM_ARCH_UNKNOWN.

sim: iq2000: reduce -Wno-error scope

Clean up the warnings in sim-if, then reduce the -Werror disable to
the files that still aren't clean that now that we require GNU make
and can set variables on a per-object basis.

sim: lm32: reduce -Wno-error scope

Clean up some warnings in dv-lm32cpu, and all in sim-if, then reduce
the -Werror disable to the files that still aren't clean that now that
we require GNU make and can set variables on a per-object basis.

sim: frv: reduce -Wno-error scope

Only two files in here still generates warnings, so reduce the -Werror
disable to that now that we require GNU make and can set variables on
a per-object basis.

sim: m32r: reduce -Wno-error scope

Only two files in here still generates warnings, so reduce the -Werror
disable to that now that we require GNU make and can set variables on
a per-object basis.

sim: mips: reduce -Wno-error scope

Fix a few printf warnings in sim-main.c, and then we're left with only
one file in here still generating warnings, so reduce the -Werror
disable to that alone now that we require GNU make and can set variables
on a per-object basis.

sim: erc32: reduce -Wno-error scope

Only one file in here still generates warnings, so reduce the -Werror
disable to that alone now that we require GNU make and can set variables
on a per-object basis.

sim: cris: reduce -Wno-error scope

Only two files in here still generates warnings, so reduce the -Werror
disable to that now that we require GNU make and can set variables on
a per-object basis.

sim: sh: reduce -Wno-error scope

Only one file in here still generates warnings, so reduce the -Werror
disable to that alone now that we require GNU make and can set variables
on a per-object basis.

sim: or1k: build with -Werror

The only warnings left in this port are a few maybe-uninitialized,
but we don't abort the build for them, so turn on -Werror everywhere.