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'.

Automatic date update in version.in

[gdb/testsuite] Fix gdb.cp/align.exp with gcc 12.1 / 11.3

Starting with gcc 12.1 / gcc 11.3, for test-case gdb.cp/align.exp we run into:
...
align.cc:29:23: error: invalid application of 'alignof' to a void type^M
   29 |     unsigned a_void = alignof (void);^M
      |                       ^~~~~~~~~~~~~~^M
...

Fix this by using __alignof__ instead.

Tested on x86_64-linux, with gcc 7.5.0, gcc 12.1 and clang 12.0.1.

gdb/debuginfod: Whitespace-only URL should disable debuginfod

Currently debuginfod is disabled when the string of server URLs
is unset or set to be the empty string (via the $DEBUGINFOD_URLS
environment variable or the 'set debuginfod urls' gdb command).

Extend this functionality so that a whitespace-only URL also disables
debuginfod.

Modify a testcase to verify that a whitespace-only URL disables
debuginfod.

gdb: remove type_wanted parameter from a few functions

The type_wanted value, passed down to the create_sals_from_location
callback, is never used.  Remove it.

Change-Id: Ic363ee13f6af593a3e875ff7fe46de130cdc190c

gnulib: update to bd11400942d6

Update the gnulib import to fixes these issues:

  - GDB build with clang + glibc < 2.33.

      https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=d6a07b4dc21b3118727743142c678858df442853
      https://lists.gnu.org/archive/html/bug-gnulib/2022-04/msg00072.html

    With glibc < 2.33, gnulib (since relatively recently) enables a
    replacement for free (see gnulib/import/m4/free.m4).  In that path,
    clang shows this error:

        make[2]: Entering directory '/home/smarchi/build/binutils-gdb-clang/gdbsupport'
          CXX      agent.o
        In file included from /home/smarchi/src/binutils-gdb/gdbsupport/agent.cc:20:
        In file included from /home/smarchi/src/binutils-gdb/gdbsupport/common-defs.h:95:
        ../gnulib/import/string.h:636:19: error: exception specification in declaration does not match previous declaration
        _GL_EXTERN_C void free (void *) throw ();
                          ^
        ../gnulib/import/stdlib.h:737:17: note: expanded from macro 'free'
        #   define free rpl_free
                        ^
        ../gnulib/import/stdlib.h:739:1: note: previous declaration is here
        _GL_FUNCDECL_RPL (free, void, (void *ptr));
        ^
        ../gnulib/import/sys/select.h:251:23: note: expanded from macro '_GL_FUNCDECL_RPL'
          _GL_FUNCDECL_RPL_1 (rpl_##func, rettype, parameters_and_attributes)
                              ^
        <scratch space>:139:1: note: expanded from here
        rpl_free
        ^

    The gnulib commit mentioned fixes the exception specification of `free`.

 - GDB build on RHEL 7:

      CC       libgnu_a-openat-proc.o
    In file included from /usr/include/string.h:633,
                     from ./string.h:41,
                     from ../../../binutils-gdb/gnulib/import/openat-proc.c:30:
    ./string.h:1105:1: error: expected identifier or '(' before '__extension__'
     1105 | _GL_FUNCDECL_SYS (strndup, char *,
          | ^~~~~~~~~~~~~~~~

     https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=84863a1c4dc8cca8fb0f6f670f67779cdd2d543b
     https://lists.gnu.org/archive/html/bug-gnulib/2022-04/msg00075.html

Change-Id: Ibd51302feece6f385d0c53e0d08921b5d95e2776

Fix Ada catchpoint regression

The breakpoint C++-ification series introduced a regression for Ada
catchpoints.  Specifically, commit 2b5ab5b8 ("Convert base breakpoints
to vtable ops") caused these to start failing.  I didn't notice this
because testing Ada using a Linux distro compiler requires installing
the GNAT debuginfo, which I hadn't done.

This patch fixes the problem.  I'm checking it in.

Automatic date update in version.in

[gdb/testsuite] Fix gdb.multi/attach-no-multi-process.exp with check-readmore

When running test-case gdb.multi/attach-no-multi-process.exp with
check-readmore, I get:
...
(gdb) attach 13411^M
Attaching to Remote target^M
No unwaited-for children left.^M
(gdb) Reading symbols from attach-no-multi-process...^M
Reading symbols from /lib64/libm.so.6...^M
(No debugging symbols found in /lib64/libm.so.6)^M
Reading symbols from /lib64/libc.so.6...^M
(No debugging symbols found in /lib64/libc.so.6)^M
Reading symbols from /lib64/ld-linux-x86-64.so.2...^M
(No debugging symbols found in /lib64/ld-linux-x86-64.so.2)^M
0x00007f5df1fffc8a in clock_nanosleep@GLIBC_2.2.5 () from /lib64/libc.so.6^M
FAIL: gdb.multi/attach-no-multi-process.exp: target_non_stop=off: \
  attach to the program via remote (timeout)
...

The problem is that the attach output is matched using gdb_test, which uses
the '$gdb_prompt $' regexp, and this does not handle the case that '(gdb) ' is
not the last available output.

Fix this by using a gdb_test_multiple instead with a '$gdb_prompt ' regexp, so
without the '$' anchor.

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

Automatic date update in version.in

opcodes: don't assume ELF in riscv, csky, rl78, mep disassemblers

Currently, the get_disassembler() implementations for riscv, csky, and
rl78--and mep_print_insn() for mep--access ELF variants of union fields
without first checking that the bfd actually represents an ELF.  This
causes undefined behavior and crashes when disassembling non-ELF files
(the "binary" BFD, for example).  Fix that.

Automatic date update in version.in

Remove create_breakpoints_sal_default

create_breakpoints_sal_default is just a simple wrapper, so remove it.

Remove allocate_bp_location

allocate_bp_location is just a small wrapper for a method call, so
inline it everywhere.

Constify breakpoint_ops

Now that all breakpoint_ops are statically initialized, they can all
be made const.

Remove breakpoint ops initialization

initialize_breakpoint_ops does not do much any more, so remove it in
favor of statically-initialize objects.

Remove vtable_breakpoint_ops

There's no need to have vtable_breakpoint_ops any more, so remove it
in favor of base_breakpoint_ops.

Remove most fields from breakpoint_ops

At this point, all implementations of breakpoints use the vtable.  So,
we can now remove most function pointers from breakpoint_ops and
switch to using methods directly in the callers.  Only the two "static
virtual" methods remain in breakpoint_ops.

Remove breakpoint_ops from init_catchpoint

init_catchpoint is only ever passed a single breakpoint_ops pointer,
so remove the parameter.

Remove breakpoint_ops from init_ada_exception_breakpoint

init_ada_exception_breakpoint is only ever passed a single
breakpoint_ops structure, so remove the parameter.

Merge probe and ordinary tracepoints

Right now, probe tracepoints are handled by a separate ops object.
However, they differ only in a small way from ordinary tracepoints,
and furthermore can be distinguished by their event location.

This patch merges the two cases, just as was done for breakpoints.

Merge probe and ordinary breakpoints

Right now, probe breakpoints are handled by a separate ops object.
However, they differ only in a small way from ordinary breakpoints,
and furthermore can be distinguished by their "probe" object.

This patch merges the two cases.  This avoids having to introduce a
new bp_ constant (which can be quite subtle to do correctly) and a new
subclass.

Remove bkpt_base_breakpoint_ops

An earlier patch removed the last use of bkpt_base_breakpoint_ops, so
remove the object entirely.

Convert static marker tracepoints to vtable ops

This converts static marker tracepoints to use vtable_breakpoint_ops.

Add bp_static_marker_tracepoint

Because the actual construction of a breakpoint is buried deep in
create_breakpoint, at present it's necessary to have a new bp_
enumerator constant any time a new subclass is needed.  Static marker
tracepoints are one such case, so this patch introduces
bp_static_marker_tracepoint and updates various spots to recognize it.

Convert ranged breakpoints to vtable ops

This converts ranged breakpoints to use vtable_breakpoint_ops.  This
requires introducing a new ranged_breakpoint type, but this is
relatively simple because ranged breakpoints can only be created by
break_range_command.

Convert dprintf to vtable ops

This converts dprintf to use vtable_breakpoint_ops.

Convert Ada catchpoints to vtable ops

This converts Ada catchpoints to use vtable_breakpoint_ops.

Convert ordinary breakpoints to vtable ops

This converts "ordinary" breakpoint to use vtable_breakpoint_ops.
Recall that an ordinary breakpoint is both the kind normally created
by users, and also a base class used by other classes.

Change inheritance of dprintf

The dprintf breakpoint ops is mostly a copy of bpkt_breakpoint_ops,
except it's written out explicitly -- and, importantly, there's
nothing that bpkt_breakpoint_ops overrides that dprintf does not.
This changes dprintf to simply inherit directly, and updates struct
dprintf_breakpoint to reflect the change as well.

Convert momentary breakpoints to vtable ops

This converts momentary breakpoints to use vtable_breakpoint_ops.

Convert internal breakpoints to vtable ops

This converts internal breakpoints to use vtable_breakpoint_ops.

Convert break-catch-throw to vtable ops

This converts break-catch-throw.c to use vtable_breakpoint_ops.

Convert base breakpoints to vtable ops

This converts base breakpoints to use vtable_breakpoint_ops.

Add some new subclasses of breakpoint

This adds a few new subclasses of breakpoint.  The inheritance
hierarchy is chosen to reflect what's already present in
initialize_breakpoint_ops -- it mirrors the way that the _ops
structures are filled in.

This patch also changes new_breakpoint_from_type to create the correct
sublcass based on bptype.  This is important due to the somewhat
inverted way in which create_breakpoint works; and in particular later
patches will change some of these entries.

Convert tracepoints to vtable ops

This converts tracepoints to use vtable_breakpoint_ops.

Convert watchpoints to vtable ops

This converts watchpoints and masked watchpoints. to use
vtable_breakpoint_ops.  For masked watchpoints, a new subclass must be
introduced, and watch_command_1 is changed to create one.

Convert break-catch-load to vtable ops

This converts break-catch-load.c to use vtable_breakpoint_ops.

Convert break-catch-fork to vtable ops

This converts break-catch-fork.c to use vtable_breakpoint_ops.

Convert break-catch-exec to vtable ops

This converts break-catch-exec.c to use vtable_breakpoint_ops.

Convert break-catch-syscall to vtable ops

This converts break-catch-syscall.c to use vtable_breakpoint_ops.

Convert break-catch-sig to use vtable ops

This converts break-catch-sig.c to use vtable_breakpoint_ops.

Add a vtable-based breakpoint ops

This adds methods to struct breakpoint.  Each method has a similar
signature to a corresponding function in breakpoint_ops, with the
exceptions of create_sals_from_location and create_breakpoints_sal,
which can't be virtual methods on breakpoint -- they are only used
during the construction of breakpoints.

Then, this adds a new vtable_breakpoint_ops structure and populates it
with functions that simply forward a call from breakpoint_ops to the
corresponding virtual method.  These are all done with lambdas,
because they are just a stepping stone -- by the end of the series,
this structure will be deleted.

Return bool from breakpoint_ops::print_one

This changes breakpoint_ops::print_one to return bool, and updates all
the implementations and the caller.  The caller is changed so that a
NULL check is no longer needed -- something that will be impossible
with a real method.

Delete some unnecessary wrapper functions

This patch deletes a few unnecessary wrapper functions from
breakpoint.c.

Add an assertion to clone_momentary_breakpoint

This adds an assertion to clone_momentary_breakpoint.  This will
eventually be removed, but in the meantime is is useful for helping
convince oneself that momentary breakpoints will always use
momentary_breakpoint_ops.  This understanding will help when cleaning
up the code later.

Boolify print_solib_event

Change print_solib_event to accept a bool parameter and update the
callers.

Move "catch load" to a new file

The "catch load" code is reasonably self-contained, and so this patch
moves it out of breakpoint.c and into a new file, break-catch-load.c.
One function from breakpoint.c, print_solib_event, now has to be
exposed, but this seems pretty reasonable.

gprofng: assertion in gprofng/src/Expression.cc:139

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

PR gprofng/29102
* src/Expression.h: Remove fixupValues.
* src/Expression.cc (Expression::copy): Fix a bug.

De-duplicate .gdb_index

This de-duplicates variables and types in .gdb_index, making the new
index closer to what gdb generated before the new DWARF scanner
series.  Spot-checking the resulting index for gdb itself, it seems
that the new scanner picks up some extra symbols not detected by the
old one.  I tested both the new and old versions of gdb on both new
and old versions of the index, and startup time in all cases is
roughly the same (it's worth noting that, for gdb itself, the index no
longer provides any benefit over the DWARF scanner).  So, I think this
fixes the size issue with the new index writer.

Regression tested on x86-64 Fedora 34.

Fix .debug_names regression with new indexer

At AdaCore, we run the internal gdb test suite in several modes,
including one using the .debug_names index.  This caught a regression
caused by the new DWARF indexer.

First, the psymtabs-based .debug_names generator was completely wrong.
However, to avoid making the rewrite series even bigger (fixing the
writer will also require rewriting the .debug_names reader), it
attempted to preserve the weirdness.

However, this was not done properly.  For example the old writer did
this:

-      case STRUCT_DOMAIN:
- return DW_TAG_structure_type;

The new code, instead, simply preserves the actual DWARF tag -- but
this makes future lookups fail, because the .debug_names reader only
looks for DW_TAG_structure_type.

This patch attempts to revert to the old behavior in the writer.

gdb/infrun: make fetch_inferior_event restore thread if exited or signalled

Commit 152a1749566 ("gdb: prune inferiors at end of
fetch_inferior_event, fix intermittent failure of
gdb.threads/fork-plus-threads.exp") introduced some follow-fork-related
test failures, such as:

    info inferiors^M
      Num  Description       Connection           Executable        ^M
    * 1    process 634972    1 (native)           /home/simark/build/binutils-gdb-one-target/gdb/testsuite/outputs/gdb.base/foll-fork/foll-fork ^M
      2    process 634975    1 (native)           /home/simark/build/binutils-gdb-one-target/gdb/testsuite/outputs/gdb.base/foll-fork/foll-fork ^M
    (gdb) PASS: gdb.base/foll-fork.exp: follow-fork-mode=parent: detach-on-fork=off: cmd=next 2: test_follow_fork: info inferiors
    inferior 2^M
    [Switching to inferior 2 [process 634975] (/home/simark/build/binutils-gdb-one-target/gdb/testsuite/outputs/gdb.base/foll-fork/foll-fork)]^M
    [Switching to thread 2.1 (Thread 0x7ffff7c9a740 (LWP 634975))]^M
    #0  0x00007ffff7d7abf7 in _Fork () from /usr/lib/libc.so.6^M
    (gdb) PASS: gdb.base/foll-fork.exp: follow-fork-mode=parent: detach-on-fork=off: cmd=next 2: test_follow_fork: inferior 2
    continue^M
    Continuing.^M
    [Inferior 2 (process 634975) exited normally]^M
    [Switching to Thread 0x7ffff7c9a740 (LWP 634972)]^M
    (gdb) PASS: gdb.base/foll-fork.exp: follow-fork-mode=parent: detach-on-fork=off: cmd=next 2: test_follow_fork: continue until exit at continue unfollowed inferior to end
    break callee^M
    Breakpoint 2 at 0x555555555160: file /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/foll-fork.c, line 9.^M
    (gdb) FAIL: gdb.base/foll-fork.exp: follow-fork-mode=parent: detach-on-fork=off: cmd=next 2: test_follow_fork: break callee

What happens here is:

 - inferior 2 is selected
 - we continue, leading to inferior 2's exit
 - we set breakpoint, expect 2 locations, but only one location is
   resolved

Reading between the lines, we understand that inferior 2 got pruned,
when it shouldn't have been.

The issue can be reproduced by hand with:

    $ ./gdb -q --data-directory=data-directory testsuite/outputs/gdb.base/foll-fork/foll-fork -ex "set detach-on-fork off" -ex start -ex "next 2" -ex "inferior 2" -ex "set debug infrun"
    ...
    Temporary breakpoint 1, main () at /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/foll-fork.c:14
    14        int  v = 5;
    [New inferior 2 (process 637627)]
    [Thread debugging using libthread_db enabled]
    Using host libthread_db library "/usr/lib/../lib/libthread_db.so.1".
    17        if (pid == 0) /* set breakpoint here */
    [Switching to inferior 2 [process 637627] (/home/simark/build/binutils-gdb-one-target/gdb/testsuite/outputs/gdb.base/foll-fork/foll-fork)]
    [Switching to thread 2.1 (Thread 0x7ffff7c9a740 (LWP 637627))]
    #0  0x00007ffff7d7abf7 in _Fork () from /usr/lib/libc.so.6
    (gdb) continue
    Continuing.
    [infrun] clear_proceed_status_thread: 637627.637627.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] proceed: start: resuming threads, all-stop-on-top-of-non-stop
        [infrun] proceed: resuming 637627.637627.0
        [infrun] resume_1: step=0, signal=GDB_SIGNAL_0, trap_expected=0, current thread [637627.637627.0] at 0x7ffff7d7abf7
        [infrun] do_target_resume: resume_ptid=637627.637627.0, step=0, sig=GDB_SIGNAL_0
        [infrun] infrun_async: enable=1
        [infrun] prepare_to_wait: prepare_to_wait
      [infrun] proceed: end: resuming threads, all-stop-on-top-of-non-stop
      [infrun] reset: reason=proceeding
      [infrun] maybe_set_commit_resumed_all_targets: enabling commit-resumed for target native
      [infrun] maybe_call_commit_resumed_all_targets: calling commit_resumed for target native
      [infrun] maybe_call_commit_resumed_all_targets: calling commit_resumed for target native
    [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:   637627.637627.0 [process 637627],
      [infrun] print_target_wait_results:   status->kind = EXITED, exit_status = 0
      [infrun] handle_inferior_event: status->kind = EXITED, exit_status = 0
    [Inferior 2 (process 637627) exited normally]
      [infrun] stop_waiting: stop_waiting
      [infrun] stop_all_threads: start: reason=presenting stop to user in all-stop, inf=-1
        [infrun] stop_all_threads: pass=0, iterations=0
        [infrun] stop_all_threads:   637624.637624.0 not executing
        [infrun] stop_all_threads: pass=1, iterations=1
        [infrun] stop_all_threads:   637624.637624.0 not executing
        [infrun] stop_all_threads: done
      [infrun] stop_all_threads: end: reason=presenting stop to user in all-stop, inf=-1
    [Switching to Thread 0x7ffff7c9a740 (LWP 637624)]
      [infrun] infrun_async: enable=0
      [infrun] reset: reason=handling event
      [infrun] maybe_set_commit_resumed_all_targets: not requesting commit-resumed for target native, no resumed threads
    (gdb) [infrun] fetch_inferior_event: exit
    (gdb) info inferiors
      Num  Description       Connection           Executable
    * 1    process 637624    1 (native)           /home/simark/build/binutils-gdb-one-target/gdb/testsuite/outputs/gdb.base/foll-fork/foll-fork
    (gdb) i th
      Id   Target Id                                      Frame
    * 1    Thread 0x7ffff7c9a740 (LWP 637624) "foll-fork" main () at /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/foll-fork.c:17

After handling the EXITED event for inferior 2, inferior 2 should have
stayed the current inferior, which should have prevented it from getting
pruned.  When debugging, we find that when getting at the
prune_inferiors call, the current inferior is inferior 1.  Further
debugging shows that prior to the call to
clean_up_just_stopped_threads_fsms, the current inferior is inferior 2,
and after, it's inferior 1.  Then, back in fetch_inferior_event, the
restore_thread object is disabled, due to:

    /* If we got a TARGET_WAITKIND_NO_RESUMED event, then the
       previously selected thread is gone.  We have two
       choices - switch to no thread selected, or restore the
       previously selected thread (now exited).  We chose the
       later, just because that's what GDB used to do.  After
       this, "info threads" says "The current thread <Thread
       ID 2> has terminated." instead of "No thread
       selected.".  */
    if (!non_stop
&& cmd_done
&& ecs->ws.kind () != TARGET_WAITKIND_NO_RESUMED)
      restore_thread.dont_restore ();

So in the end, inferior 1 stays current, and inferior 2 gets wrongfully
pruned.

I'd say clean_up_just_stopped_threads_fsms is the culprit here.  It
actually attempts to restore the event_thread to be current at the end,
after the loop (I presume the current thread on entry is always supposed
to be the event thread).  But in this case, the event is of kind EXITED,
and ecs->event_thread is not set, so the current inferior isn't
restored.

Fix that by using scoped_restore_current_thread.  If there is no current
thread, scoped_restore_current_thread will still restore the current
inferior, and that's what we want.

Random note: the thread_info object for inferior 2's thread is never
freed.  It is held (by refcount) by the restore_thread object in
fetch_inferior_event, while the inferior's thread list gets cleared, in
the exit event processing.  When the refcount reaches 0 (when the
restore_thread object is destroyed), there's nothing that actually
deletes the thread_info object.  And I think that nothing in GDB points
to it anymore, so it leaks.  I don't want to fix that in this patch, but
thought it would be good to mention it, in case somebody has an idea for
how to fix that.

Change-Id: Ibc7df543e2c46aad5f3b9250b28c3fb5912be4e8

Slightly tweak and clarify target_resume's interface

The current target_resume interface is a bit odd & non-intuitive.
I've found myself explaining it a couple times the recent past, while
reviewing patches that assumed STEP/SIGNAL always applied to the
passed in PTID.  It goes like this today:

  - if the passed in PTID is a thread, then the step/signal request is
    for that thread.

  - otherwise, if PTID is a wildcard (all threads or all threads of
    process), the step/signal request is for inferior_ptid, and PTID
    indicates which set of threads run free.

Because GDB always switches the current thread to "leader" thread
being resumed/stepped/signalled, we can simplify this a bit to:

  - step/signal are always for inferior_ptid.

  - PTID indicates the set of threads that run free.

Still not ideal, but it's a minimal change and at least there are no
special cases this way.

That's what this patch does.  It renames the PTID parameter to
SCOPE_PTID, adds some assertions to target_resume, and tweaks
target_resume's description.  In addition, it also renames PTID to
SCOPE_PTID in the remote and linux-nat targets, and simplifies their
implementation a little bit.  Other targets could do the same, but
they don't have to.

Change-Id: I02a2ec2ab3a3e9b191de1e9a84f55c17cab7daaf