opcodes/riscv-dis.c: Use bool type whenever possible

Before changing the core disassembler, we take care of minor code clarity
issues and improve readability.

This commit replaces uses of int with bool whenever possible.

opcodes/ChangeLog:

* riscv-dis.c (no_aliases) Change type to bool.
(set_default_riscv_dis_options): Use boolean.
(parse_riscv_dis_option_without_args): Likewise.
(riscv_disassemble_insn): Use boolean keywords.

opcodes/riscv-dis.c: Tidying with spacing

Before changing the core disassembler, we take care of minor code clarity
issues and improve readability.

This commit takes care of improper spacing for code clarity.

opcodes/ChangeLog:

* riscv-dis.c (riscv_disassemble_insn): Tidying with spacing.

opcodes/riscv-dis.c: Tidying with comments/clarity

Before changing the core disassembler, we take care of minor code clarity
issues and improve readability.

First, we need to clarify the roles of variables and code portions.

opcodes/ChangeLog:

* riscv-dis.c (xlen): Move before default_isa_spec. Add comment.
(default_isa_spec, default_priv_spec): Add comment.
(riscv_gpr_names, riscv_fpr_names): Likewise.
(parse_riscv_dis_option_without_args): Likewise.
(parse_riscv_dis_option, parse_riscv_dis_options): Likewise.
(maybe_print_address): Likewise.
(riscv_disassemble_insn): Fix comment about the Zfinx "extension".
Add comment about the riscv_multi_subset_supports call.

RISC-V: Test DWARF register number for "fp"

This commit adds "fp" (x8 or s0) to dw-regnums.{s,d}.

gas/ChangeLog:

* testsuite/gas/riscv/dw-regnums.s: Add "fp".
* testsuite/gas/riscv/dw-regnums.d: Likewise.

RISC-V: Move standard hints before all instructions

Because all standard hints must be placed before corresponding instruction
for the disassembler, they may taint basic RVI instruction section.

This commit moves all standard hints before all basic RVI instructions
to improve maintainability.

opcodes/ChangeLog:

* riscv-opc.c (riscv_opcodes): Move all standard hints before all
standard instructions.

RISC-V: Move certain arrays to riscv-opc.c

This is a part of small tidying (declare tables in riscv-opc.c).

include/ChangeLog:

* opcode/riscv.h (riscv_rm, riscv_pred_succ): Move declarations to
opcodes/riscv-opc.c.  New non-static definitions.

opcodes/ChangeLog:

* riscv-opc.c (riscv_rm, riscv_pred_succ): Move from
include/opcode/riscv.h.  Add description.

ld: Add --undefined-version

This cancels a previous --no-undefined-version.
gold has had --undefined-version for a long time.

Automatic date update in version.in

PowerPC, fix gdb.base/watchpoint.exp on Power 9

Test gdb.base/watchpoint.exp generates 4 test errors on Power 9.  The
test uses the test [target_info exists gdb,no_hardware_watchpoints] to
determine if the processor supports hardware watchpoints.  The check
only examines the processor type to determine if it supports hardware
watchpoints.

The PowerPC processors support hardware watchpoints with the
exception of Power 9. The hardware watchpoint support is disabled on
Power 9.  The test skip_hw_watchpoint_tests must be used to correctly
determine if the PowerPC processor supports hardware watchpoints.

This patch replaces the [target_info exists gdb,no_hardware_watchpoints]
with the skip_hw_watchpoint_tests_p check.  With the patch, the test runs
on Power 9 with hardware watchpoint force-disabled.  The test runs on
all other PowerPC processors with and without hardware watchpoints
enabled.

The patch has been tested on Power 9 to verify the test only runs with
hardware breakpoints disabled.  The patch has been tested on X86-64 with
no regression failures.  The test fails on Power 10 due to an internal GDB
error due to resource management.  The resource management issue will be
addressed in another patch.

[gdb/testsuite] Fix gdb.dwarf2/macro-source-path.exp with -m32

With test-case gdb.dwarf2/macro-source-path.exp and target board unix/-m32, I
run into:
...
as: macro-source-path-gcc11-ld238-dw5-filename-641.o: \
  unsupported relocation type: 0x1^M
...

The problem is that we have 64-bit dwarf so the debug_line offset in the
.debug_macro section is an 8-byte entity, emitted using ".8byte":
...
        .section .debug_macro
.Lcu_macros4:
        .2byte        5                 /* version */
        .byte        3                  /* flags */
        .8byte        .LLlines3         /* debug_line offset */
...
but the linker doesn't support 8-byte relocation types on a 32-bit architecture.

This is similar to what was fixed in commit a5ac8e7fa3b
("[gdb/testsuite] Fix 64-bit dwarf test-cases with -m32") for for instance
.debug_abbrev.

Fix this in the same way, by using _op_offset to emit the debug_line offset.

Tested on x86_64-linux with native and target board unix/-m32.

[gdb/testsuite] Fix gdb.dwarf2/entry-value-typedef.exp with -m32

With test-case gdb.dwarf2/entry-value-typedef.exp and target board unix/-m32,
I run into:
...
builtin_spawn -ignore SIGHUP g++ -fno-stack-protector \
  gdb/testsuite/gdb.dwarf2/entry-value-typedef-amd64.S \
  -fdiagnostics-color=never -Lbuild/libiberty -lm -m32 \
  -o outputs/gdb.dwarf2/entry-value-typedef/entry-value-typedef^M
entry-value-typedef.cpp: Assembler messages:^M
entry-value-typedef.cpp:38: Error: bad register name `%rbp'^M
...

The problem is that the test-cases selects an amd64 .S file based on the check:
...
if { [istarget "x86_64-*-linux*"] } {
...
which is also true for target board unix/-m32 on x86_64-linux.

Fix this by adding the missing is_lp64_target check.

Tested on x86_64-linux, using native and target board unix/-m32.

[gdb/testsuite] Fix gdb.mi/mi-disassemble.exp with -m32

With target board unix/-m32 and test-case gdb.mi/mi-disassemble.exp we have:
...
(gdb) ^M
print/x *((unsigned char *) 0x8048485)^M
&"print/x *((unsigned char *) 0x8048485)\n"^M
~"$9 = 0x83\n"^M
^done^M
(gdb) ^M
PASS: gdb.mi/mi-disassemble.exp: get valueof "*((unsigned char *) 0x8048485)"
FAIL: gdb.mi/mi-disassemble.exp: byte at 0x8048485 matches
...
The test-case passes with native.

With native we see in gdb.log that variable longest_insn_bytes is:
...
Longest instruction at 0x0000000000400549 with bytes '48 8b 05 20 01 00 00'
...
and variable split_bytes (added debug puts) ends up as:
...
SPLIT_BYTES: 48 8b 05 20 01 00 00
...

But with unix/-m32 we have longest_insn_byte:
...
Longest instruction at 0x08048481 with bytes '8d 4c 24 04        '
...
and split_bytes ends up as:
...
SPLIT_BYTES: 8d 4c 24 04 {} {} {} {} {} {} {} {}
...
so the trailing whitespace is translated by split to empty bytes, and the
mismatch FAILs are generated for those.

Fix this by stripping the whitespace, which makes us end up with a different
and indeed longer insn:
...
Longest instruction at 0x08048492 with bytes 'dd 05 98 85 04 08'
...

Tested on x86_64-linux, with native and target board unix/-m32.

Automatic date update in version.in

PowerPC, fix test gdb.base/watchpoint-stops-at-right-insn.exp

Test gdb.base/watchpoint-stops-at-right-insn.exp generates 4 test errors
on Power 9.  The test uses the test [target_info exists gdb,
no_hardware_watchpoints] to determine if the processor supports hardware
watchpoints.  The check only examines the processor type to determine if
it supports hardware watchpoints.  Note, the test works fine on Power 10.

The PowerPC processors support hardware watchpoints with the
exception of Power 9. The hardware watchpoint support is disabled on
Power 9.  The test skip_hw_watchpoint_tests must be used to correctly
determine if the PowerPC processor supports hardware watchpoints.

This patch replaces the [target_info exists gdb,no_hardware_watchpoints]
with the skip_hw_watchpoint_tests_p check.  With the patch, the test is
disabled on Power 9 but runs on all other PowerPC processors.

The patch has been tested on Power 9, Power 10 and X86-64 with no
regression failures.

x86: drop "regmask" static variable

Replace its two uses by more direct checks, paralleling what's already
there for SIMD registers.

[gdb/symtab] Factor out elf_symfile_read_dwarf2

Factor out elf_symfile_read_dwarf2 from elf_symfile_read.  NFC.

Tested on x86_64-linux.

[gdb/testsuite] Fix ctf test-cases on openSUSE Tumbleweed

When running test-case gdb.base/ctf-constvars.exp on openSUSE Tumbleweed (with
system gcc version 12, providing gcc -gctf support, enabling the ctf test-cases
in the gdb testsuite), I run into:
...
(gdb) print vox^M
'vox' has unknown type; cast it to its declared type^M
(gdb) FAIL: gdb.base/ctf-constvars.exp: print vox
...

There are two causes for this:
- the linker flags are missing --ctf-variables, so the information for variable
  vox is missing (reported in PR29468), and
- the executable contains some dwarf2 due to some linked-in glibc objects,
  so the ctf info is ignored (reported in PR29160).

By using:
- -Wl,--ctf-variable,
- -Wl,--strip-debug, and
we can make the test-case and some similar test-cases pass.

Tested on x86_64-linux.

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

[gdb/testsuite] Silence warnings about obsolete -gstabs

When running test-case gdb.base/gdbindex-stabs.exp on openSUSE Tumbleweed (with
gcc 12) I get:
...
gdb compile failed, gdb/testsuite/gdb.base/gdbindex-stabs.c: warning: \
  STABS debugging information is obsolete and not supported anymore
...

Silence the warning by passing quiet to gdb_compile.  Likewise in two other
test-cases.

[gdb/testsuite] Replace remaining -gt with -gctf

With test-cases gdb.base/cvexpr.exp and gdb.base/whatis.exp I run into:
...
gdb compile failed, gcc: error: unrecognized debug output level 't'
...

This is due to using additional_flags=-gt.

Commit ffb3f587933 ("CTF: multi-CU and archive support") replaced
additional_flags=-gt with additional_flags=-gctf in gdb.ctf/*.exp and
gdb.base/ctf-*.exp.

Do the same in these two test-cases.

Tested on x86_64-linux.

[gdb/testsuite] Fix gdb.base/infoline-reloc-main-from-zero.exp with recent ld

On openSUSE Tumbleweed (with ld 2.39) and test-case
gdb.base/infoline-reloc-main-from-zero.exp, I get:
...
gdb compile failed, ld: warning: infoline-reloc-main-from-zero has a LOAD \
  segment with RWX permissions
UNTESTED: gdb.base/infoline-reloc-main-from-zero.exp: \
  infoline-reloc-main-from-zero.exp
...

Fix this by compiling with -Wl,--no-warn-rwx-segments.

Tested on x86_64-linux.

[gdb/testsuite] Fix gdb.base/nested-subp{2,3}.exp with recent ld

On openSUSE Tumbleweed (with ld 2.39) I get for test-case
gdb.base/nested-subp2.exp:
...
gdb compile failed, ld: warning: tmp.o: requires executable stack \
  (because the .note.GNU-stack section is executable)
...

Fix this by compiling with -Wl,--no-warn-execstack.

Likewise in gdb.base/nested-subp3.exp

Tested on x86_64-linux.

[gdb/testsuite] Remove unnecessary perror in some test-cases

On openSUSE Tumbleweed I noticed:
...
UNTESTED: gdb.dwarf2/fission-absolute-dwo.exp: fission-absolute-dwo.exp
ERROR: failed to compile fission-absolute-dwo
...

The ERROR is unnecessary, given that an UNTESTED is already emitted.

Furthermore, it could be argued that it is incorrect because it's not a
testsuite error to not be able to compile something, and UNTESTED or
UNSUPPORTED is more appropriate.

Remove the perror call, likewise in fission-relative-dwo.exp.

Tested on x86_64-linux.

Fix objcopy's error message when it cannot add a .gnu_debuglink section because the section already exists.

PR 29665
* objcopy.c (copy_object): Use the input filename when
reporting that a .gnu_debuglink section already exists.

sim/ppc: Fix core_find_mapping diagnostics

Because "%p" is the pointer conversion specifier to print a pointer in an
implementation-defined manner, the result with format string containing
"0x%p" can be strange.  For instance, core_map_find_mapping prints error
containing "0x0x...." (processor is not NULL) or "0x(null)" (processor is
NULL) on glibc.

This commit replaces "0x%p" with "%p" to prevent unpredictable behavior.

sim/ppc: fixes for arguments to printf style functions

After the recent series of fixes to mark more functions in the
simulator with ATTRIBUTE_PRINTF, there were some build failures in the
ppc sim due, in some cases, to bugs with the arguments being passed,
and in other cases, the issues were (maybe) less serious, with
arguments being the wrong size, or type, for the printf format being
used.

This commit fixes all of the issues that I ran into.

In each case I selected the easiest solution to the problem, which is
usually just casting the argument to the correct type.  If anyone
later on thinks the print format should change, please feel free to do
that.  What we have here should keep the simulator basically working
as it does currently, which is my goal with this commit.

[gdb/contrib] Use OBJCOPY everywhere in cc-with-tweaks.sh

I noticed that the $want_gnu_debuglink code in gdb/contrib/cc-with-tweaks.sh
uses objcopy instead of $OBJCOPY.  Fix this.

Script checked with shellcheck, no new warnings added.

Tested on x86_64-linux.

Re-apply "Pass PKG_CONFIG_PATH down from top-level Makefile"

Commit 228cf97dd3c8 ("Merge configure.ac from gcc project") undid the
change originally done in de83289ef32e ("Pass PKG_CONFIG_PATH down from
top-level Makefile").  Re-apply it.

Change-Id: I91138dfca41c43b05e53e445f62e4b27882536bf

gdb: rename target_read_auxv(target_ops *) to target_read_auxv_raw

Having two overloads of target_read_auxv that don't have the same goals
is confusing.  Rename the one that reads from an explicit target_ops to
target_read_auxv_raw.  Also, it occured to me that the non-raw version
could use the raw version, that reduces duplication a bit.

Change-Id: I28e5f7cecbfcacd0174d4686efb3e4a23b4ad491

Automatic date update in version.in

Re: Merge configure.ac from gcc project

Also copy over config.acx.m4, and regenerate.

gdb: fix auxv caching

There's a flaw in the interaction of the auxv caching and the fact that
target_auxv_search allows reading auxv from an arbitrary target_ops
(passed in as a parameter).  This has consequences as explained in this
thread:

  https://inbox.sourceware.org/gdb-patches/20220719144542.1478037-1-luis.machado@arm.com/

In summary, when loading an AArch64 core file with MTE support by
passing the executable and core file names directly to GDB, we see the
MTE info:

    $ ./gdb -nx --data-directory=data-directory -q aarch64-mte-gcore aarch64-mte-gcore.core
    ...
    Program terminated with signal SIGSEGV, Segmentation fault
    Memory tag violation while accessing address 0x0000ffff8ef5e000
    Allocation tag 0x1
    Logical tag 0x0.
    #0  0x0000aaaade3d0b4c in ?? ()
    (gdb)

But if we do it as two separate commands (file and core) we don't:

    $ ./gdb -nx --data-directory=data-directory -q -ex "file aarch64-mte-gcore" -ex "core aarch64-mte-gcore.core"
    ...
    Program terminated with signal SIGSEGV, Segmentation fault.
    #0  0x0000aaaade3d0b4c in ?? ()
    (gdb)

The problem with the latter is that auxv data gets improperly cached
between the two commands.  When executing the file command, auxv gets
first queried here, when loading the executable:

    #0  target_auxv_search (ops=0x55555b842400 <exec_ops>, match=0x9, valp=0x7fffffffc5d0) at /home/simark/src/binutils-gdb/gdb/auxv.c:383
    #1  0x0000555557e576f2 in svr4_exec_displacement (displacementp=0x7fffffffc8c0) at /home/simark/src/binutils-gdb/gdb/solib-svr4.c:2482
    #2  0x0000555557e594d1 in svr4_relocate_main_executable () at /home/simark/src/binutils-gdb/gdb/solib-svr4.c:2878
    #3  0x0000555557e5989e in svr4_solib_create_inferior_hook (from_tty=1) at /home/simark/src/binutils-gdb/gdb/solib-svr4.c:2933
    #4  0x0000555557e6e49f in solib_create_inferior_hook (from_tty=1) at /home/simark/src/binutils-gdb/gdb/solib.c:1253
    #5  0x0000555557f33e29 in symbol_file_command (args=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1) at /home/simark/src/binutils-gdb/gdb/symfile.c:1655
    #6  0x00005555573319c3 in file_command (arg=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1) at /home/simark/src/binutils-gdb/gdb/exec.c:555
    #7  0x0000555556e47185 in do_simple_func (args=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1, c=0x612000047740) at /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:95
    #8  0x0000555556e551c9 in cmd_func (cmd=0x612000047740, args=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1) at /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:2543
    #9  0x00005555580e63fd in execute_command (p=0x7fffffffe02c "e", from_tty=1) at /home/simark/src/binutils-gdb/gdb/top.c:692
    #10 0x0000555557771913 in catch_command_errors (command=0x5555580e55ad <execute_command(char const*, int)>, arg=0x7fffffffe017 "file aarch64-mte-gcore", from_tty=1, do_bp_actions=true) at /home/simark/src/binutils-gdb/gdb/main.c:513
    #11 0x0000555557771fba in execute_cmdargs (cmdarg_vec=0x7fffffffd570, file_type=CMDARG_FILE, cmd_type=CMDARG_COMMAND, ret=0x7fffffffd230) at /home/simark/src/binutils-gdb/gdb/main.c:608
    #12 0x00005555577755ac in captured_main_1 (context=0x7fffffffda10) at /home/simark/src/binutils-gdb/gdb/main.c:1299
    #13 0x0000555557775c2d in captured_main (data=0x7fffffffda10) at /home/simark/src/binutils-gdb/gdb/main.c:1320
    #14 0x0000555557775cc2 in gdb_main (args=0x7fffffffda10) at /home/simark/src/binutils-gdb/gdb/main.c:1345
    #15 0x00005555568bdcbe in main (argc=10, argv=0x7fffffffdba8) at /home/simark/src/binutils-gdb/gdb/gdb.c:32

Here, target_auxv_search is called on the inferior's target stack.  The
target stack only contains the exec target, so the query returns empty
auxv data.  This gets cached for that inferior in `auxv_inferior_data`.

In its constructor (before it is pushed to the inferior's target stack),
the core_target needs to identify the right target description from the
core, and for that asks the gdbarch to read a target description from
the core file.  Because some implementations of
gdbarch_core_read_description (such as AArch64's) need to read auxv data
from the core in order to determine the right target description, the
core_target passes a pointer to itself, allowing implementations to call
target_auxv_search it.  However, because we have previously cached
(empty) auxv data for that inferior, target_auxv_search searched that
cached (empty) auxv data, not auxv data read from the core.  Remember
that this data was obtained by reading auxv on the inferior's target
stack, which only contained an exec target.

The problem I see is that while target_auxv_search offers the
flexibility of reading from an arbitrary (passed as an argument) target,
the caching doesn't do the distinction of which target is being queried,
and where the cached data came from.  So, you could read auxv from a
target A, it gets cached, then you try to read auxv from a target B, and
it returns the cached data from target A.  That sounds wrong.  In our
case, we expect to read different auxv data from the core target than
what we have read from the target stack earlier, so it doesn't make
sense to hit the cache in this case.

To fix this, I propose splitting the code paths that read auxv data from
an inferior's target stack and those that read from a passed-in target.
The code path that reads from the target stack will keep caching,
whereas the one that reads from a passed-in target won't.  And since,
searching in auxv data is independent from where this data came from,
split the "read" part from the "search" part.

From what I understand, auxv caching was introduced mostly to reduce
latency on remote connections, when doing many queries.  With the change
I propose, only the queries done while constructing the core_target
end up not using cached auxv data.  This is fine, because there are just
a handful of queries max, done at this point, and reading core files is
local.

The changes to auxv functions are:

 - Introduce 2 target_read_auxv functions.  One reads from an explicit
   target_ops and doesn't do caching (to be used in
   gdbarch_core_read_description context).  The other takes no argument,
   reads from the current inferior's target stack (it looks just like a
   standard target function wrapper) and does caching.

   The first target_read_auxv actually replaces get_auxv_inferior_data,
   since it became a trivial wrapper around it.

 - Change the existing target_auxv_search to not read auxv data from the
   target, but to accept it as a parameter (a gdb::byte_vector).  This
   function doesn't care where the data came from, it just searches in
   it.  It still needs to take a target_ops and gdbarch to know how to
   parse auxv entries.

 - Add a convenience target_auxv_search overload that reads auxv
   data from the inferior's target stack and searches in it.  This
   overload is useful to replace the exist target_auxv_search calls that
   passed the `current_inferior ()->top_target ()` target and keep the
   call sites short.

 - Modify parse_auxv to accept a target_ops and gdbarch to use for
   parsing entries.  Not strictly related to the rest of this change,
   but it seems like a good change in the context.

Changes in architecture-specific files (tdep and nat):

 - In linux-tdep, linux_get_hwcap and linux_get_hwcap2 get split in two,
   similar to target_auxv_search.  One version receives auxv data,
   target and arch as parameters.  The other gets everything from the
   current inferior.  The latter is for convenience, to avoid making
   call sites too ugly.

 - Call sites of linux_get_hwcap and linux_get_hwcap2 are adjusted to
   use either of the new versions.  The call sites in
   gdbarch_core_read_description context explicitly read auxv data from
   the passed-in target and call the linux_get_hwcap{,2} function with
   parameters.  Other call sites use the versions without parameters.

 - Same idea for arm_fbsd_read_description_auxv.

 - Call sites of target_auxv_search that passed
   `current_inferior ()->top_target ()` are changed to use the
   target_auxv_search overload that works in the current inferior.

Reviewed-By: John Baldwin <jhb@FreeBSD.org>
Reviewed-By: Luis Machado <luis.machado@arm.com>
Change-Id: Ib775a220cf1e76443fb7da2fdff8fc631128fe66

[gdb/testsuite] Fix gdb.debuginfod/fetch_src_and_symbols.exp with native-gdbserver

When running test-case gdb.debuginfod/fetch_src_and_symbols.exp with target
board native-gdbserver, I get:
...
Running gdb.debuginfod/fetch_src_and_symbols.exp ...
ERROR: tcl error sourcing gdb.debuginfod/fetch_src_and_symbols.exp.
ERROR: gdbserver does not support start without extended-remote
    while executing
"error "gdbserver does not support $command without extended-remote""
    (procedure "gdb_test_multiple" line 51)
    invoked from within
"gdb_test_multiple $command $message {*}$opts $user_code"
    (procedure "gdb_test" line 56)
    invoked from within
"gdb_test "start" "Temporary breakpoint.*""
...

Fix this by replacing gdb_test "start" with runto_main.

Tested on x86_64-linux.

Re: Error: attempt to get value of unresolved symbol `L0'

* symbols.c (S_GET_VALUE): If the unresolved symbol is the fake
label provide a more helpful error message to the user.
(S_GET_VALUE_WHERE): Like S_GET_VALUE, but includes a file/line
number for error reporting purposes.
* symbols.h (S_GET_VALUE_WHERE): Prototype.
* write.c (fixup_segment): Use S_GET_VALUE_WHERE.

sim: Initialize pbb_br_* by default

On the files generated by sim/common/genmloop.sh, variables pbb_br_type and
pbb_br_npc are declared uninitialized and passed to other functions in some
cases.  Despite that those are harmless, they will generate GCC warnings
("-Wmaybe-uninitialized").

This commit ensures that pbb_br_type and pbb_br_npc variables are
initialized to a harmless value.

sim: Check known getopt definition existence

Clang generates a warning if there is a function declaration/definition
with zero arguments.  Such declarations/definitions without a prototype (an
argument list) are deprecated forms of indefinite arguments
("-Wdeprecated-non-prototype").  On the default configuration, it causes a
build failure (unless "--disable-werror" is specified).

include/getopt.h defines some getopt function definitions but one of them
has a form "extern int getopt ();".  If this form is selected in
include/getopt.h, Clang generates a warning and the build fails by default.

In really old environments, this getopt definition with no arguments is
necessary (because the definition may change between environments).
However, this definition is now a cause of problems on modern environments.

A good news is, this definition is not always selected (e.g. if used by
binutils/*.c).  This is because configuration scripts of binutils, gas,
gprof and ld tries to find known definition of getopt function is used and
defines HAVE_DECL_GETOPT macro.  If this macro is defined when getopt.h is
included, a good form of getopt is used and Clang won't generate warnings.

This commit adds a modified portion of ld/configure.ac to find the known
getopt definition.  If we could find one (and we *will* in most modern
environments), we don't need to rely on the deprecated definition.

sim: Suppress non-literal printf warning

Clang generates a warning if the format string of a printf-like function is
not a literal ("-Wformat-nonliteral"). On the default configuration, it
causes a build failure (unless "--disable-werror" is specified).

To avoid this warning, this commit now uses vsnprintf to format error
message and pass the message to sim_engine_abort function with another
printf-style formatting.

This patch is mostly authored by Andrew Burgess and slightly modified by
Tsukasa OI.

Co-authored-by: Andrew Burgess <aburgess@redhat.com>
Signed-off-by: Tsukasa OI <research_trasio@irq.a4lg.com>

sim: Make WITH_{TRACE,PROFILE}-based macros bool

Clang generates a warning if there is an ambiguous expression (possibly a
bitwise operation (& or |), but a logical operator (&& or ||) is used;
"-Wconstant-logical-operand").  On the default configuration, it causes a
build failure (unless "--disable-werror" is specified).

This is caused by predicate macros that use the form (base_variable & flag).
Clang considers them as regular integer values (not boolean) and
generates that warning.

This commit makes Clang think those predicate macros to be boolean.

sim: Remove self-assignments

Clang generates a warning if there is a redundant self-assignment
("-Wself-assign").  On the default configuration, it causes a build failure
(unless "--disable-werror" is specified).

This commit removes redundant self-assignments from two files.

sim/rl78: Add ATTRIBUTE_PRINTF

Clang generates a warning if the format string of a printf-like function is
not a literal ("-Wformat-nonliteral").  On the default configuration, it
causes a build failure (unless "--disable-werror" is specified).

To avoid warnings on the printf-like wrapper, it requires proper
__attribute__((format)) and we have ATTRIBUTE_PRINTF macro for this reason.

This commit adds ATTRIBUTE_PRINTF to the printf-like functions.

sim/ppc: Add ATTRIBUTE_PRINTF

Clang generates a warning if the format string of a printf-like function is
not a literal ("-Wformat-nonliteral").  On the default configuration, it
causes a build failure (unless "--disable-werror" is specified).

To avoid warnings on the printf-like wrapper, it requires proper
__attribute__((format)) and we have ATTRIBUTE_PRINTF macro for this reason.

This commit adds ATTRIBUTE_PRINTF to the printf-like functions.

For the error function defined in sim_calls.c, the ATTRIBUTE_NORETURN
has been moved to the function declaration.

sim/m68hc11: Add ATTRIBUTE_PRINTF

Clang generates a warning if the format string of a printf-like function is
not a literal ("-Wformat-nonliteral").  On the default configuration, it
causes a build failure (unless "--disable-werror" is specified).

To avoid warnings on the printf-like wrapper, it requires proper
__attribute__((format)) and we have ATTRIBUTE_PRINTF macro for this reason.

This commit adds ATTRIBUTE_PRINTF to a printf-like function.

sim/m32c: Add ATTRIBUTE_PRINTF

Clang generates a warning if the format string of a printf-like function is
not a literal ("-Wformat-nonliteral").  On the default configuration, it
causes a build failure (unless "--disable-werror" is specified).

To avoid warnings on the printf-like wrapper, it requires proper
__attribute__((format)) and we have ATTRIBUTE_PRINTF macro for this reason.

This commit adds ATTRIBUTE_PRINTF to the printf-like functions.

sim/erc32: Add ATTRIBUTE_PRINTF

Clang generates a warning if the format string of a printf-like function is
not a literal ("-Wformat-nonliteral").  On the default configuration, it
causes a build failure (unless "--disable-werror" is specified).

To avoid warnings on the printf-like wrapper, it requires proper
__attribute__((format)) and we have ATTRIBUTE_PRINTF macro for this reason.

This commit adds ATTRIBUTE_PRINTF to the printf-like functions.

sim/cris: Add ATTRIBUTE_PRINTF

Clang generates a warning if the format string of a printf-like function is
not a literal ("-Wformat-nonliteral").  On the default configuration, it
causes a build failure (unless "--disable-werror" is specified).

To avoid warnings on the printf-like wrapper, it requires proper
__attribute__((format)) and we have ATTRIBUTE_PRINTF macro for this reason.

This commit adds ATTRIBUTE_PRINTF to a printf-like function.

sim/common: Add ATTRIBUTE_PRINTF

Clang generates a warning if the format string of a printf-like function is
not a literal ("-Wformat-nonliteral").  On the default configuration, it
causes a build failure (unless "--disable-werror" is specified).

To avoid warnings on the printf-like wrapper, it requires proper
__attribute__((format)) and we have ATTRIBUTE_PRINTF macro for this reason.

This commit adds ATTRIBUTE_PRINTF to a printf-like function.

fix compressed_debug_section_names definition for "zlib"

bfd/ChangeLog:

* libbfd.c: Set COMPRESS_DEBUG_GABI_ZLIB for "zlib" value.

add --enable-default-compressed-debug-sections-algorithm configure option

ChangeLog:

* configure.ac: Add --enable-default-compressed-debug-sections-algorithm.
* configure: Regenerate.

gas/ChangeLog:

* NEWS: Document the new option.
* as.c (flag_compress_debug): Set default algorithm based
on the configure option.
* configure.ac: Add --enable-default-compressed-debug-sections-algorithm.
* configure: Regenerate.
* config.in: Likewise.

ld/ChangeLog:

* NEWS: Document the new option.
* configure.ac: Add --enable-default-compressed-debug-sections-algorithm.
* configure: Regenerate.
* config.in: Likewise.
* ldmain.c: Set default algorithm based
on the configure option.

refactor usage of compressed_debug_section_type

bfd/ChangeLog:

* bfd-in.h (bfd_hash_set_default_size): Add COMPRESS_UNKNOWN
  enum value.
(struct compressed_type_tuple): New.
* bfd-in2.h (bfd_hash_set_default_size): Regenerate.
(struct compressed_type_tuple): Likewise.
* libbfd.c (ARRAY_SIZE): New macro.
(bfd_get_compression_algorithm): New function.
(bfd_get_compression_algorithm_name): Likewise.

gas/ChangeLog:

* as.c: Do not special-case, use the new functions.

ld/ChangeLog:

* emultempl/elf.em: Do not special-case, use the new functions.
* lexsup.c (elf_static_list_options): Likewise.

sim/riscv: fix multiply instructions on simulator

After this commit:

  commit 0938b032daa52129b4215d8e0eedb6c9804f5280
  Date:   Wed Feb 2 10:06:15 2022 +0900

      RISC-V: Add 'Zmmul' extension in assembler.

some instructions in the RISC-V simulator stopped working as a new
instruction class 'INSN_CLASS_ZMMUL' was added, and some existing
instructions were moved into this class.

The simulator doesn't currently handle this instruction class, and so
the instructions will now cause an illegal instruction trap.

This commit adds support for INSN_CLASS_ZMMUL, and adds a test that
ensures the affected instructions can be executed by the simulator.

Reviewed-by: Palmer Dabbelt <palmer@rivosinc.com>
Reviewed-by: Andrew Burgess <aburgess@redhat.com>

Error: attempt to get value of unresolved symbol `L0'

* symbols.c (S_GET_VALUE): If the unresolved symbol is the fake
label provide a more helpful error message to the user.

sim/moxie: add custom directory stamp rule

Because sim/moxie/moxie-gdb.dtb is neither a program nor a library, automake
does not generate dirstamp file ($builddir/sim/moxie/.dirstamp) for it.

When maintainer mode is enabled, it tries to rebuild sim/moxie/moxie-gdb.dtb
but fails because there's no rules for automake-generated dirstamp file
which moxie-gdb.dtb depends.

This commit adds its own rule for the directory stamp (modified copy of the
automake output) and adds the directory stamp file to DISTCLEANFILES to
mimic automake-generated behavior (although "make distclean" does not work
when maintainer mode is enabled).

gdb/testsuite: Fix formatting of python script

The python black formatter was complaining about formatting on the
script gdb.python/pretty-print-call-by-hand.py.  This commit changed
the offending lines to make the formatter happy.

[gdb/testsuite] Fix prompt parsing in capture_command_output

I noticed in capture_command_output that the output of a single command is
matched using two gdb_test_multiples:
- the first one matching the echoed command and skipping an optional prefix,
- the second one matching the output and the prompt.

This is error-prone, because the first gdb_test_multiple has implicit
clauses which may consume the prompt.

The problem is easy to spot with an example.  First consider:
...
set output [capture_command_output "print 1" "\\\$1 = "]
gdb_assert { [string equal $output "1"] }
...
for which we get:
...
PASS: [string equal $output "1"]
...

If we change the prefix string to a no-match, say "1 = ", and update the
output string match accordingly, we get instead:
...
FAIL: capture_command_output for print 1
FAIL: [string equal $output "\$1 = 1"]
...

The first FAIL is produced by the first gdb_test_multiple, consuming the prompt.

The second gdb_test_multiple then silently times out waiting for another prompt,
after which the second FAIL is produced.  Note that the timeout is silent
because the gdb_test_multiple is called with an empty message argument.

The second FAIL is because capture_command_output returns "", given that all
the command output was consumed by the first gdb_test_multiple.

Fix this by rewriting capture_command_output to use only a single
gdb_test_multiple.

Tested on x86_64-linux.

gprofng: no need to build version.texi

gprofng/ChangeLog
2022-10-10  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

PR gprofng/29465
PR gprofng/29667
* doc/Makefile.am: No need to build version.texi.
* doc/Makefile.in: Rebuild.

gprofng: use the --libdir path to find libraries

gprofng/ChangeLog
2022-10-10  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

PR gprofng/29663
* src/Makefile.am: Add -DLIBDIR to CPPFLAGS.
* src/Makefile.in: Rebuild.
* src/envsets.cc (putenv_libcollector_ld_misc): Use LIBDIR to find
the gprofng libraries.

gprofng: run tests without installation

gprofng/ChangeLog
2022-10-10  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

PR gprofng/29107
* testsuite/config/default.exp: Set up environment to run gprofng tests
without installation.
* testsuite/lib/Makefile.skel: Likewise.
* testsuite/lib/display-lib.exp: Likewise.

gdb/testsuite: fix race in gdb.base/async-shell.exp

I see some random failures in this test:

    FAIL: gdb.base/async-shell.exp: run & (timeout)

It can be reliably reproduced on a recent enough GNU/Linux with this
change:

    diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp
    index 44cc28b30051..2a3c8253ba5a 100644
    --- a/gdb/testsuite/lib/gdb.exp
    +++ b/gdb/testsuite/lib/gdb.exp
    @@ -1301,6 +1301,7 @@ proc gdb_test_multiple { command message args } {
         }
         set gdb_test_name "$message"

    +    sleep 2
         set result 0
         set code [catch {gdb_expect $code} string]

"recent enough" means a system where libpthread.so was merged with
libc.so, so at least glibc 2.34.

The problem is that the `run &` command prints some things after the
prompt:

    (gdb) [Thread debugging using libthread_db enabled]
    Using host libthread_db library "/usr/lib/../lib/libthread_db.so.1".

If expect is quick enough, it will consume only up to the prompt.  But
if it is slow enough, it will consume those messages at the same time as
the prompt, in which case the gdb_test used for "run &" won't match.  By
default, the prompt used by gdb_test uses a `$` to anchor the match at
the end of the buffer.  If there's anything following the prompt, it
won't match.

The diff above adds a delay between sending the command and consuming
the output, giving GDB more time to output the messages, giving a good
chance that expect consumes them at the same time as the prompt.

This is normally handled by using gdb_test_multiple and specifying a
pattern that ends with "$gdb_prompt", but not a trailing $.  I think
this is common enough that it deserves its own gdb_test option.
Therefore, add the -no-anchor-prompt option to gdb_test, and
gdb_test_no_output for completeness.  Use it in
gdb.base/async-shell.exp.

Change-Id: I9051d8800d1c10a2e95db1a575991f7723492f1b
Approved-By: Tom de Vries <tdevries@suse.de>

Automatic date update in version.in

Fix a latent bug in print_wchar

print_wchar keeps track of when escape sequences are emitted, to force
an escape sequence if needed by a subsequent character.  For example
for the string concatenation "\0" "1", gdb will print "\000\061" --
because printing "\0001" might be confusing.

However, this code has two errors.  First, this logic is not needed
for octal escapes, because there is a length limit of 3 for octal
escapes, and gdb always prints these with "%.3o".  Second, though,
this *is* needed for hex escapes, because those do not have a length
limit.

This patch fixes these problems and adds the appropriate tests.

Don't use wchar_printable in print_wchar

print_wchar uses wchar_printable, but this isn't needed -- all the
relevant cases are already handled by the 'switch'.  This changes the
code to use gdb_iswprint, and removes a somewhat confusing comment
related to this code.

Remove c_printstr

This renames c_printstr, removing a layer of indirection.

Remove c_emit_char

This renames c_emit_char, removing a layer of indirection.

Boolify need_escape in generic_emit_char

This changes 'need_escape' in generic_emit_char to be of type bool,
rather than int.

Fix latent quote char bug in generic_printstr

generic_printstr prints an empty string like:

      fputs_filtered ("\"\"", stream);

However, this seems wrong to me if the quote character is something
other than double quote.  This patch fixes this latent bug.  Thanks to
Andrew for the test case.

Co-authored-by: Andrew Burgess <aburgess@redhat.com>

Fix the guile build

The frame_info_ptr patches broke the build with Guile.  This patch
fixes the problem.  In mos cases I chose to preserve the use of
frame_info_ptr, at least where I could be sure that the object
lifetime did not interact with Guile's longjmp-based exception scheme.

Tested on x86-64 Fedora 34.

[gdb/testsuite] Detect trailing ^C/^D in command

Detect a trailing ^C/^D in the command argument of gdb_test_multiple, and
error out.

Tested on x86_64-linux.

[gdb/testsuite] Fix error message for cmd with trailing newline

I noticed that the error message in gdb_test_multiple about trailing newline
in a command does not mention the offending command, nor the word command:
...
    if [string match "*\[\r\n\]" $command] {
        error "Invalid trailing newline in \"$message\" test"
    }
...

Fix this by using instead:
...
        error "Invalid trailing newline in \"$command\" command"
...

Also add a test-case to trigger this: gdb.testsuite/gdb-test.exp.

Tested on x86_64-linux.

gdb: include the base address in in-memory bfd filenames

The struct target_buffer (in gdb_bfd.c) is used to hold information
about an in-memory BFD object created by GDB.  For now this mechanism
is used by GDB when loading information about JIT symfiles.

This commit updates target_buffer (in gdb_bfd.c) to be more C++ like,
and, at the same time, adds the base address of the symfile into the
BFD filename.

Right now, every in-memory BFD is given the filename "<in-memory>".
This filename is visible in things like 'maint info symtabs' and
'maint info line-table'.  If there are multiple in-memory BFD objects
then it can be hard to match keep track if which BFD is which.  This
commit changes the name to be "<in-memory@ADDRESS>" where ADDRESS is
replaced with the base address for where the in-memory symbol file was
read from.

As an example of how this is useful, here's the output of 'maint info
jit' showing a single loaded JIT symfile:

  (gdb) maintenance info jit
  jit_code_entry address symfile address    symfile size
  0x00000000004056b0     0x0000000007000000 17320

And here's part of the output from 'maint info symtabs':

  (gdb) maintenance info symtabs
  ...snip...
  { objfile <in-memory@0x7000000> ((struct objfile *) 0x5258250)
    { ((struct compunit_symtab *) 0x4f0afb0)
      debugformat DWARF 4
      producer GNU C17 9.3.1 20200408 (Red Hat 9.3.1-2) -mtune=generic -march=x86-64 -g -fno-stack-protector -fpic
      name jit-elf-solib.c
      dirname /tmp/binutils-gdb/build/gdb/testsuite
      blockvector ((struct blockvector *) 0x5477850)
      user ((struct compunit_symtab *) (null))
   { symtab /tmp/binutils-gdb/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.base/jit-elf-solib.c ((struct symtab *) 0x4f0b030)
     fullname (null)
     linetable ((struct linetable *) 0x5477880)
   }
    }
  }

I've added a new test that checks the new in-memory file names are
generated correctly, and also checks that the in-memory JIT files can
be dumped back out using 'dump binary memory'.

gdb: remove filename arg from gdb_bfd_open_from_target_memory

The filename argument to gdb_bfd_open_from_target_memory was never
used; this argument had a default value of nullptr, and the only call
to this function, in jit.c, relied on the default value.

In the next commit I'm going to make some changes to the
gdb_bfd_open_from_target_memory function, and, though I could take
account of a filename parameter, it seems pointless to maintain an
unused argument.

This commit removes the filename argument.

There should be no user visible changes after this commit.

gdb: add infcall specific debugging

Add two new commands:

  set debug infcall on|off
  show debug infcall

These enable some new debugging related to when GDB makes inferior
function calls.  I've added some basic debugging for what I think are
the major steps in the inferior function call process, but I'm sure we
might want to add more later.

gdb: extra debug output in thread.c

Add some extra 'threads' debug in a couple of places in thread.c.
I've also added an additional gdb_assert in one case.

gdb: improve infrun_debug_show_threads output

This commit switches to use INFRUN_SCOPED_DEBUG_START_END in the
infrun_debug_show_threads function, which means the output will get an
extra level of indentation, this looks a little nicer I think.

Add ability to create reproducible source tarballs.

* src-release.sh: Add "-r <date>" option to create reproducible
tarballs based upon a fixed timestamp of <date>.
* binutils/README-how-to-make-a-release: Add a line showing how to
use -r <date> when creating a binutils release.

gdb/frame: Add reinflation method for frame_info_ptr

Currently, despite having a smart pointer for frame_infos, GDB may
attempt to use an invalidated frame_info_ptr, which would cause internal
errors to happen.  One such example has been documented as PR
python/28856, that happened when printing frame arguments calls an
inferior function.

To avoid failures, the smart wrapper was changed to also cache the frame
id, so the pointer can be reinflated later.  For this to work, the
frame-id stuff had to be moved to their own .h file, which is included
by frame-info.h.

Frame_id caching is done explicitly using the prepare_reinflate method.
Caching is done manually so that only the pointers that need to be saved
will be, and reinflating has to be done manually using the reinflate
method because the get method and the -> operator must not change
the internals of the class.  Finally, attempting to reinflate when the
pointer is being invalidated causes the following assertion errors:

check_ptrace_stopped_lwp_gone: assertion `lp->stopped` failed.
get_frame_pc: Assertion `frame->next != NULL` failed.

As for performance concerns, my personal testing with `time make
chec-perf GDB_PERFTEST_MODE=run` showed an actual reduction of around
10% of time running.

This commit also adds a testcase that exercises the python/28856 bug with
7 different triggers, run, continue, step, backtrace, finish, up and down.
Some of them can seem to be testing the same thing twice, but since this
test relies on stale pointers, there is always a chance that GDB got lucky
when testing, so better to test extra.

Regression tested on x86_64, using both gcc and clang.

Approved-by: Tom Tomey <tom@tromey.com>

Change GDB to use frame_info_ptr

This changes GDB to use frame_info_ptr instead of frame_info *
The substitution was done with multiple sequential `sed` commands:

sed 's/^struct frame_info;/class frame_info_ptr;/'
sed 's/struct frame_info \*/frame_info_ptr /g' - which left some
    issues in a few files, that were manually fixed.
sed 's/\<frame_info \*/frame_info_ptr /g'
sed 's/frame_info_ptr $/frame_info_ptr/g' - used to remove whitespace
    problems.

The changed files were then manually checked and some 'sed' changes
undone, some constructors and some gets were added, according to what
made sense, and what Tromey originally did

Co-Authored-By: Bruno Larsen <blarsen@redhat.com>
Approved-by: Tom Tomey <tom@tromey.com>

Introduce frame_info_ptr smart pointer class

This adds frame_info_ptr, a smart pointer class.  Every instance of
the class is kept on an intrusive list.  When reinit_frame_cache is
called, the list is traversed and all the pointers are invalidated.
This should help catch the typical GDB bug of keeping a frame_info
pointer alive where a frame ID was needed instead.

Co-Authored-By: Bruno Larsen <blarsen@redhat.com>
Approved-by: Tom Tomey <tom@tromey.com>

Remove frame_id_eq

This replaces frame_id_eq with operator== and operator!=.  I wrote
this for a version of this series that I later abandoned; but since it
simplifies the code, I left this patch in.

Approved-by: Tom Tomey <tom@tromey.com>

gdb/testsuite: use 'end' at the end of python blocks

Within the testsuite, use the keyword 'end' to terminate blocks of
Python code being sent to GDB, rather than sending \004.  I could only
find three instances of this, all in tests that I originally wrote.  I
have no memory of there being any special reason why I used \004
instead of 'end' - I assume I copied this from somewhere else that has
since changed.

Non of the tests being changed here are specifically about whether
\004 can be used to terminate a Python block, so I think switching to
the more standard 'end' keyword is the right choice.

gdbsupport: re-generate configure

I get this diff when re-generating configure, probably leftover from
67d1991b785 ("egrep in binutils").

Change-Id: I759c88c2bad648736d33ff98089db45c9b686356

Merge configure.ac from gcc project

To merge with gcc's copy of configure.ac we need to revert changes to
configure.ac in the following gcc commits:
dc832fb39fc0 2022-08-25
fc259b522c0f 2022-06-25
Then reapply configure.ac changes in binutils from these binutils
commits:
50ad1254d503 2021-01-09
bb368aad297f 2022-03-11
e5f2f7d901ee 2022-07-26
2cac01e3ffff 2022-09-26
Plus copy over gcc's config/ax_cxx_compile_stdcxx.m4, then regenerate
configure.

Automatic date update in version.in

Automatic date update in version.in

Merge both implementations of debug_names::insert

The class debug_names has two 'insert' overloads, but only one of them
is ever called externally, and it simply forwards to the other
implementation.  It seems cleaner to me to have a single method, so
this patch merges the two.

[gdb/testsuite] Fix silent fail in gdb.server/connect-with-no-symbol-file.exp

With native and target boards native-gdbserver, remote-gdbserver-on-localhost and
remote-stdio-gdbserver I have for gdb.server/connect-with-no-symbol-file.exp:
...
 # of expected passes            8
...
but with native-extended-gdbserver I have instead:
...
 # of expected passes            8
 # of unexpected failures        4
...

The extra FAILs are of the form:
...
(gdb) detach^M
Detaching from pid process 28985^M
[Inferior 1 (process 28985) detached]^M
(gdb) FAIL: gdb.server/connect-with-no-symbol-file.exp: sysroot=: \
  action=permission: connection to GDBserver succeeded
...
and are due to the fact that the actual gdb output doesn't match the regexp:
...
    gdb_test "detach" \
       ".*Detaching from program: , process.*Ending remote debugging.*" \
       "connection to GDBserver succeeded"
...

With native, the actual gdb output is:
...
(gdb) detach^M
Detaching from pid process 29657^M
Ending remote debugging.^M
[Inferior 1 (process 29657) detached]^M
(gdb) Remote debugging from host ::1, port 51028^M
...
and because the regexp doesn't match, it triggers an implicit clause for
"Ending remote debugging" in gdb_test_multiple, which has the consequence
that the FAIL is silent.

Fix:
- the regexp by making it less strict
- the silent fail by rewriting into a gdb_test_multiple, and adding an
  explicit fail clause.

Tested on x86_64-linux, using native and aforementioned target boards.

Automatic date update in version.in

gdb/testsuite: fix gdb.threads/linux-dp.exp regex

On ubuntu 22.04 with the libc6-dbg package installed, I have the
following failure:

    where
    #0  print_philosopher (n=3, left=33 '!', right=33 '!') at .../gdb/testsuite/gdb.threads/linux-dp.c:105
    #1  0x000055555555576a in philosopher (data=0x55555555937c) at .../gdb/testsuite/gdb.threads/linux-dp.c:148
    #2  0x00007ffff7e11b43 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442
    #3  0x00007ffff7ea3a00 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
    (gdb) FAIL: gdb.threads/linux-dp.exp: first thread-specific breakpoint hit

The regex for this test accounts for different situations (with /
without debug symbol) but assumes that if debug info is present the
backtrace shows execution under pthread_create.  However, for the
implementation under test, we are under start_thread.

Update the regex to accept start_thread.

Tested on Ubuntu-22.04 x86_64 with and without libc6-dbg debug symbols
available.

Change-Id: I1e1536279890bca2cd07f038e026b41e46af44e0

[gdb/testsuite] Handle host cleanfiles

When running test-case gdb.server/abspath.exp with host board
local-remote-host-notty, I get:
...
$ git sti
  ...
        deleted:    gdb/testsuite/gdb.xml/trivial.xml
...

This happens as follows.  The test-case calls skip_gdbserver_test, which calls
gdb_skip_xml_test, which does:
...
    set xml_file [gdb_remote_download host "${srcdir}/gdb.xml/trivial.xml"]
...

Then proc gdb_remote_download appends $xml_file (which for this particular
host board happens to be ${srcdir}/gdb.xml/trivial.xml) to cleanfiles, which
ends up being handled in gdb_finish by:
...
       eval remote_file target delete $cleanfiles
...

The problem is that a host file is deleted using target delete.

Fix this by splitting cleanfiles up in cleanfiles_target and cleanfiles_host.

Tested on x86_64-linux.

[gdb/testsuite] Remove unnecessary warning in gdb.base/default.exp

When running test-case gdb.base/default.exp with target board
native-gdbserver, we get:
...
WARNING: Skipping backtrace and break tests because of GDB stub.
...

There's no need for such a warning, so remove it.

Tested on x86_64-linux with native and target board native-gdbserver.

[gdb/testsuite] Fix have_mpx with remote-gdbserver-on-localhost

With target board remote-gdbserver-on-localhost and gdb.arch/i386-mpx-call.exp
I run into:
...
FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd0: continue to a bnd violation
...

This is due to the have_mpx test which should return 0, but instead returns 1
because the captured output:
...
No MPX support
No MPX support
...
does not match the used regexp:
...
    set status [expr ($status == 0) \
                   && ![regexp "^No MPX support\r\n" $output]]
...
which does match the captured output with native:
...
No MPX support^M
No MPX support^M
...

Fix this by making the \r in the regexp optional.

Tested on x86_64-linux, with native and target board
remote-gdbserver-on-localhost.

[gdb/testsuite] Fix DUPLICATEs with remote-gdbserver-on-localhost

Fix some DUPLICATEs that we run into with target board
remote-gdbserver-on-localhost, by using test_with_prefix.

Tested on x86_64-linux, with native and target board
remote-gdbserver-on-localhost.

[gdb/testsuite] Fix path in test name in gdb_load_shlib

When running test-case gdb.server/solib-list.exp with target board
remote-gdbserver-on-localhost, I run into:
...
(gdb) set solib-search-path $outputs/gdb.server/solib-list^M
(gdb) PASS: gdb.server/solib-list.exp: non-stop 0: \
  set solib-search-path $outputs/gdb.server/solib-list
PATH: gdb.server/solib-list.exp: non-stop 0: \
  set solib-search-path $outputs/gdb.server/solib-list
...

This is due to this code in gdb_load_shlib:
...
       gdb_test "set solib-search-path [file dirname $file]" "" ""
...

Fix this by setting an explicit test name.

Tested on x86_64-linux, with native and target boards
remote-gdbserver-on-localhost, native-gdbserver and native-extended-gdbserver.

PR29653, objcopy/strip: fuzzed small input file induces large output file

_bfd_check_format functions should not print errors or warnings if
they return NULL.  A NULL return means the particular target under
test does not match, so there isn't any reason to make a complaint
about the target.  In fact there isn't a good reason to warn even if
the target matches, except via the _bfd_per_xvec_warn mechanism; Some
other target might be a better match.

This patch tidies pe_bfd_object_p with the above in mind, and
restricts the PE optional header SectionAlignment and FileAlignment
fields somewhat.  I chose to warn on nonsense values rather than
refusing to match.  Refusing to match would be OK too.

PR 29653
* peXXigen.c (_bfd_XXi_swap_aouthdr_in): Don't emit error about
invalid NumberOfRvaAndSizes here.  Limit loop copying data
directory to IMAGE_NUMBEROF_DIRECTORY_ENTRIES.
* peicode.h (pe_bfd_object_p): Don't clear and test bfd_error
around bfd_coff_swap_aouthdr_in.  Warn on invalid SectionAlignment,
FileAlignment and NumberOfRvaAndSizes.  Don't return NULL on
invalid NumberOfRvaAndSizes.

Automatic date update in version.in

Fix indentation in riscv-tdep.c

This just fixes some indentation in riscv-tdep.c.

gdb/arm: Handle lazy FPU state preservation

Read LSPEN, ASPEN and LSPACT bits from FPCCR and use them together
with FPCAR to identify if lazy FPU state preservation is active for
the current frame.  See "Lazy context save of FP state", in B1.5.7,
also ARM AN298, supported by Cortex-M4F architecture for details on
lazy FPU register stacking.  The same conditions are valid for other
Cortex-M cores with FPU.

This patch has been verified on a STM32F4-Discovery board by:
a) writing a non-zero value (lets use 0x1122334455667788 as an
   example) to all the D-registers in the main function
b) configured the SysTick to fire
c) in the SysTick_Handler, write some other value (lets use
   0x0022446688aaccee as an example) to one of the D-registers (D0 as
   an example) and then do "SVC #0"
d) in the SVC_Handler, write some other value (lets use
   0x0099aabbccddeeff) to one of the D-registers (D0 as an example)

In GDB, suspend the execution in the SVC_Handler function and compare
the value of the D-registers for the SVC_handler frame and the
SysTick_Handler frame.  With the patch, the value of the modified
D-register (D0) should be the new value (0x009..eff) on the
SVC_Handler frame, and the intermediate value (0x002..cee) for the
SysTick_Handler frame.  Now compare the D-register value for the
SysTick_Handler frame and the main frame.  The main frame should
have the initial value (0x112..788).

Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>
Signed-off-by: Yvan ROUX <yvan.roux@foss.st.com>

[gdb/symtab] Factor out have_complaint

After committing 8ba677d3560 ("[gdb/symtab] Don't complain about function
decls") I noticed that quite a bit of code in read_func_scope is used to decide
whether to issue the "cannot get low and high bounds for subprogram DIE at
$hex" complaint, which executes unnecessarily if we have the default
"set complaints 0".

Fix this by (NFC):
- factoring out new static function have_complaint from macro complaint, and
- using it to wrap the relevant code in read_func_scope.

Tested on x86_64-linux.

gdb: add missing nullptr checks in bpstat_check_breakpoint_conditions

Add a couple of missing nullptr checks in the function
bpstat_check_breakpoint_conditions.

No user visible change after this commit.

gdb: more infrun debug from breakpoint.c

This commit adds additional infrun debug from the breakpoint.c file.
The new debug output all relates to breakpoint condition evaluation.

There is already some infrun debug emitted from the breakpoint.c file,
so hopefully, adding more will not be contentious.  I think the
functions being instrumented make sense as part of the infrun process,
the inferior stops, evaluates the condition, and then either stops or
continues.  This new debug gives more insight into that process.

I had to make the bp_location* argument to find_loc_num_by_location
const, and add a declaration for find_loc_num_by_location.

There should be no user visible changes unless they turn on debug
output.

gdb: add some additional debug in mark_async_event_handler

Extend the existing debug printf call to include the previous state of
the async_event_handler object.

RISC-V: Print XTheadMemPair literal as "immediate"

The operand type "Xl(...)" denotes that (...) is a literal.  Specifically,
they are intended to be a constant immediate value.

This commit prints "Xl(...)" operand with dis_style_immediate style,
not dis_style_text.

opcodes/ChangeLog:

* riscv-dis.c (print_insn_args): Use dis_style_immediate on
the constant literal of the "Xl..." operand.