gprof: remove use of PTR

* basic_blocks.c: Replace uses of PTR with void * throughout.
* cg_arcs.c: Likewise.
* cg_print.c: Likewise.
* hist.c: Likewise.
* source.h: Likewise.
* symtab.c: Likewise.

gas: remove use of PTR

* config/obj-evax.c (evax_symbol_new_hook): Don't cast to PTR.

opcodes: remove use of PTR

The non-cgen parts of opcodes.

* cr16-dis.c (print_arg): Replace PTR with void *.
* crx-dis.c (print_arg): Likewise.
* rl78-dis.c (print_insn_rl78_common): Don't use PTR cast.
* rx-dis.c (print_insn_rx): Likewise.
* visium-dis.c (print_insn_visium): Likewise.
* z8k-dis.c (print_insn_z8k): Likewise.

bfd: remove use of PTR

* coffcode.h (coff_write_object_contents): Don't cast to PTR.
* elf32-csky.c (csky_elf_link_hash_traverse): Remove use of PTR
and PARAMS.
(csky_allocate_dynrelocs): Don't use PTR cast.
* elf32-nios2.c (adjust_dynrelocs, allocate_dynrelocs): Replace
PTR with void *.
* elf32-visium.c (visium_elf_howto_parity_reloc): Likewise.
* elfxx-ia64.c (ia64_elf_reloc): Likewise.
* plugin.c (bfd_plugin_bfd_print_private_bfd_data): Likewise.

include: remove use of PTR

* hashtab.h (HTAB_EMPTY_ENTRY): Replace PTR with void *.
(HTAB_DELETED_ENTRY): Likewise.

Automatic date update in version.in

IBM zSystems: Accept (. - 0x100000000) PCRel32 operands

as does not accept instructions like brasl %r0,.-0x100000000, because
of two problems with the generic overflow check:

1. PCRel32 operands are signed, but are treated as unsigned.

2. The allowed range for these operands is [-(1 << 32), (1 << 32) - 1],
   and not [-(1 << 31), (1 << 31) - 1].

Fix both by disabling the generic overflow check - it's not needed,
because s390_insert_operand () performs its own.

gas/

        * config/tc-s390.c (md_gather_operands): Set fx_no_overflow.
        * testsuite/gas/s390/s390.exp: Add zarch-z900-err.
        * testsuite/gas/s390/esa-z900.d: New test.
        * testsuite/gas/s390/esa-z900.s: New test.
        * testsuite/gas/s390/zarch-z900-err.l: New test.
        * testsuite/gas/s390/zarch-z900-err.s: New test.

gdb/testsuite: fix occasional failure in gdb.mi/mi-multi-commands.exp

In bug PR gdb/29036, another failure was reported for the test
gdb.mi/mi-multi-commands.exp.  This test sends two commands to GDB as
a single write, and then checks that both commands are executed.

The problem that was encountered here is that the output of the first
command, which looks like this:

  ^done,value="\"FIRST COMMAND\""

Is actually produced in parts, first the '^done' is printed, then the
',value="\"FIRST COMMAND\"" is printed.

What was happening is that some characters from the second command
were being echoed after the '^done' had been printed, but before the
value part had been printed.  To avoid this issue I've relaxed the
pattern that checks for the first command a little.  With this fix in
place the occasional failure in this test is no longer showing up.

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

[gdb] Update syscalls/{amd64,i386}-linux.xml

- Add a script syscalls/gen-header.py, based on syscalls/arm-linux.py.
- Add a script syscalls/update-linux.sh (alongside update-freebsd.sh and
  update-netbsd.sh).
- Use syscalls/update-linux.sh to update syscalls/{amd64,i386}-linux.xml.in.
- Regenerate syscalls/{amd64,i386}-linux.xml using syscalls/Makefile.

In gdb/syscalls/i386-linux.xml.in, updating has the following notable effect:
...
-  <syscall name="madvise1" number="220"/>
-  <syscall name="getdents64" number="221"/>
-  <syscall name="fcntl64" number="222"/>
+  <syscall name="getdents64" number="220"/>
+  <syscall name="fcntl64" number="221"/>
...

I've verified in ./arch/x86/entry/syscalls/syscall_32.tbl that the numbers are
correct.

Tested on x86_64-linux.

[gdb] Add gdb/syscalls/Makefile

Add a Makefile in gdb/syscalls that can be used to translate
gdb/syscalls/*.xml.in into gdb/syscalls/*.xml.

Calling make reveals that bfin-linux.xml is missing, so add it.

Tested on x86_64-linux.

gdb: LoongArch: Implement the return_value gdbarch method

When execute the following command on LoongArch:

  make check-gdb TESTS="gdb.base/async.exp"

there exist the following failed testcases:

  FAIL: gdb.base/async.exp: finish& (timeout)
  FAIL: gdb.base/async.exp: jump& (timeout)
  FAIL: gdb.base/async.exp: until& (timeout)
  FAIL: gdb.base/async.exp: set exec-done-display off (GDB internal error)

we can see the following messages in gdb/testsuite/gdb.log:

  finish&
  Run till exit from #0  foo () at /home/loongson/gdb.git/gdb/testsuite/gdb.base/async.c:9
  (gdb) /home/loongson/gdb.git/gdb/gdbarch.c:2646: internal-error: gdbarch_return_value: Assertion `gdbarch->return_value != NULL' failed.
  A problem internal to GDB has been detected,
  further debugging may prove unreliable.

In order to fix the above failed testcases, implement the return_value
gdbarch method on LoongArch.

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

gdb: fix for gdb.base/eof-exit.exp test failures

This fix relates to PR gdb/29032, this makes the test more stable by
ensuring that the Ctrl-D is only sent once the prompt has been
displayed.  This issue was also discussed on the mailing list here:

  https://sourceware.org/pipermail/gdb-patches/2022-April/187670.html

The problem identified in the bug report is that sometimes the Ctrl-D
(that the test sends to GDB) arrives while GDB is processing a
command.  When this happens the Ctrl-D is handled differently than if
the Ctrl-D is sent while GDB is waiting for input at a prompt.

The original intent of the test was that the Ctrl-D be sent while GDB
was waiting at a prompt, and that is the case the occurs most often,
but, when the Ctrl-D arrives during command processing, then GDB will
ignore the Ctrl-D, and the test will fail.

This commit ensures the Ctrl-D is always sent while GDB is waiting at
a prompt, which makes this test stable.

But, that still leaves an open question, what should happen when the
Ctrl-D arrives while GDB is processing a command?  This commit doesn't
attempt to answer that question, which is while bug PR gdb/29032 will
not be closed once this commit is merged.

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

[gdb] Make btrace maintainer entry more clear

Do:
...
-record btrace          <name>       <email>
+record
+  btrace               <name>       <email>
...
to clarify that the listed maintainer is only maintainer of the btrace part of
record.

ansidecl.h: sync from GCC

include/ChangeLog:

* ansidecl.h: Sync from GCC.

[gdb/tdep] Support catch syscall pipe2 for i386

With test-case gdb.base/catch-syscall.exp and target board unix/-m32, we run
into:
...
(gdb) catch syscall pipe2^M
Unknown syscall name 'pipe2'.^M
(gdb) FAIL: gdb.base/catch-syscall.exp: determine pipe syscall: catch syscall pipe2
...

Fix this by:
- adding a pipe2 entry in gdb/syscalls/i386-linux.xml.in, and
- regenerating gdb/syscalls/i386-linux.xml using
  "xsltproc --output i386-linux.xml apply-defaults.xsl i386-linux.xml.in".

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

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

[gdb/testsuite] Handle pipe2 syscall in gdb.base/catch-syscall.exp

When running test-case gdb.reverse/pipe-reverse.exp on openSUSE Tumbleweed,
I run into:
...
(gdb) continue^M
Continuing.^M
^M
Catchpoint 2 (returned from syscall pipe2), in pipe () from /lib64/libc.so.6^M
(gdb) FAIL: gdb.base/catch-syscall.exp: without arguments: \
  syscall pipe has returned
...

The current glibc on Tumbleweed is 2.35, which contains commit
"linux: Implement pipe in terms of __NR_pipe2", and consequently syscall pipe2
is used instead of syscall pipe.

Fix this by detecting whether syscall pipe or pipe2 is used before running the
tests.

Tested on x86_64-linux, specifically on:
- openSUSE Tumbleweed (with glibc 2.35), and
- openSUSE Leap 15.3 (with glibc 2.31).

On openSUSE Tumbleweed + target board unix/-m32, this exposes:
...
(gdb) catch syscall pipe2^M
Unknown syscall name 'pipe2'.^M
...
which will be fixed in a folllow-up patch.

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

[gdb/tdep] Handle pipe2 syscall for amd64

When running test-case gdb.reverse/pipe-reverse.exp on openSUSE Tumbleweed,
I run into:
...
(gdb) continue^M
Continuing.^M
Process record and replay target doesn't support syscall number 293^M
Process record: failed to record execution log.^M
^M
Program stopped.^M
0x00007ffff7daabdb in pipe () from /lib64/libc.so.6^M
(gdb) FAIL: gdb.reverse/pipe-reverse.exp: continue to breakpoint: marker2
...

The current glibc on Tumbleweed is 2.35, which contains commit
"linux: Implement pipe in terms of __NR_pipe2", and consequently syscall pipe2
is used in stead of syscall pipe.

There is already support added for syscall pipe2 for aarch64 (which only has
syscall pipe2, not syscall pipe), so enable the same for amd64, by:
- adding amd64_sys_pipe2 in enum amd64_syscall
- translating amd64_sys_pipe2 to gdb_sys_pipe2 in amd64_canonicalize_syscall

Tested on x86_64-linux, specifically on:
- openSUSE Tumbleweed (with glibc 2.35), and
- openSUSE Leap 15.3 (with glibc 2.31).

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

Automatic date update in version.in

[gdb/testsuite] Fix gdb.tui/scroll.exp with read1

When running test-case gdb.tui/scroll.exp, I get:
...
Box Dump (80 x 8) @ (0, 0):
    0 $17 = 16
    1 (gdb) p 17
    2 $18 = 17
    3 (gdb) p 18
    4 $19 = 18
    5 (gdb) p 19
    6 $20 = 19
    7 (gdb)
PASS: gdb.tui/scroll.exp: check cmd window in flip layout
...
but with check-read1 I get instead:
...
Box Dump (80 x 8) @ (0, 0):
    0 (gdb) 15
    1 (gdb) p 16
    2 $17 = 16
    3 (gdb) p 17
    4 $18 = 17
    5 (gdb) p 18
    6 $19 = 18
    7 (gdb) p 19
FAIL: gdb.tui/scroll.exp: check cmd window in flip layout
...

The "p 19" command is handled by Term::command, which sends the command and then
does Term::wait_for "^$gdb_prompt [string_to_regexp $cmd]", which:
- matches the line with "(gdb) p 19", and
- tries to match the following prompt "(gdb) "

The problem is that scrolling results in reissuing output before the "(gdb) p
19", and the second matching triggers on that.  Consequently, wait_for no
longer translates gdb output into screen actions, and the screen does not
reflect the result of "p 19".

Fix this by using a new proc wait_for_region_contents, which in contrast to
wait_for can handle a multi-line regexp.

Tested on x86_64-linux with make targets check and check-read1.

[gdb/testsuite] Fix gdb.cp/casts.exp with -m32

When running test-case gdb.cp/casts.exp with target board unix/-m32, I run
into:
...
(gdb) print (unsigned long long) &gd == gd_value^M
$31 = false^M
(gdb) FAIL: gdb.cp/casts.exp: print (unsigned long long) &gd == gd_value
...

With some additional printing, we can see in more detail why the comparison
fails:
...
(gdb) print /x &gd^M
$31 = 0xffffc5c8^M
(gdb) PASS: gdb.cp/casts.exp: print /x &gd
print /x (unsigned long long)&gd^M
$32 = 0xffffc5c8^M
(gdb) PASS: gdb.cp/casts.exp: print /x (unsigned long long)&gd
print /x gd_value^M
$33 = 0xffffffffffffc5c8^M
(gdb) PASS: gdb.cp/casts.exp: print /x gd_value
print (unsigned long long) &gd == gd_value^M
$34 = false^M
(gdb) FAIL: gdb.cp/casts.exp: print (unsigned long long) &gd == gd_value
...

The gd_value is set by this assignment:
...
  unsigned long long gd_value = (unsigned long long) &gd;
...

The problem here is directly casting from a pointer to a non-pointer-sized
integer.

Fix this by adding an intermediate cast to std::uintptr_t.

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

[gdb/testsuite] Handle init errors in gdb.mi/user-selected-context-sync.exp

In OBS, on aarch64-linux, with a gdb 11.1 based package, I run into:
...
(gdb) builtin_spawn -pty^M
new-ui mi /dev/pts/5^M
New UI allocated^M
(gdb) =thread-group-added,id="i1"^M
(gdb) ERROR: MI channel failed
warning: Error detected on fd 11^M
thread 1.1^M
Unknown thread 1.1.^M
(gdb) UNRESOLVED: gdb.mi/user-selected-context-sync.exp: mode=non-stop: \
  test_cli_inferior: reset selection to thread 1.1
...
with many more UNRESOLVED following.

The ERROR is a common problem, filed as
https://sourceware.org/bugzilla/show_bug.cgi?id=28561 .

But the many UNRESOLVEDs are due to not checking whether the setup as done in
the test_setup function succeeds or not.

Fix this by:
- making test_setup return an error upon failure
- handling test_setup error at the call site
- adding a "setup done" pass/fail to be turned into an unresolved
  in case of error during setup.

Tested on x86_64-linux, by manually triggering the error in
mi_gdb_start_separate_mi_tty.

[gdb/testsuite] Fix gdb.ada/catch_ex_std.exp with remote-gdbserver-on-localhost

When running test-case gdb.ada/catch_ex_std.exp on target board
remote-gdbserver-on-localhost, I run into:
...
(gdb) continue^M
Continuing.^M
[Inferior 1 (process 15656) exited with code 0177]^M
(gdb) FAIL: gdb.ada/catch_ex_std.exp: runto: run to main
Remote debugging from host ::1, port 49780^M
/home/vries/foo: error while loading shared libraries: libsome_package.so: \
  cannot open shared object file: No such file or directory^M
...

Fix this by adding the usual shared-library + remote-target helper
"gdb_load_shlib $sofile".

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

[gdb/testsuite] Fix gdb.threads/fork-plus-threads.exp with check-readmore

When running test-case gdb.threads/fork-plus-threads.exp with check-readmore,
I run into:
...
[Inferior 11 (process 7029) exited normally]^M
[Inferior 1 (process 6956) exited normally]^M
FAIL: gdb.threads/fork-plus-threads.exp: detach-on-fork=off: \
  inferior 1 exited (timeout)
...

The problem is that the regexp consuming the "Inferior exited normally"
messages:
- consumes more than one of those messages at a time, but
- counts only one of those messages.

Fix this by adopting a line-by-line approach, which deals with those messages
one at a time.

Tested on x86_64-linux with native, check-read1 and check-readmore.

Automatic date update in version.in

Fix "catch syscall"

Simon pointed out that some recent patches of mine broke "catch
syscall".  Apparently I forgot to finish the conversion of this code
when removing init_catchpoint.  This patch completes the conversion
and fixes the bug.

gdb/readline: fix extra 'quit' message problem

After these two commits:

  commit 4fb7bc4b147fd30b781ea2dad533956d0362295a
  Date:   Mon Mar 7 13:49:21 2022 +0000

      readline: back-port changes needed to properly detect EOF

  commit 91395d97d905c31ac38513e4aaedecb3b25e818f
  Date:   Tue Feb 15 17:28:03 2022 +0000

      gdb: handle bracketed-paste-mode and EOF correctly

It was observed that, if a previous command is selected at the
readline prompt using the up arrow key, then when the command is
accepted (by pressing return) an unexpected 'quit' message will be
printed by GDB.  Here's an example session:

  (gdb) p 123
  $1 = 123
  (gdb) p 123
  quit
  $2 = 123
  (gdb)

In this session the second 'p 123' was entered not by typing 'p 123',
but by pressing the up arrow key to select the previous command.  It
is important that the up arrow key is used, typing Ctrl-p will not
trigger the bug.

The problem here appears to be readline's EOF detection when handling
multi-character input sequences.  I have raised this issue on the
readline mailing list here:

  https://lists.gnu.org/archive/html/bug-readline/2022-04/msg00012.html

a solution has been proposed here:

  https://lists.gnu.org/archive/html/bug-readline/2022-04/msg00016.html

This patch includes a test for this issue as well as a back-port of
(the important bits of) readline commit:

  commit 2ef9cec8c48ab1ae3a16b1874a49bd1f58eaaca1
  Date:   Wed May 4 11:18:04 2022 -0400

      fix for setting RL_STATE_EOF in callback mode

That commit also includes some updates to the readline documentation
and tests that I have not included in this commit.

With this commit in place the unexpected 'quit' messages are resolved.

Fix multiple ubsan warnings in i386-dis.c

Commit 39fb369834a3 "opcodes: Make i386-dis.c thread-safe" introduced
a number of casts to bfd_signed_vma that cause undefined behaviour
with a 32-bit libbfd.  Revert those changes.

* i386-dis.c (OP_E_memory): Do not cast disp to bfd_signed_vma
for negation.
(get32, get32s): Don't use bfd_signed_vma here.

Re: Fix new linker testsuite failures due to rwx segment test problems

Fix it some more.

bfd/
* elfnn-loongarch.c: Remove commented out elf_backend_* defines.
ld/
* testsuite/ld-elf/elf.exp (target_defaults_to_execstack): Match
arm*.  Delete loongarch.

Automatic date update in version.in

PowerPC fix for gdb.server/sysroot.exp

On PowerPC, the stop in the printf function is of the form:

Breakpoint 2, 0x00007ffff7c6ab08 in printf@@GLIBC_2.17 () from /lib64/libc.so.6

On other architectures the output looks like:

Breakpoint 2, 0x0000007fb7ea29ac in printf () from /lib/aarch64-linux-gnu/libc.so.6

The following patch modifies the printf test by matchine any character
starting immediately after the printf.  The test now works for PowerPC
output as well as the output from other architectures.

The test has been run on a Power 10 system and and Intel x86_64 system.

Fix new linker testsuite failures due to rwx segment test problems

Introduce catchpoint class

This introduces a catchpoint class that is used as the base class for
all catchpoints.  init_catchpoint is rewritten to be a constructor
instead.

This changes the hierarchy a little -- some catchpoints now inherit
from base_breakpoint whereas previously they did not.  This isn't a
problem, as long as re_set is redefined in catchpoint.

Add initializers to tracepoint

This adds some initializers to tracepoint.  I think right now these
may not be needed, due to obscure rules about zero initialization.
However, this will change in the next patch, and anyway it is clearer
to be explicit.

Remove init_raw_breakpoint_without_location

This removes init_raw_breakpoint_without_location, replacing it with a
constructor on 'breakpoint' itself.  The subclasses and callers are
all updated.

Disable copying for breakpoint

It seems to me that breakpoint should use DISABLE_COPY_AND_ASSIGN.
This patch does this.

Add constructor to exception_catchpoint

This adds a constructor to exception_catchpoint and simplifies the
caller.

Add constructor to syscall_catchpoint

This adds a constructor to syscall_catchpoint and simplifies the
caller.

Add constructor to signal_catchpoint

This adds a constructor to signal_catchpoint and simplifies the
caller.

Add constructor to solib_catchpoint

This adds a constructor to solib_catchpoint and simplifies the caller.

Add constructor to fork_catchpoint

This adds a constructor to fork_catchpoint and simplifies the caller.

Remove unnecessary line from catch_exec_command_1

catch_exec_command_1 clears the new catchpoint's "exec_pathname"
field, but this is already done by virtue of calling "new".

Constify breakpoint::print_recreate

This constifies breakpoint::print_recreate.

Constify breakpoint::print_mention

This constifies breakpoint::print_mention.

Constify breakpoint::print_one

This constifies breakpoint::print_one.

Constify breakpoint::print_it

This constifies breakpoint::print_it.  Doing this pointed out some
code in ada-lang.c that can be simplified a little as well.

Move works_in_software_mode to watchpoint

works_in_software_mode is only useful for watchpoints.  This patch
moves it from breakpoint to watchpoint, and changes it to return bool.

Boolify breakpoint::explains_signal

This changes breakpoint::explains_signal to return bool.

Remove breakpoint::ops

The breakpoint::ops field is set but never used.  This removes it.

Change print_recreate_thread to a method

This changes print_recreate_thread to be a method on breakpoint.  This
function is only used as a helper by print_recreate methods, so I
thought this transformation made sense.

PowerPC: bp-permanent.exp, kill-after-signal fix

The break point after the stepi on Intel is the entry point of the user
signal handler function test_signal_handler.  The code at the break point
looks like:

     0x<hex address> <test_signal_handler>: endbr64

On PowerPC with a Linux 5.9 kernel or latter, the address where gdb stops
after the stepi is in the vdso code inserted by the kernel.  The code at the
breakpoint looks like:

  0x<hex address>  <__kernel_start_sigtramp_rt64>: bctrl

This is different from other architectures.  As discussed below, recent
kernel changes involving the vdso for PowerPC have been made changes to the
signal handler code flow.  PowerPC is now stopping in function
__kernel_start_sigtramp_rt64.  PowerPC now requires an additional stepi to
reach the user signal handler unlike other architectures.

The bp-permanent.exp and kill-after-signal tests run fine on PowerPC with an
kernel that is older than Linux 5.9.

The PowerPC 64 signal handler was updated by the Linux kernel 5.9-rc1:

    commit id: 0138ba5783ae0dcc799ad401a1e8ac8333790df9
    powerpc/64/signal: Balance return predictor stack in signal trampoline

An additional change to the PowerPC 64 signal handler was made in Linux
kernel version 5.11-rc7 :

     commit id: 24321ac668e452a4942598533d267805f291fdc9
     powerpc/64/signal: Fix regression in __kernel_sigtramp_rt64() semantics

The first kernel change, puts code into the user space signal handler (in
the vdso) as a performance optimization to prevent the call/return stack
from getting out of balance.  The patch ensures that the entire
user/kernel/vdso cycle is balanced with the addition of the "brctl"
instruction.

The second patch, fixes the semantics of __kernel_sigtramp_rt64().  A new
symbol is introduced to serve as the jump target from the kernel to the
trampoline which now consists of two parts.

The above changes for PowerPC signal handler, causes gdb to stop in the
kernel code not the user signal handler as expected.  The kernel dispatches
to the vdso code which in turn calls into the signal handler.  PowerPC is
special in that the kernel is using a vdso instruction (bctrl) to enter the
signal handler.

I do not have access to a system with the first patch but not the second.  I did
test on Power 9 with the Linux 5.15.0-27-generic kernel.  Both tests fail on
this Power 9 system.  The two tests also fail on Power 10 with the Linux
5.14.0-70.9.1.el9_0.ppc64le kernel.

The following patch fixes the issue by checking if gdb stopped at "signal
handler called".  If gdb stopped there, the tests verifies gdb is in the kernel
function __kernel_start_sigtramp_rt64 then does an additional stepi to reach the
user signal handler.  With the patch below, the tests run without errors on both
the Power 9 and Power 10 systems with out any failures.

bfd targmatch.h makefile rule

I hit this just now with a make -j build after touching config.bfd.
mv: cannot stat 'targmatch.new': No such file or directory
make[2]: *** [Makefile:2336: targmatch.h] Error 1
make[2]: *** Waiting for unfinished jobs....

Fix that by not removing the target of the rule, a practice that seems
likely to cause parallel running of the rule recipe.  The bug goes
back to 1997, the initial c0734708814c commit.

* Makefile.am (targmatch.h): rm the temp file, not targmatch.h.
* Makefile.in: Regenerate.

[gdb/testsuite] Fix gdb.dwarf2/locexpr-data-member-location.exp with nopie

When running test-case gdb.dwarf2/locexpr-data-member-location.exp with
target board unix/-fno-PIE/-no-pie/-m32 I run into:
...
(gdb) step^M
26        return 0;^M
(gdb) FAIL: gdb.dwarf2/locexpr-data-member-location.exp: step into foo
...

The problem is that the test-case tries to mimic some gdb_compile_shlib
behaviour using:
...
set flags {additional_flags=-fpic debug}
get_func_info foo $flags
...
but this doesn't work with the target board setting, because we end up doing:
...
gcc locexpr-data-member-location-lib.c -fpic -g -lm -fno-PIE -no-pie -m32 \
  -o func_addr23029.x
...
while gdb_compile_shlib properly filters out the -fno-PIE -no-pie.

Consequently, the address for foo determined by get_func_info doesn't match
the actual address of foo.

Fix this by printing the address of foo using the result of gdb_compile_shlib.

Automatic date update in version.in

gdb: use gdb::function_view for gdbarch_iterate_over_objfiles_in_search_order callback

A rather straightforward patch to change an instance of callback +
void pointer to gdb::function_view, allowing pasing lambdas that
capture, and eliminating the need for the untyped pointer.

Change-Id: I73ed644e7849945265a2c763f79f5456695b0037

gprofng: use $host instead $target

By mistake, $target was used instead of $host to configure the gprogng build.

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

PR gprofng/29113
PR gprofng/29116
* configure.ac: Use $host instead $target.
* libcollector/configure.ac: Likewise.
* configure: Rebuild.
* libcollector/configure: Rebuild.

gdb: make regcache's cooked_write_test selftest work with native-extended-gdbserver board

Running

    $ make check TESTS="gdb.gdb/unittest.exp" RUNTESTFLAGS="--target_board=native-extended-gdbserver"

I get some failures:

    Running selftest regcache::cooked_write_test::i386.^M
    Self test failed: target already pushed^M
    Running selftest regcache::cooked_write_test::i386:intel.^M
    Self test failed: target already pushed^M
    Running selftest regcache::cooked_write_test::i386:x64-32.^M
    Self test failed: target already pushed^M
    Running selftest regcache::cooked_write_test::i386:x64-32:intel.^M
    Self test failed: target already pushed^M
    Running selftest regcache::cooked_write_test::i386:x86-64.^M
    Self test failed: target already pushed^M
    Running selftest regcache::cooked_write_test::i386:x86-64:intel.^M
    Self test failed: target already pushed^M
    Running selftest regcache::cooked_write_test::i8086.^M
    Self test failed: target already pushed^M

This is because the native-extended-gdbserver automatically connects GDB
to a GDBserver on startup, and therefore pushes a remote target on the
initial inferior.  cooked_write_test is currently written in a way that
errors out if the current inferior has a process_stratum_target pushed.

Rewrite it to use scoped_mock_context, so it doesn't depend on the
current inferior (the current one upon entering the function).

Change-Id: I0357f989eacbdecc4bf88b043754451b476052ad

Move TILE-Gx files to TARGET64_LIBOPCODES_CFILES

TILE-Gx is a 64-bit core, so we should include those files in the
TARGET64_LIBOPCODES_CFILES as opposed to TARGET32_LIBOPCODES_CFILES.

Don't define ARCH_cris for BFD64

I believe it is a mistake to define ARCH_cris when BFD64 is defined. It is
a 32-bit architecture, so should be placed outside of the BFD64 block.

loongarch: Don't check ABI flags if no code section

Various packages (glib and gtk4 for example) produces data-only objects
using `ld -r -b binary` or `objcopy`, with no elf header flags set.  But
these files also have no code sections, so they should be compatible
with all ABIs.

bfd/
* elfnn-loongarch.c (elfNN_loongarch_merge_private_bfd_data):
Skip ABI checks if the input has no code sections.

Reported-by: Wu Xiaotian <yetist@gmail.com>
Suggested-by: Wang Xuerui <i@xen0n.name>
Signed-off-by: Xi Ruoyao <xry111@mengyan1223.wang>

IBM zSystems: mgrk, mg first operand requires register pair

opcodes/

* s390-opc.c (INSTR_RRF_R0RER): New instruction type.
(MASK_RRF_R0RER): Define mask for new instruction type.
* s390-opc.txt: Use RRF_R0RER for mgrk and RXY_RERRD for mg.

bfd: Check NULL pointer before setting ref_real

PR ld/29086
* linker.c (bfd_wrapped_link_hash_lookup): Check NULL pointer
before setting ref_real.

Automatic date update in version.in

LTO: Handle __real_SYM reference in IR

When an IR symbol SYM is referenced in IR via __real_SYM, its resolution
should be LDPR_PREVAILING_DEF, not PREVAILING_DEF_IRONLY, since LTO
doesn't know that __real_SYM should be resolved by SYM.

bfd/

PR ld/29086
* linker.c (bfd_wrapped_link_hash_lookup): Mark SYM is referenced
via __real_SYM.

include/

PR ld/29086
* bfdlink.h (bfd_link_hash_entry): Add ref_real.

ld/

PR ld/29086
* plugin.c (get_symbols): Resolve SYM definition to
LDPR_PREVAILING_DEF for __real_SYM reference.
* testsuite/ld-plugin/lto.exp: Run PR ld/29086 test.
* testsuite/ld-plugin/pr29086.c: New file.

cris bfd config

cris support will be built into a 32-bit bfd if using --enable-targets=all
on a 32-bit host, so we may as well make targmatch.h include cris.

* config.bfd (cris): Remove #idef BFD64.

PowerPC64 check_relocs

Tidy the dynamic reloc handling code in check_relocs, removing
leftover comments and code from when check_relocs was called as each
object file was read in.

* elf64-ppc.c (ppc64_elf_check_relocs): Tidy dynamic reloc
handling code.
(dec_dynrel_count): Do the same here.

Fix crash when creating index from index

My patches yesterday to unify the DWARF index base classes had a bug
-- namely, I did the wholesale dynamic_cast-to-static_cast too hastily
and introduced a crash.  This can be seen by trying to add an index to
a file that has an index, or by running a test like gdb-index-cxx.exp
using the cc-with-debug-names.exp target board.

This patch fixes the crash by introducing a new virtual method and
removing some of the static casts.

Fix build failure for aarch64 gdbserver

We're missing an argument.

gdb: Workaround stringop-overread warning in debuginfod-support.c on s390x

For some reason g++ 11.2.1 on s390x produces a spurious warning for
stringop-overread in debuginfod_is_enabled for url_view. Add a new
DIAGNOSTIC_IGNORE_STRINGOP_OVERREAD macro to suppress this warning.

include/ChangeLog:

* diagnostics.h (DIAGNOSTIC_IGNORE_STRINGOP_OVERREAD): New
macro.

gdb/ChangeLog:

* debuginfod-support.c (debuginfod_is_enabled): Use
DIAGNOSTIC_IGNORE_STRINGOP_OVERREAD on s390x.

Fix GDBserver Aarch64 Linux regression

Luis noticed that the recent changes to gdbserver to make it track
process and threads independently regressed a few gdb.multi/*.exp
tests for aarch64-linux.

We started seeing the following internal error for
gdb.multi/multi-target-continue.exp for example:

 Starting program: binutils-gdb/gdb/testsuite/outputs/gdb.multi/multi-target-continue/multi-target-continue ^M
 Error in re-setting breakpoint 2: Remote connection closed^M
 ../../../repos/binutils-gdb/gdb/thread.c:85: internal-error: inferior_thread: Assertion `current_thread_ != nullptr' failed.^M
 A problem internal to GDB has been detected,^M
 further debugging may prove unreliable.

A backtrace looks like:

 #0  thread_regcache_data (thread=thread@entry=0x0) at ../../../repos/binutils-gdb/gdbserver/inferiors.cc:120
 #1  0x0000aaaaaaabf0e8 in get_thread_regcache (thread=0x0, fetch=fetch@entry=0) at ../../../repos/binutils-gdb/gdbserver/regcache.cc:31
 #2  0x0000aaaaaaad785c in is_64bit_tdesc () at ../../../repos/binutils-gdb/gdbserver/linux-aarch64-low.cc:194
 #3  0x0000aaaaaaad8a48 in aarch64_target::sw_breakpoint_from_kind (this=<optimized out>, kind=4, size=0xffffffffef04) at ../../../repos/binutils-gdb/gdbserver/linux-aarch64-low.cc:3226
 #4  0x0000aaaaaaabe220 in bp_size (bp=0xaaaaaab6f3d0) at ../../../repos/binutils-gdb/gdbserver/mem-break.cc:226
 #5  check_mem_read (mem_addr=187649984471104, buf=buf@entry=0xaaaaaab625d0 "\006", mem_len=mem_len@entry=56) at ../../../repos/binutils-gdb/gdbserver/mem-break.cc:1862
 #6  0x0000aaaaaaacc660 in read_inferior_memory (memaddr=<optimized out>, myaddr=0xaaaaaab625d0 "\006", len=56) at ../../../repos/binutils-gdb/gdbserver/target.cc:93
 #7  0x0000aaaaaaac3d9c in gdb_read_memory (len=56, myaddr=0xaaaaaab625d0 "\006", memaddr=187649984471104) at ../../../repos/binutils-gdb/gdbserver/server.cc:1071
 #8  gdb_read_memory (memaddr=187649984471104, myaddr=0xaaaaaab625d0 "\006", len=56) at ../../../repos/binutils-gdb/gdbserver/server.cc:1048
 #9  0x0000aaaaaaac82a4 in process_serial_event () at ../../../repos/binutils-gdb/gdbserver/server.cc:4307
 #10 handle_serial_event (err=<optimized out>, client_data=<optimized out>) at ../../../repos/binutils-gdb/gdbserver/server.cc:4520
 #11 0x0000aaaaaaafbcd0 in gdb_wait_for_event (block=block@entry=1) at ../../../repos/binutils-gdb/gdbsupport/event-loop.cc:700
 #12 0x0000aaaaaaafc0b0 in gdb_wait_for_event (block=1) at ../../../repos/binutils-gdb/gdbsupport/event-loop.cc:596
 #13 gdb_do_one_event () at ../../../repos/binutils-gdb/gdbsupport/event-loop.cc:237
 #14 0x0000aaaaaaacacb0 in start_event_loop () at ../../../repos/binutils-gdb/gdbserver/server.cc:3518
 #15 captured_main (argc=4, argv=<optimized out>) at ../../../repos/binutils-gdb/gdbserver/server.cc:3998
 #16 0x0000aaaaaaab66dc in main (argc=<optimized out>, argv=<optimized out>) at ../../../repos/binutils-gdb/gdbserver/server.cc:4084

This sequence of functions is invoked due to a series of conditions:

 1 - The probe-based breakpoint mechanism failed (for some reason) so ...

 2 - ... gdbserver has to know what type of architecture it is dealing
     with so it can pick the right breakpoint kind, so it wants to
     check if we have a 64-bit target.

 3 - To determine the size of a register, we currently fetch the
     current thread's register cache, and the current thread pointer
     is now nullptr.

In #3, the current thread is nullptr because gdb_read_memory clears it
on purpose, via set_desired_process, exactly to expose code relying on
the current thread when it shouldn't.  It was always possible to end
up in this situation (when the current thread exits), but it was
harder to reproduce before.

This commit fixes it by tweaking is_64bit_tdesc to look at the current
process's tdesc instead of the current thread's tdesc.

Note that the thread's tdesc is itself filled from the process's
tdesc, so this should be equivalent:

 struct regcache *
 get_thread_regcache (struct thread_info *thread, int fetch)
 {
   struct regcache *regcache;

   regcache = thread_regcache_data (thread);

 ...
   if (regcache == NULL)
     {
       struct process_info *proc = get_thread_process (thread);

       gdb_assert (proc->tdesc != NULL);

       regcache = new_register_cache (proc->tdesc);
       set_thread_regcache_data (thread, regcache);
     }
 ...

Change-Id: Ibc809d7345e70a2f058b522bdc5cdbdca97e2cdc

gdb/remote: send qSymbol to all inferiors on startup

start_remote_1 calls remote_check_symbols after things are set up to
give the remote side a chance to look up symbols.  One call to
remote_check_symbols sets the "general thread", if needed, and sends one
qSymbol packet.  However, a remote target could have more than one
process on initial connection, and this would send a qSymbol for only
one of these processes.

Change it to iterate on all the target's inferiors and send a qSymbol
packet for each one.

I tested this by changing gdbserver to spawn two processes on startup:

    diff --git a/gdbserver/server.cc b/gdbserver/server.cc
    index 33c42714e72..9b682e9f85f 100644
    --- a/gdbserver/server.cc
    +++ b/gdbserver/server.cc
    @@ -3939,6 +3939,7 @@ captured_main (int argc, char *argv[])

           /* Wait till we are at first instruction in program.  */
           target_create_inferior (program_path.get (), program_args);
    +      target_create_inferior (program_path.get (), program_args);

           /* We are now (hopefully) stopped at the first instruction of
             the target process.  This assumes that the target process was

Instead of hacking GDBserver, it should also be possible to test this by
starting manually two inferiors on an "extended-remote" connection,
disconnecting from GDBserver (with the disconnect command), and
re-connecting.

I was able to see qSymbol being sent for each inferior:

      [remote] Sending packet: $Hgp828dc.828dc#1f
      [remote] Packet received: OK
      [remote] Sending packet: $qSymbol::#5b
      [remote] Packet received: qSymbol:6764625f6167656e745f6764625f74705f686561705f627566666572
      [remote] Sending packet: $qSymbol::6764625f6167656e745f6764625f74705f686561705f627566666572#1e
      [remote] Packet received: qSymbol:6e70746c5f76657273696f6e
      [remote] Sending packet: $qSymbol::6e70746c5f76657273696f6e#4d
      [remote] Packet received: OK
      [remote] Sending packet: $Hgp828dd.828dd#21
      [remote] Packet received: OK
      [remote] Sending packet: $qSymbol::#5b
      [remote] Packet received: qSymbol:6764625f6167656e745f6764625f74705f686561705f627566666572
      [remote] Sending packet: $qSymbol::6764625f6167656e745f6764625f74705f686561705f627566666572#1e
      [remote] Packet received: qSymbol:6e70746c5f76657273696f6e
      [remote] Sending packet: $qSymbol::6e70746c5f76657273696f6e#4d
      [remote] Packet received: OK

Note that there would probably be more work to be done to fully support
this scenario, more things that need to be done for each discovered
inferior instead of just for one.

Change-Id: I21c4ecf6367391e2e389b560f0b4bd906cf6472f

gdb/remote: iterate on pspace inferiors in remote_new_objfile

Commit 152a17495663 ("gdb: prune inferiors at end of
fetch_inferior_event, fix intermittent failure of
gdb.threads/fork-plus-threads.exp") broke some tests with the
native-gdbserver board, such as:

    (gdb) PASS: gdb.base/step-over-syscall.exp: detach-on-fork=off: follow-fork=child: break cond on target : vfork: break marker
    continue^M
    Continuing.^M
    terminate called after throwing an instance of 'gdb_exception_error'^M

I can manually reproduce the issue by running (just the commands that
the test does as a one liner):

    $ ./gdb -q --data-directory=data-directory \
          testsuite/outputs/gdb.base/step-over-syscall/step-over-vfork \
  -ex "tar rem | ../gdbserver/gdbserver - testsuite/outputs/gdb.base/step-over-syscall/step-over-vfork" \
  -ex "b main" \
  -ex c \
  -ex "d 1" \
  -ex "set displaced-stepping off" \
  -ex "b *0x7ffff7d7ac5a if main == 0" \
  -ex "set detach-on-fork off" \
  -ex "set follow-fork-mode child" \
  -ex c \
  -ex "inferior 1" \
  -ex "b marker" \
  -ex c

... where 0x7ffff7d7ac5a is the exact address of the vfork syscall
(which can be found by looking at gdb.log).

The important part of the above is that a vfork syscall creates inferior
2, then inferior 2 executes until exit, then we switch back to inferior
1 and try to resume it.

The uncaught exception happens here:

    #4  0x00005596969d81a9 in error (fmt=0x559692da9e40 "Cannot execute this command while the target is running.\nUse the \"interrupt\" command to stop the target\nand then try again.")
        at /home/simark/src/binutils-gdb/gdbsupport/errors.cc:43
    #5  0x0000559695af6f66 in remote_target::putpkt_binary (this=0x617000038080, buf=0x559692da4380 "qSymbol::", cnt=9) at /home/simark/src/binutils-gdb/gdb/remote.c:9560
    #6  0x0000559695af6aaf in remote_target::putpkt (this=0x617000038080, buf=0x559692da4380 "qSymbol::") at /home/simark/src/binutils-gdb/gdb/remote.c:9518
    #7  0x0000559695ab50dc in remote_target::remote_check_symbols (this=0x617000038080) at /home/simark/src/binutils-gdb/gdb/remote.c:5141
    #8  0x0000559695b3cccf in remote_new_objfile (objfile=0x0) at /home/simark/src/binutils-gdb/gdb/remote.c:14600
    #9  0x0000559693bc52a9 in std::__invoke_impl<void, void (*&)(objfile*), objfile*> (__f=@0x61b0000167f8: 0x559695b3cb1d <remote_new_objfile(objfile*)>) at /usr/include/c++/11.2.0/bits/invoke.h:61
    #10 0x0000559693bb2848 in std::__invoke_r<void, void (*&)(objfile*), objfile*> (__fn=@0x61b0000167f8: 0x559695b3cb1d <remote_new_objfile(objfile*)>) at /usr/include/c++/11.2.0/bits/invoke.h:111
    #11 0x0000559693b8dddf in std::_Function_handler<void (objfile*), void (*)(objfile*)>::_M_invoke(std::_Any_data const&, objfile*&&) (__functor=..., __args#0=@0x7ffe0bae0590: 0x0) at /usr/include/c++/11.2.0/bits/std_function.h:291
    #12 0x00005596956374b2 in std::function<void (objfile*)>::operator()(objfile*) const (this=0x61b0000167f8, __args#0=0x0) at /usr/include/c++/11.2.0/bits/std_function.h:560
    #13 0x0000559695633c64 in gdb::observers::observable<objfile*>::notify (this=0x55969ef5c480 <gdb::observers::new_objfile>, args#0=0x0) at /home/simark/src/binutils-gdb/gdb/../gdbsupport/observable.h:150
    #14 0x0000559695df6cc2 in clear_symtab_users (add_flags=...) at /home/simark/src/binutils-gdb/gdb/symfile.c:2873
    #15 0x000055969574c263 in program_space::~program_space (this=0x6120000c8a40, __in_chrg=<optimized out>) at /home/simark/src/binutils-gdb/gdb/progspace.c:154
    #16 0x0000559694fc086b in delete_inferior (inf=0x61700003bf80) at /home/simark/src/binutils-gdb/gdb/inferior.c:205
    #17 0x0000559694fc341f in prune_inferiors () at /home/simark/src/binutils-gdb/gdb/inferior.c:390
    #18 0x0000559695017ada in fetch_inferior_event () at /home/simark/src/binutils-gdb/gdb/infrun.c:4293
    #19 0x0000559694f629e6 in inferior_event_handler (event_type=INF_REG_EVENT) at /home/simark/src/binutils-gdb/gdb/inf-loop.c:41
    #20 0x0000559695b3b0e3 in remote_async_serial_handler (scb=0x6250001ef100, context=0x6170000380a8) at /home/simark/src/binutils-gdb/gdb/remote.c:14466
    #21 0x0000559695c59eb7 in run_async_handler_and_reschedule (scb=0x6250001ef100) at /home/simark/src/binutils-gdb/gdb/ser-base.c:138
    #22 0x0000559695c5a42a in fd_event (error=0, context=0x6250001ef100) at /home/simark/src/binutils-gdb/gdb/ser-base.c:189
    #23 0x00005596969d9ebf in handle_file_event (file_ptr=0x60700005af40, ready_mask=1) at /home/simark/src/binutils-gdb/gdbsupport/event-loop.cc:574
    #24 0x00005596969da7fa in gdb_wait_for_event (block=0) at /home/simark/src/binutils-gdb/gdbsupport/event-loop.cc:700
    #25 0x00005596969d8539 in gdb_do_one_event () at /home/simark/src/binutils-gdb/gdbsupport/event-loop.cc:212

If I enable "set debug infrun" just before the last continue, we see:

    (gdb) continue
    Continuing.
    [infrun] clear_proceed_status_thread: 965604.965604.0
    [infrun] proceed: enter
      [infrun] proceed: addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT
      [infrun] scoped_disable_commit_resumed: reason=proceeding
      [infrun] start_step_over: enter
        [infrun] start_step_over: stealing global queue of threads to step, length = 0
        [infrun] operator(): step-over queue now empty
      [infrun] start_step_over: exit
      [infrun] resume_1: step=0, signal=GDB_SIGNAL_0, trap_expected=0, current thread [965604.965604.0] at 0x7ffff7d7ac5c
      [infrun] do_target_resume: resume_ptid=965604.0.0, step=0, sig=GDB_SIGNAL_0
      [infrun] prepare_to_wait: prepare_to_wait
      [infrun] reset: reason=proceeding
      [infrun] maybe_set_commit_resumed_all_targets: enabling commit-resumed for target remote
      [infrun] maybe_call_commit_resumed_all_targets: calling commit_resumed for target remote
    [infrun] proceed: exit
    [infrun] fetch_inferior_event: enter
      [infrun] scoped_disable_commit_resumed: reason=handling event
      [infrun] do_target_wait: Found 2 inferiors, starting at #1
      [infrun] random_pending_event_thread: None found.
      [infrun] print_target_wait_results: target_wait (-1.0.0 [process -1], status) =
      [infrun] print_target_wait_results:   965604.965604.0 [Thread 965604.965604],
      [infrun] print_target_wait_results:   status->kind = VFORK_DONE
      [infrun] handle_inferior_event: status->kind = VFORK_DONE
      [infrun] context_switch: Switching context from 0.0.0 to 965604.965604.0
      [infrun] handle_vfork_done: not waiting for a vfork-done event
      [infrun] start_step_over: enter
        [infrun] start_step_over: stealing global queue of threads to step, length = 0
        [infrun] operator(): step-over queue now empty
      [infrun] start_step_over: exit
      [infrun] resume_1: step=0, signal=GDB_SIGNAL_0, trap_expected=0, current thread [965604.965604.0] at 0x7ffff7d7ac5c
      [infrun] do_target_resume: resume_ptid=965604.0.0, step=0, sig=GDB_SIGNAL_0
      [infrun] prepare_to_wait: prepare_to_wait
      [infrun] reset: reason=handling event
      [infrun] maybe_set_commit_resumed_all_targets: enabling commit-resumed for target remote
      [infrun] maybe_call_commit_resumed_all_targets: calling commit_resumed for target remote
    terminate called after throwing an instance of 'gdb_exception_error'

What happens is:

 - After doing the "continue" on inferior 1, the remote target gives us
   a VFORK_DONE event.  The core ignores it and resumes inferior 1.
 - Since prune_inferiors is now called after each handled event, in
   fetch_inferior_event, it is called after we handled that VFORK_DONE
   event and resumed inferior 1.
 - Inferior 2 is pruned, which (see backtrace above) causes its program
   space to be deleted, which clears the symtabs for that program space,
   which calls the new_objfile observable and remote_new_objfile
   observer (with a nullptr objfile, to indicate that the previously
   loaded symbols have been discarded), which calls
   remote_check_symbols.

remote_check_symbols is the function that sends the qSymbol packet, to
let the remote side ask for symbol addresses.  The problem is that the
remote target is working in all-stop / sync mode and is currently
resumed.  It has sent a vCont packet to resume the target and is waiting
for a stop reply.  It can't send any packets in the mean time.  That
causes the exception to be thrown.

This wasn't a problem before, when prune_inferiors was called in
normal_stop, because it was always called at a time the target was not
resumed.

An important observation here is that the new_objfile observable is
invoked for a change in inferior 2's program space (inferior 2's program
space is the current program space).  Inferior 2 isn't bound to any
process on the remote side (it has exited, that's why it's being
pruned).  It doesn't make sense to try to send a qSymbol packet for a
process that doesn't exist on the remote side.  remote_check_symbols
actually attempts to avoid that:

   /* The remote side has no concept of inferiors that aren't running
     yet, it only knows about running processes.  If we're connected
     but our current inferior is not running, we should not invite the
     remote target to request symbol lookups related to its
     (unrelated) current process.  */
  if (!target_has_execution ())
    return;

The problem here is that while inferior 2's program space is the current
program space, inferior 1 is the current inferior.  So the check above
passes, since inferior has execution.  We therefore try to send a
qSymbol packet for inferior 1 in reaction to a change in inferior 2's
program space, that's wrong.

This exposes a conceptual flaw in remote_new_objfile.  The "new_objfile"
event concerns a specific program space, which can concern multiple
inferiors, as inferiors can share a program space.  We shouldn't
consider the current inferior at all, but instead all inferiors bound to
the affected program space.  Especially since the current inferior can
be unrelated to the current program space at that point.

To be clear, we are in this state because ~program_space sets itself as
the current program space, but there is no more inferior having that
program space to switch to, inferior 2 has already been unlinked.

To fix this, make remote_new_objfile iterate on all inferiors bound to
the affected program space.  Remove the target_has_execution check from
remote_check_symbols, replace it with an assert.  All callers must
ensure that the current inferior has execution before calling it.

Change-Id: Ica643145bcc03115248290fd310cadab8ec8371c

Dwarf: rename yet another instance of "index"

As before, on sufficiently old glibc this conflicts with a global
identifier in the library headers. While there also zap the unusual
padding by blanks.

LTO plugin: sync header file with GCC

include/ChangeLog:

* plugin-api.h (enum ld_plugin_tag): Sync with GCC.

PowerPC32 treatment of absolute symbols

As already done for PowerPC64, fix dynamic relocs for absolute symbols.
The patch also tidies the dynamic reloc handling code in check_relocs,
removing leftover comments and code from when check_relocs was called
as each object file was read in.

bfd/
* elf32-ppc.c (ppc_elf_check_relocs): Set isym and ifunc earlier.
Rearrange tests for dynamic relocs, handling absolute symbols.
(allocate_dynrelocs): Don't allocate dynamic relocs for locally
defined absolute symbols.
(ppc_elf_size_dynamic_sections): Similarly.
(ppc_elf_relocate_section): Similarly.
ld/
* testsuite/ld-powerpc/abs32-pie.d,
* testsuite/ld-powerpc/abs32-pie.r,
* testsuite/ld-powerpc/abs32-reloc.s,
* testsuite/ld-powerpc/abs32-shared.d,
* testsuite/ld-powerpc/abs32-shared.r,
* testsuite/ld-powerpc/abs32-static.d,
* testsuite/ld-powerpc/abs32-static.r: New tests.
* testsuite/ld-powerpc/powerpc.exp: Run them.

gdbserver: Fix build after adding tls feature to arm tdesc.

Automatic date update in version.in

NEWS: Add a note for TLS support on FreeBSD/arm and FreeBSD/Aarch64.

Read the tpidr register from NT_ARM_TLS on Linux.

gdbserver: Read the tpidr register from NT_ARM_TLS on Linux.

Read the tpidr register from NT_ARM_TLS core dump notes on Linux Aarch64.

Fetch the NT_ARM_TLS register set for native FreeBSD/Aarch64 processes.

This permits resolving TLS variables.

Support TLS variables on FreeBSD/Aarch64.

Derive the pointer to the DTV array from the tpidr register.

Read the tpidr register from NT_ARM_TLS core dump notes on FreeBSD/Aarch64.

Add an aarch64-tls feature which includes the tpidr register.

Fetch the NT_ARM_TLS register set for native FreeBSD/arm processes.

This permits resolving TLS variables.

Support TLS variables on FreeBSD/arm.

Derive the pointer to the DTV array from the tpidruro register.

Read the tpidruro register from NT_ARM_TLS core dump notes on FreeBSD/arm.

Add an arm-tls feature which includes the tpidruro register from CP15.

fbsd-nat: Add helper routines for register sets using PT_[G]SETREGSET.

FreeBSD's kernel has recently added PT_GETREGSET and PT_SETREGSET
operations to fetch a register set named by an ELF note type.  These
helper routines provide helpers to check for a register set's
existence, fetch registers for a register set, and store registers to
a register set.

ld: Regenerate aclocal.m4 with automake 1.15.1

* aclocal.m4: Regenerate with automake 1.15.1.

gdbserver: track current process as well as current thread

The recent commit 421490af33bf ("gdbserver/linux: Access memory even
if threads are running") caused a regression in
gdb.threads/access-mem-running-thread-exit.exp with gdbserver, which I
somehow missed.  Like so:

 (gdb) print global_var
 Cannot access memory at address 0x555555558010
 (gdb) FAIL: gdb.threads/access-mem-running-thread-exit.exp: non-stop: access mem (print global_var after writing, inf=2, iter=1)

The problem starts with GDB telling GDBserver to select a thread, via
the Hg packet, which GDBserver complies with, then that thread exits,
and GDB, without knowing the thread is gone, tries to write to memory,
through the context of the previously selected Hg thread.

GDBserver's GDB-facing memory access routines, gdb_read_memory and
gdb_write_memory, call set_desired_thread to make GDBserver re-select
the thread that GDB has selected with the Hg packet.  Since the thread
is gone, set_desired_thread returns false, and the memory access
fails.

Now, to access memory, it doesn't really matter which thread is
selected.  All we should need is the target process.  Even if the
thread that GDB previously selected is gone, and GDB does not yet know
about that exit, it shouldn't matter, GDBserver should still know
which process that thread belonged to.

Fix this by making GDBserver track the current process separately,
like GDB also does.  Add a new set_desired_process routine that is
similar to set_desired_thread, but just sets the current process,
leaving the current thread as NULL.  Use it in the GDB-facing memory
read and write routines, to avoid failing if the selected thread is
gone, but the process is still around.

Change-Id: I4ff97cb6f42558efbed224b30d5c71f6112d44cd

Fix gdb.threads/access-mem-running-thread-exit.exp w/ native-extended-gdbserver

When testing gdb.threads/access-mem-running-thread-exit.exp with
--target_board=native-extended-gdbserver, we get:

  Running gdb.threads/access-mem-running-thread-exit.exp ...
  FAIL: gdb.threads/access-mem-running-thread-exit.exp: non-stop: second inferior: runto: run to main
  WARNING: Timed out waiting for EOF in server after monitor exit

  === gdb Summary ===

  # of expected passes            3
  # of unexpected failures        1
  # of unsupported tests          1

The problem is that the testcase spawns a second inferior with
-no-connection, and then runto_main does "run", which fails like so:

 (gdb) run
 Don't know how to run.  Try "help target".
 (gdb) FAIL: gdb.threads/access-mem-running-thread-exit.exp: non-stop: second inferior: runto: run to main

That "run" above failed because native-extended-gdbserver forces "set
auto-connect-native-target off", to prevent testcases from mistakenly
running programs with the native target, which would exactly be the
case here.

Fix this by letting the second inferior share the first inferior's
connection everywhere except on targets that do reload on run (e.g.,
--target_board=native-gdbserver).

Change-Id: Ib57105a238cbc69c57220e71261219fa55d329ed

gdb: add some additional thread status debug output

While working on this patch:

  https://sourceware.org/pipermail/gdb-patches/2022-January/185109.html

I found it really useful to print the executing/resumed status of all
threads (or all threads in a particular inferior) at various
places (e.g. when a new inferior is started, when GDB attaches, etc).

This debug was originally part of the above patch, but I wanted to
rewrite this as a separate patch and move the code into a new function
in infrun.h, which is what this patch does.

Unless 'set debug infrun on' is in effect, then there should be no
user visible changes after this commit.

Add a linker warning when creating potentially dangerous executable segments.  Add tests, options to disabke and configure switches to choose defaults.

Fix potential arithmetic overflow in the linker's plugin handling code.

PR 29101
* libdep_plugin.c (get_libdeps): Check for overflow when computing
amount of memory to allocate.

objdump: fix styled printing of addresses

Previous work to add styled disassembler output missed a case in
objdump_print_addr, which is fixed in this commit.

gdb/testsuite: small cleanup in mi-break-qualified.exp

It is not necessary to pass an empty string to mi_gdb_start, passing
the empty string is equivalent to passing no arguments, which is what
we do everywhere else (that we don't need to specify an actual
argument).

The only place we use 'mi_gdb_start ""' is in
gdb.mi/mi-break-qualified.exp, so in this commit I just replace that
with a call to 'mi_gdb_start' - just for consistency.

There should be no change in what is tested after this commit.

gdb/testsuite: change mi_gdb_start to take a list of flags

After this previous commit I was thinking about the API of
mi_gdb_start.  I felt that the idea of passing flags as separate
arguments and using 'args' to gather these into a list, though clever,
was not an intuitive API.

In this commit I modify mi_gdb_start so that it expects a single
argument, which should be a list of flags.  Thus, where we previously
would have said:

  mi_gdb_start separate-mi-tty separate-inferior-tty

We would now say:

  mi_gdb_start { separate-mi-tty separate-inferior-tty }

However, it turns out we never actually call mi_gdb_start passing two
arguments in this way at all.  We do in some places do this:

  mi_gdb_start separate-inferior-tty

But that's fine, a single string like this works equally well as a
single item list, so this will not need updating.

There is also one place where we do this:

  eval mi_gdb_start $start_ops

where $start_ops is a list that might contains 0, 1, or 2 items.  The
eval here is used to expand the $start_ops list so mi_gdb_start sees
the list contents as separate arguments.  In this case we just need to
drop the use of eval.

I think that the new API is more intuitive, but others might
disagree, in which case I can drop this change.

There should be no change in what is tested after this commit.

gdb/testsuite: fix mi-exec-run.exp with native-extended-gdbserver board

When running with the native-extended-gdbserver board, I currently see
one failure in gdb.mi/mi-exec-run.exp:

    FAIL: gdb.mi/mi-exec-run.exp: inferior-tty=separate: mi=separate: force-fail=0: breakpoint hit reported on console (timeout)

In this test the MI interface should be started in a separate tty,
which means we should have a CLI tty and an MI tty, however, this is
not happening.  Instead GDB is just started in MI mode and there is no
CLI tty.

The test script tries to switch between the CLI an MI terminals and
look for some expected output on each, however, as there is no CLI
terminal the expected output never arrives, and the test times out.

It turns out that this is not a GDB problem, rather, this is an issue
with argument passing within the test script.

The proc default_mi_gdb_start expects to take a set of flags (strings)
as arguments, each of flag is expected to be a separate argument.  The
default_mi_gdb_start proc collects all its arguments into a list using
the special 'args' parameter name, and then iterates over this list to
see which flags were passed.

In mi_gdb_start, which forwards to default_mi_gdb_start, the arguments
are also gathered into the 'args' parameter list, but are then
expanded back to be separate arguments using the eval trick, i.e.:

  proc mi_gdb_start { args } {
    return [eval default_mi_gdb_start $args]
  }

This ensures that when we arrive in default_mi_gdb_start each flag is
a separate argument, rather than appearing as a single list containing
all arguments.

When using the native-extended-gdbserver board however, the file
boards/native-extended-gdbserver.exp is loaded, and this file replaces
the default mi_gdb_start with its own version.

This new mi_gdb_start also gathers the arguments into an 'args' list,
but forgets to expand the arguments out using the eval trick.

As a result, when using the native-extended-gdbserver board, by the
time we get to default_mi_gdb_start, we end up with the args list
containing a single item, which is a list containing all the arguments
the user passed.

What this means is that if the user passes two arguments, then, in
default_mi_gdb_start, instead of seeing two separate arguments, we see
a single argument made by concatenating the two arguments together.

The only place this is a problem is in the test mi-exec-run.exp,
which (as far as I can see) is the only test where we might try to
pass both arguments at the same time.  Currently we think we passed
both arguments to mi_gdb_start, but mi_gdb_start behaves as if no
arguments were passed.

This commit fixes the problem by making use of the eval trick within
the native-extended-gdbserver version of mi_gdb_start.  After this,
the FAIL listed at the top of this message is resolved.

gdb: fix failures in gdb.mi/mi-exec-run.exp with native-extended-gdbserver

When running the gdb.mi/mi-exec-run.exp test using the
native-extended-gdbserver I see failures like this:

  FAIL: gdb.mi/mi-exec-run.exp: inferior-tty=main: mi=main: force-fail=1: run failure detected
  FAIL: gdb.mi/mi-exec-run.exp: inferior-tty=main: mi=separate: force-fail=1: run failure detected
  FAIL: gdb.mi/mi-exec-run.exp: inferior-tty=separate: mi=separate: force-fail=1: run failure detected

There's a race condition here, so you might see a slightly different
set of failures, but I always see some from the 'run failure detected'
test.

NOTE: I also see an additional test failure:

 FAIL: gdb.mi/mi-exec-run.exp: inferior-tty=separate: mi=separate: force-fail=0: breakpoint hit reported on console (timeout)

but that is a completely different issue, and is not being addressed
in this commit.

The problem for the 'run failure detected' test is that we end up
in gdb_expect looking for output from two spawn-ids, one from
gdbserver, and one from gdb.  We're looking for one output pattern
from each spawn-id, and for the test to pass we need to see both
patterns.

Now, if gdb exits then this is a test failure (this would indicate gdb
crashing, which is bad), so we have an eof pattern associated with
the gdb spawn-id.

However, in this particular test we expect gdbserver to fail to
execute the binary (the test binary is set non-executable), and so we
get an error message from gdbserver (which matches the pattern), and
then gdbserver exits, this is expected.

The problem is that after spotting the pattern from gdbserver, we
often see the eof from gdbserver before we see the pattern from gdb.
If this happens then we drop out of the gdb_expect without ever seeing
the pattern from gdb, and fail the test.

In this commit, I place the spawn-id of gdbserver into a global
variable, and then use this global variable as the -i option within
the gdb_expect.

Now, once we have seen the expected pattern on the gdbserver spawn-id,
the global variable is cleared.  After this the gdb_expect no longer
checks the gdbserver spawn-id for additional output, and so never sees
the eof event.  This leaves the gdb_expect running, which allows the
pattern from gdb to be seen, and for the test to pass.

I now see no failures relating to 'run failure detected'.