gdbserver/linux-low.cc: Ignore event_ptid if TARGET_WAITKIND_IGNORE

gdbserver's linux_process_target::wait loops if:

 - called in sync mode, and,
 - wait_1 returns TARGET_WAITKIND_IGNORE, _and_,
 - wait_1 also returns null_ptid.

The null_ptid check fails however when this path is taken:

   ptid_t
   linux_process_target::filter_exit_event (lwp_info *event_child,
    target_waitstatus *ourstatus)
   {
   ...
     if (!is_leader (thread))
       {
 if (report_exit_events_for (thread))
   ourstatus->set_thread_exited (0);
 else
   ourstatus->set_ignore ();            <<<<<<<

 delete_lwp (event_child);
       }
     return ptid;
   }

This makes linux_process_target::wait return TARGET_WAITKIND_IGNORE in
sync mode, which is unexpected by the core and fails an assertion.

This commit fixes it by just making linux_process_target::wait loop if
it got a TARGET_WAITKIND_IGNORE, irrespective of event_ptid.

Change-Id: I39776908a6c75cbd68aa04139ffcf7be334868cf

all-stop/synchronous RSP support thread-exit events

Currently, GDB does not understand the THREAD_EXITED stop reply in
remote all-stop mode.  There's no good reason for this, it just
happened that THREAD_EXITED was only ever reported in non-stop mode so
far.  This patch teaches GDB to parse that event in all-stop RSP too.
There is no need to add a qSupported feature for this, because the
server won't send a THREAD_EXITED event unless GDB explicitly asks for
it, with QThreadEvents, or with the GDB_THREAD_OPTION_EXIT
QThreadOptions option added in the next patch.

Change-Id: Ide5d12391adf432779fe4c79526801c4a5630966

Remove gdb/19675 kfails (displaced stepping + clone)

Now that gdb/19675 is fixed for both native and gdbserver GNU/Linux,
remove the gdb/19675 kfails.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=19675
Reviewed-By: Andrew Burgess <aburgess@redhat.com>
Change-Id: I95c1c38ca370100675d303cd3c8995860bef465d

gdbserver: Hide and don't detach pending clone children

This commit extends the logic added by these two commits from a while
ago:

 #1  7b961964f866  (gdbserver: hide fork child threads from GDB),
 #2  df5ad102009c  (gdb, gdbserver: detach fork child when detaching from fork parent)

... to handle thread clone events, which are very similar to (v)fork
events.

For #1, we want to hide clone children as well, so just update the
comments.

For #2, unlike (v)fork children, pending clone children aren't full
processes, they're just threads, so don't detach them in
handle_detach.  linux-low.cc will take care of detaching them along
with all other threads of the process, there's nothing special that
needs to be done.

Reviewed-By: Andrew Burgess <aburgess@redhat.com>
Change-Id: I7f5901d07efda576a2522d03e183994e071b8ffc

Thread options & clone events (Linux GDBserver)

This patch teaches the Linux GDBserver backend to report clone events
to GDB, when GDB has requested them with the GDB_THREAD_OPTION_CLONE
thread option, via the new QThreadOptions packet.

This shuffles code in linux_process_target::handle_extended_wait
around to a more logical order when we now have to handle and
potentially report all of fork/vfork/clone.

Raname lwp_info::fork_relative -> lwp_info::relative as the field is
no longer only about (v)fork.

With this, gdb.threads/stepi-over-clone.exp now cleanly passes against
GDBserver, so remove the native-target-only requirement from that
testcase.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=19675
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27830
Reviewed-By: Andrew Burgess <aburgess@redhat.com>
Change-Id: I3a19bc98801ec31e5c6fdbe1ebe17df855142bb2

Thread options & clone events (native Linux)

This commit teaches the native Linux target about the
GDB_THREAD_OPTION_CLONE thread option.  It's actually simpler to just
continue reporting all clone events unconditionally to the core.
There's never any harm in reporting a clone event when the option is
disabled.  All we need to do is to report support for the option,
otherwise GDB falls back to use target_thread_events().

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=19675
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27830
Reviewed-By: Andrew Burgess <aburgess@redhat.com>
Change-Id: If90316e2dcd0c61d0fefa0d463c046011698acf9

Thread options & clone events (core + remote)

A previous patch taught GDB about a new TARGET_WAITKIND_THREAD_CLONED
event kind, and made the Linux target report clone events.

A following patch will teach Linux GDBserver to do the same thing.

However, for remote debugging, it wouldn't be ideal for GDBserver to
report every clone event to GDB, when GDB only cares about such events
in some specific situations.  Reporting clone events all the time
would be potentially chatty.  We don't enable thread create/exit
events all the time for the same reason.  Instead we have the
QThreadEvents packet.  QThreadEvents is target-wide, though.

This patch makes GDB instead explicitly request that the target
reports clone events or not, on a per-thread basis.

In order to be able to do that with GDBserver, we need a new remote
protocol feature.  Since a following patch will want to enable thread
exit events on per-thread basis too, the packet introduced here is
more generic than just for clone events.  It lets you enable/disable a
set of options at once, modelled on Linux ptrace's PTRACE_SETOPTIONS.

IOW, this commit introduces a new QThreadOptions packet, that lets you
specify a set of per-thread event options you want to enable.  The
packet accepts a list of options/thread-id pairs, similarly to vCont,
processed left to right, with the options field being a number
interpreted as a bit mask of options.  The only option defined in this
commit is GDB_THREAD_OPTION_CLONE (0x1), which ask the remote target
to report clone events.  Another patch later in the series will
introduce another option.

For example, this packet sets option "1" (clone events) on thread
p1000.2345:

  QThreadOptions;1:p1000.2345

and this clears options for all threads of process 1000, and then sets
option "1" (clone events) on thread p1000.2345:

  QThreadOptions;0:p1000.-1;1:p1000.2345

This clears options of all threads of all processes:

  QThreadOptions;0

The target reports the set of supported options by including
"QThreadOptions=<supported options>" in its qSupported response.

infrun is then tweaked to enable GDB_THREAD_OPTION_CLONE when stepping
over a breakpoint.

Unlike PTRACE_SETOPTIONS, fork/vfork/clone children do NOT inherit
their parent's thread options.  This is so that GDB can send e.g.,
"QThreadOptions;0;1:TID" without worrying about threads it doesn't
know about yet.

Documentation for this new remote protocol feature is included in a
documentation patch later in the series.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=19675
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27830
Reviewed-By: Andrew Burgess <aburgess@redhat.com>
Change-Id: Ie41e5093b2573f14cf6ac41b0b5804eba75be37e

Avoid duplicate QThreadEvents packets

Similarly to QProgramSignals and QPassSignals, avoid sending duplicate
QThreadEvents packets.

Approved-By: Andrew Burgess <aburgess@redhat.com>
Change-Id: Iaf5babb0b64e1527ba4db31aac8674d82b17e8b4

Support clone events in the remote protocol

The previous patch taught GDB about a new
TARGET_WAITKIND_THREAD_CLONED event kind, and made the Linux target
report clone events.

A following patch will teach Linux GDBserver to do the same thing.

But before we get there, we need to teach the remote protocol about
TARGET_WAITKIND_THREAD_CLONED.  That's what this patch does.  Clone is
very similar to vfork and fork, and the new stop reply is likewise
handled similarly.  The stub reports "T05clone:...".

GDBserver core is taught to handle TARGET_WAITKIND_THREAD_CLONED and
forward it to GDB in this patch, but no backend actually emits it yet.
That will be done in a following patch.

Documentation for this new remote protocol feature is included in a
documentation patch later in the series.

Reviewed-By: Andrew Burgess <aburgess@redhat.com>
Change-Id: If271f20320d864f074d8ac0d531cc1a323da847f
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=19675
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27830

Step over clone syscall w/ breakpoint, TARGET_WAITKIND_THREAD_CLONED

(A good chunk of the problem statement in the commit log below is
Andrew's, adjusted for a different solution, and for covering
displaced stepping too.  The testcase is mostly Andrew's too.)

This commit addresses bugs gdb/19675 and gdb/27830, which are about
stepping over a breakpoint set at a clone syscall instruction, one is
about displaced stepping, and the other about in-line stepping.

Currently, when a new thread is created through a clone syscall, GDB
sets the new thread running.  With 'continue' this makes sense
(assuming no schedlock):

 - all-stop mode, user issues 'continue', all threads are set running,
   a newly created thread should also be set running.

 - non-stop mode, user issues 'continue', other pre-existing threads
   are not affected, but as the new thread is (sort-of) a child of the
   thread the user asked to run, it makes sense that the new threads
   should be created in the running state.

Similarly, if we are stopped at the clone syscall, and there's no
software breakpoint at this address, then the current behaviour is
fine:

 - all-stop mode, user issues 'stepi', stepping will be done in place
   (as there's no breakpoint to step over).  While stepping the thread
   of interest all the other threads will be allowed to continue.  A
   newly created thread will be set running, and then stopped once the
   thread of interest has completed its step.

 - non-stop mode, user issues 'stepi', stepping will be done in place
   (as there's no breakpoint to step over).  Other threads might be
   running or stopped, but as with the continue case above, the new
   thread will be created running.  The only possible issue here is
   that the new thread will be left running after the initial thread
   has completed its stepi.  The user would need to manually select
   the thread and interrupt it, this might not be what the user
   expects.  However, this is not something this commit tries to
   change.

The problem then is what happens when we try to step over a clone
syscall if there is a breakpoint at the syscall address.

- For both all-stop and non-stop modes, with in-line stepping:

   + user issues 'stepi',
   + [non-stop mode only] GDB stops all threads.  In all-stop mode all
     threads are already stopped.
   + GDB removes s/w breakpoint at syscall address,
   + GDB single steps just the thread of interest, all other threads
     are left stopped,
   + New thread is created running,
   + Initial thread completes its step,
   + [non-stop mode only] GDB resumes all threads that it previously
     stopped.

There are two problems in the in-line stepping scenario above:

  1. The new thread might pass through the same code that the initial
     thread is in (i.e. the clone syscall code), in which case it will
     fail to hit the breakpoint in clone as this was removed so the
     first thread can single step,

  2. The new thread might trigger some other stop event before the
     initial thread reports its step completion.  If this happens we
     end up triggering an assertion as GDB assumes that only the
     thread being stepped should stop.  The assert looks like this:

     infrun.c:5899: internal-error: int finish_step_over(execution_control_state*): Assertion `ecs->event_thread->control.trap_expected' failed.

- For both all-stop and non-stop modes, with displaced stepping:

   + user issues 'stepi',
   + GDB starts the displaced step, moves thread's PC to the
     out-of-line scratch pad, maybe adjusts registers,
   + GDB single steps the thread of interest, [non-stop mode only] all
     other threads are left as they were, either running or stopped.
     In all-stop, all other threads are left stopped.
   + New thread is created running,
   + Initial thread completes its step, GDB re-adjusts its PC,
     restores/releases scratchpad,
   + [non-stop mode only] GDB resumes the thread, now past its
     breakpoint.
   + [all-stop mode only] GDB resumes all threads.

There is one problem with the displaced stepping scenario above:

  3. When the parent thread completed its step, GDB adjusted its PC,
     but did not adjust the child's PC, thus that new child thread
     will continue execution in the scratch pad, invoking undefined
     behavior.  If you're lucky, you see a crash.  If unlucky, the
     inferior gets silently corrupted.

What is needed is for GDB to have more control over whether the new
thread is created running or not.  Issue #1 above requires that the
new thread not be allowed to run until the breakpoint has been
reinserted.  The only way to guarantee this is if the new thread is
held in a stopped state until the single step has completed.  Issue #3
above requires that GDB is informed of when a thread clones itself,
and of what is the child's ptid, so that GDB can fixup both the parent
and the child.

When looking for solutions to this problem I considered how GDB
handles fork/vfork as these have some of the same issues.  The main
difference between fork/vfork and clone is that the clone events are
not reported back to core GDB.  Instead, the clone event is handled
automatically in the target code and the child thread is immediately
set running.

Note we have support for requesting thread creation events out of the
target (TARGET_WAITKIND_THREAD_CREATED).  However, those are reported
for the new/child thread.  That would be sufficient to address in-line
stepping (issue #1), but not for displaced-stepping (issue #3).  To
handle displaced-stepping, we need an event that is reported to the
_parent_ of the clone, as the information about the displaced step is
associated with the clone parent.  TARGET_WAITKIND_THREAD_CREATED
includes no indication of which thread is the parent that spawned the
new child.  In fact, for some targets, like e.g., Windows, it would be
impossible to know which thread that was, as thread creation there
doesn't work by "cloning".

The solution implemented here is to model clone on fork/vfork, and
introduce a new TARGET_WAITKIND_THREAD_CLONED event.  This event is
similar to TARGET_WAITKIND_FORKED and TARGET_WAITKIND_VFORKED, except
that we end up with a new thread in the same process, instead of a new
thread of a new process.  Like FORKED and VFORKED, THREAD_CLONED
waitstatuses have a child_ptid property, and the child is held stopped
until GDB explicitly resumes it.  This addresses the in-line stepping
case (issues #1 and #2).

The infrun code that handles displaced stepping fixup for the child
after a fork/vfork event is thus reused for THREAD_CLONE, with some
minimal conditions added, addressing the displaced stepping case
(issue #3).

The native Linux backend is adjusted to unconditionally report
TARGET_WAITKIND_THREAD_CLONED events to the core.

Following the follow_fork model in core GDB, we introduce a
target_follow_clone target method, which is responsible for making the
new clone child visible to the rest of GDB.

Subsequent patches will add clone events support to the remote
protocol and gdbserver.

displaced_step_in_progress_thread becomes unused with this patch, but
a new use will reappear later in the series.  To avoid deleting it and
readding it back, this patch marks it with attribute unused, and the
latter patch removes the attribute again.  We need to do this because
the function is static, and with no callers, the compiler would warn,
(error with -Werror), breaking the build.

This adds a new gdb.threads/stepi-over-clone.exp testcase, which
exercises stepping over a clone syscall, with displaced stepping vs
inline stepping, and all-stop vs non-stop.  We already test stepping
over clone syscalls with gdb.base/step-over-syscall.exp, but this test
uses pthreads, while the other test uses raw clone, and this one is
more thorough.  The testcase passes on native GNU/Linux, but fails
against GDBserver.  GDBserver will be fixed by a later patch in the
series.

Co-authored-by: Andrew Burgess <aburgess@redhat.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=19675
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27830
Change-Id: I95c06024736384ae8542a67ed9fdf6534c325c8e
Reviewed-By: Andrew Burgess <aburgess@redhat.com>

gdb/linux: Delete all other LWPs immediately on ptrace exec event

I noticed that on an Ubuntu 20.04 system, after a following patch
("Step over clone syscall w/ breakpoint,
TARGET_WAITKIND_THREAD_CLONED"), the gdb.threads/step-over-exec.exp
was passing cleanly, but still, we'd end up with four new unexpected
GDB core dumps:

 === gdb Summary ===

 # of unexpected core files      4
 # of expected passes            48

That said patch is making the pre-existing
gdb.threads/step-over-exec.exp testcase (almost silently) expose a
latent problem in gdb/linux-nat.c, resulting in a GDB crash when:

 #1 - a non-leader thread execs
 #2 - the post-exec program stops somewhere
 #3 - you kill the inferior

Instead of #3 directly, the testcase just returns, which ends up in
gdb_exit, tearing down GDB, which kills the inferior, and is thus
equivalent to #3 above.

Vis (after said patch is applied):

 $ gdb --args ./gdb /home/pedro/gdb/build/gdb/testsuite/outputs/gdb.threads/step-over-exec/step-over-exec-execr-thread-other-diff-text-segs-true
 ...
 (top-gdb) r
 ...
 (gdb) b main
 ...
 (gdb) r
 ...
 Breakpoint 1, main (argc=1, argv=0x7fffffffdb88) at /home/pedro/gdb/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.threads/step-over-exec.c:69
 69        argv0 = argv[0];
 (gdb) c
 Continuing.
 [New Thread 0x7ffff7d89700 (LWP 2506975)]
 Other going in exec.
 Exec-ing /home/pedro/gdb/build/gdb/testsuite/outputs/gdb.threads/step-over-exec/step-over-exec-execr-thread-other-diff-text-segs-true-execd
 process 2506769 is executing new program: /home/pedro/gdb/build/gdb/testsuite/outputs/gdb.threads/step-over-exec/step-over-exec-execr-thread-other-diff-text-segs-true-execd

 Thread 1 "step-over-exec-" hit Breakpoint 1, main () at /home/pedro/gdb/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.threads/step-over-exec-execd.c:28
 28        foo ();
 (gdb) k
 ...
 Thread 1 "gdb" received signal SIGSEGV, Segmentation fault.
 0x000055555574444c in thread_info::has_pending_waitstatus (this=0x0) at ../../src/gdb/gdbthread.h:393
 393         return m_suspend.waitstatus_pending_p;
 (top-gdb) bt
 #0  0x000055555574444c in thread_info::has_pending_waitstatus (this=0x0) at ../../src/gdb/gdbthread.h:393
 #1  0x0000555555a884d1 in get_pending_child_status (lp=0x5555579b8230, ws=0x7fffffffd130) at ../../src/gdb/linux-nat.c:1345
 #2  0x0000555555a8e5e6 in kill_unfollowed_child_callback (lp=0x5555579b8230) at ../../src/gdb/linux-nat.c:3564
 #3  0x0000555555a92a26 in gdb::function_view<int (lwp_info*)>::bind<int, lwp_info*>(int (*)(lwp_info*))::{lambda(gdb::fv_detail::erased_callable, lwp_info*)#1}::operator()(gdb::fv_detail::erased_callable, lwp_info*) const (this=0x0, ecall=..., args#0=0x5555579b8230) at ../../src/gdb/../gdbsupport/function-view.h:284
 #4  0x0000555555a92a51 in gdb::function_view<int (lwp_info*)>::bind<int, lwp_info*>(int (*)(lwp_info*))::{lambda(gdb::fv_detail::erased_callable, lwp_info*)#1}::_FUN(gdb::fv_detail::erased_callable, lwp_info*) () at ../../src/gdb/../gdbsupport/function-view.h:278
 #5  0x0000555555a91f84 in gdb::function_view<int (lwp_info*)>::operator()(lwp_info*) const (this=0x7fffffffd210, args#0=0x5555579b8230) at ../../src/gdb/../gdbsupport/function-view.h:247
 #6  0x0000555555a87072 in iterate_over_lwps(ptid_t, gdb::function_view<int (lwp_info*)>) (filter=..., callback=...) at ../../src/gdb/linux-nat.c:864
 #7  0x0000555555a8e732 in linux_nat_target::kill (this=0x55555653af40 <the_amd64_linux_nat_target>) at ../../src/gdb/linux-nat.c:3590
 #8  0x0000555555cfdc11 in target_kill () at ../../src/gdb/target.c:911
 ...

The root of the problem is that when a non-leader LWP execs, it just
changes its tid to the tgid, replacing the pre-exec leader thread,
becoming the new leader.  There's no thread exit event for the execing
thread.  It's as if the old pre-exec LWP vanishes without trace.  The
ptrace man page says:

 "PTRACE_O_TRACEEXEC (since Linux 2.5.46)
Stop the tracee at the next execve(2).  A waitpid(2) by the
tracer will return a status value such that

  status>>8 == (SIGTRAP | (PTRACE_EVENT_EXEC<<8))

If the execing thread is not a thread group leader, the thread
ID is reset to thread group leader's ID before this stop.
Since Linux 3.0, the former thread ID can be retrieved with
PTRACE_GETEVENTMSG."

When the core of GDB processes an exec events, it deletes all the
threads of the inferior.  But, that is too late -- deleting the thread
does not delete the corresponding LWP, so we end leaving the pre-exec
non-leader LWP stale in the LWP list.  That's what leads to the crash
above -- linux_nat_target::kill iterates over all LWPs, and after the
patch in question, that code will look for the corresponding
thread_info for each LWP.  For the pre-exec non-leader LWP still
listed, won't find one.

This patch fixes it, by deleting the pre-exec non-leader LWP (and
thread) from the LWP/thread lists as soon as we get an exec event out
of ptrace.

GDBserver does not need an equivalent fix, because it is already doing
this, as side effect of mourning the pre-exec process, in
gdbserver/linux-low.cc:

  else if (event == PTRACE_EVENT_EXEC && cs.report_exec_events)
    {
...
      /* Delete the execing process and all its threads.  */
      mourn (proc);
      switch_to_thread (nullptr);

The crash with gdb.threads/step-over-exec.exp is not observable on
newer systems, which postdate the glibc change to move "libpthread.so"
internals to "libc.so.6", because right after the exec, GDB traps a
load event for "libc.so.6", which leads to GDB trying to open
libthread_db for the post-exec inferior, and, on such systems that
succeeds.  When we load libthread_db, we call
linux_stop_and_wait_all_lwps, which, as the name suggests, stops all
lwps, and then waits to see their stops.  While doing this, GDB
detects that the pre-exec stale LWP is gone, and deletes it.

If we use "catch exec" to stop right at the exec before the
"libc.so.6" load event ever happens, and issue "kill" right there,
then GDB crashes on newer systems as well.  So instead of tweaking
gdb.threads/step-over-exec.exp to cover the fix, add a new
gdb.threads/threads-after-exec.exp testcase that uses "catch exec".
The test also uses the new "maint info linux-lwps" command if testing
on Linux native, which also exposes the stale LWP problem with an
unfixed GDB.

Also tweak a comment in infrun.c:follow_exec referring to how
linux-nat.c used to behave, as it would become stale otherwise.

Reviewed-By: Andrew Burgess <aburgess@redhat.com>
Change-Id: I21ec18072c7750f3a972160ae6b9e46590376643

Add "maint info linux-lwps" command

This adds a maintenance command that lets you list all the LWPs under
control of the linux-nat target.

For example:

 (gdb) maint info linux-lwps
 LWP Ptid        Thread ID
 560948.561047.0 None
 560948.560948.0 1.1

This shows that "560948.561047.0" LWP doesn't map to any thread_info
object, which is bogus.  We'll be using this in a testcase in a
following patch.

Co-Authored-By: Pedro Alves <pedro@palves.net>
Change-Id: Ic4e9e123385976e5cd054391990124b7a20fb3f5

[gdb/tui] Fix Wmaybe-uninitialized in tui_find_disassembly_address

When building gdb with -O2, we run into:
...
gdb/tui/tui-disasm.c: In function ‘CORE_ADDR tui_find_disassembly_address \
  (gdbarch*, CORE_ADDR, int)’:
gdb/tui/tui-disasm.c:293:7: warning: ‘last_addr’ may be used uninitialized \
  in this function [-Wmaybe-uninitialized]
       if (last_addr < pc)
       ^~
...

The warning triggers since commit 72535eb14bd ("[gdb/tui] Fix segfault in
tui_find_disassembly_address").

Fix the warning by ensuring that last_addr is initialized at the point of
use:
...
+      last_addr = asm_lines.back ().addr;
       if (last_addr < pc)
...

Tested on x86_64-linux.

[gdb/tui] Make assert in tui_find_disassembly_address more strict

In tui_find_disassembly_address we find an assert:
...
      if (asm_lines.size () < max_lines)
{
  if (!possible_new_low.has_value ())
    return new_low;

  /* Take the best possible match we have.  */
  new_low = *possible_new_low;
  next_addr = tui_disassemble (gdbarch, asm_lines, new_low, max_lines);
  last_addr = asm_lines.back ().addr;
  gdb_assert (asm_lines.size () >= max_lines);
}
...

The comment right above:
...
      /* If we failed to disassemble the required number of lines then the
 following walk forward is not going to work, it assumes that
 ASM_LINES contains exactly MAX_LINES entries.  Instead we should
 consider falling back to a previous possible start address in
 POSSIBLE_NEW_LOW.  */
...
claims that the more strict asm_lines.size () == max_line is required.

Update the assert to reflect this, and move it to after the if because it's
supposed to hold in general, not just when entering the if.

Tested on x86_64-linux.

Remove declaration of re_comp

defs.h declares re_comp, but it shouldn't.  If this is needed, it
should be picked up from xregex.h via gdb_regex.h.

Tested by rebuilding.

Reviewed-by: Kevin Buettner <kevinb@redhat.com>

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

bfd, binutils: add gfx11 amdgpu architectures

Teach bfd and readelf about some recent gfx11 architectures.  This code
is taken from the rocgdb 5.7.x branch [1].

[1] https://github.com/rocm-Developer-Tools/rocgdb/tree/rocm-5.7.x

bfd/ChangeLog:

* archures.c (bfd_mach_amdgcn_gfx1100, bfd_mach_amdgcn_gfx1101,
bfd_mach_amdgcn_gfx1102): New.
* bfd-in2.h (bfd_mach_amdgcn_gfx1100, bfd_mach_amdgcn_gfx1101,
bfd_mach_amdgcn_gfx1102): New.
* cpu-amdgcn.c (arch_info_struct): Add entries for
bfd_mach_amdgcn_gfx1100, bfd_mach_amdgcn_gfx1101,
bfd_mach_amdgcn_gfx1102.

binutils/ChangeLog:

* readelf.c (decode_AMDGPU_machine_flags): Handle gfx1100,
gfx1101, gfx1102.

include/ChangeLog:

* elf/amdgpu.h (EF_AMDGPU_MACH_AMDGCN_GFX1100,
EF_AMDGPU_MACH_AMDGCN_GFX1101,
EF_AMDGPU_MACH_AMDGCN_GFX1102): New.

Change-Id: I95a8a62942e359781a1c9fa2079950fbcf2a78b8
Co-Authored-By: Laurent Morichetti <laurent.morichetti@amd.com>
Cc: Lancelot Six <lancelot.six@amd.com>

Correct formatting errors in elf32-microblaze.c

Signed-off-by: Michael J. Eager <eager@eagercon.com>

Gold/MIPS: Use EM_MIPS instead of EM_MIPS_RS3_LE for little endian

GAS/MIPS: Fix testcase module-defer-warn2 for r2+ triples

readelf..debug-dump=loc displays bogus base addresses

  PR 30880
  * dwarf.c (read_and_display_attr_value): Fix loclist handling. (display_loclists_list): Likewise.

GAS/MIPS: Add mips16-e-irix.d testcase

MIPS: Change all E_MIPS_* to EF_MIPS_*

Add ability to change linker warning messages into errors when reporting executable stacks and/or executable segments.

  include
  * bfdlink.h (struct bfd_link_info): Update descriptions of the 'execstack', 'noexecstack' and 'warn_execstack' fields. Add 'error_exectack' and 'warn_is_error_for_rwx_segments' fields.

  bfd
  * elf.c (assign_file_positions_except_relocs): Turn warnings about executable segments into errors if so requested.
  * elflink.c (bfd_elf_size_dynamic_sections): Turn warnings about executable stacks into errors if so requested.

  ld
  * ldlex.h (enum option_values): Add OPTION_ERROR_EXECSTACK, OPTION_NO_ERROR_EXECSTACK, OPTION_WARN_EXECSTACK_OBJECTS, OPTION_ERROR_RWX_SEGMENTS and OPTION_NO_ERROR_RWX_SEGMENTS. (struct ld_option): Add new long options. (parse_args): Parse new long options. (elf_static_list_options): Display the new options.
  * ld.texi: Document the new command line options.
  * configure.ac (error-execstack): New configuration option. (error-rwx-segments): New configuration option.
  * emultempl/elf.em (_before_parse): Initialse the new linkinfo fields.
  * NEWS: Mention the new features.
  * config.in: Regenerate.
  * configure: Regenerate.
  * testsuite/ld-elf/commonpage2.d: Disable errors for RWX segments and/or executable stacks.
  * testsuite/ld-elf/elf.exp: Likewise.
  * testsuite/ld-elf/header.d: Likewise.
  * testsuite/ld-elf/loadaddr1.d: Likewise.
  * testsuite/ld-elf/loadaddr2.d: Likewise.
  * testsuite/ld-elf/maxpage4.d: Likewise.
  * testsuite/ld-elf/nobits-1.d: Likewise.
  * testsuite/ld-elf/note-1.d: Likewise.
  * testsuite/ld-elf/orphan-10.d: Likewise.
  * testsuite/ld-elf/orphan-11.d: Likewise.
  * testsuite/ld-elf/orphan-12.d: Likewise.
  * testsuite/ld-elf/orphan-5.d: Likewise.
  * testsuite/ld-elf/orphan-7.d: Likewise.
  * testsuite/ld-elf/orphan-8.d: Likewise.
  * testsuite/ld-elf/orphan-9.d: Likewise.
  * testsuite/ld-elf/orphan-region.d: Likewise.
  * testsuite/ld-elf/orphan.d: Likewise.
  * testsuite/ld-elf/pr19539.d: Likewise.
  * testsuite/ld-elf/pr26256-1a.d: Likewise.
  * testsuite/ld-elf/pr26907.d: Likewise.
  * testsuite/ld-elf/pr28597.d: Likewise.
  * testsuite/ld-elf/retain2.d: Likewise.
  * testsuite/ld-elf/shared.exp: Likewise.
  * testsuite/ld-elf/size-1.d: Likewise.
  * testsuite/ld-elf/textaddr7.d: Likewise.
  * testsuite/ld-elf/warn1.d: Likewise.
  * testsuite/ld-elf/warn2.d: Likewise.
  * testsuite/ld-i386/discarded1.d: Likewise.
  * testsuite/ld-i386/pr19175.d: Likewise.
  * testsuite/ld-i386/pr19539.d: Likewise.
  * testsuite/ld-i386/pr23189.d: Likewise.
  * testsuite/ld-plugin/lto-3r.d: Likewise.
  * testsuite/ld-plugin/lto-5r.d: Likewise.
  * testsuite/ld-plugin/lto.exp: Likewise.
  * testsuite/ld-powerpc/ppc476-shared.d: Likewise.
  * testsuite/ld-powerpc/ppc476-shared2.d: Likewise.
  * testsuite/ld-powerpc/pr28827-2.d: Likewise.
  * testsuite/ld-s390/s390.exp: Likewise.
  * testsuite/ld-scripts/align2a.d: Likewise.
  * testsuite/ld-scripts/align2b.d: Likewise.
  * testsuite/ld-scripts/align5.d: Likewise.
  * testsuite/ld-scripts/alignof.exp: Likewise.
  * testsuite/ld-scripts/crossref.exp: Likewise.
  * testsuite/ld-scripts/defined2.d: Likewise.
  * testsuite/ld-scripts/defined3.d: Likewise.
  * testsuite/ld-scripts/defined5.d: Likewise.
  * testsuite/ld-scripts/pr14962.d: Likewise.
  * testsuite/ld-scripts/pr18963.d: Likewise.
  * testsuite/ld-scripts/pr20302.d: Likewise.
  * testsuite/ld-scripts/print-memory-usage.exp: Likewise.
  * testsuite/ld-scripts/rgn-at1.d: Likewise.
  * testsuite/ld-scripts/rgn-at10.d: Likewise.
  * testsuite/ld-scripts/rgn-at4.d: Likewise.
  * testsuite/ld-scripts/rgn-at6.d: Likewise.
  * testsuite/ld-scripts/rgn-at8.d: Likewise.
  * testsuite/ld-scripts/rgn-at9.d: Likewise.
  * testsuite/ld-scripts/rgn-over1.d: Likewise.
  * testsuite/ld-scripts/rgn-over2.d: Likewise.
  * testsuite/ld-scripts/rgn-over4.d: Likewise.
  * testsuite/ld-scripts/rgn-over5.d: Likewise.
  * testsuite/ld-scripts/rgn-over6.d: Likewise.
  * testsuite/ld-scripts/script.exp: Likewise.
  * testsuite/ld-scripts/sizeof.exp: Likewise.
  * testsuite/ld-scripts/sort-file.d: Likewise.
  * testsuite/ld-x86-64/discarded1.d: Likewise.
  * testsuite/ld-x86-64/pr19175.d: Likewise.
  * testsuite/ld-x86-64/pr19539a.d: Likewise.
  * testsuite/ld-x86-64/pr19539b.d: Likewise.
  * testsuite/ld-x86-64/pr23189.d: Likewise.

Move new features above the 'Changes in 2.41' comment

Add support for ilp32 register alias.

Automatic date update in version.in

bfd: use less memory in string merging

the offset-to-entry mappings are allocated in blocks, which may
become a bit wasteful in case there are extremely many small
input files or sections.  This made it so that a large project
(Qt5WebEngine) didn't build anymore on x86 32bit due to address
space limits.  It barely fit into address space before the new
string merging, and then got pushed over the limit by this.

So instead of leaving the waste reallocate the maps to their final
size once known.  Now the link barely fits again.

bfd/
    * merge.c (record_section): Reallocate offset maps to their
    final size.

ld: Avoid overflows in string merging

as the bug report shows we had an overflow in the test if
hash table resizing is needed.  Reorder the expression to avoid
that.  There's still a bug somewhere in gracefully handling
failure in resizing (e.g. out of memory), but this pushes the
boundary for that occurring somewhen into the future and
immediately helps the reporter.

    bfd/

    PR ld/31009
    * merge.c (NEEDS_RESIZE): New macro avoiding overflow.
    (sec_merge_maybe_resize): Use it.
    (sec_merge_hash_insert): Ditto.

ld: aarch64: Use lp64 abi in recent BTI stub tests

The tests are not compatible with ilp32 abi: the GNU property
note is ABI dependent (size changes) and the disasm is ABI
dependent too.  Making the test portable between the ABIs is
not trivial.

For now force lp64 abi.

ld: aarch64: Add BTI stub insertion test PR30930

The test creates a large shared library and covers a number of
BTI stub insertion cases.

bfd: aarch64: Avoid BTI stub for a PLT that has BTI

We decide to emit BTI stubs based on the instruction at the target
location. But PLT code is generated later than the stubs so we always
read 0 which is not a valid BTI.

Fix the logic to special case the PLT section: this is code the linker
generates so we know when it will have BTI.

This avoids BTI stubs in large executables where the PLTs have them
already. An alternative is to never emit BTI stubs for PLTs, instead
use BTI in the PLT if a library gets too big, however that may be
more tricky given the ordering of PLT sizing and stub insertion.

Related to bug 30957.

bfd: aarch64: Fix leaks in case of BTI stub reuse

BTI stub parameters were recomputed even if those were already set up.
This is unnecessary work and leaks the symbol name that is allocated
for the stub.

bfd: aarch64: Fix broken BTI stub PR30930

Input sections are grouped together that can use the same stub area
(within reach) and these groups have a stable id.

Stubs have a name generated from the stub group id and target symbol.
When a relocation requires a stub with a name that already exists, the
stub is reused instead of adding a new one.

For an indirect branch stub another BTI stub may be inserted near the
target to provide a BTI landing pad.

The BTI stub can end up with the same stub group id and thus the same
name as the indirect stub. This happens if the target symbol is within
reach of the indirect branch stub. Then, due to the name collision,
only a single stub was emmitted which branched to itself causing an
infinite loop at runtime.

A possible solution is to just name the BTI stubs differently, but
since in the problematic case the indirect and BTI stub are in the
same stub area, a better solution is to emit a single stub with a
direct branch. The stub is still needed since the caller cannot reach
the target directly and we also want a BTI landing pad in the stub in
case other indirect stubs target the same symbol and thus need a BTI
stub.

In short we convert an indirect branch stub into a BTI stub when the
target is within reach and has no BTI. It is a hassle to change the
symbol of the stub so a BTI stub may end up with *_veneer instead of
*_bti_veneer after the conversion, but this should not matter much.
(Refactoring some of _bfd_aarch64_add_call_stub_entries would be
useful but too much for this bug fix patch.)

The same conversion to direct branch could be done even if the target
did not need a BTI. The stub groups are fixed in the current logic so
linking can fail if too many stubs are inserted and the section layout
is changed too much, but this only happens in extreme cases that can
be reasonably ignored. Because of this the target cannot go out of
reach during stub insertion so the optimization is valid, but not
implemented by this patch for the non-BTI case.

Fixes bug 30930.

bfd: aarch64: Fix BTI stub optimization PR30957

The instruction was looked up in the wrong input file (file of branch
source instead of branch target) when optimizing away BTI stubs in

  commit 5834f36d93cabf1a8bcc7dd7654141aed3d296bc
  bfd: aarch64: Optimize BTI stubs PR30076

This can cause adding BTI stubs when they are not necessary or removing
them when they are (the latter is a correctness issue but it is very
unlikely in practice).

Fixes bug 30957.

aarch64: Fix error in THE system register checking

The erroneous omission of a "reg_value == " in the THE system register
encoding check added in [1] led to an error which was not picked up in
GCC but which was flagged in Clang due to its use of
[-Werror,-Wconstant-logical-operand] check.  Together with this fix we
add a new test for the THE registers to pick up their illegal use,
adding an extra and important layer of validation.

Furthermore, in separating system register from instruction
implementation (with which only the former was of concern in the cited
patch), additions made to `aarch64-tbl.h' are rolled back so
that these can be added later when adding THE instructions to the
codebase, a more natural place for these changes.

[1] https://sourceware.org/pipermail/binutils/2023-November/130314.html

opcodes/ChangeLog:

* aarch64-opc.c (aarch64_sys_ins_reg_supported_p): Fix typo.
* aarch64-tbl.h (THE): Remove.
 (aarch64_feature_set aarch64_feature_the): Likewise.

gas/ChangeLog:

* testsuite/gas/aarch64/illegal-sysreg-8.l: Add tests for THE
system registers.
* testsuite/gas/aarch64/illegal-sysreg-8.s: Likewise.

x86: rework UWRMSR operand swapping

As indicated during review already, doing the swapping early is overall
cheaper than doing it only after operand matching.

x86: do away with is_evex_encoding()

As we have grown more uses of it, it becomes increasingly more desirable
to replace it by a simpler check. Have i386-gen do at build time what so
far was done at runtime: Deal with templates indicating EVEX-encoding by
other than the EVex attribute, and set that to "dynamic" in such cases.

This then allows simplifying a number of other conditionals as well.

x86: split insn templates' CPU field

Right now the opcode table has entries with ISA restrictions of the form
FEAT1|FEAT2, the meaning of which depends on context and requires
special treatment in tc-i386.c: Sometimes this means "both features
requires", whereas originally it was intended to solely mean "all of
these features required". Split the field, with the original one
regaining its original meaning. The new field now truly means "any of
these". The combination of both fields is still and &&-type check, i.e.
(all of these) && (any of these). In the opcode table more involved
combinations of features then also need expressing this way: "all"
entities first, follow by "any" entities enclosed in parentheses, e.g.
x64&(AVX|AVX512F). If the "all" part is empty, parentheses may not be
added around the "any" part (unless parsing logic was further relaxed).

Note that this way AVX512VL no longer needs as much special treatment,
and hence templates previously using AVX512F|AVX512VL are switched to
just AVX512VL.

Note further that this requires FMA handling as resulting from
da0784f961d8 ("x86: fold FMA VEX and EVEX templates") to be slightly
re-done: FMA now becomes more similar to AVX and AVX2.

x86: Cpu64 handling improvements

First of all we want to also accumulate its reverse dependencies, such
that we can use them in cpu_flags_match(). This is in particular in
preparation of APX additions, such that e.g. BMI VEX-encoding templates
can become combined VEX/EVEX ones.

Once we have the reverse dependencies, we can further leverage them to
omit explicit "&x64" from any insn templates dealing with 64-bit-mode-
only ISA extensions. Besides helping readability for several insn
templates we already have, this will also help with what is going to be
added for APX (as all of the new templates would otherwise need to have
"&x64").

Note that rather than leaving a meaningless CPU_64_FLAGS (which is
unused anyway), its emitting is now also suppressed.

x86: Intel Core processors do not support CMPXCHG16B

This being a 64-bit-only instruction (see also i386-opc.tbl) it cannot
possibly be supported by CPUs not supporting 64-bit mode.

Automatic date update in version.in

rs6000, Fix test gdb.base/store.exp

The test currently fails for IEEE 128-bit floating point types.  PowerPC
supports the IBM double 128-bit floating point format and IEEE 128-bit
format.  The IBM double 128-bit floating point format uses two 64-bit
floating point registers to store the 128-bit value.  The IEEE 128-bit
floating point format stores the value in a single 128-bit vector-scalar
register (vsr).

The various floating point values, 32-bit float, 64-bit double, IBM double
128-bit float and IEEE 128-bit floating point numbers are all mapped to the
DWARF fpr numbers.  The issue is the IEEE 128-bit floating point values are
actually stored in a vsr not the fprs.  This patch changes the register
mapping for the vsrs from the fpr to the vsr registers so the value is
properly accessed by GDB.  The functions rs6000_linux_register_to_value,
rs6000_linux_value_to_register, rs6000_linux_value_from_register check if
the value is an IEEE 128-bit floating point value and adjust the register
number as needed.  The test in function rs6000_convert_register_p is fixed
so it is only true for floating point values.

This patch fixes three regression tests in gdb.base/store.exp.

The patch has been tested on Power 8 LE/BE, Power 9 LE/BE and Power 10 LE
with no regressions.

rs6000, Fix Linux DWARF register mapping

Overview of issues fixed by the patch.

The primary issue this patch fixes is the DWARF register mapping for
Linux.  The changes in ppc-linux-tdep.c fix the DWARF register mapping
issues.  The register mapping issue is responsible for two of the
five regression bugs seen in gdb.base/store.exp.

Once the register mapping was fixed, an underlying issue with the unwinding
of the signal trampoline in common-code in ifrun.c was found.  This
underlying bug is best described by Ulrich in the following description.

  The unwinder bug shows up on platforms where the kernel uses a trampoline
  to dispatch "calls to" the signal handler (not just *returns from* the
  signal handler).  Many platforms use a trampoline for signal return, and
  that is working fine, but the only platform I'm (Ulrich) aware of that
  uses a trampoline for signal handler calls is (recent kernels for)
  PowerPC.  I believe the rationale for using a trampoline here
  is to improve performance by avoiding unbalancing of the
  branch predictor's call/return stack.

  However, on PowerPC the bug is dormant as well as it is hidden
  by *another* bug that prevents correct unwinding out of the
  signal trampoline.  This is because the custom CFI for the
  trampoline uses a register number (VSCR) that is not ever used
  by compiler-generated CFI, and that particular register is
  mapped to an invalid number by the current PowerPC DWARF mapper.

The underlying unwinder bug is exposed by the "new" regression failures
in gdb.base/sigstep.exp.  These failures were previously masked by
the fact that GDB was not seeing a valid frame when it tried to unwind
the frames.  The sigstep.exp test is specifically testing stepping into
a signal handler.  With the correct DWARF register mapping in place,
specifically the VSCR mapping, the signal trampoline code now unwinds to a
valid frame exposing the pre-existing bug in how the signal handler on
PowerPC works.  The one line change infrun.c fixes the exiting bug in
the common-code for platforms that use a trampoline to dispatch calls
to the signal handler by not stopping in the SIGTRAMP_FRAME.

Detailed description of the DWARF register mapping fix.

The PowerPC DWARF register mapping is the same for the .eh_frame and
.debug_frame on Linux.  PowerPC uses different mapping for .eh_frame and
.debug_frame on other operating systems.  The current GDB support for
mapping the DWARF registers in rs6000_linux_dwarf2_reg_to_regnum and
rs6000_adjust_frame_regnum file gdb/rs6000-tdep.c is not correct for Linux.
The files have some legacy mappings for spe_acc, spefscr, EV which was
removed from GCC in 2017.

This patch adds a two new functions rs6000_linux_dwarf2_reg_to_regnum,
and rs6000_linux_adjust_frame_regnum in file gdb/ppc-linux-tdep.c to handle
the DWARF register mappings on Linux.  Function
rs6000_linux_dwarf2_reg_to_regnum is installed for both gdb_dwarf_to_regnum
and gdbarch_stab_reg_to_regnum since the mappings are the same.

The ppc_linux_init_abi function in gdb/ppc-linux-tdep.c is updated to
call set_gdbarch_dwarf2_reg_to_regnum map the new function
rs6000_linux_dwarf2_reg_to_regnum for the architecture.  Similarly,
dwarf2_frame_set_adjust_regnum is called to map
rs6000_linux_adjust_frame_regnum into the architecture.

Additional detail on the signal handling fix.

The specific sequence of events for handling a signal on most
architectures is as follows:

  1) Some code is running when a signal arrives.
  2) The kernel handles the signal and dispatches to the handler.
    ...

However on PowerPC the sequence of events is:

  1) Some code is running when a signal arrives.
  2) The kernel handles the signal and dispatches to the trampoline.
  3) The trampoline performs a normal function call to the handler.
      ...

We want the "nexti" to step into, not over, signal handlers invoked by
the kernel.  This is the case for most platforms as the kernel puts a
signal trampoline frame onto the stack to handle proper return after the
handler.  However, on some platforms such as PowerPC, the kernel actually
uses a trampoline to handle *invocation* of the handler.  We do not
want GDB to stop in the SIGTRAMP_FRAME.  The issue is fixed in function
process_event_stop_test by adding a check that the frame is not a
SIGTRAMP_FRAME to the if statement to stop in a subroutine call.  This
prevents GDB from erroneously detecting the trampoline invocation as a
subroutine call.

This patch fixes two regression test failures in gdb.base/store.exp.

The patch then fixes an exposed, dormant, signal handling issue that
is exposed in the signal handling test gdb.base/sigstep.exp.

The patch has been tested on Power 8 LE/BE, Power 9 LE/BE, Power 10 with
no new regressions.  Note, only two of the five failures in store.exp
are fixed.  The remaining three failures are fixed in a following
patch.

gdb: call update_thread_list after completing an inferior call

I noticed that if GDB is using a remote or extended-remote target,
then, if an inferior call caused a new thread to appear, or for an
existing thread to exit, then these events are not reported to the
user.

The problem is that for these targets GDB relies on a call to
update_thread_list to learn about changes to the inferior's thread
list.

If GDB doesn't pass through the normal stop code then GDB will not
call update_thread_list, and so will not report changes in the thread
list.

This commit adds an additional update_thread_list call, after which
thread events are correctly reported.

gdb: call update_thread_list for $_inferior_thread_count function

I noticed that sometimes the value returned by $_inferior_thread_count
can become out of sync with the actual thread count of the inferior,
and will disagree with the number of threads reported by 'info
threads'.  This commit fixes this issue.

The cause of the problem is that 'info threads' includes a call to
update_thread_list, this can be seen in print_thread_info_1 in
thread.c, while $_inferior_thread_count doesn't include a similar
call, see the function inferior_thread_count_make_value also in
thread.c.

Of course, this is only a problem when GDB is running on a target that
relies on update_thread_list calls to learn about new threads,
e.g. remote or extended-remote targets.  Native targets generally
learn about new threads as soon as they appear and will not have this
problem.

I ran into this issue when writing a test for the next commit which
uses inferior function calls to add an remove threads from an
inferior.  But for testing I've made use of non-stop mode and
asynchronous inferior execution; by reading the inferior state I can
know when a new thread has been created, at which point I can print
$_inferior_thread_count while the inferior is still running.  This is
important, if I stop the inferior then GDB will pass through an
update_thread_list call in the normal stop code, which will
synchronise the thread list, after which $_inferior_thread_count will
report the correct value.

With this change in place $_inferior_thread_count is now correct.

gdb: add a custom command completer for disassemble command

Add a new command completer function for the disassemble command.
There are two things that this completion function changes.  First,
after the previous commit, the new function calls skip_over_slash_fmt,
which means that hitting tab after entering a /OPT flag now inserts a
space ready to start typing the address to disassemble at:

  (gdb) disassemble /r<TAB>
  (gdb) disassemble /r <CURSOR>

But also, we now get symbol completion after a /OPT option set,
previously this would do nothing:

  (gdb) disassemble /r mai<TAB>

But now:

  (gdb) disassemble /r mai<TAB>
  (gdb) disassemble /r main <CURSOR>

Which was my main motivation for working on this commit.

However, I have made a second change in the completion function.
Currently, the disassemble command calls the generic
location_completer function, however, the disassemble docs say:

     Note that the 'disassemble' command's address arguments are specified
  using expressions in your programming language (*note Expressions:
  Expressions.), not location specs (*note Location Specifications::).
  So, for example, if you want to disassemble function 'bar' in file
  'foo.c', you must type 'disassemble 'foo.c'::bar' and not 'disassemble
  foo.c:bar'.

And indeed, if I try:

  (gdb) disassemble hello.c:main
  No symbol "hello" in current context.
  (gdb) disassemble hello.c::main
  No symbol "hello" in current context.
  (gdb) disassemble 'hello.c'::main
  Dump of assembler code for function main:
  ... snip ...

But, if I do this:

  (gdb) disassemble hell<TAB>
  (gdb) disassemble hello.c:<CURSOR>

which is a consequence of using the location_completer function.  So
in this commit, after calling skip_over_slash_fmt, I forward the bulk
of the disassemble command completion to expression_completer.  Now
when I try this:

  (gdb) disassemble hell<TAB>

gives nothing, which I think is an improvement.  There is one slight
disappointment, if I do:

  (gdb) disassemble 'hell<TAB>

I still get nothing.  I had hoped that this would expand to:
'hello.c':: but I guess this is a limitation of the current
expression_completer implementation, however, I don't think this is a
regression, the previous expansion was just wrong.  Fixing
expression_completer is out of scope for this commit.

I've added some disassembler command completion tests, and also a test
that disassembling using 'FILE'::FUNC syntax works, as I don't think
that is tested anywhere.

gdb: make skip_over_slash_fmt available outside printcmd.c

Move the function skip_over_slash_fmt into completer.c, and make it
extern, with a declaration in completer.h.

This is a refactor in order to support the next commit.  I've not
changed any of the code in skip_over_slash_fmt.

There should be no user visible changes after this commit.

gdb: error if /r and /b are used with disassemble command

The disassembler gained a new /b flag in this commit:

  commit d4ce49b7ac077a9882d6a5e689e260300045ca88
  Date:   Tue Jun 21 20:23:35 2022 +0100

      gdb: disassembler opcode display formatting

The /b and /r flags result in the instruction opcodes displayed in
different formats, so it's not possible to have both at the same
time.  Currently the /b flag overrides the /r flag.

We have a similar situation with the /m and /s flags, but here, if the
user tries to use both flags then they will get an error.

I think the error is clearer, so in this commit I propose that we add
an error if /r and /b are both used.

Obviously this change breaks backwards compatibility.  I don't have a
compelling argument for why we should make the change beyond my
feeling that it was a mistake not to add this error from the start,
and that the new behaviour is better.

Reviewed-By: Eli Zaretskii <eliz@gnu.org>

gas: S_GET_{NAME,SEGMENT}() don't alter their input symbol

Make their parameters pointer-to-const, thus allowing callers to also be
const-correct where possible.

ld: print branch fixups into the map file for ppc elf targets

In a safety context, it could interesting to track the trampolines being
generated, ensuring there are expected or not.

bfd/ChangeLog:

* elf32-ppc.c (ppc_elf_relax_section): Log branch fixups.

ld/ChangeLog:

* ld.texi (--print-map): Add new item about fixups.

Add minimal thread-safety to BFD

This patch provides some minimal thread-safety to BFD.

The BFD client can request thread-safety by providing a lock and
unlock function.  The globals used during BFD creation (e.g.,
bfd_id_counter) are then locked, and the file descriptor cache is also
locked.  A function to clean up any thread-local data is now provided
for BFD clients.

* bfd-in2.h: Regenerate.
* bfd.c (lock_fn, unlock_fn): New globals.
(bfd_thread_init, bfd_thread_cleanup, bfd_lock, bfd_unlock): New
functions.
* cache.c (bfd_cache_lookup_worker): Use _bfd_open_file_unlocked.
(cache_btell, cache_bseek, cache_bread, cache_bwrite): Lock
and unlock.
(cache_bclose): Add comment.
(cache_bflush, cache_bstat, cache_bmmap): Lock and unlock.
(_bfd_cache_init_unlocked): New function.
(bfd_cache_init): Use it.  Lock and unlock.
(_bfd_cache_close_unlocked): New function.
(bfd_cache_close, bfd_cache_close_all): Use it.  Lock and unlock.
(_bfd_open_file_unlocked): New function.
(bfd_open_file): Use it.  Lock and unlock.
* doc/bfd.texi (BFD front end): Add Threading menu item.
* libbfd.h: Regenerate.
* opncls.c (_bfd_new_bfd): Lock and unlock.
* po/bfd.pot: Regenerate.

Make various error-related globals thread-local

This changes bfd_error et al to be thread-local.

* Makefile.in: Regenerate.
* aclocal.m4: Include ax_tls.m4.
* ax_tls.m4: New file.
* bfd.c: (bfd_error, input_error, input_bfd, _bfd_error_buf):
Now thread-local.
(bfd_asprintf): Update docs.
* config.in, configure: Regenerate.
* configure.ac: Call AX_TLS.
* po/bfd.pot: Regenerate.

Make _bfd_error_buf static

This makes _bfd_error_buf static and adds a way to clear it.  I felt
that this made the subsequent patches a little cleaner.

* bfd.c (_bfd_error_buf): Now static.
(bfd_set_input_error): Use _bfd_clear_error_data.
(_bfd_clear_error_data): New function.
(bfd_init): Use _bfd_clear_error_data.
* libbfd.h: Regenerate.
* opncls.c (bfd_close_all_done): Use _bfd_clear_error_data.
* po/bfd.pot: Regenerate.

Automatic date update in version.in

aarch64: Add LSE128 instructions

Implement, together with the necessary tests, the following new LSE128
atomic instructions:

  * Atomic bit clear on quadword in memory (ldclrp{a|l|al});
  * Atomic bit set on quadword in memory (ldsetp{a|l|al});
  * Swap quadword in memory (swpp{a|l|al});

gas/ChangeLog:

* testsuite/gas/aarch64/lse128-atomic.d: New.
* testsuite/gas/aarch64/lse128-atomic.s: Likewise.

opcodes/ChangeLog:

* aarch64-tbl.h (ldclrp): new _LSE128_INSN entry.
(ldclrpa):  Likewise.
(ldclrpal): Likewise.
(ldclrpl): Likewise.
(ldsetp): Likewise.
(ldsetpa): Likewise.
(ldsetpal): Likewise.
(ldsetpl): Likewise.
(swpp): Likewise.
(swppa): Likewise.
(swppal): Likewise.
(swppl): Likewise.
* aarch64-asm-2.c: Regenerate.
* aarch64-dis-2.c: Likewise.
* aarch64-opc-2.c: Likewise.

aarch64: Add arch support for LSE128 extension

Enable the `+lse128' feature modifier which, together with new
internal feature flags, enables LSE128 instructions, which are
represented via the new `_LSE128_INSN' macro.

gas/ChangeLog:

* config/tc-aarch64.c (aarch64_features): Add new "lse128"
entry.

include/ChangeLog:

* include/opcode/aarch64.h (enum aarch64_feature_bit): New
AARCH64_FEATURE_LSE128 feature bit.
(enum aarch64_insn_class): New lse128_atomic instruction class.

opcodes/ChangeLog:

* opcodes/aarch64-tbl.h (aarch64_feature_lse128): New.
(LSE128): Likewise.
(_LSE128_INSN): Likewise.

aarch64: Add LSE128 instruction operand support

Given the particular encoding of the LSE128 instructions, create the
necessary shared input+output operand register description and
handling in the code to allow for the encoding of the LSE128 128-bit
atomic operations.

gas/ChangeLog:

* config/tc-aarch64.c (parse_operands):

include/ChangeLog:

* opcode/aarch64.h (enum aarch64_opnd):

opcodes/ChangeLog:

* aarch64-opc.c (fields):
(aarch64_print_operand):
* aarch64-opc.h (enum aarch64_field_kind):
* aarch64-tbl.h (AARCH64_OPERANDS):

aarch64: Add 128-bit system register flags

In preparation for the implementation of 128-bit system register
support across the toolchain, this patch adds the feature flag
F_REG_128 and adds it to relevant system registers in
`aarch64-sys-regs.def'.

Given the shared nature of this file, this change is made necessary
initially to implement argument validation in the `__arm_rsr128' and
`__armwsr128' ACLE intrinsics in GCC, but will be of subsequent use in
the binutils implementation of the corresponding `mrrs' and `msrr'
instructions.

Regression tested on aarch64-linux-gnu, no regressions.

opcodes/ChangeLog:

* aarch64-opc.h (F_REG_128):  New flag.
* aarch64-sys-regs.def (par_el1): Add F_REG_128 flag.
(rcwmask_el1): Likewise.
(rcwsmask_el1): Likewise.
(ttbr0_el1): Likewise.
(ttbr0_el12): Likewise.
(ttbr0_el2): Likewise.
(ttbr1_el1): Likewise.
(ttbr1_el12): Likewise.
(ttbr1_el2): Likewise.
(vttbr_el2): Likewise.

aarch64: Add THE system register support

Add Binutils support for system registers associated with the
Translation Hardening Extension (THE).

In doing so, we also add core feature support for THE, enabling its
associated feature flag and implementing the necessary
feature-checking machinery.

Regression tested on aarch64-linux-gnu, no regressions.

gas/ChangeLog:

* config/tc-aarch64.c (aarch64_features): Add "+the" feature modifier.
* doc/c-aarch64.texi (AArch64 Extensions): Update
documentation for `the' option.
* testsuite/gas/aarch64/sysreg-8.s: Add tests for `the'
associated system registers.
* testsuite/gas/aarch64/sysreg-8.d: Likewise.

include/ChangeLog:

* opcode/aarch64.h (enum aarch64_feature_bit): Add
AARCH64_FEATURE_THE.

opcode/ChangeLog:

* aarch64-opc.c (aarch64_sys_ins_reg_supported_p): Add `the'
system register check support.
* aarch64-sys-regs.def: Add `rcwmask_el1' and `rcwsmask_el1'
* aarch64-tbl.h: Define `THE' preprocessor macro.

gdb/arm: remove thumb bit in arm_adjust_breakpoint_address

When compiling gdb with -fsanitize=address on ARM, I get a crash in test
gdb.arch/arm-disp-step.exp, reproduced easily with:

    $ ./gdb -nx -q --data-directory=data-directory testsuite/outputs/gdb.arch/arm-disp-step/arm-disp-step -ex "break *test_call_end"
    Reading symbols from testsuite/outputs/gdb.arch/arm-disp-step/arm-disp-step...
    =================================================================
    ==23295==ERROR: AddressSanitizer: heap-buffer-overflow on address 0xb4a14fd1 at pc 0x01a48871 bp 0xbeab8490 sp 0xbeab8494

Since it doesn't require running the program, it can be reproduced locally on a
dev machine other than ARM, after acquiring the test binary.

The length of the allocate buffer `buf` is 1, and we try to extract an
integer of size 2 from it.  The length of 1 comes from the subtraction
`bpaddr - boundary`.  Normally, on ARM, all instructions are aligned on
a multiple of 2, so it's weird for this subtraction to result in 1.  In
this case, boundary comes from the result of find_pc_partial_function
returning 0x549:

    (gdb) p/x bpaddr
    $2 = 0x54a
    (gdb) p/x boundary
    $3 = 0x549
    (gdb) p/x bpaddr - boundary
    $4 = 0x1

0x549 is the address of the test_call_subr label, 0x548, with the thumb
bit enabled.  Before doing some math with the address, I think we need
to strip the thumb bit, like is done elsewhere (for instance for bpaddr
earlier in the same function).

I wonder if find_pc_partial_function should do that itself, in order to
return an address that is suitable for arithmetic.  In any case, that
would be a change with a broad impact, so for now just fix the issue
locally.

After the patch:

    $ ./gdb -nx -q --data-directory=data-directory testsuite/outputs/gdb.arch/arm-disp-step/arm-disp-step -ex "break *test_call_end"
    Reading symbols from testsuite/outputs/gdb.arch/arm-disp-step/arm-disp-step...
    Breakpoint 1 at 0x54a: file /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.arch/arm-disp-step.S, line 103.

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

ld/x86: reduce testsuite dependency on system object files

PR ld/30722
Tests looking for certain .note-section recorded properties may not
involve object files from the underlying platform (e.g. via using the C
compiler for linking): Such object files may themselves have similar
note sections, and hence they may influence the overall outcome.

For now convert just the tests known to be affected by crt*.o coming
with "ISA v3 needed" notes. Eventually other tests ought to be
converted, too.

Revert "ld x86_64 tests: Accept x86-64-v3 as a needed ISA"

This reverts commit bf77f42f6708d8b5ba92336d876042826d8d29c1.
It wrongly altered testcase expectations; the issue will need
taking care of differently.

RISC-V: Add support for XCValu extension in CV32E40P

Spec: https://docs.openhwgroup.org/projects/cv32e40p-user-manual/en/latest/instruction_set_extensions.html

Contributors:
  Mary Bennett <mary.bennett@embecosm.com>
  Nandni Jamnadas <nandni.jamnadas@embecosm.com>
  Pietra Ferreira <pietra.ferreira@embecosm.com>
  Charlie Keaney
  Jessica Mills
  Craig Blackmore <craig.blackmore@embecosm.com>
  Simon Cook <simon.cook@embecosm.com>
  Jeremy Bennett <jeremy.bennett@embecosm.com>
  Helene Chelin <helene.chelin@embecosm.com>

bfd/ChangeLog:

* elfxx-riscv.c (riscv_multi_subset_supports): Added `xcvalu`
          instruction class.
(riscv_multi_subset_supports_ext): Likewise.

gas/ChangeLog:

* config/tc-riscv.c (validate_riscv_insn): Added the necessary
          operands for the extension.
(riscv_ip): Likewise.
* doc/c-riscv.texi: Noted XCValu as an additional ISA extension
          for CORE-V.
* testsuite/gas/riscv/cv-alu-boundaries.d: New test.
* testsuite/gas/riscv/cv-alu-boundaries.l: New test.
* testsuite/gas/riscv/cv-alu-boundaries.s: New test.
* testsuite/gas/riscv/cv-alu-fail-march.d: New test.
* testsuite/gas/riscv/cv-alu-fail-march.l: New test.
* testsuite/gas/riscv/cv-alu-fail-march.s: New test.
* testsuite/gas/riscv/cv-alu-fail-operand-01.d: New test.
* testsuite/gas/riscv/cv-alu-fail-operand-01.l: New test.
* testsuite/gas/riscv/cv-alu-fail-operand-01.s: New test.
* testsuite/gas/riscv/cv-alu-fail-operand-02.d: New test.
* testsuite/gas/riscv/cv-alu-fail-operand-02.l: New test.
* testsuite/gas/riscv/cv-alu-fail-operand-02.s: New test.
* testsuite/gas/riscv/cv-alu-fail-operand-03.d: New test.
* testsuite/gas/riscv/cv-alu-fail-operand-03.l: New test.
* testsuite/gas/riscv/cv-alu-fail-operand-03.s: New test.
* testsuite/gas/riscv/cv-alu-fail-operand-04.d: New test.
* testsuite/gas/riscv/cv-alu-fail-operand-04.l: New test.
* testsuite/gas/riscv/cv-alu-fail-operand-04.s: New test.
* testsuite/gas/riscv/cv-alu-fail-operand-05.d: New test.
* testsuite/gas/riscv/cv-alu-fail-operand-05.l: New test.
* testsuite/gas/riscv/cv-alu-fail-operand-05.s: New test.
* testsuite/gas/riscv/cv-alu-fail-operand-06.d: New test.
* testsuite/gas/riscv/cv-alu-fail-operand-06.l: New test.
* testsuite/gas/riscv/cv-alu-fail-operand-06.s: New test.
* testsuite/gas/riscv/cv-alu-fail-operand-07.d: New test.
* testsuite/gas/riscv/cv-alu-fail-operand-07.l: New test.
* testsuite/gas/riscv/cv-alu-fail-operand-07.s: New test.
* testsuite/gas/riscv/cv-alu-insns.d: New test.
* testsuite/gas/riscv/cv-alu-insns.s: New test.

opcodes/ChangeLog:

* riscv-dis.c (print_insn_args): Disassemble xcb operand.
* riscv-opc.c: Defined the MASK and added XCValu instructions.

include/ChangeLog:

* opcode/riscv-opc.h: Added corresponding MATCH and MASK macros
          for XCValu.
* opcode/riscv.h: Added corresponding EXTRACT and ENCODE macros
          for XCValu.
(enum riscv_insn_class): Added the XCValu instruction class.

RISC-V: Add support for XCVmac extension in CV32E40P

Spec: https://docs.openhwgroup.org/projects/cv32e40p-user-manual/en/latest/instruction_set_extensions.html

Contributors:
  Mary Bennett <mary.bennett@embecosm.com>
  Nandni Jamnadas <nandni.jamnadas@embecosm.com>
  Pietra Ferreira <pietra.ferreira@embecosm.com>
  Charlie Keaney
  Jessica Mills
  Craig Blackmore <craig.blackmore@embecosm.com>
  Simon Cook <simon.cook@embecosm.com>
  Jeremy Bennett <jeremy.bennett@embecosm.com>
  Helene Chelin <helene.chelin@embecosm.com>

bfd/ChangeLog:

* elfxx-riscv.c (riscv_multi_subset_supports): Added `xcvmac`
          instruction class.
(riscv_multi_subset_supports_ext): Likewise.

gas/ChangeLog:

* config/tc-riscv.c (validate_riscv_insn): Added the necessary
          operands for the extension.
(riscv_ip): Likewise.
* doc/c-riscv.texi: Noted XCVmac as an additional ISA extension
          for CORE-V.
* testsuite/gas/riscv/cv-mac-fail-march.d: New test.
* testsuite/gas/riscv/cv-mac-fail-march.l: New test.
* testsuite/gas/riscv/cv-mac-fail-march.s: New test.
* testsuite/gas/riscv/cv-mac-fail-operand.d: New test.
* testsuite/gas/riscv/cv-mac-fail-operand.l: New test.
* testsuite/gas/riscv/cv-mac-fail-operand.s: New test.
* testsuite/gas/riscv/cv-mac-insns.d: New test.
* testsuite/gas/riscv/cv-mac-insns.s: New test.

opcodes/ChangeLog:

* riscv-dis.c (print_insn_args): Disassemble information with
          the EXTRACT macro implemented.
* riscv-opc.c: Defined the MASK and added
          XCVmac instructions.

include/ChangeLog:

* opcode/riscv-opc.h: Added corresponding MATCH and MASK macros
          for XCVmac.
* opcode/riscv.h: Added corresponding EXTRACT and ENCODE macros
          for uimm.
(enum riscv_insn_class): Added the XCVmac instruction class.

Remove EXTERN_C and related defines

common-defs.h has a few defines that I suspect were used during the
transition to C++.  These aren't needed any more, so remove them.

Tested by rebuilding.

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

Automatic date update in version.in

gdb: Update email address for Carl Love in gdb/MAINTAINERS

Fix resizing of TUI python windows

When resizing from a big to small terminal size, and you have a
TUI python window that would then be outside of the new size,
valgrind shows this error:

==3389== Invalid read of size 1
==3389==    at 0xC3DFEE: wnoutrefresh (lib_refresh.c:167)
==3389==    by 0xC3E3C9: wrefresh (lib_refresh.c:63)
==3389==    by 0xA9766C: tui_unhighlight_win(tui_win_info*) (tui-wingeneral.c:134)
==3389==    by 0x98921C: tui_py_window::rerender() (py-tui.c:183)
==3389==    by 0xA8C23C: tui_layout_split::apply(int, int, int, int, bool) (tui-layout.c:1030)
==3389==    by 0xA8C2A2: tui_layout_split::apply(int, int, int, int, bool) (tui-layout.c:1033)
==3389==    by 0xA8C23C: tui_layout_split::apply(int, int, int, int, bool) (tui-layout.c:1030)
==3389==    by 0xA8B1F8: tui_apply_current_layout(bool) (tui-layout.c:81)
==3389==    by 0xA95CDB: tui_resize_all() (tui-win.c:525)
==3389==    by 0xA95D1E: tui_async_resize_screen(void*) (tui-win.c:562)
==3389==    by 0x6B855D: invoke_async_signal_handlers() (async-event.c:234)
==3389==    by 0xC0CEF8: gdb_do_one_event(int) (event-loop.cc:199)
==3389==  Address 0x115cc214 is 1,332 bytes inside a block of size 2,240 free'd
==3389==    at 0x4A0A430: free (vg_replace_malloc.c:446)
==3389==    by 0xC3CF7D: _nc_freewin (lib_newwin.c:121)
==3389==    by 0xA8B1C6: tui_apply_current_layout(bool) (tui-layout.c:78)
==3389==    by 0xA95CDB: tui_resize_all() (tui-win.c:525)
==3389==    by 0xA95D1E: tui_async_resize_screen(void*) (tui-win.c:562)
==3389==    by 0x6B855D: invoke_async_signal_handlers() (async-event.c:234)
==3389==    by 0xC0CEF8: gdb_do_one_event(int) (event-loop.cc:199)
==3389==    by 0x8E40E9: captured_command_loop() (main.c:407)
==3389==    by 0x8E5E54: gdb_main(captured_main_args*) (main.c:1324)
==3389==    by 0x62AC04: main (gdb.c:39)

It's because tui_py_window::m_inner_window still has the outside
coordinates, and wnoutrefresh then does an out-of-bounds access.

Fix this by resetting m_inner_window on every resize, it will anyways
be recreated in the next rerender call.

Approved-By: Andrew Burgess <aburgess@redhat.com>

Change gdb.base/examine-backwards.exp for AIX.

In AIX unused or constant variables are collected as garbage by the linker and in the dwarf dump
an address with all f's in hexadecimal are assigned. Hence the testcase fails with many failures stating
it cannot access memory.

This patch is a small change to get it working in AIX as well.

ld: =fillexp different behaviors for hexidecimal literal

  PR 30865
  * ld.texi: Update description of the FILL command.
  * testsuite/ld-scripts/fill2.d: New test.
  * testsuite/ld-scripts/fill2.t: New test source.
  * testsuite/ld-scripts/data.exp: Run the new test.

RISC-V: Make sure rv32q conflict won't affect the fp-q-insns-32 gas testcase.

Same as commit 4352c0ac04a.

gas/
* testsuite/gas/riscv/fp-q-insns-32.d: Set q to v2.2.

RISC-V: Moved out linker internal relocations after R_RISCV_max.

Just the lightest modifications about this, without any further checks and
considering --emit-relocs.  We will need to improve it in the future, but
first do this to avoid conflicts between linker internal relocations and the
new definition of psabi.  For example, TLSDESC relocs.

Passed riscv-gnu-toolchain regressions, so should be safe enough to commit.

Co-authored-by: Tsukasa OI <research_trasio@irq.a4lg.com>
bfd/
* reloc.c: Removed linker internal relocations.
* bfd-in2.h: Regenerated.
* libbfd.h: Regenerated.
* elfnn-riscv.c: Defined R_RISCV_DELETE in include/elf/riscv.h.
* elfxx-riscv.c (howto_table, howto_table_internal): Moved linker
internal relocations from howto_table into howto_table_internal.
(riscv_reloc_map): Removed linker internal relocations mapping.
(riscv_elf_rtype_to_howto): Return howto of linker internal
relocations from howto_table_internal.
include/
* elf/riscv.h: Defined linker internal relocations after R_RISCV_max.

[gdb/testsuite] Fix gdb.dwarf2/dw2-gas-workaround.exp

Recently added test-case gdb.dwarf2/dw2-gas-workaround.exp:
- passes when gdb is configured using $(cd ../src; pwd)/configure, but
- fails when using ../src/configure.

Fix this by making the matching more precise:
...
-    -re -wrap "$objdir.*" {
+    -re -wrap "name_for_id = $objdir/$srcfile\r\n.*" {
...
such that we only fail on the line:
...
[symtab-create] start_subfile: name = dw2-lines.c, name_for_id = \
  /data/vries/gdb/leap-15-4/build/gdb/testsuite/dw2-lines.c^M
...

Reported-By: Carl Love <cel@us.ibm.com>

Automatic date update in version.in

Pre-read DWZ file in DWARF reader

While working on background reading of DWARF, I came across the
DWZ-reading code.  This code can query the user (via the debuginfod
support) -- something that cannot be done off the main thread.

Looking into it, I realized that this code can be run much earlier,
avoiding this problem.  Digging a bit deeper, I also found a
discrepancy here between how the DWARF reader works in "readnow" mode
as compared to the normal modes.

This patch cleans this up by trying to read the DWZ file earlier, and
also by having the DWARF reader convert any exception here into a
warning.  This unifies the various cases, but also makes it so that
errors do not prevent gdb from continuing on to the extent possible.

Regression tested on x86-64 Fedora 38.

Automatic date update in version.in

Automatic date update in version.in

Remove unused declaration

I found a declaration in py-stopevent.h for which there is no
definition.  This patch removes it.

gdbsupport: mark array_view::slice with [[nodiscard]]

I (almost) had a bug where I did:

    buffer.slice (...)

but I meant:

    buffer = buffer.slice (...)

The first one does nothing, it creates a new array_view but without
using it, it's useless.  Mark the slice methods with [[nodiscard]]
(which is standard C++17) so that error would generate a warning.

I guess that many functions could be marked as nodiscard, essentially
function that is pure (doesn't have side-effects).  But this one seems
particularly easy to mis-use.

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

gdbsupport: record and print failed selftest names

Since "maint selftest" now runs quite a lot of tests (especially in an
all-targets build), I thought it would be useful to print a summary at
the end of what failed.  So, implement that.

Print the summary before the "Ran %d unit tests, %zu failed\n" line, so
that that one remains the last line, and the gdb.gdb/unittest.exp
doesn't need to be changed.

The output looks like (if I force a failure in a test):

    (gdb) maint selftest
    ...
    Running selftest value_copy.
    Running selftest xml_escape_text.
    Running selftest xml_escape_text_append.

    Failures:
      aarch64-analyze-prologue

    Ran 4134 unit tests, 1 failed
    (gdb)

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

gas: correct ignoring of C-style number suffixes

First of all the respective original changes didn't deal with just 0
having such a suffix - this needs additional logic outside of
integer_constant(). Further bogus suffixes having more than two L-s
were accepted, while valid suffixes with U following the L(s) weren't.
Finally respective tests were introduced for Sparc only.

Reviewed-by: Neal Frager <neal.frager@amd.com>

RISC-V: reduce redundancy in load/store macro insn handling

Within the groups L{B,BU,H,HU,W,WU,D}, S{B,H,W,D}, FL{H,W,D,Q}, and
FS{H,W,D,Q} the sole difference between the handling is the insn
mnemonic passed to the common handling functions. The intended mnemonic,
however, can easily be retrieved. Furthermore leverags that Sx and FSx
are then handled identically, too, and hence their cases can also be
folded.

RISC-V: Lx/Sx macro insn tests

Make sure these (continue to) work as intended.

RISC-V: add F- and D-extension testcases

Make sure future changes won't regress any of this. Also cover the FLH
and FSH macro insns of the Zfh extension.

RISC-V: make FLQ/FSQ macro-insns work

When support for the Q extension was added, the libopcodes side of these
macro-insns was properly covered, but no backing support in gas was
added. In new testcases cover not just these, but all Q-extension insns.

Automatic date update in version.in

[gdb/tdep] Fix nr array elements in ppc64_aggregate_candidate

On AlmaLinux 9.2 powerpc64le I run into:
...
(gdb) PASS: gdb.ada/array_return.exp: continuing to Create_Small_Float_Vector
finish^M
Run till exit from #0  pck.create_small_float_vector () at pck.adb:30^M
0x00000000100022d4 in p () at p.adb:25^M
25         Vector := Create_Small_Float_Vector;^M
Value returned is $3 = (2.80259693e-45, 2.80259693e-45)^M
(gdb) FAIL: gdb.ada/array_return.exp: value printed by finish of Create_Small_Float_Vector
...
while this is expected:
...
Value returned is $3 = (4.25, 4.25)^M
...

The problem is here in ppc64_aggregate_candidate:
...
  if (!get_array_bounds (type, &low_bound, &high_bound))
    return -1;
  count *= high_bound - low_bound
...

The array type (containing 2 elements) is:
...
   type Small_Float_Vector is array (1 .. 2) of Float;
...
so we have:
...
(gdb) p low_bound
$1 = 1
(gdb) p high_bound
$2 = 2
...
but we calculate the number of elements in the array using
"high_bound - low_bound", which is 1.

Consequently, gdb fails to correctly classify the type as a ELFv2 homogeneous
aggregate.

Fix this by calculating the number of elements in the array by using
"high_bound - low_bound + 1" instead.

Furthermore, high_bound can (in general, though perhaps not here) also be
smaller than low_bound, so to be safe take that into account as well:
...
  LONGEST nr_array_elements = (low_bound > high_bound
       ? 0
       : (high_bound - low_bound + 1));
  count *= nr_array_elements;
...

Tested on powerpc64le-linux.

Approved-By: Ulrich Weigand <uweigand@de.ibm.com>
PR tdep/31015
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31015

aarch64: Add GCS system registers.

This patch adds support for 10 new AArch64 system registers
(gcscre0_el1, gcscr_el1, gcscr_el12, gcscr_el2, gcscr_el3,
gcspr_el0, gcspr_el1 ,gcspr_el12, gcspr_el2 and gcspr_el3),
which are enabled on using Guarded Control Stack (+gcs flag)
feature.

aarch64: Add support for GCSB DSYNC instruction.

This patch adds support for Guarded control stack data synchronization
instruction (GCSB DSYNC). This instruction is allocated to existing
HINT space and uses the HINT number 19 and to match this an entry is
added to the aarch64_hint_options array.

aarch64: Add support for GCS extension.

This patch adds for Guarded Control Stack Extension (GCS) extension. GCS feature is
optional from Armv9.4-A architecture and enabled by passing +gcs option to -march
(eg: -march=armv9.4-a+gcs) or using ".arch_extension gcs" directive in the assembly file.

Also this patch adds support for GCS instructions gcspushx, gcspopcx, gcspopx,
gcsss1, gcsss2, gcspushm, gcspopm, gcsstr and gcssttr.

aarch64: Add support for Check Feature Status Extension.

This patch adds support for Check Feature Status Extension (CHK) which
is mandatory from Armv8.0-A. Also this patch supports "chkfeat" instruction
(hint #40).

aarch64: Add support for Armv8.9-A and Armv9.4-A Architectures.

This patch adds AArch64 support for Armv8.9-A architecture (-march=armv8.9-a)
and Armv9.4-A architecture (-march=armv9.4-a).

ld x86_64 tests: Accept x86-64-v3 as a needed ISA

  * testsuite/ld-x86-64/property-3.r: Update regexp to allow for targets which support x86-64-v3.
  * testsuite/ld-x86-64/property-4.r: Likewise.
  * testsuite/ld-x86-64/property-5.r: Likewise.

gprofng: remove dependency on help2man

help2man is no longer used to create the gprofng man pages.

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

* configure.ac: Remove HELP2MAN.
* Makefile.in: Rebuild.
* configure: Rebuild.
* doc/Makefile.in: Rebuild.
* gp-display-html/Makefile.in: Rebuild.
* src/Makefile.in: Rebuild.

Automatic date update in version.in

gdb: use gdb::byte_vector instead of gdb::def_vector<gdb_byte>

Use the gdb::byte_vector typedef when possible.

Change-Id: Ib2199201c052496992011ea02979de023d4d8a9a

Fix typo in recent update to the ld/NEWS file