gdb: use libtool in GDB_AC_CHECK_BFD

The GDB_AC_CHECK_BFD macro defined in gdb/acinclude.m4 uses the
AC_LINK_IFELSE autoconf macro in order to link a simple program to
check features of libbfd.

If libbfd's link dependencies change, it was necessary to reflect them
either in the definition of the macro, or as a consequence of checking
for them with an autoconf macro resulting in an addition to LIBS.

This patch modifies the definition of the GDB_CHECK_BFD macro in order
to use libtool to perform the test link.  This makes it possible to
not have to list dependencies of libbfd (which are indirect to GDB) at
all.

After this patch:

  configure:28553: checking for ELF support in BFD
  configure:28573: ./libtool --quiet --mode=link gcc -o conftest \
                   -I../../gdb/../include -I../bfd \
                   -I../../gdb/../bfd -g -O2 \
                   -L../bfd -L../libiberty conftest.c -lbfd -liberty \
                   -lncursesw -lm -ldl  >&5
  configure:28573: $? = 0
  configure:28583: result: yes

Tests performed:

- Configure --with-system-zlib and --without-system-zlib.
- Check link dependencies of installed GDB with both --enable-shared
  and --disable-shared.
- Run installed GDB in both cases.

Approved-By: Simon Marchi <simon.marchi@efficios.com>

Fix crash in ada_print_type

The "varstring" paramter to ada_print_type can be null, but one spot
failed to check this.  This could cause a crash in some situations.

As this is Ada-specific, and we've been using it internally at AdaCore
for a while, I am going to push it.

Add AMD znver4 processor support

2022-09-28  Tejas Joshi <TejasSanjay.Joshi@amd.com>

gas/

        * config/tc-i386.c (cpu_arch): Add znver4 ARCH and rmpquery SUBARCH.
        (md_assemble): Expand comment before swap_operands() with rmpquery.
        * doc/c-i386.texi: Add znver4.
        * testsuite/gas/i386/arch-14-1.d: New.
        * testsuite/gas/i386/arch-14-1.s: New.
        * testsuite/gas/i386/arch-14-znver4.d: New.
        * testsuite/gas/i386/i386.exp: Add new znver4 test cases.
        * testsuite/gas/i386/rmpquery.d: New.
        * testsuite/gas/i386/rmpquery.s: New.
        * testsuite/gas/i386/x86-64-arch-4-1.d: New.
        * testsuite/gas/i386/x86-64-arch-4-1.s: New.
        * testsuite/gas/i386/x86-64-arch-4-znver4.d: New.

opcodes/

        * i386-dis.c (x86_64_table): Add rmpquery.
        * i386-gen.c (cpu_flag_init): Add CPU_ZNVER4_FLAGS and
        CPU_RMPQUERY_FLAGS.
        (cpu_flags): Add CpuRMPQUERY.
        * i386-opc.h (enum): Add CpuRMPQUERY.
        (i386_cpu_flags): Add cpurmpquery.
        * i386-opc.tbl: Add rmpquery insn.
        * i386-init.h: Re-generated.
        * i386-tbl.h: Re-generated.

gdb/testsuite: get_set_option_choices: expect \r\n after each item

I get some random failures since commit 8d45c3a82a0e ("[gdb/testsuite]
Set completions to unlimited in get_set_option_choices"), which can be
reproduced with:

    $ make check-read1 TESTS="gdb.base/parse_number.exp"

For instance:

    set architecture A^M
    Ambiguous item "A".^M
    (gdb) FAIL: gdb.base/parse_number.exp: arch=A: set architecture A

The problem is the regexp in get_set_option_choices, it is possible that
is only matches part of a completion result.  With check-read1, that is
always one letter.

Fix this by expecting the \r\n at the end of the line, so we only match
entire results.  Use ^ in match patterns to ensure we don't miss any
output.

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

aarch64, testsuite: Fixed recently added cssc.d

Fixed wrong paste in cssc.d.

gas/ChangeLog:

* testsuite/gas/aarch64/cssc.d: Removed duplicate head.

[gdb/testsuite] Normalize gdbserver path name

Currently for the target board remote-gdbserver-on-localhost we use the
gdbserver file on build, using a file name which includes "/../".

Fix this by using a normalized file name instead.

This allows us to be more restrictive about which files REMOTE_TARGET_USERNAME
can access:
...
-    remote_exec build "chmod go-rx $objdir/outputs"
+    remote_exec build "chmod go-rx $objdir"
...

Tested on x86_64-linux.

[gdb/testsuite] Fix gdb.base/jit-elf-so.exp for remote target

With test-case gdb.base/jit-elf-so.exp and target board
remote-gdbserver-on-localhost (using REMOTE_TARGET_USERNAME) we run into some
failures.

Fix these by:
- setting jit_libname with the name as returned by gdb_load_shlib
- allowing the libraries to be prefixed with the remote target directory.

Tested on x86_64-linux.

Co-Authored-by: Ivan Tetyushkin <ivan.tetyushkin@syntacore.com>

[gdb/testsuite] Fix gdb.base/jit-reader-exec.exp for remote target

With test-case gdb.base/jit-reader-exec.exp and target board
remote-gdbserver-on-localhost (using REMOTE_TARGET_USERNAME) we run into some
failures.

Fix this by adding the missing gdb_remote_download.

Tested on x86_64-linux.

Co-Authored-by: Ivan Tetyushkin <ivan.tetyushkin@syntacore.com>

[gdb/testsuite] Fix gdb.base/info-shared.exp for remote target

With test-case gdb.base/info-shared.exp and target board
remote-gdbserver-on-localhost (using REMOTE_TARGET_USERNAME) we run into some
failures.

Fix these by adding the missing gdb_load_shlib.

Tested on x86_64-linux.

Co-Authored-by: Ivan Tetyushkin <ivan.tetyushkin@syntacore.com>

[gdb/testsuite] Fix gdb.base/solib-vanish.exp for remote target

When running test-case gdb.base/solib-vanish.exp with target board
remote-gdbserver-on-localhost (using REMOTE_TARGET_USERNAME) we run into some
failures.

Fix these by adding the missing gdb_load_shlib.

Tested on x86_64-linux.

Co-Authored-by: Ivan Tetyushkin <ivan.tetyushkin@syntacore.com>

[gdb/testsuite] Fix gdb.base/infcall-exec.exp for remote target

When running test-case gdb.base/infcall-exec.exp with target board
remote-gdbserver-on-localhost (using REMOTE_TARGET_USERNAME) we run into:
...
(gdb) call (int) execlp ("$outputs/gdb.base/infcall-exec/infcall-exec2", \
  "$outputs/gdb.base/infcall-exec/infcall-exec2", (char *)0)^M
$1 = -1^M
(gdb) FAIL: gdb.base/infcall-exec.exp: call execlp
...

Fix this by using just:
...
(gdb) call (int) execlp ("infcall-exec2", "infcall-exec2", (char *)0)^M
...
and using putenv ("PATH=...") to allow infcall-exec to exec infcall-exec2
if it's available alongside.

Also fix the exec name in the test-case, such that we can successfully
run the test-case:
...
$ ./outputs/gdb.base/infcall-exec/infcall-exec
PATH SETTING: 'PATH=./outputs/gdb.base/infcall-exec'
$
...

Tested on x86_64-linux.

Co-Authored-by: Ivan Tetyushkin <ivan.tetyushkin@syntacore.com>

[gdb/testsuite] Fix gdb.base/print-file-var.exp for remote target

When running test-case gdb.base/print-file-var.exp with target board
remote-gdbserver-on-localhost (using REMOTE_TARGET_USERNAME) we run into some
failures.

Fix these by using the name of a shared lib as returned by gdb_load_shlib.

This required splitting up the gdb_load_shlib functionality, which is now
defined as:
...
proc gdb_load_shlib { file } {
    set dest [gdb_download_shlib $file]
    gdb_locate_shlib $file
    return $dest
}
...
such that we can do gdb_download_shlib before gdb is started.

Tested on x86_64-linux.

Co-Authored-by: Ivan Tetyushkin <ivan.tetyushkin@syntacore.com>

[gdb/testsuite] Add REMOTE_TARGET_USERNAME in remote-gdbserver-on-localhost.exp

As reported here
( https://sourceware.org/pipermail/gdb-patches/2022-October/193147.html ) a
number of test-cases fails with a remote target setup, for instance test-case
gdb.base/print-file-var.exp.

So, why don't we see these fails with our remote target boards in
gdb/testsuite/boards, say remote-gdbserver-on-localhost.exp?

The problem is that the target board uses the same machine and user for
both (by-definition-local) build and remote target, and when using absolute
pathnames to refer to files on build, we can access those files on target,
which in a real remote target setup wouldn't be the case: we'd have to
download them to target first, and then the filename would also be different.

For aforementioned test-case, this happens when the name of a shared library is
passed as absolute file name to gcc:
...
gcc ...  -DSHLIB_NAME="$outputs/gdb.base/print-file-var/\
  print-file-var-lib2-hidden0-dlopen1-version_id_main0_c.so"
...

Make these problems visible with remote-gdbserver-on-localhost.exp by
adding an option to specify a test account (still on the same machine)
using REMOTE_TARGET_USERNAME.

We make sure by restricting file permissions, that the test account cannot see
the build files on the $USER account, and that the $USER account cannot see
the target files on the test account.

And so we can reproduce the reported fails:
...
$ cd build/gdb
$ tc="gdb.base/print-file-var.exp"
$ tb="--target_board remote-gdbserver-on-localhost"
$ tbu="REMOTE_TARGET_USERNAME=remote-target"
$ make check RUNTESTFLAGS="$tb $tbu $tc"
   ...
FAIL: gdb.base/print-file-var.exp: lang=c: hidden=0: dlopen=1: \
  version_id_main=0: continue to STOP marker
...

Tested on x86_64-linux.

Reported-by: Ivan Tetyushkin <ivan.tetyushkin@syntacore.com>

[gdb/testsuite] Fix gdb.base/info_sources_2.exp for remote target

With test-case gdb.base/info_sources_2.exp and target board
remote-gdbserver-on-localhost (using REMOTE_TARGET_USERNAME) we run into some
failures.

Fix these by adding the missing gdb_load_shlib.

Tested on x86_64-linux.

[gdb/testsuite] Fix gdb.base/foll-exec.exp for remote target

When running test-case gdb.base/foll-exec.exp with target board
remote-gdbserver-on-localhost.exp, I run into:
...
(gdb) PASS: gdb.base/foll-exec.exp: insert first exec catchpoint
continue^M
Continuing.^M
[Inferior 1 (process 4476) exited normally]^M
(gdb) FAIL: gdb.base/foll-exec.exp: continue to first exec catchpoint (the program e\
xited)
...

The problem is that the foll-exec executable expects the exec-ed executable
execd-prog alongside it, but it's missing.

Fix this by adding the missing gdb_remote_download.

Likewise in a few other test-cases.

Tested on x86_64-linux.

[gdb/testssuite] Skip aarch64 in skip_gdbserver_test if no xml support

On aarch64-linux, with a gdb build without libexpat, so without xml support, I
run into:
...
(gdb) builtin_spawn attach-no-multi-process^M
attach 26808^M
Attaching to Remote target^M
warning: Can not parse XML target description; XML support was disabled at \
  compile time^M
Reading symbols from attach-no-multi-process...^M
Remote 'g' packet reply is too long (expected 788 bytes, got 796 bytes): ... ^M
...

The test-case checks for skip_gdbserver_tests and that one contains a check
for xml support:
...
    # If GDB is lack of XML support, and targets, like arm, have
    # multiple target descriptions, GDB doesn't know which target
    # description GDBserver uses, and may fail to parse 'g' packet
    # after connection.
    if { [gdb_skip_xml_test]
 && ([istarget "arm*-*-linux*"]
      || [istarget "mips*-*-linux*"]
      || [istarget "powerpc*-*-linux*"]
      || [istarget "s390*-*-linux*"]
      || [istarget "x86_64-*-linux*"]
      || [istarget "i\[34567\]86-*-linux*"]) } {
return 1
    }
...
but it doesn't trigger because aarch64 is missing.

Fix this by adding istarget "aarch64*-*-linux*".

Tested on aarch64-linux.

Approved-By: Luis Machado <luis.machado@arm.com>

Enable multi-process debugging for AIX

This patch adds multi-process debugging feature in AIX.

Till now AIX supported debugging only one inferior at a time,
now we can be able to debug multi process.  Users can use set
follow fork mode in child or parent and set detach on fork on
or off to enable/disable simultaneous debugging of parent/child.

Automatic date update in version.in

PowerPC, fix support for printing the function return value for non-trivial values.

Currently, a non-trivial return value from a function cannot currently be
reliably determined on PowerPC.  This is due to the fact that the PowerPC
ABI uses register r3 to store the address of the buffer containing the
non-trivial return value when the function is called.  The PowerPC ABI
does not guarantee the value in register r3 is not modified in the
function.  Thus the value in r3 cannot be reliably used to obtain the
return addreses on exit from the function.

This patch adds a new gdbarch method to allow PowerPC to access the value
of r3 on entry to a function. On PowerPC, the new gdbarch method attempts
to use the DW_OP_entry_value for the DWARF entries, when exiting the
function, to determine the value of r3 on entry to the function.  This
requires the use of the -fvar-tracking compiler option to compile the
user application thus generating the DW_OP_entry_value in the binary.  The
DW_OP_entry_value entries in the binary file allows GDB to resolve the
DW_TAG_call_site entries.  This new gdbarch method is used to get the
return buffer address, in the case of a function returning a nontrivial
data type, on exit from the function.  The GDB function should_stop checks
to see if RETURN_BUF is non-zero.  By default, RETURN_BUF will be set to
zero by the new gdbarch method call for all architectures except PowerPC.
The get_return_value function will be used to obtain the return value on
all other architectures as is currently being done if RETURN_BUF is zero.
On PowerPC, the new gdbarch method will return a nonzero address in
RETURN_BUF if the value can be determined.  The value_at function uses the
return buffer address to get the return value.

This patch fixes five testcase failures in gdb.cp/non-trivial-retval.exp.
The correct function return values are now reported.

Note this patch is dependent on patch: "PowerPC, function
ppc64_sysv_abi_return_value add missing return value convention".

This patch has been tested on Power 10 and x86-64 with no regressions.

PowerPC, function ppc64_sysv_abi_return_value add missing return value convention

This patch address five testcase failures in gdb.cp/non-trivial-retval.exp.
The following commit resulted in the five testcases failures on PowerPC.
The value returned by the function is being reported incorrectly.

  commit b1718fcdd1d2a5c514f8ee504ba07fb3f42b8608
  Author: Andrew Burgess <aburgess@redhat.com>
  Date:   Mon Dec 13 16:56:16 2021 +0000

      gdb: on x86-64 non-trivial C++ objects are returned in memory

      Fixes PR gdb/28681.  It was observed that after using the `finish`
      command an incorrect value was displayed in some cases.  Specifically,
      this behaviour was observed on an x86-64 target.

The function:

  enum return_value_convention
  ppc64_sysv_abi_return_value (struct gdbarch *gdbarch, struct value *function,
                               struct type *valtype, struct regcache *regcache,
                               gdb_byte *readbuf, const gdb_byte *writebuf)

should return RETURN_VALUE_STRUCT_CONVENTION if the valtype->code() is
TYPE_CODE_STRUCT and if the language_pass_by_reference is not
trivially_copyable.

This patch adds the needed code to return the value
RETURN_VALUE_STRUCT_CONVENTION in this case.

With this patch, the five test cases still fail but with the message "Value
returned has type: A. Cannot determine contents".  The PowerPC ABI stores
the address of the buffer containing the function return value in register
r3 on entry to the function.  However, the PowerPC ABI does not guarentee
that r3 will not be modified in the function.  So when the function returns,
the return buffer address cannot be reliably obtained from register r3.
Thus the message "Cannot determine contents" is appropriate in this case.

Remove dump_prefix_expression

Since the expression rewrite, dump_prefix_expression has been
misnamed.  This patch cleans this up by removing the function, turning
it into a method on struct expression.

aarch64: Add support for Common Short Sequence Compression extension

This patch adds support for the CSSC extension and its corresponding
instructions: ABS, CNT, CTZ, SMAX, UMAX, SMIN, UMIN.

gas/ChangeLog:

        * config/tc-aarch64.c (parse_operands): Handle new operand types.
        * doc/c-aarch64.texi: Document new extension.
        * testsuite/gas/aarch64/cssc.d: New test.
        * testsuite/gas/aarch64/cssc.s: New test.

include/ChangeLog:

        * opcode/aarch64.h (AARCH64_FEATURE_CSSC): New feature Macro.
        (enum aarch64_opnd): New operand types.
        (enum aarch64_insn_class): New instruction class.

opcodes/ChangeLog:

* aarch64-asm-2.c: Regenerate.
* aarch64-dis-2.c: Regenerate.
* aarch64-opc-2.c: Regenerate.
* aarch64-opc.c (operand_general_constraint_met_p): Update for new
operand types.
(aarch64_print_operand): Likewise.
* aarch64-opc.h (enum aarch64_field_kind): Declare FLD_CSSC_imm8 field.
* aarch64-tbl.h (aarch64_feature_cssc): Define new feature set.
(CSSC): Define new feature set Macro.
(CSSC_INSN): Define new instruction type.
(aarch64_opcode_table): Add new instructions.

x86: fold special-operand insn attributes into a single enum

Attributes which aren't used together in any single insn template can be
converted from individual booleans to a single enum, as was done for a few
other attributes before. This is more space efficient. Collect together
all attributes which express special operand constraints (and which fit
the criteria for folding).

pru: bfd: Correct default to no execstack

Data and instruction memories are strictly separated, so it is not
possible to execute instructions from the stack memory on PRU.

I don't see any difference in testsuite results with or without this
change.

bfd/ChangeLog:

* elf32-pru.c (elf_backend_default_execstack): Define as 0.

ld/ChangeLog:

* testsuite/ld-elf/elf.exp (target_defaults_to_execstack):
Return 0 for pru.

Signed-off-by: Dimitar Dimitrov <dimitar@dinux.eu>

[gas] arm: Add support for new unwinder directive ".pacspval".

This patch adds the assembler support for the new unwinder
directive ".pacspval" and encodes this directives with opcode
"0xb5". This opcode indicates the unwinder to use effective
vsp as modifier for PAC validation.

gas/ChangeLog:

2022-11-07  Srinath Parvathaneni  <srinath.parvathaneni@arm.com>

        * doc/c-arm.texi: Document directive.
        * config/tc-arm.c (s_arm_unwind_pacspval): Define function.
        (md_pseudo_table): Add entry for pacspval directive.
        * testsuite/gas/arm/ehabi-pacbti-m.d: New test.
        * testsuite/gas/arm/ehabi-pacbti-m.s: Likewise.

[readelf] arm: Support for new pacbti unwind opcode 0xb5.

This patch adds readelf support for decoding the exception
table opcode "0xb5", which indicates to use effective vsp
as modifier for PAC validation as defined by EHABI
(https://github.com/ARM-software/abi-aa/releases/download/2022Q3/ehabi32.pdf
Section 10.3).

binutils/ChangeLog:

2022-11-07  Srinath Parvathaneni  <srinath.parvathaneni@arm.com>

        * readelf.c (decode_arm_unwind_bytecode): Add entry to decode opcode 0xb5.

gdb/unittests: PR28413, suppress warnings generated by Gnulib

Gnulib generates a warning if the system version of certain functions
are used (to redirect the developer to use Gnulib version).  It caused a
compiler error when...

-   Compiled with Clang
-   -Werror is specified (by default)
-   C++ standard used by Clang is before C++17 (by default as of 15.0.0)
    when this unit test is activated.

This issue is raised as PR28413.

However, previous proposal to fix this issue (a "fix" to Gnulib):
<https://lists.gnu.org/archive/html/bug-gnulib/2021-10/msg00003.html>
was rejected because it ruins the intent of Gnulib warnings.

So, we need a Binutils/GDB-side solution.

This commit tries to address this issue on the GDB side.  We have
"include/diagnostics.h" to disable certain warnings only when necessary.

This commit suppresses the Gnulib warnings by surrounding entire #include
block with DIAGNOSTIC_IGNORE_USER_DEFINED_WARNINGS to disable Gnulib-
generated warnings on all standard C++ header files.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28413
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Change-Id: Ieeb5a31a6902808d4c7263a2868ae19a35e0ccaa

arm: Add support for Cortex-X1C CPU.

This patch adds support for Cortex-X1C CPU in Arm.

bfd/ChangeLog:

2022-11-09  Srinath Parvathaneni  <srinath.parvathaneni@arm.com>

        * cpu-arm.c (processors): Add Cortex-X1C CPU entry.

gas/ChangeLog:

2022-11-09  Srinath Parvathaneni  <srinath.parvathaneni@arm.com>

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

[gdb/testsuite] Run gdb.arch/ppc64-symtab-cordic.exp for --enable-targets=all

While looking at test-case gdb.arch/ppc64-symtab-cordic.exp I realized that
the test-case is too restrictive here:
...
if {![istarget "powerpc*"] || ![is_lp64_target]} {
    verbose "Skipping powerpc64 separate debug file symtab test."
    return
}
...
and can also be run on x86_64-linux, if "set arch powerpc:common64" is
supported, which is the case if we've build gdb with --enable-targets=all.

Fix this by instead checking if powerpc:common64 is in the completion list for
"set arch".

This allows us to remove the 'untested "powerpc:common64 is not supported"'.

While we're at it, clean up the test-case by using clean_restart.

Tested on x86_64-linux.

[gdb/testsuite] Handle with_set arch

I realized that the more irregular output of show arch:
...
(gdb) show arch^M
The target architecture is set to "auto" (currently "i386").^M
...
would be a problem for something like:
...
with_set arch powerpc:common64 {}
...
and indeed:
...
(gdb) set arch powerpc:common64^M
The target architecture is set to "powerpc:common64".^M
(gdb) FAIL: gdb.base/foo.exp: set arch powerpc:common64
...
and:
...
(gdb) set arch set to "auto" (currently "i386")^M
Undefined item: "set".^M
...

Fix this in with_set by handling this type of output.

Tested on x86_64-linux.

[gdb/testsuite] Set completions to unlimited in get_set_option_choices

In some test-case I tried to use get_set_option_choices "set architecture" and
ran into max-completions:
...
set architecture simple^M
set architecture tomcat^M
set architecture xscale^M
set architecture  *** List may be truncated, max-completions reached. ***^M
(gdb) PASS: gdb.base/foo.exp: complete set architecture
...

There's only one test-case using this currently: gdb.base/parse_number.exp,
and it locally sets max-completions to unlimited.

Fix this by:
- factoring out a new proc with_set out of proc with_complaints, and
- using it to temporarily set max-completions to unlimited in
  get_set_option_choice.

Tested on x86_64-linux, by running test-cases that excercise
get_set_option_choice and with_complaints.

Re: objcopy renaming section with explicit flags

For now, xfail the new test.  Some header/aux-header rewriting is
required at the very least.

* testsuite/binutils-all/rename-section-01.d: xfail xcoff.

objcopy renaming section with explicit flags

This tidies SEC_RELOC handling in bfd, in the process fixing a bug
with objcopy when renaming sections.

bfd/
* reloc.c (_bfd_generic_set_reloc): Set/clear SEC_RELOC depending
on reloc count.
* elf64-sparc.c (elf64_sparc_set_reloc): Likewise.
binutils/
* objcopy.c (copy_relocations_in_section): Remove now unnecessary
clearing of SEC_RELOC.
* testsuite/binutils-all/rename-section-01.d: New test.
* testsuite/binutils-all/objcopy.exp: Run it.
gas/
* write.c (size_seg): Remove unneccesary twiddle of SEC_RELOC.
(write_relocs): Likewise.  Always call bfd_set_reloc.

Automatic date update in version.in

Fix Cygwin build after 02d04eac

Commit 02d04eac "Use strwinerror in gdb/windows-nat.c" also moves
strwinerror() under the USE_WIN32API conditional, which is not defined
for Cygwin (and looks like it shouldn't be, as appears to imply
non-POSIX and MiNGW and WinSock...)

Also enable the declaration and definition of strwinerror() when
__CYGWIN__ is defined.

Drop apparently unneeded include of winsock2.h

Commit d08bae3d ("Implement target async for Windows") unconditionally
includes winsock2.h.  We don't want to do that on Cygwin, since
including both winsock2.h and sys/select.h causes incompatible
redefinition problems.

Since that include is apparently unneeded, just drop it.

Fixes: d08bae3d

Automatic date update in version.in

sim: pru: Fix behaviour when loop count is zero

If the counter for LOOP instruction is provided by a register with
value zero, then the instruction must cause a PC jump directly to the
loop end.  But in that particular case simulator must not initialize
its internal loop variables, because loop body will not be executed.
Instead, simulator must obtain the loop's end address directly from
the LOOP instruction.

Signed-off-by: Dimitar Dimitrov <dimitar@dinux.eu>

PowerPC64 paddi -Mraw

On a testcase like
 pla 8,foo@pcrel
disassembled with -Mpower10 results in
   0: 00 00 10 06  pla     r8,0 # 0
   4: 00 00 00 39
0: R_PPC64_PCREL34 foo
but with -Mpower10 -Mraw
   0: 00 00 10 06  .long 0x6100000
0: R_PPC64_PCREL34 foo
   4: 00 00 00 39  addi    r8,0,0

The instruction is unrecognised due to the hack we have in
extract_pcrel0 in order to disassemble paddi with RA0=0 and R=1 as
pla.  I could have just added "&& !(dialect & PPC_OPCODE_RAW)" to the
condition in extract_pcrel0 under which *invalid is set, but went for
this larger patch that reorders the extended insn pla to the more
usual place before its underlying machine insn.  (la is after addi
because we never disassemble to la.)

gas/
* testsuite/gas/ppc/raw.d,
* testsuite/gas/ppc/raw.s: Add pla.
opcodes/
* ppc-opc.c (extract_pcrel1): Rename from extract_pcrel0 and
invert *invalid logic.
(PCREL1): Rename from PCREL0.
(prefix_opcodes): Sort pla before paddi, adjusting R operand
for pla, paddi and psubi.

libctf: use libtool for link test in configure

The configure check for ELF support in BFD uses the AC_TRY_LINK.  If
libbfd's dependencies change, this macro will need to be updated
manually with explicit additions to LDFLAGS and LIBS.

This patch updates the check to use libtool instead.

ChangeLog:

* libctf/configure.ac: Use libtool instead.
* libctf/configure: Regenerated.

Automatic date update in version.in

gdb: fix start breakpoint expression not working in some languages

Commit 0be837be9fb4 ("gdb: make "start" breakpoint inferior-specific")
regresses gdb.ada/start.exp:

    (gdb) start
    Error in expression, near `1'.
    (gdb) UNTESTED: gdb.ada/start.exp: start failed to land inside the right procedure

This is because in Ada, the equality operator is =, not ==.

I checked the other languages supported by GDB, these other languages
use = for equality:

 - Pascal: tests like gdb.pascal/hello.exp are affected too
 - Modula-2: I tried building a Modula-2 hello world using gm2, but it
   seems like the generated DWARF doesn't specify the Modula-2 language
   in the CUs, it's C++ and C, so the selected language isn't
   "modula-2".  But if I manually do "set language modula-2" on a dummy
   program and then "start", I get the same error.

Other languages all use ==.

So, a short term fix would be to use = or == in the expression, based on
the current language.  If this was meant to be permanent, I would
suggest adding something like an "equality_operator" method to
language_defn, that returns the right equality operator for the
language.  But the goal is to replace all this with proper
inferior-specific breakpoints, so I hope all this is temporary.

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

sim: igen: cleanup archaic pointer-to-long printf casts

Use proper %p to printf a pointer instead of casting it to long and
using 0x%lx.  It's cleaner, more correct, and doesn't break on LLP64.

[gdb/testsuite] Don't timeout on prompt in gdb_start_cmd

We're currently running into a timeout at:
...
(gdb) start ^M
Error in expression, near `1'.^M
(gdb) UNTESTED: gdb.ada/start.exp: start failed to land inside the right \
  procedure
...
due to the fact that gdb_start_cmd doesn't handle a prompt as reaction to
the start command.

Fix this by handling the prompt.  Reduces execution time of the test-case from
1m1s to 1s.

Tested on x86_64-linux.

[gdb/testsuite] Better error checking in has_hw_wp_support

With gdb 12.1, on powerpc64le I ran into ERRORs related to has_hw_wp_support
usage, which was already fixed on trunk by commits:
- 13f72372413 ("gdb/testsuite: fix gdb.base/break-idempotent.exp on ppc"), and
- 01a32ee0b8c ("PowerPC, fix gdb.base/watchpoint.exp on Power 9")

While looking into these ERRORs and the commits that fix them, it occurred to
me that while the commits fix the root cause, the failure mode is not great.

The test-cases expect a running instance of gdb upon return, which is not
there, so there's an long stream of ERRORs generated as a result.

Fix this at the start of has_hw_wp_support, by (instead of accomodating a
running gdb instance by calling gdb_exit), checking whether it's called
without a running gdb instance, and erroring out otherwise.  This way, there's
just one error.

I also noticed that in case we do an early exit due to !runto_main, we don't
clean up, so copy the missing cleanups (gdb_exit and $obj file deletion) from
the regular exit.

Tested on x86_64-linux, using has_hw_wp_support for x86_64 in
skip_hw_watchpoint_tests.

gdb/py-inferior: Keep inferior threads in a map

The python code maintains a list of threads for each inferior.  This
list is implemented as a linked list.  When the number of threads grows
high, this implementation can begin to be a performance bottleneck as
finding a particular thread_object in the list has a complexity of O(N).

We see this in ROCgdb[1], a downstream port of GDB for AMDGUP.  On
AMDGPU devices, the number of threads can get significantly higher than
on usual GDB workloads.

In some situations, we can reach the end of the inferior process with
GDB still having a substantial list of known threads.  While running
target_mourn_inferior, we end up in inferior::clear_thread_list which
iterates over all remaining threads and marks each thread exited.  This
fires the gdb::observers::thread_exit observer and eventually
py-inferior.c:set_thread_exited gets called.  This function searches in
the linked list with poor performances.

This patch proposes to change the linked list that keeps the per
inferior_object list of thread_objects into a std::unordered_map.  This
allows to have the search operation complexity be O(1) on average
instead of O(N).

With this patch, we can complete clear_thread_list in about 2.5 seconds
compared to 10 minutes without it.

Except for the performance change, no user visible change is expected.

Regression tested on Ubuntu-22.04 x86_64.

[1] https://github.com/ROCm-Developer-Tools/ROCgdb

Make sure a copy_insn_closure is available when we have a match in copy_insn_closure_by_addr

PR gdb/29272

Investigating PR29272, it was mentioned a particular test used to work on
GDB 10, but it started failing with GDB 11 onwards. I tracked it down to
some displaced stepping improvements on commit
187b041e2514827b9d86190ed2471c4c7a352874.

In particular, one of the corner cases using copy_insn_closure_by_addr got
silently broken. It is hard to spot because it doesn't have any good tests
for it, and the situation is quite specific to the Arm target.

Essentially, the change from the displaced stepping improvements made it so
we could still invoke copy_insn_closure_by_addr correctly to return the
pointer to a copy_insn_closure, but it always returned nullptr due to
the order of the statements in displaced_step_buffer::prepare.

The way it is now, we first write the address of the displaced step buffer
to PC and then save the copy_insn_closure pointer.

The problem is that writing to PC for the Arm target requires figuring
out if the new PC is thumb mode or not.

With no copy_insn_closure data, the logic to determine the thumb mode
during displaced stepping doesn't work, and gives random results that
are difficult to track (SIGILL, SIGSEGV etc).

Fix this by reordering the PC write in displaced_step_buffer::prepare
and, for safety, add an assertion to
displaced_step_buffer::copy_insn_closure_by_addr so GDB stops right
when it sees this invalid situation. If this gets broken again in the
future, it will be easier to spot.

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

Approved-By: Simon Marchi <simon.marchi@efficios.com>

gdb, btrace: Fix rn-dl-bind.exp for new icx remark.

When running the test with the latest Intel compiler:

Running gdb/gdb/testsuite/gdb.btrace/rn-dl-bind.exp ...
gdb compile failed, icpx: warning: treating 'c' input as 'c++' when
in C++ mode, this behavior is deprecated [-Wdeprecated]

The test doesn't seem to test something specifically for C++,
so I removed the C++ compilation option. Alternatively we could rename
rn-dl-bind.exp.c to rn-dl-bind.exp.cc.

Signed-off-by: Felix Willgerodt <felix.willgerodt@intel.com>

gdb/testsuite: disable gdb.cp/call-method-register.exp when not using gcc

The test gdb.cp/call-method-register.exp assumes that the class will be
placed on a register. However, this keyword has been deprecated since
C++11, and Clang, for instance, does not feel the need to follow it.
Since this test is not usable without this working, this commit marks
this test as untested.

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

gdb/testsuite: remove XFAIL on gdb.cp/temargs.exp

gdb.cp/temargs.exp last 2 tests always setup an XFAILs, despite checking
for old gcc versions.  However, Clang does not fail in this test,
turning into XPASSes and slighty annoying when comparing between
compilers.  To change this, make the xfails only happen if we using gcc.

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

gdb/testsuite: disable some tests of gdb.cp/typeid.exp when using Clang

Since Clang chooses to not add any debug information for base types,
expecting it to be included with libraries' informations, gdb.cp/typeid.exp
will always fail if the program hasn't started.  This commit fixes that by
making it so when using Clang, the base type variables aren't tested.

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

gdb/testsuite: skip gdb.cp/anon-struct.exp when using Clang

When Clang compiles anonymous structures, it does not add linkage names in
their dwarf representations. This is compounded by Clang not adding linkage
names to subprograms of those anonymous structs (for instance, the
constructor). With these 2 things together, GDB is unable to refer to
any of them, so there is no way to pass any of the tests of
gdb.cp/anon-struct.exp

Since this isn't a bug on Clang or GDB according to the DWARF
specifications as DW_AT_name is optional for all DIEs, the test was marked
as untested.

Since I was already touching the file, I also added a comment at the top
of the file explaining what it is testing for.

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

gdb/testsuite: allow for Clang style destructors on gdb.cp/m-static.exp

when running gdb.cp/m-static.exp using Clang, we get the following
failures:

    print test1.~gnu_obj_1^M
    $6 = {void (gnu_obj_1 * const)} 0x555555555470 <gnu_obj_1::~gnu_obj_1()>^M
    (gdb) FAIL: gdb.cp/m-static.exp: simple object instance, print destructor
    ptype test1.~gnu_obj_1^M
    type = void (gnu_obj_1 * const)^M
    (gdb) FAIL: gdb.cp/m-static.exp: simple object instance, ptype destructor
    print test1.'~gnu_obj_1'^M
    $7 = {void (gnu_obj_1 * const)} 0x555555555470 <gnu_obj_1::~gnu_obj_1()>^M
    (gdb) FAIL: gdb.cp/m-static.exp: simple object instance, print quoted destructor

This is because the test is expecting an extra integer parameter on the
destructor. Looking at the debuginfo, it seems that there is nothing
actually wrong with this output, so these tests were changed to test
multiple possible regexps.

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

gdb/testsuite: add XFAIL to gdb.cp/derivation.exp when using Clang

When running gdb.cp/derivation.exp using Clang, we get an unexpected
failure when printing the type of a class with an internal typedef. This
happens because Clang doesn't add accessibility information for typedefs
inside classes (see https://github.com/llvm/llvm-project/issues/57608
for more info). To help with Clang testing, an XFAIL was added to this
test.

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

gdb/testsuite: account for clang's nested destructor calls on gdb.cp/mb-ctor.exp

When compiling virtual classes's destructors, two versions are compiled,
one with a single parameter (this) and the other with 2 parameters (this
and vtt).

GCC's compilation makes it so either the version with 1
parameter or the one with 2 parameters is called, depending on whether
the destructor is being called by the class itself or by an inherited
class. On the test gdb.cp/mb-ctor.exp, this means that the breakpoint
set at the destructor will be hit 4 times.

Clang, on the other hand, makes the single-parameter version call the 2
parameter version, probably in an attempt to reduce the size of the
resulting executable. This means that the gdb.cp/mb-ctor.exp will hit 6
breakpoints before finishing, and is the reason why this test was
failing. To make this test stop failing, a compiler check is added and
another "continue" instruction is issued to account for this difference.

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

gdb/testsuite: enable running gdb.cp/classes.exp with clang

When attempting to run the gdb.cp/classes.exp test using Clang++, the
test fails to prepare with -Wnon-c-typedef-for-linkage like the
previously fixed gdb.cp/class2.exp. Upon fixing this, the test shows 5
unexpected failures. One such failures is:

ptype/r class class_with_public_typedef
type = class class_with_public_typedef {
  private:
    int a;
  public:
    class_with_public_typedef::INT b;

  private:
    typedef int INT;
}
(gdb) FAIL: gdb.cp/classes.exp: ptype class class_with_public_typedef // wrong access specifier for typedef: private

While g++ provided the following output:

ptype/r class class_with_public_typedef
type = class class_with_public_typedef {
  private:
    int a;
  public:
    class_with_public_typedef::INT b;

    typedef int INT;
}
(gdb) PASS: gdb.cp/classes.exp: ptype class class_with_public_typedef

This error happens because Clang does not add DW_AT_accessibility to
typedefs inside classes, and without this information GDB defaults to
assuming the typedef is private.  Since there is nothing that GDB can do
about this, these tests have been set as xfails, and Clang bug 57608 has
been filed.

Bug: https://github.com/llvm/llvm-project/issues/57608
Approved-by: Tom Tromey <tom@tromey.com>

gdb/testsuite: ignore Non-C-typedefs for gdb.cp/class2.exp

When attempting to test gdb.cp/class2.exp using Clang, it fails to
prepare with the following error:

Executing on host: clang++    -fdiagnostics-color=never -Wno-unknown-warning-option  -c -g -o /home/blarsen/Documents/fsf_build/gdb/testsuite/outputs/gdb.cp/class2/class20.o /home/blarsen/Documents/fsf_build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.cp/class2.cc    (timeout = 300)
builtin_spawn -ignore SIGHUP clang++ -fdiagnostics-color=never -Wno-unknown-warning-option -c -g -o /home/blarsen/Documents/fsf_build/gdb/testsuite/outputs/gdb.cp/class2/class20.o /home/blarsen/Documents/fsf_build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.cp/class2.cc
/home/blarsen/Documents/fsf_build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.cp/class2.cc:53:14: warning: anonymous non-C-compatible type given name for linkage purposes by typedef declaration; add a tag name here [-Wnon-c-typedef-for-linkage]
typedef class {
             ^
              Dbase
/home/blarsen/Documents/fsf_build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.cp/class2.cc:54:2: note: type is not C-compatible due to this member declaration
 public:
 ^~~~~~~
/home/blarsen/Documents/fsf_build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.cp/class2.cc:58:3: note: type is given name 'Dbase' for linkage purposes by this typedef declaration
} Dbase;
  ^
1 warning generated.
gdb compile failed, /home/blarsen/Documents/fsf_build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.cp/class2.cc:53:14: warning: anonymous non-C-compatible type given name for linkage purposes by typedef declaration; add a tag name here [-Wnon-c-typedef-for-linkage]
typedef class {
             ^
              Dbase
/home/blarsen/Documents/fsf_build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.cp/class2.cc:54:2: note: type is not C-compatible due to this member declaration
 public:
 ^~~~~~~
/home/blarsen/Documents/fsf_build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.cp/class2.cc:58:3: note: type is given name 'Dbase' for linkage purposes by this typedef declaration
} Dbase;
  ^
1 warning generated.
UNTESTED: gdb.cp/class2.exp: failed to prepare

This can be silenced by adding -Wno-non-c-typedef-for-linkage for Clang
11 or later.  The test shows no failures with this change.

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

gas: accept custom ".linefile <n> ."

While .linefile is generally intended for gas internal use only, its use
in a source file would better not result in an internal error. Give use
of it outside of any macro(-like) construct the meaning of restoring the
original (physical) input file name.

x86: drop stray IsString from PadLock insns

The need for IsString on the PadLock insns went away with the
introduction of RepPrefixOk. Drop these leftovers.

x86: drop duplicate sse4a entry from cpu_arch[]

Of the two instances the first is correct in using ANY_SSE4A as 3rd
argument to SUBARCH(), so drop the wrong/redundant/dead 2nd one.

PR28834, PR26946 sanity checking section size

This patch provides a new function to sanity check section sizes.
It's mostly extracted from what we had in bfd_get_full_section_contents
but also handles compressed debug sections.
Improvements are:
- section file offset is taken into account,
- added checks that a compressed section can be read from file.

The function is then used when handling multiple .debug_* sections
that need to be read into a single buffer, to sanity check sizes
before allocating the buffer.

PR 26946, PR 28834
* Makefile.am (LIBBFD_H_FILES): Add section.c.
* compress.c (bfd_get_full_section_contents): Move section size
sanity checks..
* section.c (_bfd_section_size_insane): ..to here.  New function.
* dwarf2.c (read_section): Use _bfd_section_size_insane.
(_bfd_dwarf2_slurp_debug_info): Likewise.
* Makefile.in: Regenerate.
* libbfd.h: Regenerate.

Sanity check SHT_MIPS_OPTIONS size

* elfxx-mips.c (_bfd_mips_elf_section_from_shdr): Use
bfd_malloc_and_get_section to read contents of .MIPS.options.

Re: gold: add --compress-debug-sections=zstd [PR 29641]

Fix the following:
compressed_output.cc:86:8: error: assignment of read-only variable ‘size’
   86 |   size = ZSTD_compress(*compressed_data + header_size, size, uncompressed_data,

gold: add --compress-debug-sections=zstd [PR 29641]

This option compresses output debug sections with zstd and sets ch_type
to ELFCOMPRESS_ZSTD.  Latest gdb and lldb support ELFCOMPRESS_ZSTD.

There will be an error if zstd is not enabled at configure time.

    error: --compress-debug-sections=zstd: gold is not built with zstd support

gold, dwp: support zstd compressed input debug sections [PR 29641]

This feature is enabled if config/zstd.m4 uses zstd.

gprofng: fix typo in configure.ac

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

* configure.ac: Fix typo in redirect operator.
* configure: Rebuild.

Fix adrp distance check

gold/
* aarch64.cc (aarch64_valid_for_adrp_p): Shift offset
as a signed number.

Automatic date update in version.in

sim: v850: rename v850.dc to align with other ports

Other arches use the .dc extension for the instruction decode table.

sim: igen: fix hang when decoding boolean rule constants

The parser for boolean rules fails to skip over the , separator in
the options which makes it hang forever.  No dc files in the tree
use boolean rules atm which is why no one noticed.

sim: igen: mark error func as noreturn since it exits

sim: igen: mark output funcs with printf attribute

... and fix the legitimate bug that it catches.

sim: igen: constify various func arguments

sim: ppc: rename ppc-instructions to powerpc.igen

To make it clear this is an input to the igen tool, rename it with an
igen extension.  This matches the other files in the ppc dir (altivec
& e500 igen files), and the other igen ports (mips, mn10300, v850).

i386: Check invalid (%dx) usage

(%dx) isn't a valid memory address in any modes.  It is used as a special
memory operand for input/output port address in AT&T syntax and should
only be used with input/output instructions.  Update i386_att_operand to
set i.input_output_operand to true for (%dx) and issue an error if (%dx)
is used with non-input/output instructions.

PR gas/29751
* config/tc-i386.c (_i386_insn): Add input_output_operand.
(md_assemble): Issue an error if input/output memory operand is
used with non-input/output instructions.
(i386_att_operand): Set i.input_output_operand to true for
(%dx).
* testsuite/gas/i386/inval.l: Updated.
* testsuite/gas/i386/x86-64-inval.l: Likewise.
* testsuite/gas/i386/inval.s: Add tests for invalid (%dx) usage.
* testsuite/gas/i386/x86-64-inval.s: Likewise.

gdb: make "start" breakpoint inferior-specific

I saw this failure on a CI:

    (gdb) add-inferior
    [New inferior 2]
    Added inferior 2
    (gdb) PASS: gdb.threads/vfork-multi-inferior.exp: method=non-stop: add-inferior
    inferior 2
    [Switching to inferior 2 [<null>] (<noexec>)]
    (gdb) PASS: gdb.threads/vfork-multi-inferior.exp: method=non-stop: inferior 2
    kill
    The program is not being run.
    (gdb) file /home/jenkins/workspace/binutils-gdb_master_linuxbuild/platform/jammy-amd64/target_board/unix/tmp/tmp.GYATAXR8Ku/gdb/testsuite/outputs/gdb.threads/vfork-multi-inferior/vfork-multi-inferior-sleep
    Reading symbols from /home/jenkins/workspace/binutils-gdb_master_linuxbuild/platform/jammy-amd64/target_board/unix/tmp/tmp.GYATAXR8Ku/gdb/testsuite/outputs/gdb.threads/vfork-multi-inferior/vfork-multi-inferior-sleep...
    (gdb) run &
    Starting program: /home/jenkins/workspace/binutils-gdb_master_linuxbuild/platform/jammy-amd64/target_board/unix/tmp/tmp.GYATAXR8Ku/gdb/testsuite/outputs/gdb.threads/vfork-multi-inferior/vfork-multi-inferior-sleep
    (gdb) PASS: gdb.threads/vfork-multi-inferior.exp: method=non-stop: run inferior 2
    inferior 1
    [Switching to inferior 1 [<null>] (<noexec>)]
    (gdb) PASS: gdb.threads/vfork-multi-inferior.exp: method=non-stop: inferior 1
    kill
    The program is not being run.
    (gdb) file /home/jenkins/workspace/binutils-gdb_master_linuxbuild/platform/jammy-amd64/target_board/unix/tmp/tmp.GYATAXR8Ku/gdb/testsuite/outputs/gdb.threads/vfork-multi-inferior/vfork-multi-inferior
    Reading symbols from /home/jenkins/workspace/binutils-gdb_master_linuxbuild/platform/jammy-amd64/target_board/unix/tmp/tmp.GYATAXR8Ku/gdb/testsuite/outputs/gdb.threads/vfork-multi-inferior/vfork-multi-inferior...
    (gdb) break should_break_here
    Breakpoint 1 at 0x11b1: file /home/jenkins/workspace/binutils-gdb_master_linuxbuild/platform/jammy-amd64/target_board/unix/src/binutils-gdb/gdb/testsuite/gdb.threads/vfork-multi-inferior.c, line 25.
    (gdb) PASS: gdb.threads/vfork-multi-inferior.exp: method=non-stop: break should_break_here
    [Thread debugging using libthread_db enabled]
    Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
    start
    Temporary breakpoint 2 at 0x11c0: -qualified main. (2 locations)
    Starting program: /home/jenkins/workspace/binutils-gdb_master_linuxbuild/platform/jammy-amd64/target_board/unix/tmp/tmp.GYATAXR8Ku/gdb/testsuite/outputs/gdb.threads/vfork-multi-inferior/vfork-multi-inferior
    [Thread debugging using libthread_db enabled]
    Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

    Thread 2.1 "vfork-multi-inf" hit Temporary breakpoint 2, main () at /home/jenkins/workspace/binutils-gdb_master_linuxbuild/platform/jammy-amd64/target_board/unix/src/binutils-gdb/gdb/testsuite/gdb.threads/vfork-multi-inferior-sleep.c:23
    23   sleep (30);
    (gdb) FAIL: gdb.threads/vfork-multi-inferior.exp: method=non-stop: start inferior 1

What happens is:

 1. We start inferior 2 with "run&", it runs very slowly, takes time to
    get to main
 2. We switch to inferior 1, and run "start"
 3. The temporary breakpoint inserted by "start" applies to all inferiors
 4. Inferior 2 hits that breakpoint and GDB reports that hit

To avoid this, breakpoints inserted by "start" should be
inferior-specific.  However, we don't have a nice way to make
inferior-specific breakpoints yet.  It's possible to make
pspace-specific breakpoints (for example how the internal_breakpoint
constructor does) by creating a symtab_and_line manually.  However,
inferiors can share program spaces (usually on particular embedded
targets), so we could have a situation where two inferiors run the same
code in the same program space.  In that case, it would just not be
possible to insert a breakpoint in one inferior but not the other.

A simple solution that should work all the time is to add a condition to
the breakpoint inserted by "start", to check the inferior reporting the
hit is the expected one.  This is what this patch implements.

Add a test that does:

 - start in background inferior 1 that sleeps before reaching its main
   function (using a sleep in a global C++ object's constructor)
 - start inferior 2 with the "start" command, which also sleeps before
   reaching its main function
 - validate that we hit the breakpoint in inferior 2

Without the fix, we hit the breakpoint in inferior 1 pretty much all the
time.  There could be some unfortunate scheduling causing the test not
to catch the bug, for instance if the scheduler decides not to schedule
inferior 1 for a long time, but it would be really rare.  If the bug is
re-introduced, the test will catch it much more often than not, so it
will be noticed.

Reviewed-By: Bruno Larsen <blarsen@redhat.com>
Approved-By: Pedro Alves <pedro@palves.net>
Change-Id: Ib0148498a476bfa634ed62353c95f163623c686a

gdb: Fix regressions caused by 041de3d73aa121f2ff0c077213598963bfb34b79

Commit 041de3d73aa changed the output format of all error messages when
GDB couldn't determine a compatible overload for a given function, but
it was only supposed to change if the failure happened due to incomplete
types. This commit removes the stray . that was added

gdb/debuginfod: Improve progress updates

If the download size is known, a progress bar is displayed along with
the percentage of completion and the total download size.

  Downloading separate debug info for /lib/libxyz.so
  [############                                      ]  25% (10.01 M)

If the download size is not known, a progress indicator is displayed
with a ticker ("###") that moves across the screen at a rate of 1 tick
every 0.5 seconds.

  Downloading separate debug info for /lib/libxyz.so
  [         ###                                                      ]

If the output stream is not a tty, batch mode is enabled, the screen is
too narrow or width has been set to 'unlimited', then only a static
description of the download is printed. No bar or ticker is displayed.

  Downloading separate debug info for /lib/libxyz.so...

In any case, if the size of the download is known at the time the
description is printed then it will be included in the description.

  Downloading 10.01 MB separate debug info for /lib/libxyz.so...

gdb: add special handling for frame level 0 in frame_info_ptr

I noticed this problem while preparing the initial submission for the
ROCm GDB port.  One particularity of this patch set is that it does not
support unwinding frames, that requires support of some DWARF extensions
that will come later.  It was still possible to run to a breakpoint and
print frame #0, though.

When rebasing on top of the frame_info_ptr work, GDB started tripping on
a prepare_reinflate call, making it not possible anymore to event print
the frame when stopping on a breakpoint.  One thing to know about frame
0 is that its id is lazily computed when something requests it through
get_frame_id.  See:

  https://gitlab.com/gnutools/binutils-gdb/-/blob/23912acd402f5af9caf91b257e5209ec4c58a09c/gdb/frame.c#L2070-2080

So, up to that prepare_reinflate call, frame 0's id was not computed,
and prepare_reinflate, calling get_frame_id, forces it to be computed.
Computing the frame id generally requires unwinding the previous frame,
which with my ROCm GDB patch fails.  An exception is thrown and the
printing of the frame is simply abandonned.

Regardless of this ROCm GDB problem (which is admittedly temporary, it
will be possible to unwind with subsequent patches), we want to avoid
prepare_reinflate to force the computing of the frame id, for the same
reasons we lazily compute it in the first place.

In addition, frame 0's id is subject to change across a frame cache
reset.  This is why save_selected_frame and restore_selected_frame have
special handling for frame 0:

  https://gitlab.com/gnutools/binutils-gdb/-/blob/23912acd402f5af9caf91b257e5209ec4c58a09c/gdb/frame.c#L1841-1863

For this last reason, we also need to handle frame 0 specially in
prepare_reinflate / reinflate.  Because the frame id of frame 0 can
change across a frame cache reset, we must not rely on the frame id from
that frame to reinflate it.  We should instead just re-fetch the current
frame at that point.

This patch adds a frame_info_ptr::m_cached_level field, set in
frame_info_ptr::prepare_reinflate, so we can tell if a frame is frame 0.
There are cases where a frame_info_ptr object wraps a sentinel frame,
for which frame_relative_level returns -1, so I have chosen the value -2
to represent "invalid frame level", for when the frame_info_ptr object
is empty.

In frame_info_ptr::prepare_reinflate, only cache the frame id if the
frame level is not 0.  It's fine to cache the frame id for the sentinel
frame, it will be properly handled by frame_find_by_id later.

In frame_info_ptr::reinflate, if the frame level is 0, call
get_current_frame to get the target's current frame.  Otherwise, use
frame_find_by_id just as before.

This patch should not have user-visible changes with upstream GDB.  But
it will avoid forcing the computation of frame 0's when calling
prepare_reinflate.  And, well, it fixes the upcoming ROCm GDB patch
series.

Change-Id: I176ed7ee9317ddbb190acee8366e087e08e4d266
Reviewed-By: Bruno Larsen <blarsen@redhat.com>

gdb: add missing prepare_reinflate call in print_frame_info

print_frame_info calls frame_info_ptr::reinflate, but not
frame_info_ptr::prepare_reinflate, add the call to prepare_reinflate.
It works right now, because all callers of print_frame_info that could
possibly lead to the pretty printers being called, and the frame_info
objects being invalidated, do call prepare_reinflate themselves.  And
since the cached frame id is copied when passing a frame_info_ptr by
value, print_frame_info does have a cached frame id on entry.  So
technically, this change isn't needed.  But I don't think it's good for
a function to rely on its callers to have called prepare_reinflate, if
it intends to call reinflate.

Change-Id: Ie332b2d5479aef46f83fdc1120c7c83f4e84d1b0
Reviewed-By: Bruno Larsen <blarsen@redhat.com>

gdb: use frame_id_p instead of comparing to null_frame_id in frame_info_ptr::reinflate

The assertion

    gdb_assert (m_cached_id != null_frame_id);

is always true, as comparing equal to null_frame_id is always false
(it's the first case in frame_id::operator==, not sure why it's not this
way, but that's what it is).

Replace the comparison with a call to frame_id_p.

Approved-By: Tom Tromey <tom@tromey.com>
Change-Id: I93986e6a85ac56353690792552e5b3b4cedec7fb

gdb: remove manual frame_info reinflation code in backtrace_command_1

With the following patch applied (gdb: use frame_id_p instead of
comparing to null_frame_id in frame_info_ptr::reinflate), I would get:

    $ ./gdb -q -nx --data-directory=data-directory testsuite/outputs/gdb.base/bt-selected-frame/bt-selected-frame -ex "b breakpt" -ex r -ex "bt full"
    Reading symbols from testsuite/outputs/gdb.base/bt-selected-frame/bt-selected-frame...
    Breakpoint 1 at 0x1131: file /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.base/bt-selected-frame.c, line 22.
    Starting program: /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.base/bt-selected-frame/bt-selected-frame
    [Thread debugging using libthread_db enabled]
    Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

    Breakpoint 1, breakpt () at /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.base/bt-selected-frame.c:22
    22      }
    #0  breakpt () at /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.base/bt-selected-frame.c:22
    No locals.
    /home/smarchi/src/binutils-gdb/gdb/frame-info.c:42: internal-error: reinflate: Assertion `frame_id_p (m_cached_id)' failed.

This is because the code in backtrace_command_1 to manually reinflate
`fi` steps overs frame_info_ptr's toes.

When calling

    fi.prepare_reinflate ();

`fi` gets properly filled with the cached frame id.  But when this
happens:

    fi = frame_find_by_id (frame_id);

`fi` gets replaced by a brand new frame_info_ptr that doesn't have a
cached frame id.  Then this is called without a cached frame id:

    fi.reinflate ();

That doesn't cause any problem currently, since

 - the gdb_assert in the reinflate method doesn't actually do anything
   (the following patch fixes that)
 - `fi.m_ptr` will always be non-nullptr, since we just got it from
   frame_find_by_id, so reinflate will not do anything, it won't try to
   use m_cached_id

Fix that by removing the code to manually re-fetch the frame.  That
should be taken care of by frame_info_ptr::reinflate.

Note that the old code checked if we successfully re-inflated the frame
or not, and if not it did emit a warning.  The equivalent in
frame_info_ptr::reinflate asserts that the frame has been successfully
re-inflated.  It's not clear if / when this can happen, but if it can
happen, we'll need to find a solution to this problem globally
(everywhere a frame_info_ptr can be re-inflated), not just here.  So I
propose to leave it like this, until it does become a problem.

Reviewed-By: Bruno Larsen <blarsen@redhat.com>
Change-Id: I07b783d94e2853e0a2d058fe7deaf04eddf24835

gdb: move frame_info_ptr method implementations to frame-info.c

I don't see any particular reason why the implementations of the
frame_info_ptr object are in the header file.  It only seems to add some
complexity.  Since we can't include frame.h in frame-info.h, we have to
add declarations of functions defined in frame.c, in frame-info.h.  By
moving the implementations to a new frame-info.c, we can avoid that.

Change-Id: I435c828f81b8a3392c43ef018af31effddf6be9c
Reviewed-By: Bruno Larsen <blarsen@redhat.com>
Reviewed-By: Tom Tromey <tom@tromey.com>

gdb: add prepare_reinflate/reinflate around print_frame_args in info_frame_command_core

I noticed this crash:

    $ ./gdb --data-directory=data-directory -nx -q \
          testsuite/outputs/gdb.python/pretty-print-call-by-hand/pretty-print-call-by-hand \
  -x testsuite/outputs/gdb.python/pretty-print-call-by-hand/pretty-print-call-by-hand.py \
  -ex "b g" -ex r
    (gdb) info frame
    Stack level 0, frame at 0x7fffffffdd80:
     rip = 0x555555555160 in g
        (/home/simark/src/binutils-gdb/gdb/testsuite/gdb.python/pretty-print-call-by-hand.c:41); saved rip = 0x5555555551a3
     called by frame at 0x7fffffffdda0
     source language c.
     Arglist at 0x7fffffffdd70, args: mt=mytype is 0x555555556004 "hello world",
        depth=10

    Fatal signal: Segmentation fault

This is another case of frame_info being invalidated under a function's
feet.  The stack trace when the frame_info get invalidated looks like:

    ... many frames to pretty print the arg, that eventually invalidate the frame_infos ...
    #35 0x00005568d0a8ab24 in print_frame_arg (fp_opts=..., arg=0x7ffc3216bcb0) at /home/simark/src/binutils-gdb/gdb/stack.c:489
    #36 0x00005568d0a8cc75 in print_frame_args (fp_opts=..., func=0x621000233210, frame=..., num=-1, stream=0x60b000000300)
        at /home/simark/src/binutils-gdb/gdb/stack.c:898
    #37 0x00005568d0a9536d in info_frame_command_core (fi=..., selected_frame_p=true) at /home/simark/src/binutils-gdb/gdb/stack.c:1682

print_frame_args knows that print_frame_arg can invalidate frame_info
objects, and therefore calls prepare_reinflate/reinflate.  However,
info_frame_command_core has a separate frame_info_ptr instance (it is
passed by value / copy).  So info_frame_command_core needs to know that
print_frame_args can invalidate frame_info objects, and therefore needs
to prepare_reinflate/reinflate as well.  Add those calls, and enhance
the gdb.python/pretty-print-call-by-hand.exp test to test that command.

Reviewed-By: Bruno Larsen <blarsen@redhat.com>
Change-Id: I9edaae06d62e97ffdb30938d364437737238a960

gdb: clear other.m_cached_id in frame_info_ptr's move ctor

We do it in the move assignment operator, so I think it makes sense to
do it here too for consistency.  I don't think it's absolutely necessary
to clear the other object's fields (in other words, copy constructor and
move constructor could be the same), as there is no exclusive resource
being transfered.  The important thing is to leave the moved-from object
in an unknown, but valid state.  But still, I think that clearing the
fields of the moved-from object is not a bad idea, it helps ensure we
don't rely on the moved-from object after.

Change-Id: Iee900ff9d25dad51d62765d694f2e01524351340
Reviewed-By: Bruno Larsen <blarsen@redhat.com>

gdb/c++: Improve error messages in overload resolution

When resolving overloaded functions, GDB relies on knowing relationships
between types, i.e. if a type inherits from another. However, some
compilers may not add complete information for given types as a way to
reduce unnecessary debug information. In these cases, GDB would just say
that it couldn't resolve the method or function, with no extra
information.

The problem is that sometimes the user may not know that the type
information is incomplete, and may just assume that there is a bug in
GDB. To improve the user experience, we attempt to detect if the
overload match failed because of an incomplete type, and warn the user
of this.

This commit also adds a testcase confirming that the message is only
triggered in the correct scenario. This test was not developed as an
expansion of gdb.cp/overload.cc because it needed the dwarf assembler,
and porting all of overload.cc seemed unnecessary.

Approved-By: Tom Tromey <tom@tromey.com>

gdb/testsuite: allowed for function_range to deal with mangled functions

When calling get_func_info inside a test case, it would cause failures
if the function was printed using a C++ style mangled name. The current
patch fixes this by allowing for mangled names along with the current
rules.

Approved-By: Tom Tromey <tom@tromey.com>

ld/testsuite: skip ld-size when -shared is not supported

ld/ChangeLog:

        * testsuite/ld-size/size.exp: Skip when -shared is not
supported.

mach-o reloc size overflow

* mach-o.c (bfd_mach_o_canonicalize_reloc): Set bfd_error on
multiply overflow.

Sanity check reloc count in get_reloc_upper_bound

The idea here is the stop tools from allocating up to 32G per section
for the arelent pointer array, only to find a little later that the
section reloc count was fuzzed.  This usually doesn't hurt much (on
systems that allow malloc overcommit) except when compiled with asan.

We already do this for ELF targets, and while fixing the logic
recently I decided other targets ought to do the same.

* elf64-sparc.c (elf64_sparc_get_reloc_upper_bound): Sanity check
section reloc count against file size.
* mach-o.c (bfd_mach_o_get_reloc_upper_bound): Likewise.
* aoutx.h (get_reloc_upper_bound): Likewise, and don't duplicate
check done in bfd_get_reloc_upper_bound.
* pdp11.c (get_reloc_upper_bound): Likewise.
* coffgen.c (coff_get_reloc_upper_bound): Likewise.

gdb/testsuite: Fix rtld-step-nodebugsym.exp

The test case introduced in bafcc335266 (Fix stepping in rtld without
debug symbol) fails on some systems as reported by PR/29768.  This can
be seen if the system does not have debug info for the libc:

  (gdb) step^M
  Single stepping until exit from function main,^M
  which has no line number information.^M
  hello world[Inferior 1 (process 48203) exited normally]^M
  (gdb) PASS: gdb.base/rtld-step-nodebugsym.exp: step
  continue^M
  The program is not being run.^M
  (gdb) FAIL: gdb.base/rtld-step-nodebugsym.exp: continue until exit (the program is no longer running)

Without glibc debug info, GDB steps until the program finishes, and
then "gdb_continue_to_end" fails.

As this test was designed to check that GDB does not crash in the "step"
command, the continue does not carry real meaning to the test.

Replace it by "print 0" so we still check that after the step command
GDB is still alive, which is what we care about.

Tested on Ubuntu-22.04 x86_64, with and without libc6-dbg.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29768
Approved-By: Simon Marchi <simon.marchi@efficios.com>

sim: ppc: drop old makefile fragment

Support for these files was dropped almost 30 years ago, but the ppc
arch was missed.  Clean that up now too.

sim: ppc: drop support for dgen -L option

Nothing passes this to dgen, and even if it did, nothing would happen
because the generated spreg.[ch] files don't include any references
back to the original data table.  So drop it to simplify.

sim: ppc: collapse is_readonly & length switch tables heavily

Since we know we'll return 0 by default, we don't have to output case
statements for readonly or length fields whose values are also zero.
This is the most common case by far and thus generates a much smaller
switch table in the end.

sim: ppc: collapse is_valid switch table more

Instead of writing:
  case 1:
    return 1;
  case 2:
    return 1;
  ...etc...

Output a single return so we get:
  case 1:
  case 2:
  case ...
    return 1;

This saves ~100 lines of code.  Hopefully the compiler was already
smart enough to optimize to the same code, but if not, this probably
helps there too :).

sim: ppc: pull default switch return out

This saves a single line for the same result.  By itself, it's not
interesting, but we can further optimize the generated output and
completely omit the switch table in some cases.  Which we'll do in
follow up commits.

sim: ppc: constify spreg table

This internal table is only ever read, so constify it.

ld: Add module information substream to PDB files

[opcodes/arm] Fix potential null pointer dereferences

  PR tdep/29598

  As pointed out in the bug ticket, we have a couple potential null pointer
  dereferencing situations. Harden those.

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

[gdb/aarch64] Use safer memory read routines

  PR tdep/28796

  As reported, we are using some memory read routines that don't handle read
  errors gracefully. Convert those to use the safe_* versions if available.

  This allows the code to handle those read errors in a more sensible way.

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