Add more filename styling

I found a few spots where filename styling ought to be applied, but is
not.

Fix maybe-uninitialized warning in py-infthread.c

I got this warning from py-infthread.c using the Fedora 34 system GCC:

../../binutils-gdb/gdb/python/py-infthread.c:102:30: warning: ‘extra_info’ may be used uninitialized in this function [-Wmaybe-uninitialized]

I think this happens because GDB_PY_HANDLE_EXCEPTION expands to an
'if' whose condition is always true -- but GCC can't know this.  This
patch avoids the warning by adding a harmless initialization.

Handle multi-byte bracket sequences in Ada lexer

As noted in an earlier patch, the Ada lexer does not handle multi-byte
bracket sequences.  This patch adds support for these for character
literals.  gdb does not generally seem to handle the Ada wide string
types, so for the time being these continue to be excluded -- but an
explicit error is added to make this more clear.

Handle 'QWW' encoding case in Ada enums

In Ada, an enum can contain character literals.  GNAT encodes these
values in a special way.  For example, the Unicode character U+0178
would be represented as 'QW0178' in the DWARF:

 <3><112f>: Abbrev Number: 2 (DW_TAG_enumerator)
    <1130>   DW_AT_name        : (indirect string, offset: 0x19ff): QW0178
    <1134>   DW_AT_const_value : 2

gdb handles this reasonably well, but failed to handle the 'QWW'
encoding, which is used for characters outside the base plane.

Also, while working on this, I noticed that gdb will print the decimal
value for an enum character constant:

    (gdb) print Char_X
    $2 = 1 'x'

This is a nice feature, IMO, because in this situation the 'x' enum
constant does not have its usual decimal value -- it has the value
that's assigned based on the enumeration type.

However, gdb did not do this when it decided to print the constant
using the bracket notation:

    (gdb) print Char_Thorn
    $3 = ["de"]

This patch changes gdb to print the decimal value here as well, and to
put the bracket notation in single quotes -- otherwise gdb will be
printing something that it can't then read.  Now it looks like:

    (gdb) print Char_Thorn
    $3 = 4 '["de"]'

Note that gdb can't read longer bracket notations, like the other ones
printed in this test case:

    (gdb) print Char_King
    $4 = 3 '["01fa00"]'

While I think this is a bug, I plan to fix it separately.

Finally, in the new test case, the copyright dates are chosen this way
because this all started as a copy of an existing test.

gdb/python: Add gdb.InferiorThread.details attribute

This adds a new read-only attribute gdb.InferiorThread.details, this
attribute contains a string, the results of target_extra_thread_info
for the thread, or None, if target_extra_thread_info returns nullptr.

As the string returned by target_extra_thread_info is unstructured,
this attribute is only really useful for echoing straight through to
the user, but, if a user wants to write a command that displays the
same, or a similar 'Thread Id' to the one seen in 'info threads', then
they need access to this string.

Given that the string produced by target_extra_thread_info varies by
target, there's only minimal testing of this attribute, I check that
the attribute can be accessed, and that the return value is either
None, or a string.

Error when gdb_is_target_1 is called without running gdb instance

This is a snafu that I encountered while implementing the previous
patch, which attempted to use gdb_is_target_native.  This proc and
gdb_is_target_remote both rely on gdb_is_target_1, which actually
cannot be called without gdb already running.

This patch adds appropriate warning comments to these procs and
causes gdb_is_target_1 to issue a Tcl error if it is called without a
gdb instance already running.  This should prevent unwitting callers
from using this at the wrong time.

Fix gdb.fortran "failed to extract expected results" errors

When running the gdb.fortran tests array-slices.exp and lbound-ubound.exp,
the test suite throws several ERRORs on native-gdbserver/-m{32,64},
and native-extended-gdbsever/-m{32,64}:

[on native-extended-gdbserver/-m64]
Running /home/keiths/work/gdb/branches/testsuite-errors/linux/gdb/testsuite/../../../src/gdb/testsuite/gdb.fortran/array-slices.exp ...
ERROR: failed to extract expected results
ERROR: failed to extract expected results
Running /home/keiths/work/gdb/branches/testsuite-errors/linux/gdb/testsuite/../../../src/gdb/testsuite/gdb.fortran/lbound-ubound.exp ...
ERROR: failed to extract expected results for lbound

This occurs because the tests require inferior I/O which we do not have
access to while using these targets.

This patch skips these tests when running on non-native targets.

Further correct the handling of long pathnames on Windows hosts.

PR 25713
* bfdio.c (_bfd_real_fopen): Fix handling of parhs longer than 260
characters on Windows hosts.

Clarify the wording of the error message when an obsolete configuration is encountered.

PR 28886
* config.bfd: Update error message for obsolete configurations.

Automatic date update in version.in

Automatic date update in version.in

Handle recursive internal problem in gdb_internal_error_resync

I came across this problem when testing gdb.base/gdb-sigterm.exp
on a machine with a pre-release version of glib-2.34 installed:

A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) Recursive internal problem.
FAIL: gdb.base/gdb-sigterm.exp: expect eof #0 (GDB internal error)
Resyncing due to internal error.
ERROR: : spawn id exp11 not open
    while executing
"expect {
-i exp11 -timeout 10
    -re "Quit this debugging session\\? \\(y or n\\) $" {
send_gdb "n\n" answer
incr count
    }
    -re "Create..."
    ("uplevel" body line 1)
    invoked from within
"uplevel $body" NONE : spawn id exp11 not open
ERROR: Could not resync from internal error (timeout)
gdb.base/gdb-sigterm.exp: expect eof #0: stepped 9 times
UNRESOLVED: gdb.base/gdb-sigterm.exp: 50 SIGTERM passes

I don't have a problem with the latter ERROR nor the UNRESOLVED
messages.  However the first ERROR regarding the exp11 spawn id
not being open is not especially useful.

This commit handles the "Recursive internal problem" case, avoiding
the problematic ERROR shown above.

With this commit in place, the log messages look like this instead:

A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) Recursive internal problem.
FAIL: gdb.base/gdb-sigterm.exp: expect eof #15 (GDB internal error)
Resyncing due to internal error.
ERROR: Could not resync from internal error (recursive internal problem)
gdb.base/gdb-sigterm.exp: expect eof #15: stepped 12 times
UNRESOLVED: gdb.base/gdb-sigterm.exp: 50 SIGTERM passes

gdb/testsuite/ChangeLog:

* lib/gdb.exp (gdb_internal_error_resync): Handle "Recursive
internal problem".

Automatic date update in version.in

gdb-add-index: disable debuginfod

gdb-add-index may trigger debuginfod's first-use notice.  The notice
is misleading in this case.  It instructs the user to modify .gdbinit
in order to permanently enable/disable debuginfod but gdb-add-index
invokes gdb with -nx which ignores .gdbinit.

Additionally debuginfod is not needed for gdb-add-index since the
symbol file is given as an argument and should already be present
locally.

Fix this by disabling debuginfod when gdb-add-index invokes gdb.

gdb: add operator+= and operator+ overload for std::string

This commit adds operator+= and operator+ overloads for adding
gdb::unique_xmalloc_ptr<char> to a std::string.  I could only find 3
places in GDB where this was useful right now, and these all make use
of operator+=.

I've also added a self test for gdb::unique_xmalloc_ptr<char>, which
makes use of both operator+= and operator+, so they are both getting
used/tested.

There should be no user visible changes after this commit, except when
running 'maint selftest', where the new self test is visible.

Print MI prompt on interrupted command

Joel noticed that if the remote dies unexpectedly during a command --
you can simulate this by using "continue" and then killing gdbserver
-- then the CLI will print a new prompt, but MI will not.  Later, we
found out that this was also filed in bugzilla as PR mi/23820.

The output looks something like this:

    | (gdb)
    | cont
    | &"cont\n"
    | ~"Continuing.\n"
    | ^running
    | *running,thread-id="all"
    | (gdb)
    | [... some output from GDB during program startup...]
    | =thread-exited,id="1",group-id="i1"
    | =thread-group-exited,id="i1"
    | &"Remote connection closed\n"

Now, what about that "(gdb)" in the middle?

That prompt comes from this questionable code in
mi-interp.c:mi_on_resume_1:

      /* This is what gdb used to do historically -- printing prompt
 even if it cannot actually accept any input.  This will be
 surely removed for MI3, and may be removed even earlier.  */
      if (current_ui->prompt_state == PROMPT_BLOCKED)
fputs_unfiltered ("(gdb) \n", mi->raw_stdout);

... which seems like something to remove.  But maybe the intent here
is that this prompt is sufficient, and MI clients must be ready to
handle output coming after a prompt.  On the other hand, if this code
*is* removed, then nothing would print a prompt in this scenario.

Anyway, the CLI and the TUI handle emitting the prompt here by hooking
into gdb::observers::command_error, but MI doesn't install an observer
here.

This patch adds the missing observer and arranges to show the MI
prompt.  Regression tested on x86-64 Fedora 34.

It seems like this area could be improved a bit, by having
start_event_loop call the prompt-displaying code directly, rather than
indirecting through an observer.  However, I haven't done this.

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

gdb/testsuite: fix list.exp test cases

PR testsuite/7142 -- old enough to have been converted from Gnats --
points out that test_list_filename_and_function in gdb.base/list.exp
has "fails" that are unmatched with passes.  This patch cleans this up
a little.

Co-authored-by: Tom Tromey <tromey@adacore.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=7142

RISC-V: Remove a loop in the ISA parser

Since commit e601909a3287bf541c6a7d82214bb387d2c76d82 ("RISC-V: Support
to parse the multi-letter prefix in the architecture string.") changed
so that all prefixed extensions are parsed in single
riscv_parse_prefixed_ext call, a "while" loop on riscv_parse_subset
is no longer required.

bfd/ChangeLog:

* elfxx-riscv.c (riscv_parse_subset): Remove unnecessary loop.

RISC-V: Fix mask for some fcvt instructions

This commit fixes incorrect uses of mask values in 'fcvt' instruction
family.

opcodes/ChangeLog:

* riscv-opc.c (riscv_opcodes): Fix incorrect uses of mask values
in 'fcvt' instruction family.

Support template lookups in strncmp_iw_with_mode

This patch adds support for wild template parameter list matches, similar
to how ABI tags or function overloads are now handled.

With this patch, users will be able to "gloss over" the details of matching
template parameter lists.  This is accomplished by adding (yet more) logic
to strncmp_iw_with_mode to skip parameter lists if none is explicitly given
by the user.

Here's a simple example using gdb.linespec/cpls-ops.exp:

Before
------
(gdb) ptype test_op_call
type = struct test_op_call {
  public:
    void operator()(void);
    void operator()(int);
    void operator()(long);
    void operator()<int>(int *);
}
(gdb) b test_op_call::operator()
Breakpoint 1 at 0x400583: test_op_call::operator(). (3 locations)
(gdb) i b
Num     Type           Disp Enb Address            What
1       breakpoint     keep y   <MULTIPLE>
1.1                         y     0x400583 in test_op_call::operator()(int)
                                                   at cpls-ops.cc:43
1.2                         y     0x40058e in test_op_call::operator()()
                                                   at cpls-ops.cc:47
1.3                         y     0x40059e in test_op_call::operator()(long)
                                                   at cpls-ops.cc:51

The breakpoint at test_op_call::operator()<int> was never set.

After
-----
(gdb) b test_op_call::operator()
Breakpoint 1 at 0x400583: test_op_call::operator(). (4 locations)
(gdb) i b
Num     Type           Disp Enb Address            What
1       breakpoint     keep y   <MULTIPLE>
1.1                         y     0x400583 in test_op_call::operator()(int)
                                                   at cpls-ops.cc:43
1.2                         y     0x40058e in test_op_call::operator()()
                                                   at cpls-ops.cc:47
1.3                         y     0x40059e in test_op_call::operator()(long)
                                                   at cpls-ops.cc:51
1.4                         y     0x4008d0 in test_op_call::operator()<int>(int*)
                                                   at cpls-ops.cc:57

Similar to how scope lookups work, passing "-qualified" to the break command
will cause a literal lookup of the symbol.  In the example immediately above,
this will cause GDB to only find the three non-template functions.

Unit tests for strncmp_iw_with_mode

This patch attempts to make a start at adding unit tests for
strncmp_iw_with_mode.  While there is quite a bit of testing
of this function in other tests, these are currently end-to-end
tests.

This patch attempts to cover the basics of string matching, white
space, C++ ABI tags, and several other topics. However, one area
that is ostensibly missing is testing the `match_for_lcd' feature.
This is otherwise tested as part of our end-to-end DejaGNU-based
testing.

Move find_toplevel_char to cp-support.[ch]

find_toplevel_char is being used more and more outside of linespec.c, so
this patch moves it into cp-support.[ch].

Automatic date update in version.in

Fix crash in Fortran code

PR fortran/28801 points out a gdb crash that can be provoked by
certain Fortran code.  The bug is that f77_get_upperbound assumes the
property is either a constant or undefined, but in this case it is
PROP_LOCEXPR.

This patch fixes the crash by making this function (and the
lower-bound one as well) do the correct check before calling
'const_val'.

Thanks to Andrew for writing the test case.

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

Revert "do_target_wait_1: Clear TARGET_WNOHANG if the target isn't async."

Commit 14b3360508b1 ("do_target_wait_1: Clear
TARGET_WNOHANG if the target isn't async.") broke some multi-target
tests, such as gdb.multi/multi-target-info-inferiors.exp.  The symptom
is that execution just hangs at some point.  What happens is:

1. One remote inferior is started, and now sits stopped at a breakpoint.
   It is not "async" at this point (but it "can async").

2. We run a native inferior, the event loop gets woken up by the native
   target's fd.

3. In do_target_wait, we randomly choose an inferior to call target_wait
   on first, it happens to be the remote inferior.

4. Because the target is currently not "async", we clear
   TARGET_WNOHANG, resulting in synchronous wait.  We therefore block
   here:

  #0  0x00007fe9540dbb4d in select () from /usr/lib/libc.so.6
  #1  0x000055fc7e821da7 in gdb_select (n=15, readfds=0x7ffdb77c1fb0, writefds=0x0, exceptfds=0x7ffdb77c2050, timeout=0x7ffdb77c1f90) at /home/simark/src/binutils-gdb/gdb/posix-hdep.c:31
  #2  0x000055fc7ddef905 in interruptible_select (n=15, readfds=0x7ffdb77c1fb0, writefds=0x0, exceptfds=0x7ffdb77c2050, timeout=0x7ffdb77c1f90) at /home/simark/src/binutils-gdb/gdb/event-top.c:1134
  #3  0x000055fc7eda58e4 in ser_base_wait_for (scb=0x6250002e4100, timeout=1) at /home/simark/src/binutils-gdb/gdb/ser-base.c:240
  #4  0x000055fc7eda66ba in do_ser_base_readchar (scb=0x6250002e4100, timeout=-1) at /home/simark/src/binutils-gdb/gdb/ser-base.c:365
  #5  0x000055fc7eda6ff6 in generic_readchar (scb=0x6250002e4100, timeout=-1, do_readchar=0x55fc7eda663c <do_ser_base_readchar(serial*, int)>) at /home/simark/src/binutils-gdb/gdb/ser-base.c:444
  #6  0x000055fc7eda718a in ser_base_readchar (scb=0x6250002e4100, timeout=-1) at /home/simark/src/binutils-gdb/gdb/ser-base.c:471
  #7  0x000055fc7edb1ecd in serial_readchar (scb=0x6250002e4100, timeout=-1) at /home/simark/src/binutils-gdb/gdb/serial.c:393
  #8  0x000055fc7ec48b8f in remote_target::readchar (this=0x617000038780, timeout=-1) at /home/simark/src/binutils-gdb/gdb/remote.c:9446
  #9  0x000055fc7ec4da82 in remote_target::getpkt_or_notif_sane_1 (this=0x617000038780, buf=0x6170000387a8, forever=1, expecting_notif=1, is_notif=0x7ffdb77c24f0) at /home/simark/src/binutils-gdb/gdb/remote.c:9928
  #10 0x000055fc7ec4f045 in remote_target::getpkt_or_notif_sane (this=0x617000038780, buf=0x6170000387a8, forever=1, is_notif=0x7ffdb77c24f0) at /home/simark/src/binutils-gdb/gdb/remote.c:10037
  #11 0x000055fc7ec354d4 in remote_target::wait_ns (this=0x617000038780, ptid=..., status=0x7ffdb77c33c8, options=...) at /home/simark/src/binutils-gdb/gdb/remote.c:8147
  #12 0x000055fc7ec38aa1 in remote_target::wait (this=0x617000038780, ptid=..., status=0x7ffdb77c33c8, options=...) at /home/simark/src/binutils-gdb/gdb/remote.c:8337
  #13 0x000055fc7f1409ce in target_wait (ptid=..., status=0x7ffdb77c33c8, options=...) at /home/simark/src/binutils-gdb/gdb/target.c:2612
  #14 0x000055fc7e19da98 in do_target_wait_1 (inf=0x617000038080, ptid=..., status=0x7ffdb77c33c8, options=...) at /home/simark/src/binutils-gdb/gdb/infrun.c:3636
  #15 0x000055fc7e19e26b in operator() (__closure=0x7ffdb77c2f90, inf=0x617000038080) at /home/simark/src/binutils-gdb/gdb/infrun.c:3697
  #16 0x000055fc7e19f0c4 in do_target_wait (ecs=0x7ffdb77c33a0, options=...) at /home/simark/src/binutils-gdb/gdb/infrun.c:3716
  #17 0x000055fc7e1a31f7 in fetch_inferior_event () at /home/simark/src/binutils-gdb/gdb/infrun.c:4061

Before the aforementioned commit, we would not have cleared
TARGET_WNOHANG, the remote target's wait would have returned nothing,
and we would have consumed the native target's event.

After applying this revert, the testsuite state looks as good as before
for me on Ubuntu 20.04 amd64.

Change-Id: Ic17a1642935cabcc16c25cb6899d52e12c2f5c3f

gdb: use a range based for loop when iterating over an array

Make use of a range based for loop to iterate over a static global
array, removing the need to have a null entry at the end of the
array.

There should be no user visible changes after this commit.

gdb/darwin: skip over WIFSTOPPED wait4 status

On modern Darwin's, there appears to be a new circumstance in which a
MACH_NOTIFY_DEAD_NAME message can be received, and which was not
previously accounted for: to signal the WIFSTOPPED condition in the
debuggee. In that case the debuggee is not dead yet (and in fact,
counting it as dead would cause a zombie leak - A process in such a
state reparents to PID 1, but cannot be killed).

 - Read and ignore such messages (counting on the next exception message
   to let us know of the inferior's new state again)
 - Refactor logging so as to clearly distinguish between the
   MACH_NOTIFY_DEAD_NAME cases (WIFEXITED, WIFSTOPPED, signal, or
   something else), and warn in the last case

Co-authored-by: Louis-He <1726110778@qq.com>
Co-authored-by: Philippe Blain <levraiphilippeblain@gmail.com>
Change-Id: Ie86904a894e9bd154e6b674b1bfbfbaee7fde3e1

gdb/linux-tdep: move "Perms" column right

Commit 29ef4c0699e1 ("gdb/linux-tdep.c: Add Perms to the 'info proc
mappings' output") has broken test gdb.base/info-proc.exp on Linux,
because it changes the output of "info proc mappings" in a way that the
test does not expect (my bad for not testing before pushing).

I looked at how FreeBSD handles this, since I remembered it did show
permission flags.  It looks like this:

          Start Addr           End Addr       Size     Offset   Flags   File
            0x200000           0x243000    0x43000        0x0  r-- CN-- /usr/local/bin/tmux

(I think that `Flags` and the flags not being aligned is not
intentional)

The test passes on FreeBSD, because the test looks for four hex numbers
in a row and ignores the rest:

    ".*Mapped address spaces:.*${hex}${ws}${hex}${ws}${hex}${ws}${hex}.*"

I suggest fixing it on Linux by moving the flags column to the same
place as in the FreeBSD output.  It makes things a bit more consistent
between OSes, and we don't have to touch the test.

At the same time, make use of the actual length of the permission's
string to specify the number of characters to print.

Before this patch, the output looks like:

          Start Addr           End Addr   Perms       Size     Offset objfile
      0x55dd4b544000     0x55dd4b546000   r--p      0x2000        0x0 /usr/bin/sleep

and after, it looks like:

          Start Addr           End Addr       Size     Offset  Perms  objfile
      0x5622ae662000     0x5622ae664000     0x2000        0x0  r--p   /usr/bin/sleep

Change-Id: If0fc167b010b25f97a3c54e2f491df4973ccde8f

gdb/linux-tdep: make read_mapping return a structure

Change read_mapping to return a structure instead of taking many output
parameters.  Change the string + length output parameters (permissions
and device) to be gdb::string_view, since that's what string_view is
for (a non-NULL terminated view on a string).  No changes in behavior
expected.

Change-Id: I86e627d84d3dda8c9b835592b0f4de8d90d12112

Automatic date update in version.in

Fix bug in C++ overload resolution

PR c++/28901 points out a bug in C++ overload resolution.  When
comparing two overloads, one might be better than the other for
certain parameters -- but, if that one also has some invalid
conversion, then it should never be considered the better choice.
Instead, a valid-but-not-apparently-quite-as-good overload should be
preferred.

This patch fixes this problem by changing how overload comparisons are
done.  I don't believe it should affect any currently valid overload
resolution; nor should it affect resolutions where all the choices are
equally invalid.

gdb/linux-tdep.c: Add Perms to the 'info proc mappings' output

Fixes #28914 and so it adds a 'Perms' (permissions) column to the
'info proc mappings' command output. This will allow users to know
the memory pages permissions right away from GDB instead of having
to fetch them from the /proc/$pid/maps file (which is also what GDB
does internally, but it just did not print that column).

Below I am also showing how an example output looks like before and
after this commit in case someone wonders.

On i386 targets - before this commit:
```
(gdb) info proc mappings
process 3461464
Mapped address spaces:

    Start Addr   End Addr        Size     Offset objfile
    0x56555000 0x56556000      0x1000        0x0 /home/dc/src/binutils-gdb/build/a.out
    0x56556000 0x56557000      0x1000     0x1000 /home/dc/src/binutils-gdb/build/a.out
    0x56557000 0x56558000      0x1000     0x2000 /home/dc/src/binutils-gdb/build/a.out
    0x56558000 0x5655a000      0x2000     0x2000 /home/dc/src/binutils-gdb/build/a.out
    0xf7fc4000 0xf7fc8000      0x4000        0x0 [vvar]
    0xf7fc8000 0xf7fca000      0x2000        0x0 [vdso]
    0xf7fca000 0xf7fcb000      0x1000        0x0 /usr/lib/i386-linux-gnu/ld-2.33.so
    0xf7fcb000 0xf7fee000     0x23000     0x1000 /usr/lib/i386-linux-gnu/ld-2.33.so
    0xf7fee000 0xf7ffb000      0xd000    0x24000 /usr/lib/i386-linux-gnu/ld-2.33.so
    0xf7ffb000 0xf7ffe000      0x3000    0x30000 /usr/lib/i386-linux-gnu/ld-2.33.so
    0xfffdc000 0xffffe000     0x22000        0x0 [stack]
(gdb)
```

On i386 targets - after this commit:
```
(gdb) info proc mappings
process 3461464
Mapped address spaces:

    Start Addr   End Addr   Perms       Size     Offset objfile
    0x56555000 0x56556000   r--p      0x1000        0x0 /home/dc/src/binutils-gdb/build/a.out
    0x56556000 0x56557000   r-xp      0x1000     0x1000 /home/dc/src/binutils-gdb/build/a.out
    0x56557000 0x56558000   r--p      0x1000     0x2000 /home/dc/src/binutils-gdb/build/a.out
    0x56558000 0x5655a000   rw-p      0x2000     0x2000 /home/dc/src/binutils-gdb/build/a.out
    0xf7fc4000 0xf7fc8000   r--p      0x4000        0x0 [vvar]
    0xf7fc8000 0xf7fca000   r-xp      0x2000        0x0 [vdso]
    0xf7fca000 0xf7fcb000   r--p      0x1000        0x0 /usr/lib/i386-linux-gnu/ld-2.33.so
    0xf7fcb000 0xf7fee000   r-xp     0x23000     0x1000 /usr/lib/i386-linux-gnu/ld-2.33.so
    0xf7fee000 0xf7ffb000   r--p      0xd000    0x24000 /usr/lib/i386-linux-gnu/ld-2.33.so
    0xf7ffb000 0xf7ffe000   rw-p      0x3000    0x30000 /usr/lib/i386-linux-gnu/ld-2.33.so
    0xfffdc000 0xffffe000   rw-p     0x22000        0x0 [stack]
(gdb)
```

On amd64 targets - after this commit:
```
(gdb) info proc mappings
process 3461869
Mapped address spaces:

          Start Addr           End Addr   Perms       Size     Offset objfile
      0x555555554000     0x555555555000   r--p      0x1000        0x0 /home/dc/src/binutils-gdb/build/a.out
      0x555555555000     0x555555556000   r-xp      0x1000     0x1000 /home/dc/src/binutils-gdb/build/a.out
      0x555555556000     0x555555557000   r--p      0x1000     0x2000 /home/dc/src/binutils-gdb/build/a.out
      0x555555557000     0x555555559000   rw-p      0x2000     0x2000 /home/dc/src/binutils-gdb/build/a.out
      0x7ffff7fc3000     0x7ffff7fc7000   r--p      0x4000        0x0 [vvar]
      0x7ffff7fc7000     0x7ffff7fc9000   r-xp      0x2000        0x0 [vdso]
      0x7ffff7fc9000     0x7ffff7fca000   r--p      0x1000        0x0 /usr/lib/x86_64-linux-gnu/ld-2.33.so
      0x7ffff7fca000     0x7ffff7ff1000   r-xp     0x27000     0x1000 /usr/lib/x86_64-linux-gnu/ld-2.33.so
      0x7ffff7ff1000     0x7ffff7ffb000   r--p      0xa000    0x28000 /usr/lib/x86_64-linux-gnu/ld-2.33.so
      0x7ffff7ffb000     0x7ffff7fff000   rw-p      0x4000    0x31000 /usr/lib/x86_64-linux-gnu/ld-2.33.so
      0x7ffffffdd000     0x7ffffffff000   rw-p     0x22000        0x0 [stack]
  0xffffffffff600000 0xffffffffff601000   --xp      0x1000        0x0 [vsyscall]
(gdb)
```

Signed-off-by: Dominik 'Disconnect3d' Czarnota <dominik.b.czarnota@gmail.com>
Change-Id: I4991f6cc758cd532eae3ae98c29d22e7bd9d9c36

RISC-V: PR28733, add missing extension info to 'unrecognized opcode' error

Currently we report errors as "unrecognized opcode `fence.i'" when the
opcode isn't part of the selected extensions.
This patch expands that error message to include the missing extension
information. For example, now the error message would be "unrecognized
opcode `fence.i', extension `zifencei' required".
If the opcode is not a part of any extension, the error message reverts
to "unrecognized opcode `<op statement>'".

Signed-off-by: Patrick O'Neill <patrick@rivosinc.com>
bfd/
pr 28733
* elfxx-riscv.c (riscv_multi_subset_supports_ext): New function,
used to return the extension string for each INSN_CLASS_*.
* elfxx-riscv.h: Added extern riscv_multi_subset_supports_ext.
gas/
pr 28733
* config/tc-riscv.c (struct riscv_ip_error): New structure,
contains information about errors that occur within the riscv_ip.
(riscv_ip): Use struct riscv_ip_error to report more detailed errors.
* testsuite/gas/riscv/c-fld-fsd-fail.l: Updated.
* testsuite/gas/riscv/march-imply-i2p1-01.: Likewise.

RISC-V: PR28733, add missing extension info to 'invalid CSR' error

Currently we report errors as "invalid CSR 'fscr' for the current ISA"
when the instruction isn't valid.

This patch expands that error message to include the missing extension
information. For example, now the error message would be "invalid CSR
'fscr' for the current ISA, CSR 'fscr' needs 'f' extension".

Signed-off-by: Patrick O'Neill <patrick@rivosinc.com>
gas/
pr 28733
* config/tc-riscv.c (riscv_csr_address): Report more details
when the CSR is invalid.
* testsuite/gas/riscv/csr-version-1p10.l: Updated detailed errors.
* testsuite/gas/riscv/csr-version-1p11.l: Likewise.
* testsuite/gas/riscv/csr-version-1p12.l: Likewise.
* testsuite/gas/riscv/csr-version-1p9p1.l: Likewise.

binutils 2.38 vs. ppc32 linux kernel

Commit b25f942e18d6 made .machine more strict.  Weaken it again.

* config/tc-ppc.c (ppc_machine): Treat an early .machine specially,
keeping sticky options to work around gcc bugs.

RISC-V: Updated CSRs to privileged spec v1.12 and debug spec v1.0.

* Removed N extension CSRs,
ustatus, uie, utvec, uscratch, uepc, ucause, utval and uip.

* Removed two supervisor CSRs,
sedeleg and sideleg.

* Changed debug CSR address of scontext from 0x7aa to 0x5a8.  We cannot support
different versions of debug specs for now, so only supporting the latest one is
the only way to move forward.

* Added debug CSRs,
mscontext (0x7aa), mcontrol6 (0x7a1, tdata1) and tmexttrigger ((0x7a1, tdata1).

* Regarded hcontext as a debug CSR.

include/
* opcode/riscv-opc.h: Updated CSRs to privileged spec v1.12 and
debug spec v1.0.
gas/
* testsuite/gas/riscv/csr.s: Updated CSRs to privileged spec v1.12
and debug spec v1.0.
* testsuite/gas/riscv/csr-dw-regnums.d: Likewise.
* testsuite/gas/riscv/csr-version-1p10.d: Likewise.
* testsuite/gas/riscv/csr-version-1p10.l: Likewise.
* testsuite/gas/riscv/csr-version-1p11.d: Likewise.
* testsuite/gas/riscv/csr-version-1p11.l: Likewise.
* testsuite/gas/riscv/csr-version-1p12.d: Likewise.
* testsuite/gas/riscv/csr-version-1p12.l: Likewise.
* testsuite/gas/riscv/csr-version-1p9p1.d: Likewise.
* testsuite/gas/riscv/csr-version-1p9p1.l: Likewise.
* testsuite/gas/riscv/csr-dw-regnums.d: Likewise.
* testsuite/gas/riscv/csr-dw-regnums.s: Likewise.

RISC-V: Add Privileged Architecture 1.12 CSRs

This commit adds,

* Most of CSRs as listed in the Privileged Architecture,
version 1.12 (except scontext and mscontext).

* Testcases for most CSRs added on the Privileged
Architecture, version 1.12 (except moved "scontext" and
new "mscontext").

include/ChangeLog:

* opcode/riscv-opc.h (CSR_SENVCFG, CSR_MCONFIGPTR, CSR_MENVCFG,
CSR_MSTATUSH, CSR_MENVCFGH, CSR_MTINST, CSR_MTVAL2, CSR_MSECCFG,
CSR_MSECCFGH, CSR_PMPCFG4, CSR_PMPCFG5, CSR_PMPCFG6,
CSR_PMPCFG7, CSR_PMPCFG8, CSR_PMPCFG9, CSR_PMPCFG10,
CSR_PMPCFG11, CSR_PMPCFG12, CSR_PMPCFG13, CSR_PMPCFG14,
CSR_PMPCFG15, CSR_PMPADDR16, CSR_PMPADDR17, CSR_PMPADDR18,
CSR_PMPADDR19, CSR_PMPADDR20, CSR_PMPADDR21, CSR_PMPADDR22,
CSR_PMPADDR23, CSR_PMPADDR24, CSR_PMPADDR25, CSR_PMPADDR26,
CSR_PMPADDR27, CSR_PMPADDR28, CSR_PMPADDR29, CSR_PMPADDR30,
CSR_PMPADDR31, CSR_PMPADDR32, CSR_PMPADDR33, CSR_PMPADDR34,
CSR_PMPADDR35, CSR_PMPADDR36, CSR_PMPADDR37, CSR_PMPADDR38,
CSR_PMPADDR39, CSR_PMPADDR40, CSR_PMPADDR41, CSR_PMPADDR42,
CSR_PMPADDR43, CSR_PMPADDR44, CSR_PMPADDR45, CSR_PMPADDR46,
CSR_PMPADDR47, CSR_PMPADDR48, CSR_PMPADDR49, CSR_PMPADDR50,
CSR_PMPADDR51, CSR_PMPADDR52, CSR_PMPADDR53, CSR_PMPADDR54,
CSR_PMPADDR55, CSR_PMPADDR56, CSR_PMPADDR57, CSR_PMPADDR58,
CSR_PMPADDR59, CSR_PMPADDR60, CSR_PMPADDR61, CSR_PMPADDR62,
CSR_PMPADDR63): New CSR macros.

gas/ChangeLog:

* testsuite/gas/riscv/csr-dw-regnums.s: Add new CSRs.
* testsuite/gas/riscv/csr-dw-regnums.d: Likewise.
* testsuite/gas/riscv/csr.s: Add new CSRs.
* testsuite/gas/riscv/csr-version-1p9p1.d: Likewise.
* testsuite/gas/riscv/csr-version-1p9p1.l: Likewise.
* testsuite/gas/riscv/csr-version-1p10.d: Likewise.
* testsuite/gas/riscv/csr-version-1p10.l: Likewise.
* testsuite/gas/riscv/csr-version-1p11.d: Likewise.
* testsuite/gas/riscv/csr-version-1p11.l: Likewise.
* testsuite/gas/riscv/csr-version-1p12.d: Likewise.
* testsuite/gas/riscv/csr-version-1p12.l: Likewise.

RISC-V: Reorganize testcases for CFI directives

This commit reorganizes and adds some CSRs to csr-dw-regnums.[sd] to
make it test the same CSRs as csr.s.

gas/ChangeLog:

* testsuite/gas/riscv/csr-dw-regnums.s: Reorganize and add
defined CSRs tested in csr.s.
* testsuite/gas/riscv/csr-dw-regnums.d: Likewise.

Automatic date update in version.in

NEWS: Note that the FreeBSD async target supports async mode.

inf-ptrace: Add an event_pipe to be used for async mode in subclasses.

Subclasses of inf_ptrace_target have to opt-in to using the event_pipe
by implementing the can_async_p and async methods.  For subclasses
which do this, inf_ptrace_target provides is_async_p, async_wait_fd
and closes the pipe in the close target method.

inf_ptrace_target also provides wrapper routines around the event pipe
(async_file_open, async_file_close, async_file_flush, and
async_file_mark) for use in target methods such as async.
inf_ptrace_target also exports a static async_file_mark_if_open
function which can be used in SIGCHLD signal handlers.

Enable async mode in the target in attach_cmd.

If the attach target supports async mode, enable it after the
attach target's ::attach method returns.

fbsd-nat: Return nullptr rather than failing ::thread_name.

ptrace on FreeBSD cannot be used against running processes and instead
fails with EBUSY.  This meant that 'info threads' would fail if any of
the threads were running (for example when using schedule-multiple=on
in gdb.base/fork-running-state.exp).  Instead of throwing errors, just
return nullptr as no thread name is better than causing info threads to
fail completely.

fbsd-nat: Various cleanups to the ::resume entry debug message.

Move the message from 'show debug fbsd-lwp' to 'show debug fbsd-nat'
since it is helpful for debugging async target support and not just
LWP support.

Use target_pid_to_str to format the ptid and log the step and signo
arguments.

fbsd-nat: Include ptrace operation in error messages.

fbsd-nat: Implement async target support.

This is a fairly simple version of async target support.

Synchronous mode still uses blocking waitpid() calls in
inf_ptrace::wait() unlike the Linux native target which always uses
WNOHANG and uses sigsuspend() for synchronous operation.

Asynchronous mode registers an event pipe with the core as a file
handle and writes to the pipe when SIGCHLD is raised.  TARGET_WNOHANG
is handled by inf_ptrace::wait().

inf-ptrace: Support async targets in inf_ptrace_target::wait.

- Handle TARGET_WNOHANG by passing WNOHANG to waitpid and returning
  TARGET_WAITKIND_IGNORE if there are no events to report.

- Handle a race in async mode where SIGCHLD might signal the event
  pipe for an event that has already been reported.  If the event was
  the exit of the last child process, waitpid() will fail with ECHILD
  rather than returning a pid of 0.  For this case, return
  TARGET_WAITKIND_NO_RESUMED.

inf-ptrace: Return an IGNORE event if waitpid() fails.

Previously this returned a TARGET_WAITKIND_SIGNALLED event for
inferior_ptid.  However, inferior_ptid is invalid during ::wait()
methods after the multi-target changes, so this was triggering an
assertion further up the stack.

do_target_wait_1: Clear TARGET_WNOHANG if the target isn't async.

Previously, TARGET_WNOHANG was cleared if a target supported async
mode even if async mode wasn't currently enabled.  This change only
permits TARGET_WNOHANG if async mode is enabled.

Don't enable async mode at the end of target ::resume methods.

Now that target_resume always enables async mode after target::resume
returns, these calls are redundant.

The other place that target resume methods are invoked outside of
target_resume are as the beneath target in record_full_wait_1.  In
this case, async mode should already be enabled when supported by the
target before the resume method is invoked due to the following:

  In general, targets which support async mode run as async until
  ::wait returns TARGET_WAITKIND_NO_RESUMED to indicate that there are
  no unwaited for children (either they have exited or are stopped).
  When that occurs, the loop in wait_one disables async mode.  Later
  if a stopped child is resumed, async mode is re-enabled in
  do_target_resume before waiting for the next event.

  In the case of record_full_wait_1, this function is invoked from the
  ::wait target method when fetching an event.  If the underlying
  target supports async mode, then an earlier call to do_target_resume
  to resume the child reporting an event in the loop in
  record_full_wait_1 would have already enabled async mode before
  ::wait was invoked.  In addition, nothing in the code executed in
  the loop in record_full_wait_1 disables async mode.  Async mode is
  only disabled higher in the call stack in wait_one after ::wait
  returns.

  It is also true that async mode can be disabled by an
  INF_EXEC_COMPLETE event passed to inferior_event_handle, but all of
  the places that invoke that are in the gdb core which is "above" a
  target ::wait method.

Note that there is an earlier call to enable async mode in
linux_nat_target::resume.  That call also marks the async event pipe
to report an existing event after enabling async mode, so it needs to
stay.

Enable async mode on supported targets in target_resume.

Enabling async mode above the target layer removes duplicate code in
::resume methods of async-capable targets.  Commit 5b6d1e4fa4f
("Multi-target support") enabled async mode in do_target_resume after
target_resume returns which is a step in this direction.  However,
other callers of target_resume such as target_continue do not enable
async mode.  Rather than enabling async mode in each of the callers
after target_resume returns, enable async mode at the end of
target_resume.

gdbserver linux-low: Convert linux_event_pipe to the event_pipe class.

Use event_pipe from gdbsupport in place of the existing file
descriptor array.

gdb linux-nat: Convert linux_nat_event_pipe to the event_pipe class.

Use event_pipe from gdbsupport in place of the existing file
descriptor array.

gdbsupport: Add an event-pipe class.

This pulls out the implementation of an event pipe used to implement
target async support in both linux-low.cc (gdbserver) and linux-nat.c
(gdb).

This will be used to replace the existing event pipe in linux-low.cc
and linux-nat.c in future commits.

Co-Authored-By: Lancelot SIX <lsix@lancelotsix.com>

gdb: fix detection of compilation and linking flags for source-highlight

Currently there are two problems with the detection of
source-highlight via pkg-config in GDB's configure script:

1. The LDFLAGS variable is used to pass the 'pkg-config --libs' output
to AC_LINK_IFELSE, which results in the "-L/some/path
-lsource-highlight" preceding the conftest.cpp, which can result in a
failure to find symbols referenced in conftest.cpp, if the linker is
using --as-needed by default.

2. The CFLAGS variable is used to pass the 'pkg-config --cflags'
output to AC_LINK_IFELSE.  However, as the current language is C++,
AC_LINK_IFELSE will actuall use CXXFLAGS, not CFLAGS, so any flags
returned from pkg-config will not be seen.

This patch fixes both of these mistakes, allowing GDB to correctly
configure and build using source-highlight installed into a custom
prefix, e.g. ~/opt/gdb-git (because the system version of
source-highlight is too old).

gdb/testsuite/README: point to default value of INTERNAL_GDBFLAGS

The INTERNAL_GDBFLAGS runtest variable was updated in 55c3ad88013
([gdb/testsuite] Prevent pagination in GDB_INTERNALFLAGS, 2020-10-26) to
disable pagination, and in aae1c79a03a (PR python/12227..., 2010-12-07)
to point to the data directory, but its default value mentioned in the
testsuite's README was not kept up to date.

To avoid it getting out of sync even more, point the reader to the
definition of the variable in lib/gdb.exp, and move the explanation of
the different flags there. Also adjust the example in the README
so it follows the flags added in 55c3ad88013.

Change-Id: I3533608a7d6ae5198af09c7dc7743bde24c19ed7

RISC-V: Maintain a string to hold the canonical order

Using dummy entry in riscv_supported_std_ext cause confusing and wrongly
support `b` and `k` extensions.

bfd/
* elfxx-riscv.c (riscv_supported_std_ext): Drop unsupported
extensions.
(riscv_ext_canonical_order): New.
(riscv_init_ext_order): Use riscv_ext_canonical_order rather
than riscv_supported_std_ext to compute canonical order.

V2 Changes:

- Use `*ext` rather than `*ext != NULL` for checking is reach end of
  string.

Automatic date update in version.in

Re: ld: Support customized output section type

"DO NOT EDIT!" says the comment at the top of bfd-in2.h.  Move the new
type field where it belongs.

PR ld/28841
* section.c (struct bfd_section): Add type.  Formatting.
(BFD_FAKE_SECTION): Formatting.
* bfd-in2.h: Regenerate.

sim: gdbinit: hoist setup to common code

This was left in subdirs because of the dynamic cgen usage.  However,
we can move this breakpoint call to runtime and let gdb detect whether
the symbol exists.

gdb/testsuite: relax pattern in new gdb.mi/mi-multi-commands.exp test

I saw some failures in the test gdb.mi/mi-multi-commands.exp that I
added recently.  This test was added in commit:

  commit d08cbc5d3203118da5583296e49273cf82378042
  Date:   Wed Dec 22 12:57:44 2021 +0000

      gdb: unbuffer all input streams when not using readline

The failures I see only occurred when my machine was very heavily
loaded.

In this test I send multiple commands from dejagnu to gdb with a
single send_gdb call.  In a well behaving world what I want to happen
is that the gdb console sees both commands arrive and echos the text
of those commands.  Then gdb starts processing the first command,
prints the result, and then processes the second command, and prints
the result.

However, what I saw in my loaded environment was that only after
sending the two commands, only the first command was echoed to gdb's
terminal.  Then gdb started processing the first command, and started
to write the output.  Now, mixed in with the first command output, the
second command was echoed to gdb's terminal.  Finally, gdb would
finish printing the first command output, and would read and handle
the second command.

This mixing of command echoing with the first command output was
causing the test matching patterns to fail.

In this commit I change the command I use in the test from a CLI
command to an MI command, this reduces the number of lines of output
that come from the test, CLI commands sent through the MI interpreter
are echoed back like this:

  (gdb)
  set $a = "FIRST COMMAND"
  &"set $a = \"FIRST COMMAND\"\n"
  ^done
  (gdb)

While this is not the case for true MI command:

  (gdb)
  -data-evaluate-expression $a
  ^done,value="\"FIRST COMMAND\""
  (gdb)

Less output makes for simpler patterns to match against.

Next, when sending two command to gdb I was previously trying to spot
the output of the first command followed by the prompt with nothing
between.  This is not really needed, for the first command I can look
for just the ^done,value="\"FIRST COMMAND\"" string, then I can start
looking for the output of the second command.

So long as the second pattern matches up to the gdb prompt, then I can
be sure than nothing is left over in the expect buffer to muck up
later matches.

As to see the second command output gdb must have read in the second
command, the second command output never suffers from the corruption
that the first command output does.

Since making this change, I've not seen a failure in this test.

gdb: avoid nullptr access in dbxread.c from read_dbx_symtab

This fixes a GDB crash reported in bug pr/28900, related to reading in
some stabs debug information.

In this commit my goal is to stop GDB crashing.  I am not trying to
ensure that GDB makes the best possible use of the available stabs
debug information.  At this point I consider stabs a legacy debug
format, with only limited support in GDB.

So, the problem appears to be that, when reading in the stabs data, we
need to find a N_SO entry, this is the entry that defines the start of
a compilation unit (or at least the location of a corresponding source
file).

It is while handling an N_SO that GDB creates a psymtab to hold the
incoming debug information (symbols, etc).

The problem we hit in the bug is that we encounter some symbol
information (an N_PC entry) outside of an N_SO entry - that is we find
some symbol information that is not associated with any source file.

We already have some protection for this case, look (in
read_dbx_symtab) at the handling of N_PC entries of type 'F' and 'f',
if we have no psymtab (the pst variable is nullptr) then we issue a
complaint.  However, for whatever reason, in both 'f' and 'F'
handling, there is one place where we assume that the pst
variable (the psymtab) is not nullptr.  This is a mistake.

In this commit, I guard these two locations (in 'f' and 'F' handling)
so we no longer assume pst is not nullptr.

While I was at it, I audited all the other uses of pst in
read_dbx_symtab, and in every potentially dangerous case I added a
nullptr check, and issue a suitable complaint if pst is found to be
nullptr.

It might well be true that we could/should do something smarter if we
see a debug symbol outside of an N_SO entry, and if anyone wanted to
do that work, they're welcome too.  But this commit is just about
preventing the nullptr access, and the subsequent GDB crash.

I don't have any tests for this change, I have no idea how to generate
weird stabs data for testing.  The original binary from the bug report
now loads just fine without GDB crashing.

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

gdb: make use of std::string in dbxread.c and xcoffread.c

While taking a look through dbxread.c I spotted a couple of places
where making use of std::string would remove the need for manual
memory allocation and memcpy.

During review Simon pointed out that the same code exists in
xcoffread.c, so I've applied the same fix there too.

There should be no user visible changes after this commit.

Automatic date update in version.in

gdb: Only paginate for filtered output in fputs_maybe_filtered

A have had situation where a unfiltered output (done using
fputs_unfiltered) ended up triggering pagination.  The backtrace for this was:

    ...
    #24 0x000055839377ee4e in check_async_event_handlers () at ../../gdb/async-event.c:335
    #25 0x0000558394b67b57 in gdb_do_one_event () at ../../gdbsupport/event-loop.cc:216
    #26 0x0000558394587454 in gdb_readline_wrapper (prompt=0x7ffd907712d0 "--Type <RET> for more, q to quit, c to continue without paging--") at ../../gdb/top.c:1148
    #27 0x0000558394707270 in prompt_for_continue () at ../../gdb/utils.c:1438
    #28 0x00005583947088b3 in fputs_maybe_filtered (linebuffer=0x60c0000f4000 "   [...quite big message...]", stream=0x60300028e9d0, filter=0) at ../../gdb/utils.c:1752
    #29 0x0000558394708e57 in fputs_unfiltered (linebuffer=0x60c0000f4000 "   [...quite big message...]", stream=0x60300028e9d0) at ../../gdb/utils.c:1811
    ...

This comes from what appears to be a oversight in fputs_maybe_filtered.  This
function has a FILTER parameter which if true makes the function pause after
every screenful (i.e. triggers pagination).

The filter parameter is correctly used to guard the first place where
prompt_for_continue.  There is a second place in the function which can call
prompt_for_continue, but is currently unguarded.  I believe that this is an
oversight, this patch fixes that.

Tested on Linux-x86_64, no regression observed.

Change-Id: Iad8ffd50a87cf20077500878e2564b5a7dc81ece

Automatic date update in version.in

gdb/darwin: remove not-so-harmless spurious call to `wait4`

As seen in https://sourceware.org/bugzilla/show_bug.cgi?id=24069 this
code will typically wait4() a second time on the same process that was
already wait4()'d a few lines above. While this used to be
harmless/idempotent (when we assumed that the process already exited),
this now causes a deadlock in the WIFSTOPPED case.

The early (~2019) history of bug #24069 cautiously suggests to use
WNOHANG instead of outright deleting the call. However, tests on the
current version of Darwin (Big Sur) demonstrate that gdb runs just fine
without a redundant call to wait4(), as would be expected.
Notwithstanding the debatable value of conserving bug compatibility with
an OS release that is more than a decade old, there is scant evidence of
what that double-wait4() was supposed to achieve in the first place - A
cursory investigation with `git blame` pinpoints commits bb00b29d7802
and a80b95ba67e2 from the 2008-2009 era, but fails to answer the
"why" question conclusively.

Co-Authored-By: Philippe Blain <levraiphilippeblain@gmail.com>
Change-Id: Id4e4415d66d6ff6b3552b60d761693f17015e4a0

Automatic date update in version.in

Add constructor to bound_minimal_symbol

This adds a constructor to bound_minimal_symbol, to avoid a build
failure with clang that Simon pointed out.

I also took the opportunity to remove some redundant initializations,
and to change one use of push_back to emplace_back, as suggested by
Simon.

Fix typo in ld.texi

ld/
* ld.texi (Output Section Type): Fix typo in @code syntax.

gdb: remove newlines from some linux_nat_debug_printf calls

Change-Id: I80328fab7096221356864b5a4fb30858b48d2c10

Automatic date update in version.in

Updated Serbian translations for the bfd, gold, ld and opcodes directories

Automatic date update in version.in

ld: Support customized output section type

bfd/
    PR ld/28841
    * bfd-in2.h (struct bfd_section): Add type.
    (discarded_section): Add field.
    * elf.c (elf_fake_sections): Handle bfd_section::type.
    * section.c (BFD_FAKE_SECTION): Add field.
    * mri.c (mri_draw_tree): Update function call.

ld/
    PR ld/28841
    * ld.texi: Document new output section type.
    * ldlex.l: Add new token TYPE.
    * ldgram.y: Handle TYPE=exp.
    * ldlang.h: Add type_section to list of section types.
    * ldlang.c (lang_add_section): Handle type_section.
    (map_input_to_output_sections): Handle type_section.
    * testsuite/ld-scripts/output-section-types.t: Add tests.
    * testsuite/ld-scripts/output-section-types.d: Update.

gdb/tui: add a missing white space character

Just adds a missing space.  There should be no user visible changes
after this commit.

gdb: convert callback_handler_installed from int to bool

Simple int to bool conversion on callback_handler_installed in
event-top.c.  There should be no user visible changes after this
commit.

gas local label and dollar label handling

Much of the gas source and older BFD source use "long" for function
parameters and variables, when other types would be more appropriate.
This patch fixes one of those cases.  Dollar labels and numeric local
labels do not need large numbers.  Small positive itegers are usually
all that is required.  Due to allowing longs, it was possible for
fb_label_name and dollar_label_name to overflow their buffers.

* symbols.c: Delete unnecessary forward declarations.
(dollar_labels, dollar_label_instances): Use unsigned int.
(dollar_label_defined, dollar_label_instance): Likewise.
(define_dollar_label): Likewise.
(fb_low_counter, fb_labels, fb_label_instances): Likewise.
(fb_label_instance_inc, fb_label_instance): Likewise.
(fb_label_count, fb_label_max): Make them size_t.
(dollar_label_name, fb_label_name): Rewrite using sprintf.
* symbols.h (dollar_label_defined): Update prototype.
(define_dollar_label, dollar_label_name): Likewise.
(fb_label_instance_inc, fb_label_name): Likewise.
* config/bfin-lex.l (yylex): Remove unnecessary casts.
* expr.c (integer_constant): Likewise.
* read.c (read_a_source_file): Limit numeric label range to int.

ubsan: s_app_line integer overflow

There are quite a few ubsan warnings in gas.  This one disappears with
a code tidy.

* read.c (s_app_line): Rename 'l' to 'linenum'.  Avoid ubsan
warning.

pe_ILF_make_a_symbol_reloc segfault

pei-aarch64-little apparently lacks support for BFD_RELOC_RVA.

* peicode.h (pe_ILF_make_a_symbol_reloc): Don't segfault on
NULL howto.

What to do when sh_addralign isn't a power of two

BFD generally doesn't handle anything but a power of two section
alignment, and ELF sh_addralign is required to be an integral power of
two (or zero) by the ELF spec.  Of course this is ignored by fuzzers,
and because bfd_log2 rounds up, we can end up with alignment_power
being 32 on a 32-bit object or 64 on a 64-bit object.  That then
triggers ubsan warnings in places like bfd_update_compression_header
where we want to convert from alignment_power back to an alignment.
I suppose we could reject object files that have non-compliant
sh_addralign, but I think it's also reasonable to use the greatest
power of two divisor of sh_addralign, ie. the rightmost 1 bit.

* elf.c (_bfd_elf_make_section_from_shdr): Use greatest power
of two divisor of sh_addralign.
(_bfd_elf_assign_file_position_for_section): Likewise.
(assign_file_positions_for_non_load_sections): Likewise.

asan: buffer overflow in vms-alpha.c

* vms-alpha.c (evax_bfd_print_dst): Sanity check another place
printing strings.

asan : use of uninitialized value in buffer_and_nest

* macro.c (buffer_and_nest): Don't read past end of string buffer.

asan: buffer overflow in peXXigen.c

* peXXigen.c (_bfd_XX_bfd_copy_private_bfd_data_common): Properly
sanity check DataDirectory[PE_DEBUG_DATA].Size.

sim/common: Improve sim_dump_memory head comment

As requested by Mike.

* sim-memopt.c: Improve head comment.

sim/testsuite/cris/c/stat3.c: Fix formatting nit

* c/stat3.c (main): Fix formatting nit.

sim: testsuite: cleanup the istarget * logic

Now that the multitarget testing has settled, clean up the cases where
istarget * is used.  This ends up being mostly style unindenting.

Automatic date update in version.in

i386: Update I386_NEED_DYNAMIC_RELOC_TYPE_P for DT_TEXTREL

Update I386_NEED_DYNAMIC_RELOC_TYPE_P to allow R_386_TLS_IE for relocation
in read-only section.

bfd/

PR ld/28894
* elfxx-x86.h (I386_NEED_DYNAMIC_RELOC_TYPE_P): Allow
R_386_TLS_IE.

ld/
PR ld/28894
* testsuite/ld-i386/i386.exp: Run pr28894.
* testsuite/ld-i386/pr28894.d: New file.
* testsuite/ld-i386/pr28894.s: Likewise.

sim/testsuite: Default global_cc_os and global_cc_works properly

There was an omission on 3e6dc39ed7a8 "sim/testsuite: Set
global_cc_os also when no compiler is found"; global_cc_os
wasn't set for other than the primary target, which means
that the "unguarded" use of global_cc_os in
testsuite/cris/c/c.exp caused the dreaded "ERROR: can't read
"global_cc_os": no such variable" when e.g. configuring for
pru-elf and doing "make check-sim".  Better initializing
both variables at the top to default values, rather than
adding another single 'set global_cc_os ""', to reduce the
risk of not setting them properly if or when that
if-statement-chain is made longer.

sim/testsuite:
* lib/sim-defs.exp (sim_init_toolchain): Default
global_cc_os and global_cc_works properly, before if-chain.

x86: Add has_sib to struct instr_info

Add has_sib to struct instr_info and use SIB info only if ins->has_sib
is true.

PR binutils/28892
* i386-dis.c (instr_info): Add has_sib.
(get_sib): Set has_sib.
(OP_E_memory): Replace havesib with ins->has_sib.
(OP_VEX): Use ins->sib.index only if ins->has_sib is true.

gdb: Respect the DW_CC_nocall attribute

It is possible for a compiler to optimize a function in a such ways that
the function does not follow the calling convention of the target.  In
such situation, the compiler can use the DW_AT_calling_convention
attribute with the value DW_CC_nocall to tell the debugger that it is
unsafe to call the function.  The DWARF5 standard states, in 3.3.1.1:

  > If the value of the calling convention attribute is the constant
  > DW_CC_nocall, the subroutine does not obey standard calling
  > conventions, and it may not be safe for the debugger to call this
  > subroutine.

Non standard calling convention can affect GDB's assumptions in multiple
ways, including how arguments are passed to the function, how values are
returned, and so on.  For this reason, it is unsafe for GDB to try to do
the following operations on a function with marked with DW_CC_nocall:

- call / print an expression requiring the function to be evaluated,
- inspect the value a function returns using the 'finish' command,
- force the value returned by a function using the 'return' command.

This patch ensures that if a command which relies on GDB's knowledge of
the target's calling convention is used on a function marked nocall, GDB
prints an appropriate message to the user and does not proceed with the
operation which is unreliable.

Note that it is still possible for someone to use a vendor specific
value for the DW_AT_calling_convention attribute for example to indicate
the use of an alternative calling convention.  This commit does not
prevent this, and target dependent code can be adjusted if one wanted to
support multiple calling conventions.

Tested on x86_64-Linux, with no regression observed.

Change-Id: I72970dae68234cb83edbc0cf71aa3d6002a4a540

gdb: add a symbol* argument to get_return_value

Add an argument to the get_return_value function to indicate the symbol
of the function the debuggee is returning from.  This will be used by
the following patch.

Since the function return type can be deduced from the symbol remove the
value_type argument which becomes redundant.

No user visible change after this patch.

Tested on x86_64-linux.

Change-Id: Idf1279f1f7199f5022738a6679e0fa63fbd22edc
Co-authored-by: Simon Marchi <simon.marchi@polymtl.ca>

x86-64: Use MAXPAGESIZE for the relro segment alignment

Adjust x86-64 linker tests after reverting

commit 31b4d3a16f200bf04db8439a63b72bba7af4e1be
Author: Alan Modra <amodra@gmail.com>
Date:   Thu Feb 3 08:57:47 2022 +1030

    PR28824, relro security issues, x86 keep COMMONPAGESIZE relro

to use MAXPAGESIZE for the end of the relro segment alignment, like other
ELF targets.

* testsuite/ld-x86-64/plt-main-bnd.dd: Updated.
* testsuite/ld-x86-64/plt-main-ibt-x32.dd: Likewise.
* testsuite/ld-x86-64/plt-main-ibt.dd: Likewise.
* testsuite/ld-x86-64/pr14207.d: Likewise.
* testsuite/ld-x86-64/pr18176.d: Likewise.
* testsuite/ld-x86-64/pr20830a-now.d: Likewise.
* testsuite/ld-x86-64/pr20830a.d: Likewise.
* testsuite/ld-x86-64/pr20830b-now.d: Likewise.
* testsuite/ld-x86-64/pr20830b.d: Likewise.
* testsuite/ld-x86-64/pr21038a-now.d: Likewise.
* testsuite/ld-x86-64/pr21038a.d: Likewise.
* testsuite/ld-x86-64/pr21038b-now.d: Likewise.
* testsuite/ld-x86-64/pr21038b.d: Likewise.
* testsuite/ld-x86-64/pr21038c-now.d: Likewise.
* testsuite/ld-x86-64/pr21038c.d: Likewise.

Revert "PR28824, relro security issues, x86 keep COMMONPAGESIZE relro"

This reverts commit 31b4d3a16f200bf04db8439a63b72bba7af4e1be.

Automatic date update in version.in

sim/testsuite/cris: If failing compilation, mark C tests as errors

...when we know we have a working compiler.  This will reduce
the risk of faulty edits by exposing them rather than hiding
them as "unresolved".  It also harmonizes behavior with that of
run_sim_test.

* c/c.exp: Mark C tests failing compilation test errors.

sim/testsuite/cris: Remove faulty use of basename in C tests

Calls to basename were added here as part of commit
e1e1ae6e9b5e "sim: testsuite: fix objdir handling", but that
commit missed adding "#include <libgen.h>" or the equivalent
GNU extension, see basename(3).  Fixing that shows a logical
error in the change to openpf1.c; the non-/-prefixed
code-path was changed instead of the "/"-prefixed code-path,
which is the one executed after that commit.

For "newlib" these tests failed linking after that commit.
Recent newlib has the (asm-renamed) GNU-extension-variant of
basename, but we're better off not using it at all.

Unfortunately, compilation failures for C tests run by the
machinery in c.exp are currently just marked "unresolved",
in contrast to C and assembler tests run by calling
run_sim_test.

The interaction of calling with the full program-path vs.
use of --sysroot exposes a consistency problem: when
--sysroot is used, argv[0] isn't the path by which the
program can find itself.  It's undecided whether argv[0] for
the program running in the simulator should be edited
(related to the naked argument to the simulator before
passing on to the simulated program) to remove a leading
--sysroot.  Either way, such a change would be out of scope
for this commit.

* c/stat3.c (mybasename): New macro.  Use it instead of basename.
* c/openpf1.c: Correct basename-related change and update related
comment.

sim: Add sim_dump_memory for debugging

Intended to be called from the debugger tool.

sim/common:
* sim-memopt.c (sim_dump_memory): New function.

sim: Fix use of out-of-tree assembler and linker when testing

With commit 7a259895bb2d "sim: testsuite: expand arch specific
toolchain settings", trying to use out-of-tree ld and as at test-time
broke for the "primary target", like when testing a release-tarball.

Subsequent to that commit, all assembler tests without in-tree-built
tools FAIL, getting errors when trying to call
$(abs_builddir)/../gas/as-new.  But, that isn't the actual culprint;
it's actually it's its immediate predecessor, commit 8996c21067373
"sim: testsuite: setup per-port toolchain settings for multitarget
build", which hardcodes in-tree-paths to those tools instead of
considering e.g. $(<X>_FOR_TARGET), the preferred overridable variable
for single-target builds, as set up by the toplevel Makefile.

This commit calls GCC_TARGET_TOOL (a deceptive name; gcc-specific
features aren't used) from toplev/config/acx.m4, somewhat like calls
in toplev/configure.ac but without the NCN_STRICT_CHECK_TARGET_TOOLS
step, for each X to find a value for $(<X>_FOR_TARGET).  N.B.: in-tree
tools still override any ${target}-${tool} found in $PATH, i.e. only
previously broken builds are affected.

The variables $(<X>_FOR_TARGET) are usually overridden by the toplevel
Makefile to the same value or better, but has to be set here too, as
automake "wants" Makefiles to be self-contained (you get an error
pointing out that the variable may be empty).  If it hadn't been for
that, SIM_AC_CHECK_TOOLCHAIN_FOR_PRIMARY_TARGET would not be needed.
This detail should only (positively) affect users invoking "make
check" in sim/ instead of "make check-sim" (or "make check") at the
toplevel.  Now the output from "configure" matches the target tools
actually used by sim at test-time, for the "primary target".

Using $(CC) for "example-" targets CC_FOR_TARGET is not changed, as
that appears to be a deliberate special-case.

Note that all tools still have to be installed and present in
$PATH at configure-time to be properly used at test-time.

sim:
* m4/sim_ac_toolchain.m4 (SIM_AC_CHECK_TOOLCHAIN_FOR_PRIMARY_TARGET):
New defun.
(SIM_TOOLCHAIN_VARS): Call it using AC_REQUIRE, and use variables
AS_FOR_TARGET, LD_FOR_TARGET and CC_FOR_TARGET instead of hard-coded
values.
* Makefile.in, configure: Regenerate.