[gdb/testsuite] Add warning for timeout in accept_gdb_output

In accept_gdb_output we have:
...
            timeout {
                # Assume a timeout means we somehow missed the
                # expected result, and carry on.
                return 0
            }
...

The timeout is silent, and though in some places the return value is checked,
this is not done consistently, and consequently there are silent timeouts
when running the TUI testsuite (gdb.tui/*.exp and gdb.python/tui*.exp).

Each timeout is 10 seconds, and there are 5 in total in the TUI tests, taking
50 seconds overall:
...
real    1m0.275s
user    0m10.440s
sys     0m1.343s
...

With an entire testsuite run taking about 30 minutes, that is about 2.5% of
the time spent waiting in TUI tests.

Let's make the timeouts visible using a warning, such that they can be fixed.

Tested on x86_64-linux.

Automatic date update in version.in

[gdb/testsuite] Fix auto-indent in gdb.gdb/python-helper.exp

When editing gdb.gdb/python-helper.exp, auto-indent is broken in my editor
(emacs).

The problem is that this:
...
if { 1 } {
    foo "{" "}"<ENTER>bar
}
...
produces this:
...
if { 1 } {
    foo "{" "}"
bar
}
...

Note that this doesn't happen for "{}".

Fix this by using "\{" and "\}".

Tested on x86_64-linux.

[gdb/testsuite] Fix gdb.gdb/python-helper.exp with -O2 -flto

On openSUSE Leap 15.4, with gcc 7.5.0, when building gdb with
-O2 -g -flto=auto, I run into:
...
FAIL: gdb.gdb/python-helper.exp: hit breakpoint in outer gdb
FAIL: gdb.gdb/python-helper.exp: print integer from DWARF info
FAIL: gdb.gdb/python-helper.exp: print *type->main_type
...

Fix the first two FAILs by using $bkptno_numopt_re.

The last FAIL is due to:
...
(outer-gdb) print *type->main_type^M
A syntax error in expression, near `->main_type'.^M
(outer-gdb) FAIL: gdb.gdb/python-helper.exp: print *type->main_type
...
because:
...
(outer-gdb) print type^M
Attempt to use a type name as an expression^M
...

Fix this by making the test unresolved if "print type" or
"print type->main_type" doesn't succeed.

On openSUSE Tumbleweed, with gcc 13.0.1, when building gdb with
-O2 -g -flto=auto, I run into timeouts due to the breakpoint in c_print_type
not hitting.  Fix this by detecting the situation and bailing out.

Tested on x86_64-linux.

[gdb/testsuite] Fix -wrap in presence of -prompt in gdb_test_multiple

While writing a gdb_test_multiple call in a test-case I tried to use -wrap in
combination with -prompt and found out that it doesn't work, because -wrap uses
"$gdb_prompt $" instead of $prompt_regexp.

Fix this by making -wrap use $prompt_regexp.

Tested on x86_64-linux.

gdb: remove end_stepping_range observable

I noticed that this observable was never notified, which means we can
probably safely remove it.  The notification was removed in:

    commit 243a925328f8e3184b2356bee497181049c0174f
    Author: Pedro Alves <palves@redhat.com>
    Date:   Wed Sep 9 18:23:24 2015 +0100

        Replace "struct continuation" mechanism by something more extensible

print_end_stepping_range_reason in turn becomes unused, so remote it as
well.

Change-Id: If5da5149276c282d2540097c8c4327ce0f70431a

[gdb/testsuite] Use -std=gnu99 for gdb.server/attach-flag.exp

When using a compiler defaulting to -std=gnu90, we run into:
...
Running gdb.server/attach-flag.exp ...
gdb compile failed, attach-flag.c: In function 'main':
attach-flag.c:22:3: error: 'for' loop initial declarations are only allowed \
  in C99 or C11 mode
   for (int i = 0; i < NTHREADS; i++)
   ^~~
attach-flag.c:22:3: note: use option -std=c99, -std=gnu99, -std=c11 or \
  -std=gnu11 to compile your code
...

Fix this by using -std=gnu99.

Tested on x86_64-linux.

[gdb/testsuite] Require GCC >= 5.x.x in gdb.base/utf8-identifiers.exp

Test-case gdb.base/utf8-identifiers.exp compiles starting with GCC 5, so
require this.

Tested on x86_64-linux.

[gdb/testsuite] Fix gdb.multi/multi-arch.exp on powerpc64le

When running test-case gdb.multi/multi-arch.exp on powerpc64le-linux, I run into:
...
Running gdb/testsuite/gdb.multi/multi-arch.exp ...
gdb compile failed, In file included from /usr/include/features.h:399:0,
                 from /usr/include/stdio.h:27,
                 from gdb/testsuite/gdb.multi/hangout.c:18:
/usr/include/gnu/stubs.h:8:27: fatal error: gnu/stubs-32.h: \
  No such file or directory
 # include <gnu/stubs-32.h>
                           ^
compilation terminated.
...

The problem is that the test-case attempts to use gcc -m32 to produce an
executable while that's not available.

Fix this by:
- introduce a new caching proc have_compile_and_link_flag, and
- using have_compile_and_link_flag in test-case gdb.multi/multi-arch.exp.

Tested on:
- x86_64-linux (openSUSE Leap 15.4), and
- powerpc64le-linux (CentOS-7).

[gdb/testsuite] Add basic lmap for tcl < 8.6

With test-case gdb.dwarf2/dw2-abs-hi-pc.exp and tcl 8.5, I run into:
...
ERROR: tcl error sourcing gdb/testsuite/gdb.dwarf2/dw2-abs-hi-pc.exp.
ERROR: invalid command name "lmap"
    while executing
"::gdb_tcl_unknown lmap i {dw2-abs-hi-pc.c dw2-abs-hi-pc-hello.c \
  dw2-abs-hi-pc-world.c} { expr { "$srcdir/$subdir/$i" } }"
...

Fix this by adding basic lmap support for tcl version < 8.6.

Tested on x86_64-linux.

[gdb/testsuite] Don't use string cat in gdb.dwarf2/dw2-abs-hi-pc.exp

Test-case gdb.dwarf2/dw2-abs-hi-pc.exp uses string cat:
...
set sources [lmap i $sources { string cat "${srcdir}/${subdir}/" $i }]
...
but that's only supported starting tcl 8.6.

Fix this by using "expr" instead:
...
set sources [lmap i $sources { expr { "$srcdir/$subdir/$i" } }]
...

Tested on x86_64-linux.

New georgian translation for the bfd sub-directory

Revert "x86: work around compiler diagnosing dangling pointer"

This reverts commit 983db9932a302f9e2ae1f1d4fd7c3149560bc269.

gcc-13 i386-dis.c warning

opcodes/i386-dis.c: In function ‘print_insn’:
opcodes/i386-dis.c:9865:22: error: storing the address of local
variable ‘priv’ in ‘*info.private_data’ [-Werror=dangling-pointer=]

* i386-dis.c (print_insn): Clear info->private_data before
returning.

asan: segfault in coff_mangle_symbols

The testcase managed to trigger creation of a wild pointer in
coff_slurp_symbol_table.  Stop that happening, and fix an unrelated
problem I happened to see in bfd_coff_get_syment.

* coff-bfd.c (bfd_coff_get_syment): Clear fix_value after
converting n_value from a pointer to an index.
* coffcode.h (coff_slurp_symbol_table <C_BSTAT>): Sanity check
symbol value before converting to a pointer.

objcopy of archives tidy

This makes sure the input element bfd is closed before exiting the
loop copying elements.

* objcopy.c (copy_archive): Rename output_bfd to output_element.
Localise last_element.  Close this_element in more error cases.

[gdb/testsuite] Skip dap tests for tcl 8.5

When running the dap tests on a system with tcl 8.5, we run into:
...
ERROR: tcl error sourcing gdb/testsuite/gdb.dap/memory.exp.
ERROR: bad class "entier": must be alnum, alpha, ascii, control, boolean, \
  digit, double, false, graph, integer, list, lower, print, punct, space, \
  true, upper, wideinteger, wordchar, or xdigit
    while executing
"string is entier $num"
    (procedure "num" line 16)
    invoked from within
...

Fix this by:
- requiring tcl 8.6 in allow_dap_tests, and
- adding the missing require allow_dap_tests in gdb.dap/memory.exp.

Tested on x86_64-linux.

x86: work around compiler diagnosing dangling pointer

For quite come time print_insn() has been storing the address of a local
variable into info->private_data. Since the compiler can't know that the
field won't be accessed again after print_insn() returns, it may kind of
legitimately diagnose this. And recent enough gcc does as of the
introduction of the fetch_error() return paths (replacing setjmp()-based
error handling).

Utilizing that neither prefix_name() nor i386_dis_printf() actually use
info->private_data, zap the pointer in fetch_error(), after having
retrieved it for local use.

Automatic date update in version.in

MIPS: fix loongson3 llsc workaround

-mfix-looongson3-llsc may add sync instructions not needed on some
asm code with lots of debug info.

PR: 30153
* gas/config/tc-mips.c(fix_loongson3_llsc): clear logistic.

MIPS: default output r6 obj if the triple is r6

If the triple is mipsisa32r6* or mipsisa64r6*, ld/as should output
r6 objects by default.
The triples with vendor `img` should do same.

The examples include:
as xx.s -o xx.o
ld -r -b binary xx.dat -o xx.o

MIPS: support mips*64 as CPU and gnuabi64 as ABI

For MIPS64r6 ports, Debian as an example, `mipsisa64r6el` is
used as the cpu name in triple.
Let's recognize them by `mips*64*(el)`.

For 64bit Ports, like Debian's mips64el and mips64r6el ports,
`gnuabi64` is used as the abi section.
Let's use N64 abi by default for the triple with gnuabi64.

LoongArch: Fix loongarch32 test fails

Regenerated macro_op_32.d and add skip loongarch64-*-*.

gas/ChangeLog:

* testsuite/gas/loongarch/macro_op_32.d: Regenerated.

ld/ChangeLog:

* testsuite/ld-loongarch-elf/macro_op_32.d: Regenerated.

Automatic date update in version.in

[gdb/testsuite] Remove debug prints in gdb_find_gdc

When running the gdb.dlang test-cases, and forcing gdb_find_gdc to be used
rather than dejagnu's copy (mimicing what happens with an older dejagnu
without find_gdc), I run into these debug prints:
...
Tool Root: /data/vries/gdb/leap-15-4/build
CC: gdc
...

Remove these.

Tested on x86_64-linux.

gdb: Fix false match issue in skip_prologue_using_linetable

[ Changes in v2:
  - rebase on trunk
  Changes in v3:
  - add test-case ]

We should exclude matches to the ending PC to prevent false matches with the
next function, as prologue_end is located at the end PC.

  <fun1>:
    0x00: ... <-- start_pc
    0x04: ...
    0x08: ... <-- breakpoint
    0x0c: ret
  <fun2>:
    0x10: ret <-- end_pc | prologue_end of fun2

Tested on x86_64-linux.

Co-Authored-By: WANG Rui <r@hev.cc> (fix, tiny change [1])
Co-Authored-By: Tom de Vries <tdevries@suse.de> (test-case)
Approved-by: Kevin Buettner <kevinb@redhat.com>
[1] https://www.gnu.org/prep/maintain/html_node/Legally-Significant.html

PR symtab/30369
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30369

Automatic date update in version.in

gdb: remove language_auto

I think that the language_auto enumerator and the auto_language class
can be removed.  There isn't really an "auto" language, it's only a
construct of the "set language" command to say "pick the appropriate
language automatically".  But "auto" is never the current language.  The
`current_language` points to the current effective language, and the
fact that we're in "auto language" mode is noted by the language_mode
global.

 - Change set_language to handle the "auto" (and "local", which is a
   synonym) early, instead of in the for loop.  I think it makes the two
   cases (auto vs explicit language) more clearly separated anyway.

 - Adjust add_set_language_command to hard-code the "auto" string,
   instead of using the "auto" language definition.

 - Remove auto_language, rename auto_or_unknown_language to
   unknown_language and move the bits of the existing unknown_language
   in there.

 - Remove the set_language at the end of _initialize_language.  I think
   it's not needed, because we call set_language in gdb_init, after all
   _initialize functions are called.  There is some chance that an
   _initialize function that runs after _initialize_language implicitly
   depends on current_language being set, but my testsuite runs haven't
   found anything like that.

 - Use language_unknown instead of language_auto when creating a minimal
   symbol (minimal_symbol_reader::record_full).  I think that this value
   is used to indicate that we don't know the symbol of the minimal
   symbol (yet), so language_unknown makes sense to me.  Update a
   condition accordingly in ada-lang.c.  symbol_find_demangled_name also
   appears to "normalize" this value from "unknown" to "auto", remove
   that part and update the condition to just check for
   language_unknown.

Change-Id: I47bcd6c15f607d9818f2e6e413053c2dc8ec5034
Reviewed-By: Tom Tromey <tom@tromey.com>

gdb: switch "set language" to getter/setter

The `language` global variable is mostly a scratch variable used for the
setting.  The source of truth is really current_language and
language_mode (auto vs manual), which are set by the
set_language_command callback.

Switch the setting to use the add_setshow_enum_cmd overload that takes a
value getter and setter.

Change-Id: Ief5b2f93fd7337eed7ec96023639ae3dfe62250b
Reviewed-By: Tom Tromey <tom@tromey.com>

gdb: remove return value of set_language

set_language returns the previous language, but nothing uses it.  Remove
the return value.  This lets us remove the assignment to
current_language, in _initialize_language.

Change-Id: Ifccf9b488434c1addf4626130a74e159a37d8c17
Reviewed-By: Tom Tromey <tom@tromey.com>

[gdb/testsuite] Add make-check-all.sh

Directory gdb/testsuite/boards contains a number of host/target boards, which
run a test-case (or test-cases) in a different way.

The benefits of using these boards are:
- improving test coverage of gdb,
- making the testsuite more robust, and
- making sure the test-cases work for non-native and remote setups, if
  possible.

Each board is slightly different, and developers need to learn how to use each
one, what parameters to pass and how, and which ones can be used in
combination with each other.  This is a threshold to start using them.

And then there quite a few, so I suppose typically only a few will be used by
each developer.

Add script gdb/testsuite/make-check-all.sh, that's intended to function as a
drop-in replacement of make check, while excercising all host/target boards in
gdb/testsuite/boards.

An example of make-check-all.sh for one test-case is:
...
 $  ~/gdb/src/gdb/testsuite/make-check-all.sh gdb.base/advance.exp
 LOCAL:
 # of expected passes            8
 TARGET BOARD: cc-with-gdb-index
 # of expected passes            8
   ...
 HOST BOARD: local-remote-host-notty, TARGET BOARD: remote-stdio-gdbserver
 # of expected passes            8
 HOST/TARGET BOARD: local-remote-host-native
 # of expected passes            8
...

Shell-checked and tested on x86_64-linux.

Co-Authored-By: Simon Marchi <simon.marchi@efficios.com>
Reviewed-By: Andrew Burgess <aburgess@redhat.com>

[gdb/cli] Add maint info screen

While working on PRs tui/30337 and cli/30346 I came across various notions of
width in gdb, as reported by gdb, readline, curses and the environment
variables.

As for gdb, readline and the environment variables, the way things work
is:
- Gdb asks readline to detect screen size,
- readline sets the actual screen size in the environment variables
  COLUMNS and LINES,
- readline reports back a screen size to gdb, which may have one column
  less than the actual screen size, to deal with lack of auto-wrap.
  This becomes gdb's notion of screen size (in other words the point where
  we can expect the gdb command line to wrap),
- Gdb then explicitly sets readline's screen size, which readline itself may
  adjust to deal with lack of auto-wrap.  This becomes readlines notion
  of screen size (well, internally the unadjusted one, but it'll report back
  the adjusted one).

Add a command "maint info screen" that prints these notions, both for width
and height.

For TERM=xterm we have:
...
$ TERM=xterm gdb -ex "maint info screen"
Number of characters gdb thinks are in a line is 118.
Number of characters readline reports are in a line is 118.
Number of characters curses thinks are in a line is 118.
Number of characters environment thinks are in a line is 118 (COLUMNS).
Number of lines gdb thinks are in a page is 27.
Number of lines readline reports are in a page is 27.
Number of lines curses thinks are in a page is 27.
Number of lines environment thinks are in a page is 27 (LINES).
...

And for TERM=ansi:
...
$ TERM=ansi gdb -ex "maint info screen"
Number of characters gdb thinks are in a line is 117.
Number of characters readline reports are in a line is 116.
Number of characters curses thinks are in a line is 118.
Number of characters environment thinks are in a line is 118 (COLUMNS).
Number of lines gdb thinks are in a page is 27.
Number of lines readline reports are in a page is 27.
Number of lines curses thinks are in a page is 27.
Number of lines environment thinks are in a page is 27 (LINES).
...

[ The fact that we have "characters readline reports are in a line is 116" is
is due to gdb making readline adjust twice for the lack of auto-wrap, this is
PR cli/30346.

Likewise we can detect tui/30337 by doing a resize in TUI mode and doing
"maint info screen":
...
Number of characters characters curses thinks are in a line is 110.
Number of characters environment thinks are in a line is 111 (COLUMNS). ]

And for TERM=ansi, with width and heigth set to 0:
...
Number of characters gdb thinks are in a line is 4294967295 (unlimited).
Number of characters readline reports are in a line is 32766 (unlimited - 1).
Number of characters curses thinks are in a line is 118.
Number of characters environment thinks are in a line is 118 (COLUMNS).
Number of lines gdb thinks are in a page is 4294967295 (unlimited).
Number of lines readline reports are in a page is 32767 (unlimited).
Number of lines curses thinks are in a page is 27.
Number of lines environment thinks are in a page is 27 (LINES).
...

[ Note that when doing a resize by say maximizing or de-maximizing a terminal,
all reported values are updated, except for curses when not in TUI mode.

Maybe that means there's a bug.  If not, then maybe we should not print
the curses lines unless in TUI mode, or annotate those lines such that it's
clear that the values may be not up-to-date. ]

I'd like to use this command in the regression test for PR cli/30346.

Tested on x86_64-linux.

Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Reviewed-By: Tom Tromey <tom@tromey.com>

Fix -Wmaybe-uninitialized warning in opcodes/i386-dis.c

A recent change in opcodes/i386-dis.c caused a build failure on my
x86-64 Fedora 36 system, which uses:

$ gcc --version
gcc (GCC) 12.2.1 20221121 (Red Hat 12.2.1-4)
[...]

The error is:

../../binutils-gdb/opcodes/i386-dis.c: In function ‘OP_J’:
../../binutils-gdb/opcodes/i386-dis.c:12705:22: error: ‘val’ may be used uninitialized [-Werror=maybe-uninitialized]
12705 |           disp = val & 0x8000 ? val - 0x10000 : val;
      |                  ~~~~^~~~~~~~

This patch fixes the warning.

opcodes/ChangeLog
2023-04-21  Tom Tromey  <tromey@adacore.com>

* i386-dis.c (OP_J): Check result of get16.

Use entry values for 32-bit PPC struct return

AdaCore has a local patch for PPC "finish", but last year, Ulrich
Weigand pointed out that this patch was incorrect.  It may work for
simple functions like the one in the internal test, but nothing
guarantees that r3 will be preserved by the callee, so checking r3 on
exit is not always correct.

This patch fixes the problem using the same approach as PPC64: use the
entry value of r3, if available.  Ulrich confirmed this matches the
PPC32 ABI.

Handle erroneous DW_AT_call_return_pc

On PPC64, with the test case included in an earlier patch, we found
that "finish" would still not correctly find the return value via
entry values.

The issue is simple.  The compiler emits:

   0x00000000100032b8 <+28>: bl      0x1000320c <pck__create_large>
   0x00000000100032bc <+32>: nop
   0x00000000100032c0 <+36>: li      r9,42

... but the DWARF says:

    <162a>   DW_AT_call_return_pc: 0x100032c0

That is, the declared return PC is one instruction past the actual
return PC.

This patch adds a new arch hook to handle this scenario, and
implements it for PPC64.  Some care is taken so that GDB will continue
to work if this compiler bug is fixed.  A GCC patch is here:

    https://gcc.gnu.org/pipermail/gcc-patches/2023-March/613336.html

No check for 'nop' is done, as subsequent discussion revealed that the
linker might replace this with another instruction.

Handle function descriptors in call_site_target

call_site_target::iterate_over_addresses may look up a minimal symbol.
On platforms like PPC64 that use function descriptors, this may find
an unexpected address.  The fix is to use gdbarch_convert_from_func_ptr_addr
to convert from a function descriptor to the address recorded at the
call site.

I've added a new test case that is based on the internal AdaCore test
that provoked this bug.  However, I'm unable to test it as-is on
PPC64.

x86: drop (explicit) BFD64 dependency from disassembler

get64() is unreachable when !BFD64 (due to a check relatively early in
print_insn()). Let's avoid the associated #ifdef-ary (or else we should
extend it to remove more dead code).

x86: drop use of setjmp() from disassembler

With the longjmp() uses all gone, the setjmp() isn't necessary anymore
either.

x86: change fetch error handling for get<N>()

Make them return boolean and convert FETCH_DATA() uses to fetch_code().
With this no further users of FETCH_DATA() remain, so the macro and its
backing function are dropped as well.

Leave value types as they were for the helper functions, even if I don't
think that beyond get64() use of bfd_{,signed_}vma is really necessary.
With type change of "disp" in OP_E_memory(), change the 2nd parameter of
print_displacement() to a signed type as well, though (eliminating the
need for a local variable of signed type). This also eliminates the need
for custom printing of '-' in Intel syntax displacement expressions.

While there drop forward declarations which aren't really needed.

x86: change fetch error handling when processing operands

Make the handler functions all return boolean and convert FETCH_DATA()
uses to fetch_code().

x86: change fetch error handling in get_valid_dis386()

Introduce a special error indicator node, for the sole (real) caller
to recognize and act upon.

x86: change fetch error handling in ckprefix()

Use a tristate (enum) return value type to be able to express all three
cases which are of interest to the (sole) caller. This also allows doing
away with the abuse of "rex_used".

x86: change fetch error handling in top-level function

... and its direct helper get_sib(). Using setjmp()/longjmp() for fetch
error handling is problematic, as per
https://sourceware.org/pipermail/binutils/2023-March/126687.html. Start
using more conventional error handling instead.

Also introduce a fetch_modrm() helper, for subsequent re-use.

x86: move fetch error handling into a helper function

... such that it can be used from other than the setjmp() error handling
path.

Since I'd like the function's parameter to be pointer-to-const, two
other functions need respective constification then, too (along with
needing to be forward-declared).

bfd: fix STRICT_PE_FORMAT build

A semicolon was missing and "name" needs to be pointer-to-const. While
adding "const" there, also add it for "sec".

RISC-V: Optimize relaxation of gp with max_alignment.

This should be the first related issue, which posted in riscv-gnu-toolchain,
https://github.com/riscv-collab/riscv-gnu-toolchain/issues/497

If the output sections are not between gp and the symbol, then their alignments
shouldn't affect the gp relaxation.  However, this patch improves this idea
even more, it limits the range to the gp+-2k, which means only the output
section which are in the [gp-2K, gp+2K) range need to be considered.

Even if the output section candidates may be different for each relax passes,
the symbol that can be relaxed ar this round will not be truncated at next
round.  That is because this round you can do relaxation which means that the
section where the symbol is located is within the [gp-2K, gp+2K) range, so all
the output section alignments between them should be considered.  In other
words, if the alignments between them may cause truncated, then we should
already preserve the size and won't do the gp relaxation this time.

This patch can resolve the github issue which mentioned above, and also passed
all gcc/binutils regressions of riscv-gnu-toolchain, so should be worth and
safe enough to commit.

Originally, this patch also do the same optimization for the call relaxations,
https://sourceware.org/pipermail/binutils/2022-October/123918.html
But just in case there is something that has not been considered, we only
deal with the gp relaxation at this time.

bfd/
* elfnn-riscv.c (riscv_elf_link_hash_table): Added new bfd_vma,
max_alignment_for_gp.  It is used to record the maximum alignment of
the output sections, which are in the [gp-2K, gp+2k) range.
(riscv_elf_link_hash_table_create): Init max_alignment_for_gp to -1.
(_bfd_riscv_get_max_alignment): Added new parameter, gp.  If gp is
zero, then all the output section alignments are possible candidates;
Otherwise, only the output sections which are in the [gp-2K, gp+2K)
range need to be considered.
(_bfd_riscv_relax_lui): Called _bfd_riscv_get_max_alignment with the
non-zero gp if the max_alignment_for_gp is -1.
(_bfd_riscv_relax_pc): Likewise.
(_bfd_riscv_relax_section): Record the first input section, so that
we can reset the max_alignment_for_gp for each repeated relax passes.
ld/
* testsuite/ld-riscv-elf/ld-riscv-elf.exp: Updated.
* testsuite/ld-riscv-elf/relax-max-align-gp.*: New testcase.  It fails
without this patch.

ld: add missing period after @xref

At least older versions of one of the doc generation tools complain
(warn) about it missing.

Keeping track of rs6000-coff archive element pointers

rs6000-coff archives use a linked list of file offsets, where each
element points to the next element.  The idea is to allow updating of
large archives quickly without rewriting the whole archive.  (binutils
ar does not do this.)  Unfortunately this is an easy target for
fuzzers to create an archive that will cause ar or any other tool
processing archives to hang.  I'd implemented guards against pointing
back to the previous element, but of course that didn't last long.

So this patch implements a scheme to keep track of file offset ranges
used by elements as _bfd_read_ar_hdr is called for each element.  See
the add_range function comment.  I needed a place to stash the list,
so chose the obvious artdata.tdata backend extension to archive's
tdata, already used by xcoff.  That involved a little cleanup, because
while it would be possible to continue using different artdata.tdata
for the big and small archives, it's nicer to use a union.

If anyone is concerned this list of element ranges might grow large
and thus significantly slow down the tools, adjacent ranges are
merged.  In fact something like "ar t" will only ever have one range
on xcoff archives generated by binutils/ar.  I agree there might still
be a problem with ld random element access via the armap.

include/
* coff/xcoff.h (SIZEOF_AR_FILE_HDR): Use sizeof.
(SIZEOF_AR_FILE_HDR_BIG, SIZEOF_AR_HDR, SIZEOF_AR_HDR_BIG): Likewise.
(struct ar_ranges, struct xcoff_artdata): New.
(x_artdata): Define.
(xcoff_big_format_p): Rewrite.
(xcoff_ardata, xcoff_ardata_big): Delete.
bfd/
* coff-rs6000.c: Replace uses of xcoff_ardata and
xcoff_ardata_big throughout file.
(_bfd_xcoff_archive_p): Adjust artdata.tdata allocation.
(add_range): New function.
(_bfd_xcoff_read_ar_hdr): Use it here.  Fix memory leak.
(_bfd_xcoff_openr_next_archived_file): Remove old sanity
checks.  Set up range for header.
(xcoff_write_archive_contents_old): Make the temporary
artdata.tdata used here to pass info down to
_bfd_compute_and_write_armap a struct xcoff_artdata.
(xcoff_write_archive_contents_big): Likewise.
* coff64-rs6000.c: Replace uses of xcoff_ardata and
xcoff_ardata_big throughout file.
(xcoff64_archive_p): Adjust artdata.tdata allocation.

Delete struct artdata archive_head

This element is unused.  Ideally we'd be moving archive_head and
other archive specific fields from struct bfd to here, but that's a
much larger change than this little bit of cleanup.

* libbfd-in.h (struct artdata): Delete archive_head.
* libbfd.h: Regenerate.
* archive.c,
* coff-rs6000.c,
* coff64-rs6000.c: Delete comments mentioning artdata archive_head.

Automatic date update in version.in

Add a SECURITY.txt file describing the GNU Binutils' project's stance on security related bugs.

x86: adjust an ILP32 testcase using .insn

In commit 6967633c8b49 ("x86: convert testcases to use .insn") an ILP32
clone of a testcase was missed in the set of tests needing --divide
added.

Reported-by: Clément Chigot <chigot@adacore.com>

Automatic date update in version.in

sh4-linux segfaults running ld testsuite

Segmentation fault
FAIL: pr22269-1 (static pie undefined weak)
and others running "visibility (hidden undef)" tests

No code has any right to access bfd_link_hash_entry u.def without
first checking the type, and SYMBOL_REFERENCES_LOCAL isn't sufficient.

* elf32-sh.c (sh_elf_finish_dynamic_symbol): Don't use relative
relocs in GOT unless symbol is defined.

PR30343 infrastructure

Make ldemul_before_plugin_all_symbols_read more useful.

* ldlang.c (lang_process): Move call to
ldemul_before_plugin_all_symbols_read outside BFD_SUPPORTS_PLUGINS.
Allow backends to add to gc_sym_list before handling entry sym.
* ldelf.c (ldelf_before_plugin_all_symbols_read): Test
lto_plugin_active.

ubsan: signed integer overflow in display_debug_lines_raw

This one was caused by me unnecessarily promoting an "int adv" to
"int64_t adv".  The expression overflowing was 4259 + 9223372036854775807
with the left number being unsigned int.

* dwarf.h (DWARF2_Internal_LineInfo): Replace unsigned short
with uint16_t and unsigned char with uint8_t.  Make li_line_base
an int8_t.
* dwarf.c (display_debug_lines_raw): Revert "adv" back to an int.

Yet another out-of-memory fuzzed object

Do I care about out of memory conditions triggered by fuzzers?  Not
much.  Your operating system ought to be able to handle it by killing
the memory hog.  Oh well, this one was an element of a coff-alpha
archive that said it was a little less that 2**64 in size.  The
coff-alpha compression scheme expands at most 8 times, so we can do
better in bfd_get_file_size.

* bfdio.c (bfd_get_file_size): Assume elements in compressed
archive can only expand a maximum of eight times.
* coffgen.c (_bfd_coff_get_external_symbols): Sanity check
size of symbol table agains file size.

buffer overflow in print_symname

* ecoff.c (_bfd_ecoff_slurp_symbolic_info): Zero terminate
string sections.

libsframe: minor formatting fixes in sframe_encoder_write_fre

libsframe/
* sframe.c (sframe_encoder_write_fre): Formatting fixes for
  readability.

libsframe: use consistent function argument names

libsframe/
* sframe.c (sframe_decoder_get_header): Use consistent function
arg names.
(sframe_decoder_free): Likewise.
(sframe_encode): Use more appropriate var name.

sframe: correct some typos

include/
* sframe.h: Correct a typo.

libsframe/
* sframe.c: Likewise.

libsframe: use return type of bool for predicate functions

libsframe/
* sframe.c (sframe_header_sanity_check_p): Change return type to
bool.
(sframe_fre_sanity_check_p): Likewise.

gas: sframe: fix comment

gas: sframe: use ATTRIBUTE_UNUSED consistently

gas/
* gen-sframe.c (sframe_set_version): Use ATTRIBUTE_UNUSED
consistently.
(output_sframe): Likewise.
(sframe_set_fre_info): Remove the usage of ATTRIBUTE_UNUSED.

Remove adjust_type_signedness

I happened across adjust_type_signedness, which may be used to modify
a type when printing an Ada value.  Modifying a type like this is a
bad idea -- they should normally be considered immutable.  Removing
this function still passes both the dejagnu and internal AdaCore
tests, though, so this patch drops it.

As this was reviewed internally, and only affect Ada, I am checking it
in.

Fix: readelf: loc_offset XX too big

  PR 30355
  * dwarf.c (read_and_display_attr_value): Correctly handle DW_loclistx attributes that index a version 5 .debug_loclists section.

gas: document that get_symbol_name() can clobber the input buffer

Callers which want to make further parsing attempts at the buffer passed
to the function need to be aware that due to the potential of string
concatenation the input buffer may be altered in ways beyond what can be
undone by putting back at *input_line_pointer the character that the
function returns.

x86: parse_register() must not alter the parsed string

This reverts the code change done by 100f993c53a5 ("x86: Check
unbalanced braces in memory reference"), which wrongly identified
e87fb6a6d0cd ("x86/gas: support quoted address scale factor in AT&T
syntax") as the root cause of PR gas/30248. (The testcase is left in
place, no matter that it's at best marginally useful in that shape.)

The problem instead is that parse_register() alters the string handed to
it, thus breaking valid assumptions in subsequent parsing code. Since
the function's behavior is a result of get_symbol_name()'s, make a copy
of the incoming string before invoking that function.

Like for parse_real_register() follow the model of strtol() et al: input
string is const-qualified to signal that the string isn't altered, but
the returned "end" pointer is not const-qualified, requiring const to be
cast away (which generally is a bad idea, but the alternative would
again be more convoluted code).

x86: parse_real_register() does not alter the parsed string

Follow the model of strtol() et al - input string is const-qualified to
signal that the string isn't altered, but the returned "end" pointer is
not const-qualified, requiring const to be cast away (which generally is
a bad idea, but the alternative would be more convoluted code).

Updated Hungarian translation for the gprof directory

Automatic date update in version.in

gdb: re-format Python code with black 23

Change-Id: I849d10d69c254342bf01e955ffe62a2b60f9de4b

PowerPC: fix _Float128 type output string

PowerPC supports two 128-bit floating point formats, the IBM long double
and IEEE 128-bit float.  The issue is the DWARF information does not
distinguish between the two.  There have been proposals of how to extend
the DWARF information as discussed in

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104194

but has not been fully implemented.

GCC introduced the _Float128 internal type as a work around for the issue.
The workaround is not transparent to GDB.  The internal _Float128 type
name is printed rather then the user specified long double type.  This
patch adds a new gdbarch method to allow PowerPC to detect the GCC
workaround.  The workaround checks for "_Float128" name when reading the
base typedef from the die_info.  If the workaround is detected, the type
and format fields from the _Float128 typedef are copied to the long
double typedef.  The same is done for the complex long double typedef.

This patch fixes 74 regression test failures in
gdb.base/whatis-ptype-typedefs.exp on PowerPC with IEEE float 128 as the
default on GCC.  It fixes one regression test failure in
gdb.base/complex-parts.exp.

The patch has been tested on Power 10 where GCC defaults to IEEE Float
128-bit and on Power 10 where GCC defaults to the IBM 128-bit float.  The
patch as also been tested on X86-64 with no new regression failures.

Symbols with GOT relocatios do not fix adjustbale

  gas
    * config/tc-loongarch.c (loongarch_fix_adjustable): Symbols with GOT relocatios do not fix adjustbale.
    * testsuite/gas/loongarch/macro_op_large_abs.d: Regenerated.
    * testsuite/gas/loongarch/macro_op_large_pc.d: Regenerated.
  ld
     * testsuite/ld-loongarch-elf/macro_op.d: Regenerated. -

Assembler Internal Docs: Describe handling of opcodes for relaxation a bit better.

RISC-V: Cache the latest mapping symbol and its boundary.

This issue was reported from https://github.com/riscv-collab/riscv-gnu-toolchain/issues/1188

Current flow:
1) Scan any mapping symbol less than this instruciton.
2) If not found, did a backward search.

The flow seems not big issue, let run an example here:

$x:
0x0 a   <--- Found at step 1
0x4 b   <--- Not found in step 1, but found at step 2
0x8 c   <--- Not found in step 1, but found at step 2
$d
0x12 .word 1234 <-- Found at step 1

The instruciton didn't have the same address with mapping symbol will
still did backward search again and again.

So the new flow is:
1) Use the last mapping symbol status if the address is still within the range
   of the current mapping symbol.
2) Scan any mapping symbol less than this instruciton.
3) If not found, did a backward search.
4) If a proper mapping symbol is found in either step 2 or 3, find its boundary,
   and cache that.

Use the same example to run the new flow again:

$x:
0x0 a   <--- Found at step 2, the boundary is 0x12
0x4 b   <--- Cache hit at step 1, within the boundary.
0x8 c   <--- Cache hit at step 1, within the boundary.
$d
0x12 .word 1234 <-- Found at step 2, the boundary is the end of section.

The disassemble time of the test cases has been reduced from ~20 minutes to ~4
seconds.

opcode/ChangeLog
PR 30282
* riscv-dis.c (last_map_symbol_boundary): New.
(last_map_state): New.
(last_map_section): New.
(riscv_search_mapping_symbol): Cache the result of latest
mapping symbol.

objdump use of uninitialised value in pr_string_field

PR 30365
* rdcoff.c (parse_coff_struct_type): Leave bitsize zero when no
auxents.

objdump buffer overflow in fetch_indexed_string

PR 30361
* dwarf.c (fetch_indexed_string): Sanity check string index.

Automatic date update in version.in

gprofng: 30360 Seg. Fault when application uses std::thread

We interpose a lot of libC functions (dlopen, fork, pthread_create, etc.).
Some of these functions have versions. For example,

% nm -D /lib64/gprofng/libgp-collector.so  | grep thread_create@ | sort
000000000004b420 T pthread_create@GLIBC_2.34
000000000004b490 T pthread_create@GLIBC_2.17
000000000004b500 T pthread_create@GLIBC_2.2.5
000000000004b570 T pthread_create@GLIBC_2.1
000000000004b5e0 T pthread_create@GLIBC_2.0

Our library does not set the default version for symbols.
This is correct because we don't know which libC will be used.

gcc and g++ links differently the version symbols when the default version is
not set. c-linker is using our pthread_create@GLIBC_2.34 and c++-linker is using
our pthread_create@GLIBC_2.0 by default.

The current implementation of the interposed functions is:
  If we are in our pthread_create@GLIBC_<NN>,
  we use dlvsym (dlflag, "pthread_create", "GLIBC_<NN>") to find and call
  the same function from libC.
In the test from PR 30360, pthread_create@GLIBC_2.0 is not in the current libC.
We need to call the default version symbol from libC.

gprofng/ChangeLog
2023-04-16  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

PR gprofng/30360
* libcollector/iotrace.c: Find and call a default libC version symbol.
* libcollector/dispatcher.c: Likewise.
* libcollector/iotrace.c: Likewise.
* libcollector/linetrace.c: Likewise.
* libcollector/mmaptrace.c: Likewise.
* libcollector/synctrace.c: Likewise.
* libcollector/collector.h (REAL_DCL): Remove an unused argument.

gprofng: Update documentation

This patch addresses bugzilla 29521:
Bug 29521 - [docs] man pages are not in the release tarball

The dependence on help2man to create the man pages has been eliminated.
All man pages are now written in Texinfo. Texi2pod and pod2man are used
to generate the man pages from the source.

The user guide has been significantly expanded. It also includes all
the man pages. These are formatted appropriately in the INFO, PDF, and
HTML formats.

The index in the user guide has been enhanced to include an overview
of all options and commands that have been documented so far.

The work on the documentation has not been completed, but this is
a significant step forward.

gprofng/ChangeLog
2023-04-15  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

PR gprofng/29521
* doc/Makefile.am: Build documentation.
* doc/gprofng.texi: Update documentation.
* doc/version.texi: Likewise.
* src/Makefile.am: Move the man pages generation to doc/Makefile.am.
* gp-display-html/Makefile.am: Likewise.
* doc/gp-archive.texi: New file.
* doc/gp-collect-app.texi: New file.
* doc/gp-display-html.texi: New file.
* doc/gp-display-src.texi: New file.
* doc/gp-display-text.texi: New file.
* doc/gp-macros.texi: New file.
* doc/gprofng_ug.texi: New file.
* doc/Makefile.in: Rebuild.
* gp-display-html/Makefile.in: Rebuild.
* src/Makefile.in" Rebuild.

Remove some unnecessary casts from ada-lang.c

I noticed some unnecessary casts to LONGEST in ada-lang.c.  This patch
removes the ones I think are very clearly not needed.  I'm checking
this in as obvious.

gdb/amdgpu: add follow fork and exec support

Prior to this patch, it's not possible for GDB to debug GPU code in fork
children or after an exec.  The amd-dbgapi target attaches to processes
when an inferior appears due to a "run" or "attach" command, but not
after a fork or exec.  This patch adds support for that, such that it's
possible to for an inferior to fork and for GDB to debug the GPU code in
the child.

To achieve that, use the inferior_forked and inferior_execd observers.

In the case of fork, we have nothing to do if `child_inf` is nullptr,
meaning that GDB won't debug the child.  We also don't attach if the
inferior has vforked.  We are already attached to the parent's address
space, which is shared with the child, so trying to attach would cause
problems.  And anyway, the inferior can't do anything other than exec or
exit, it certainly won't start GPU kernels before exec'ing.

In the case of exec, we detach from the exec'ing inferior and attach to
the following inferior.  This works regardless of whether they are the
same or not.  If they are the same, meaning the execution continues in
the existing inferior, we need to do a detach/attach anyway, as
amd-dbgapi needs to be aware of the new address space created by the
exec.

Note that we use observers and not target_ops::follow_{fork,exec} here.
When the amd-dbgapi target is compiled in, it will attach (in the
amd_dbgapi_process_attach sense, not the ptrace sense) to native
inferiors when they appear, but won't push itself on the inferior's
target stack just yet.  It only pushes itself if the inferior
initializes the ROCm runtime.  So, if a non-GPU-using inferior calls
fork, an amd_dbgapi_target::follow_fork method would not get called.
Same for exec.  A previous version of the code had the amd-dbgapi target
pushed all the time, in which case we could use the target methods.  But
we prefer having the target pushed only when necessary, it's less
intrusive when doing native debugging that doesn't involve the GPU.

Change-Id: I5819c151c371120da8bab2fa9cbfa8769ba1d6f9
Reviewed-By: Pedro Alves <pedro@palves.net>

gdb: switch to right inferior in fetch_inferior_event

The problem explained and fixed in the previous patch could have also
been fixed by this patch.  But I think it's good change anyhow, that
could prevent future bugs, so here it is.

fetch_inferior_event switches to an arbitrary (in practice, the first) inferior
of the process target of the inferior used to fetch the event.  The idea is
that the event handling code will need to do some target calls, so we want to
switch to an inferior that has target target.

However, you can have two inferiors that share a process target, but with one
inferior having an additional target on top:

        inf 1            inf 2
        -----            -----
                         another target
        process target   process target
        exec             exec

Let's say inferior 2 is selected by do_target_wait and returns an event that is
really synthetized by "another target".  This "another target" could be a
thread or record stratum target (in the case explained by the previous patch,
it was the arch stratum target, but it's because the amd-dbgapi abuses the arch
layer).  fetch_inferior_event will then switch to the first inferior with
"process target", so inferior 1.  handle_signal_stop then tries to fetch the
thread's registers:

    ecs->event_thread->set_stop_pc
      (regcache_read_pc (get_thread_regcache (ecs->event_thread)));

This will try to get the thread's register by calling into the current target
stack, the stack of inferior 1.  This is problematic because "another target"
might have a special fetch_registers implementation.

I think it would be a good idea to switch to the inferior for which the
even was reported, not just some inferior of the same process target.
This will ensure that any target call done before we eventually call
context_switch will be done on the full target stack that reported the
event.

Not all events are associated to an inferior though.  For instance,
TARGET_WAITKIND_NO_RESUMED.  In those cases, some targets return
null_ptid, some return minus_one_ptid (ideally the expected return value
should be clearly defined / documented).  So, if the ptid returned is
either of these, switch to an arbitrary inferior with that process
target, as before.

Change-Id: I1ffc8c1095125ab591d0dc79ea40025b1d7454af
Reviewed-By: Pedro Alves <pedro@palves.net>

gdb: make regcache::raw_update switch to right inferior

With the following patch, which teaches the amd-dbgapi target to handle
inferiors that fork, we end up with target stacks in the following
state, when an inferior that does not use the GPU forks an inferior that
eventually uses the GPU.

    inf 1            inf 2
    -----            -----
                     amd-dbgapi
    linux-nat        linux-nat
    exec             exec

When a GPU thread from inferior 2 hits a breakpoint, the following
sequence of events would happen, if it was not for the current patch.

 - we start with inferior 1 as current
 - do_target_wait_1 makes inferior 2 current, does a target_wait, which
   returns a stop event for an amd-dbgapi wave (thread).
 - do_target_wait's scoped_restore_current_thread restores inferior 1 as
   current
 - fetch_inferior_event calls switch_to_target_no_thread with linux-nat
   as the process target, since linux-nat is officially the process
   target of inferior 2.  This makes inferior 1 the current inferior, as
   it's the first inferior with that target.
 - In handle_signal_stop, we have:

    ecs->event_thread->suspend.stop_pc
      = regcache_read_pc (get_thread_regcache (ecs->event_thread));

    context_switch (ecs);

   regcache_read_pc executes while inferior 1 is still the current one
   (because it's before the `context_switch`).  This is a problem,
   because the regcache is for a ptid managed by the amd-dbgapi target
   (e.g. (12345, 1, 1)), a ptid that does not make sense for the
   linux-nat target.  The fetch_registers target call goes directly
   to the linux-nat target, which gets confused.
 - We would then get an error like:

     Couldn't get extended state status: No such process.

   ... since linux-nat tries to do a ptrace call on tid 1.

GDB should switch to the inferior the ptid belongs to before doing the
target call to fetch registers, to make sure the call hits the right
target stack (it should be handled by the amd-dbgapi target in this
case).  In fact the following patch does this change, and it would be
enough to fix this specific problem.

However, I propose to change regcache to make it switch to the right
inferior, if needed, before doing target calls.  That makes the
interface as a whole more independent of the global context.

My first attempt at doing this was to find an inferior using the process
stratum target and the ptid that regcache already knows about:

      gdb::optional<scoped_restore_current_thread> restore_thread;
      inferior *inf = find_inferior_ptid (this->target (), this->ptid ());
      if (inf != current_inferior ())
{
  restore_thread.emplace ();
  switch_to_inferior_no_thread (inf);
}

However, this caused some failures in fork-related tests and gdbserver
boards.  When we detach a fork child, we may create a regcache for the
child, but there is no corresponding inferior.  For instance, to restore
the PC after a displaced step over the fork syscall.  So
find_inferior_ptid would return nullptr, and
switch_to_inferior_no_thread would hit a failed assertion.

So, this patch adds to regcache the information "the inferior to switch
to to makes target calls".  In typical cases, it will be the inferior
that matches the regcache's ptid.  But in some cases, like the detached
fork child one, it will be another inferior (in this example, it will be
the fork parent inferior).

The problem that we witnessed was in regcache::raw_update specifically,
but I looked for other regcache methods doing target calls, and added
the same inferior switching code to raw_write too.

In the regcache constructor and in get_thread_arch_aspace_regcache,
"inf_for_target_calls" replaces the process_stratum_target parameter.
We suppose that the process stratum target that would be passed
otherwise is the same that is in inf_for_target_calls's target stack, so
we don't need to pass both in parallel.  The process stratum target is
still used as a key in the `target_pid_ptid_regcache_map` map, but
that's it.

There is one spot that needs to be updated outside of the regcache code,
which is the path that handles the "restore PC after a displaced step in
a fork child we're about to detach" case mentioned above.

regcache_test_data needs to be changed to include full-fledged mock
contexts (because there now needs to be inferiors, not just targets).

Change-Id: Id088569ce106e1f194d9ae7240ff436f11c5e123
Reviewed-By: Pedro Alves <pedro@palves.net>

gdb: add maybe_switch_inferior function

Add the maybe_switch_inferior function, which ensures that the given
inferior is the current one.  Return an instantiated
scoped_restore_current_thread object only we actually needed to switch
inferior.

Returning a scoped_restore_current_thread requires it to be
move-constructible, so give it a move constructor.

Change-Id: I1231037102ed6166f2530399e8257ad937fb0569
Reviewed-By: Pedro Alves <pedro@palves.net>

gdb: remove regcache::target

The regcache class takes a process_stratum_target and then exposes it
through regcache::target.  But it doesn't use it itself, suggesting it
doesn't really make sense to put it there.  The only user of
regcache::target is record_btrace_target::fetch_registers, but it might
as well just get it from the current target stack.  This simplifies a
little bit a patch later in this series.

Change-Id: I8878d875805681c77f469ac1a2bf3a508559a62d
Reviewed-By: Pedro Alves <pedro@palves.net>

gdb: add inferior_forked observable

In the upcoming patch to support fork in the amd-dbgapi target, the
amd-dbgapi target will need to be notified of fork events through an
observer, to attach itself (attach in the amd-dbgapi sense, not ptrace
sense) to the new inferior / process.

The reason that this can't be done through target_ops::follow_fork is
that the amd-dbgapi target isn't pushed on the inferior's target stack
right away.  It attaches itself to the process and only pushes itself on
its target stack if and when the inferior initializes the ROCm runtime.

If an inferior that is not using the ROCm runtime forks, we want to be
notified of it, so we can attach to the child, and catch if the child
starts using the ROCm runtime.

So, add a new observable and notify it in follow_fork_inferior.  It will
be used later in this series.

Change-Id: I67fced5a9cba6d5da72b9c7ea1c8397644ca1d54
Reviewed-By: Pedro Alves <pedro@palves.net>

gdb: pass execing and following inferior to inferior_execd observers

The upcoming patch to support exec in the amd-dbgapi target needs to
detach amd-dbgapi from the inferior doing the exec and attach amd-dbgapi
to the inferior continuing the execution.  They may or may not be the
same, depending on the `set follow-exec-mode` setting.  But even if they
are the same, we need to do the detach / attach dance.

With the current observable signature, the observers only receive the
inferior in which execution continues (the "following" inferior).

Change the signature to pass both inferiors, and update all existing
observers.

Change-Id: I259d1ea09f70f43be739378d6023796f2fce2659
Reviewed-By: Pedro Alves <pedro@palves.net>

Add 128-bit integer support to the Ada parser

This adds support for 128-bit integers to the Ada parser.

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

Remove some Ada parser helper functions

These helper functions in the Ada parser don't seem all that
worthwhile to me, so this patch removes them.

Add overload of fits_in_type

This adds an overload of fits_in_type that accepts a gdb_mpz.  A
subsequent patch will use this.

Add 128-bit integer support to the Rust parser

This adds support for 128-bit integers to the Rust parser.

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

Convert long_const_operation to use gdb_mpz

This changes long_const_operation to use gdb_mpz for its storage.

Additions to gdb_mpz

In preparation for adding more 128-bit support to gdb, a few additions
to gdb_mpz are needed.

First, this adds a new 'as_integer_truncate' method.  This method
works like 'as_integer' but does not require the value to fit in the
target type -- it just truncates.

Second, gdb_mpz::export_bits is changed to handle the somewhat unusual
situation of zero-length types.  This can happen for a Rust '()' type;
but I think other languages have zero-bit integer types as well.

Finally, this adds some operator== overloads.

Make the .rsrc section read only.

  PR 30142
  * peXXigen.c (_bfd_XXi_swap_scnhdr_out): Do not force the .rsrc section to be writeable.
  * rescoff.c (write_coff_file): Add the SEC_READONLY flag to the .rsrc section.

[gdb/symtab] Handle empty file name in .debug_line section

With DWARF 5, it's possible to produce an empty file name in the File Name
Table of the .debug_line section:
...
 The File Name Table (offset 0x112, lines 1, columns 2):
  Entry Dir     Name
  0     1       (indirect line string, offset: 0x2d):
...

Currently, when gdb reads an exec containing such debug info, it segfaults:
...
Thread 1 "gdb" received signal SIGSEGV, Segmentation fault.
0x000000000072cd38 in dwarf2_start_subfile (cu=0x2badc50, fe=..., lh=...) at \
  gdb/dwarf2/read.c:18716
18716     if (!IS_ABSOLUTE_PATH (filename) && dirname != NULL)
...
because read_direct_string transforms "" into a nullptr, and we end up
dereferencing the nullptr.

Note that the behaviour of read_direct_string has been present since repo
creation.

Fix this in read_formatted_entries, by transforming nullptr filenames in to ""
filenames.

Tested on x86_64-linux.

Reviewed-By: Tom Tromey <tom@tromey.com>
PR symtab/30357
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30357

Add support for the .gnu.sgstubs section to the linker for ARM/ELF based targets.

  PR 30354
  * emulparams/armelf.sh (OTHER_PLT_SECTIONS): Define in order to handle the .gnu.sgstubs section.

Automatic date update in version.in

Automatic date update in version.in