RISC-V: Removed the v0.93 bitmanip ZBA/ZBB/ZBC instructions.

bfd/
    * elfxx-riscv.c (riscv_parse_prefixed_ext): Removed zb*.
gas/
    * config/tc-riscv.c (riscv_multi_subset_supports): Removed
    INSN_CLASS_ZB*.
    * testsuite/gas/riscv/bitmanip-insns-32.d: Removed.
    * testsuite/gas/riscv/bitmanip-insns-64.d: Removed.
    * testsuite/gas/riscv/bitmanip-insns.s: Removed.
include/
    * opcode/riscv-opc.h: Removed macros for zb* extensions.
    * opcode/riscv.h (riscv_insn_class): Removed INSN_CLASS_ZB*.
opcodes/
    * riscv-opc.c (MASK_RVB_IMM): Removed.
    (riscv_opcodes): Removed zb* instructions.
    (riscv_ext_version_table): Removed versions for zb*.

PR27311, (symbol from plugin): undefined reference, hidden sym

bfd/
PR 27311
* elflink.c (elf_link_add_object_symbols): Don't pull in as-needed
libraries for IR references on pass over libraries after LTO
recompilation.
ld/
* testsuite/ld-plugin/pr27311d.c: New test.
* testsuite/ld-plugin/lto.exp: Rename pr27311 to pr27311-1, compile
and link new test as pr27311-2.

Automatic date update in version.in

gdb: infrun: move stop_soon variable to inner scoped in handle_inferior_event

Moving it to an inner scope makes it clearer where it's used (only while
handling the TARGET_WAITKIND_LOADED event).

gdb/ChangeLog:

* infrun.c (handle_inferior_event): Move stop_soon variable to
inner scope.

Change-Id: Ic57685a21714cfbb38f1487ee96cea1d12b44652

IBM Z: Add missing vector formats to .insn docs

gas/

* doc/c-s390.texi: Document vector instruction formats.

Re: PR27311, ld.bfd (symbol from plugin): undefined reference

This does exactly the same as making decisions based on an override
in _bfd_elf_add_default_symbol, and is simpler.

PR 27311
* elflink.c (_bfd_elf_add_default_symbol): Revert last two changes.
(elf_link_add_object_symbols): Here too.  Don't pull in as-needed
libraries when H is an indirect symbol after calling
_bfd_elf_add_default_symbol.

pr27270 and pr27284, ar segfaults and wrong file mode

PR 27270
PR 27284
PR 26945
* ar.c: Don't include libbfd.h.
(write_archive): Replace xmalloc+strcpy with xstrdup.  Use
bfd_stat rather than fstat on iostream.  Move stat and fd tests
outside of _WIN32 ifdef.  Delete skip_stat variable.
* arsup.c (temp_name, real_ofd): New static variables.
(ar_open): Use make_tempname and bfd_fdopenw.
(ar_save): Adjust to suit ar_open changes.  Move stat output
of _WIN32 ifdef.
* objcopy.c: Don't include libbfd.h.
(copy_file): Use bfd_stat.

PR27311 again, ld.bfd (symbol from plugin): undefined reference

bfd/
PR 27311
* elflink.c (_bfd_elf_add_default_symbol): Clear override when
undecorated symbol will have a different version.
ld/
* testsuite/ld-ifunc/ifunc.exp (libpr16467b.so, libpr16467bn.so):
Link with --as-needed.

Testcase for detaching while stepping over breakpoint

This adds a testcase that exercises detaching while GDB is stepping
over a breakpoint, in all combinations of:

  - maint target non-stop off/on
  - set non-stop on/off
  - displaced stepping on/off

This exercises the bugs fixed in the previous 8 patches.

gdb/testsuite/ChangeLog:

* gdb.threads/detach-step-over.c: New file.
* gdb.threads/detach-step-over.exp: New file.

detach in all-stop with threads running

A following patch will add a testcase that has a number of threads
constantly stepping over a breakpoint, and then has GDB detach the
process, while threads are running.  If we have more than one inferior
running, and we detach from just one of the inferiors, we expect that
the remaining inferior continues running.  However, in all-stop, if
GDB needs to pause the target for the detach, nothing is re-resuming
the other inferiors after the detach.  "info threads" shows the
threads as running, but they really aren't.  This fixes it.

gdb/ChangeLog:

* infcmd.c (detach_command): Hold strong reference to target, and
if all-stop on entry, restart threads on exit.
* infrun.c (switch_back_to_stepped_thread): Factor out bits to ...
(restart_stepped_thread): ... this new function.  Also handle
trap_expected.
(restart_after_all_stop_detach): New function.
* infrun.h (restart_after_all_stop_detach): Declare.

detach with in-line step over in progress

A following patch will add a testcase that has a number of threads
constantly stepping over a breakpoint, and then has GDB detach the
process.  That testcase exercises both "set displaced-stepping
on/off".  Testing with "set displaced-stepping off" reveals that GDB
does not handle the case of the user typing "detach" just while some
thread is in the middle of an in-line step over.  If that thread
belongs to the inferior that is being detached, then the step-over
never finishes, and threads of other inferiors are never re-resumed.
This fixes it.

gdb/ChangeLog:

* infrun.c (struct step_over_info): Initialize fields.
(prepare_for_detach): Handle ongoing in-line step over.

detach and breakpoint removal

A following patch will add a testcase that has a number of threads
constantly stepping over a breakpoint, and then has GDB detach the
process.  That testcase sometimes fails with the inferior crashing
with SIGTRAP after the detach because of the bug fixed by this patch,
when tested with the native target.

The problem is that target_detach removes breakpoints from the target
immediately, and that does not work with the native GNU/Linux target
(and probably no other native target) currently.  The test wouldn't
fail with this issue when testing against gdbserver, because gdbserver
does allow accessing memory while the current thread is running, by
transparently pausing all threads temporarily, without GDB noticing.
Implementing that in gdbserver was a lot of work, so I'm not looking
forward right now to do the same in the native target.  Instead, I
came up with a simpler solution -- push the breakpoints removal down
to the targets.  The Linux target conveniently already pauses all
threads before detaching them, since PTRACE_DETACH only works with
stopped threads, so we move removing breakpoints to after that.  Only
the remote and GNU/Linux targets support support async execution, so
no other target should really need this.

gdb/ChangeLog:

* linux-nat.c (linux_nat_target::detach): Remove breakpoints
here...
* remote.c (remote_target::remote_detach_1): ... and here ...
* target.c (target_detach): ... instead of here.
* target.h (target_ops::detach): Add comment.

prepare_for_detach and ongoing displaced stepping

I noticed that "detach" while a program was running sometimes resulted
in the process crashing.  I tracked it down to this change to
prepare_for_detach in commit 187b041e ("gdb: move displaced stepping
logic to gdbarch, allow starting concurrent displaced steps"):

    /* Is any thread of this process displaced stepping?  If not,
       there's nothing else to do.  */
 -  if (displaced->step_thread == nullptr)
 +  if (displaced_step_in_progress (inf))
      return;

The problem above is that the condition was inadvertently flipped.  It
should have been:

   if (!displaced_step_in_progress (inf))

So I fixed it, and wrote a testcase to exercise it.  The testcase has
a number of threads constantly stepping over a breakpoint, and then
GDB detaches the process, while threads are running and stepping over
the breakpoint.  And then I was surprised that my testcase would hang
-- GDB would get stuck in an infinite loop in prepare_for_detach,
here:

  while (displaced_step_in_progress (inf))
    {
      ...

What is going on is that since we now have two displaced stepping
buffers, as one displaced step finishes, GDB starts another, and
there's another one already in progress, and on and on, so the
displaced_step_in_progress condition never turns false.  This happens
because we go via the whole handle_inferior_event, which tries to
start new step overs when one finishes.  And also because while we
remove breakpoints from the target before prepare_for_detach is
called, handle_inferior_event ends up calling insert_breakpoints via
e.g. keep_going.

Thinking through all this, I came to the conclusion that going through
the whole handle_inferior_event isn't ideal.  A _lot_ is done by that
function, e.g., some thread may get a signal which is passed to the
inferior, and gdb decides to try to get over the signal handler, which
reinstalls breakpoints.  Or some process may exit.  We can end up
reporting these events via normal_stop while detaching, maybe end up
running some breakpoint commands, or maybe even something runs an
inferior function call.  Etc.  All this after the user has already
declared they don't want to debug the process anymore, by asking to
detach.

I came to the conclusion that it's better to do the minimal amount of
work possible, in a more controlled fashion, without going through
handle_inferior_event.  So in the new approach implemented by this
patch, if there are threads of the inferior that we're detaching in
the middle of a displaced step, stop them, and cancel the displaced
step.  This is basically what stop_all_threads already does, via
wait_one and (the now factored out) handle_one, so I'm reusing those.

gdb/ChangeLog:

* infrun.c (struct wait_one_event): Move higher up.
(prepare_for_detach): Abort in-progress displaced steps instead of
letting them complete.
(handle_one): If the inferior is detaching, don't add the thread
back to the global step-over chain.
(restart_threads): Don't restart threads if detaching.
(handle_signal_stop): Remove inferior::detaching reference.

prepare_for_detach: don't release scoped_restore at the end

After detaching from a process, the inf->detaching flag is
inadvertently left set to true.  If you afterwards reuse the same
inferior to start a new process, GDB will mishave...

The problem is that prepare_for_detach discards the scoped_restore at
the end, while the intention is for the flag to be set only for the
duration of prepare_for_detach.

This was already a bug in the original commit that added
prepare_for_detach, commit 24291992dac3 ("PR gdb/11321"), by yours
truly.  Back then, we still used cleanups, and the function called
discard_cleanups instead of do_cleanups, by mistake.

gdb/ChangeLog:

* infrun.c (prepare_for_detach): Don't release scoped_restore
before returning.

Factor out after-stop event handling code from stop_all_threads

This moves the code handling an event out of wait_one to a separate
function, to be used in another context in a following patch.

gdb/ChangeLog:

* infrun.c (handle_one): New function, factored out from ...
(stop_all_threads): ... here.

gdbserver: spurious SIGTRAP w/ detach while step-over in progress

A following patch will add a new testcase that has two processes, each
with a number of threads constantly tripping a breakpoint and stepping
over it, because the breakpoint has a condition that evals false.
Then GDB detaches from one of the processes, while both processes are
running.  And then the testcase sends a SIGUSR1 to the other process.

When run against gdbserver, that would occasionaly fail like this:

 (gdb) PASS: gdb.threads/detach-step-over.exp: iter 1: detach
 Executing on target: kill -SIGUSR1 208303    (timeout = 300)
 spawn -ignore SIGHUP kill -SIGUSR1 208303

 Thread 2.5 "detach-step-ove" received signal SIGTRAP, Trace/breakpoint trap.
 [Switching to Thread 208303.208305]
 0x000055555555522a in thread_func (arg=0x0) at /home/pedro/gdb/binutils-gdb/src/gdb/testsuite/gdb.threads/detach-step-over.c:54
 54            counter++; /* Set breakpoint here.  */

What happened was that GDBserver is doing a step-over for process A
when a detach request for process B arrives.  And that generates a
spurious SIGTRAP report for process A, as seen above.

The GDBserver logs reveal what happened:

 - GDB manages to detach while a step over is in progress.  That reaches
   linux_process_target::complete_ongoing_step_over(), which does:

      /* Passing NULL_PTID as filter indicates we want all events to
 be left pending.  Eventually this returns when there are no
 unwaited-for children left.  */
      ret = wait_for_event_filtered (minus_one_ptid, null_ptid, &wstat,
     __WALL);

   As the comment say, this leaves all events pending, _including_ the
   just finished step SIGTRAP.  We never discard that SIGTRAP.  So
   GDBserver reports the SIGTRAP to GDB.  GDB can't explain the
   SIGTRAP, so it reports it to the user.

The GDBserver log looks like this.  The LWP of interest is 208305:

 Need step over [LWP 208305]? yes, found breakpoint at 0x555555555227
 proceed_all_lwps: found thread 208305 needing a step-over
 Starting step-over on LWP 208305.  Stopping all threads

208305 starts a step-over.

 >>>> entering void linux_process_target::stop_all_lwps(int, lwp_info*)
 stop_all_lwps (stop-and-suspend, except=LWP 208303.208305)
 Sending sigstop to lwp 208303
 Sending sigstop to lwp 207755
 wait_for_sigstop: pulling events
 LWFE: waitpid(-1, ...) returned 207755, ERRNO-OK
 LLW: waitpid 207755 received Stopped (signal) (stopped)
 pc is 0x7f7e045593bf
 Expected stop.
 LLW: SIGSTOP caught for LWP 207755.207755 while stopping threads.
 LWFE: waitpid(-1, ...) returned 208303, ERRNO-OK
 LLW: waitpid 208303 received Stopped (signal) (stopped)
 pc is 0x7ffff7e743bf
 Expected stop.
 LLW: SIGSTOP caught for LWP 208303.208303 while stopping threads.
 LWFE: waitpid(-1, ...) returned 0, ERRNO-OK
 leader_pid=208303, leader_lp!=NULL=1, num_lwps=11, zombie=0
 leader_pid=207755, leader_lp!=NULL=1, num_lwps=11, zombie=0
 LLW: exit (no unwaited-for LWP)
 stop_all_lwps done, setting stopping_threads back to !stopping
 <<<< exiting void linux_process_target::stop_all_lwps(int, lwp_info*)
 Done stopping all threads for step-over.
 pc is 0x555555555227
 Writing 8b to 0x555555555227 in process 208305
 Could not findsigchld_handler
  fast tracepoint jump at 0x555555555227 in list (uninserting).
   pending reinsert at 0x555555555227
   step from pc 0x555555555227
 Resuming lwp 208305 (step, signal 0, stop expected)
 <<<< exiting ptid_t linux_process_target::wait_1(ptid_t, target_waitstatus*, target_wait_flags)
 handling possible serial event
 getpkt ("D;32b8b");  [no ack sent]

The detach request arrives.

 sigchld_handler
 Tracing is already off, ignoring
 detach: step over in progress, finish it first

GDBserver realizes a step over for 208305 was in progress, let's it
finish.

 LWFE: waitpid(-1, ...) returned 208305, ERRNO-OK
 LLW: waitpid 208305 received Stopped (signal) (stopped)
 pc is 0x555555555227
 Expected stop.
 LLW: step LWP 208303.208305, 0, 0 (discard delayed SIGSTOP)
   pending reinsert at 0x555555555227
   step from pc 0x555555555227
 Resuming lwp 208305 (step, signal 0, stop not expected)
 LWFE: waitpid(-1, ...) returned 0, ERRNO-OK
 leader_pid=208303, leader_lp!=NULL=1, num_lwps=11, zombie=0
 leader_pid=207755, leader_lp!=NULL=1, num_lwps=11, zombie=0
 sigsuspend'ing
 LWFE: waitpid(-1, ...) returned 208305, ERRNO-OK
 LLW: waitpid 208305 received Trace/breakpoint trap (stopped)
 pc is 0x55555555522a
 CSBB: LWP 208303.208305 stopped by trace
 LWFE: waitpid(-1, ...) returned 0, ERRNO-OK
 leader_pid=208303, leader_lp!=NULL=1, num_lwps=11, zombie=0
 leader_pid=207755, leader_lp!=NULL=1, num_lwps=11, zombie=0
 LLW: exit (no unwaited-for LWP)
 Finished step over.

The step-over for 208305 finishes.

 Writing cc to 0x555555555227 in process 208305
 Could not find fast tracepoint jump at 0x555555555227 in list (reinserting).
 >>>> entering void linux_process_target::stop_all_lwps(int, lwp_info*)
 stop_all_lwps (stop, except=none)
 wait_for_sigstop: pulling events

The detach proceeds (snipped).

...

 proceed_one_lwp: lwp 208305
    LWP 208305 has pending status, leaving stopped

Later on, 208305 has a pending status (the step SIGTRAP from the
step-over), so GDBserver starts the process of reporting it.

...

 wait_1 ret = LWP 208303.208305, 1, 5
 <<<< exiting ptid_t linux_process_target::wait_1(ptid_t, target_waitstatus*, target_wait_flags)

...

and eventually GDB receives the stop notification (T05 == SIGTRAP):

 getpkt ("vStopped");  [no ack sent]
 sigchld_handler
 vStopped: acking 3
 Writing resume reply for LWP 208303.208305:1
 putpkt ("$T0506:f0ee58f7ff7f0* ;07:f0ee58f7ff7f0* ;10:2a525*"550* ;thread:p32daf.32db1;core:c;#37"); [noack mode]

From the GDB side, we see:

 [infrun] fetch_inferior_event: enter
   [infrun] fetch_inferior_event: fetch_inferior_event enter
   [infrun] do_target_wait: Found 2 inferiors, starting at #1
   [infrun] print_target_wait_results: target_wait (-1.0.0 [process -1], status) =
   [infrun] print_target_wait_results:   208303.208305.0 [Thread 208303.208305],
   [infrun] print_target_wait_results:   status->kind = stopped, signal = GDB_SIGNAL_TRAP
   [infrun] handle_inferior_event: status->kind = stopped, signal = GDB_SIGNAL_TRAP
   [infrun] start_step_over: enter
     [infrun] start_step_over: stealing global queue of threads to step, length = 6
     [infrun] operator(): putting back 6 threads to step in global queue
   [infrun] start_step_over: exit
   [infrun] handle_signal_stop: context switch
   [infrun] context_switch: Switching context from process 0 to Thread 208303.208305
   [infrun] handle_signal_stop: stop_pc=0x55555555522a
   [infrun] handle_signal_stop: random signal (GDB_SIGNAL_TRAP)
   [infrun] stop_waiting: stop_waiting
   [infrun] stop_all_threads: starting

The fix is to discard the step SIGTRAP, unless GDB wanted the thread
to step.

gdbserver/ChangeLog:

* linux-low.cc (linux_process_target::complete_ongoing_step_over):
Discard step SIGTRAP, unless GDB wanted the thread to step.

Fix a couple vStopped pending ack bugs

A following patch will add a testcase that has two processes with
threads stepping over a breakpoint continuously, and then detaches
from one of the processes while threads are running.  The other
process continues stepping over its breakpoint.  And then the testcase
sends a SIGUSR1, expecting that GDB reports it.  That would sometimes
hang against gdbserver, due to the bugs fixed here.  Both bugs are
related, in that they're about remote protocol asynchronous Stop
notifications.  There's a bug in GDB, and another in GDBserver.

The GDB bug:

- when we detach from a process, the remote target discards any
  pending RSP notification related to that process, including the
  in-flight, yet-unacked notification.  Discarding the in-flight
  notification is the problem.  Until the in-flight notification is
  acked with a vStopped packet, the server won't send another %Stop
  notification.  As a result, the debug session gets messed up.  In
  the new testcase's case, GDB would hang inside stop_all_threads,
  waiting for a stop for one of the process'es threads, which never
  arrived -- its stop reply was permanently stuck in the stop reply
  queue, waiting for a vStopped packet that never arrived.

  In summary:

   1. GDBserver sends stop notification about thread X, the remote
      target receives it and stores it
   2. At the same time, GDB detaches thread X's inferior
   3. The remote target discards the received stop notification
   4. GDBserver waits forever for the ack

The GDBserver bug:

  GDBserver has the opposite bug.  It also discards notifications for
  the process being detached.  If that discards the head of the
  notification queue, when gdb sends an ack, it ends up acking the
  _next_ notification.  Meaning, gdb loses one notification.  In the
  testcase, this results in a similar hang in stop_all_threads.

So we have two very similar bugs in GDB and GDBserver, both resulting
in a similar symptom.  That's why I'm fixing them both at the same
time.

gdb/ChangeLog:

* remote.c (remote_notif_stop_ack): Don't error out on
TARGET_WAITKIND_IGNORE; instead, just ignore the notification.
(remote_target::discard_pending_stop_replies): Don't delete
in-flight notification; instead, clear its contents.

gdbserver/ChangeLog:

* server.cc (discard_queued_stop_replies): Don't ever discard the
notification at the head of the list.

Testcase for attaching in non-stop mode

This adds a testcase exercising attaching to a multi-threaded process,
in all combinations of:

  - set non-stop on/off
  - maint target non-stop off/on
  - "attach" vs "attach &"

This exercises the bugs fixed in the two previous patches.

gdb/testsuite/ChangeLog:

* gdb.threads/attach-non-stop.c: New file.
* gdb.threads/attach-non-stop.exp: New file.

Fix "target extended-remote" + "maint set target-non-stop" + "attach"

With "target extended-remote" + "maint set target-non-stop", attaching
hangs like so:

 (gdb) attach 1244450
 Attaching to process 1244450
 [New Thread 1244450.1244450]
 [New Thread 1244450.1244453]
 [New Thread 1244450.1244454]
 [New Thread 1244450.1244455]
 [New Thread 1244450.1244456]
 [New Thread 1244450.1244457]
 [New Thread 1244450.1244458]
 [New Thread 1244450.1244459]
 [New Thread 1244450.1244461]
 [New Thread 1244450.1244462]
 [New Thread 1244450.1244463]
 * hang *

Attaching to the hung GDB shows that GDB is busy in an infinite loop
in stop_all_threads:

 (top-gdb) bt
 #0  stop_all_threads () at /home/pedro/gdb/binutils-gdb/src/gdb/infrun.c:4755
 #1  0x000055555597b424 in stop_waiting (ecs=0x7fffffffd930) at /home/pedro/gdb/binutils-gdb/src/gdb/infrun.c:7738
 #2  0x0000555555976fba in handle_signal_stop (ecs=0x7fffffffd930) at /home/pedro/gdb/binutils-gdb/src/gdb/infrun.c:5868
 #3  0x0000555555975f6a in handle_inferior_event (ecs=0x7fffffffd930) at /home/pedro/gdb/binutils-gdb/src/gdb/infrun.c:5527
 #4  0x0000555555971da4 in fetch_inferior_event () at /home/pedro/gdb/binutils-gdb/src/gdb/infrun.c:3910
 #5  0x00005555559540b2 in inferior_event_handler (event_type=INF_REG_EVENT) at /home/pedro/gdb/binutils-gdb/src/gdb/inf-loop.c:42
 #6  0x000055555597e825 in infrun_async_inferior_event_handler (data=0x0) at /home/pedro/gdb/binutils-gdb/src/gdb/infrun.c:9162
 #7  0x0000555555687d1d in check_async_event_handlers () at /home/pedro/gdb/binutils-gdb/src/gdb/async-event.c:328
 #8  0x0000555555e48284 in gdb_do_one_event () at /home/pedro/gdb/binutils-gdb/src/gdbsupport/event-loop.cc:216
 #9  0x00005555559e7512 in start_event_loop () at /home/pedro/gdb/binutils-gdb/src/gdb/main.c:347
 #10 0x00005555559e765d in captured_command_loop () at /home/pedro/gdb/binutils-gdb/src/gdb/main.c:407
 #11 0x00005555559e8f80 in captured_main (data=0x7fffffffdb70) at /home/pedro/gdb/binutils-gdb/src/gdb/main.c:1239
 #12 0x00005555559e8ff2 in gdb_main (args=0x7fffffffdb70) at /home/pedro/gdb/binutils-gdb/src/gdb/main.c:1254
 #13 0x0000555555627c86 in main (argc=12, argv=0x7fffffffdc88) at /home/pedro/gdb/binutils-gdb/src/gdb/gdb.c:32

The problem is that the remote sends stops for all the threads:

 Packet received: l/home/pedro/gdb/binutils-gdb/build/gdb/testsuite/outputs/gdb.threads/attach-non-stop/attach-non-stop
 Sending packet: $vStopped#55...Packet received: T0006:f06e25edec7f0000;07:f06e25edec7f0000;10:f14190ccf4550000;thread:p12fd22.12fd2f;core:15;
 Sending packet: $vStopped#55...Packet received: T0006:f0dea5f0ec7f0000;07:f0dea5f0ec7f0000;10:e84190ccf4550000;thread:p12fd22.12fd27;core:4;
 Sending packet: $vStopped#55...Packet received: T0006:f0ee25f1ec7f0000;07:f0ee25f1ec7f0000;10:f14190ccf4550000;thread:p12fd22.12fd26;core:5;
 Sending packet: $vStopped#55...Packet received: T0006:f0bea5efec7f0000;07:f0bea5efec7f0000;10:f14190ccf4550000;thread:p12fd22.12fd29;core:1;
 Sending packet: $vStopped#55...Packet received: T0006:f0ce25f0ec7f0000;07:f0ce25f0ec7f0000;10:e84190ccf4550000;thread:p12fd22.12fd28;core:a;
 Sending packet: $vStopped#55...Packet received: T0006:f07ea5edec7f0000;07:f07ea5edec7f0000;10:e84190ccf4550000;thread:p12fd22.12fd2e;core:f;
 Sending packet: $vStopped#55...Packet received: T0006:f0ae25efec7f0000;07:f0ae25efec7f0000;10:df4190ccf4550000;thread:p12fd22.12fd2a;core:6;
 Sending packet: $vStopped#55...Packet received: T0006:0000000000000000;07:c0e8a381fe7f0000;10:bf43b4f1ec7f0000;thread:p12fd22.12fd22;core:2;
 Sending packet: $vStopped#55...Packet received: T0006:f0fea5f1ec7f0000;07:f0fea5f1ec7f0000;10:df4190ccf4550000;thread:p12fd22.12fd25;core:8;
 Sending packet: $vStopped#55...Packet received: T0006:f09ea5eeec7f0000;07:f09ea5eeec7f0000;10:e84190ccf4550000;thread:p12fd22.12fd2b;core:b;
 Sending packet: $vStopped#55...Packet received: OK

But then wait_one never consumes them, always hitting this path:

 4473          if (nfds == 0)
 4474            {
 4475              /* No waitable targets left.  All must be stopped.  */
 4476              return {NULL, minus_one_ptid, {TARGET_WAITKIND_NO_RESUMED}};
 4477            }

Resulting in GDB constanly calling target_stop to stop threads, but
the remote target never reporting back the stops to infrun.

That TARGET_WAITKIND_NO_RESUMED path shown above is always taken
because here, in wait_one too, just above:

 4428          for (inferior *inf : all_inferiors ())
 4429            {
 4430              process_stratum_target *target = inf->process_target ();
 4431              if (target == NULL
 4432                  || !target->is_async_p ()
                           ^^^^^^^^^^^^^^^^^^^^^
 4433                  || !target->threads_executing)
 4434                continue;

... the remote target is not async.

And in turn that happened because extended_remote_target::attach
misses enabling async in the target-non-stop path.

A testcase exercising this will be added in a following patch.

gdb/ChangeLog:

* remote.c (extended_remote_target::attach): Set target async in
the target-non-stop path too.

Fix attaching in non-stop mode (PR gdb/27055)

Attaching in non-stop mode currently misbehaves, like so:

 (gdb) attach 1244450
 Attaching to process 1244450
 [New LWP 1244453]
 [New LWP 1244454]
 [New LWP 1244455]
 [New LWP 1244456]
 [New LWP 1244457]
 [New LWP 1244458]
 [New LWP 1244459]
 [New LWP 1244461]
 [New LWP 1244462]
 [New LWP 1244463]
 No unwaited-for children left.

At this point, GDB's stopped/running thread state is out of sync with
the inferior:

(gdb) info threads
  Id   Target Id                     Frame
* 1    LWP 1244450 "attach-non-stop" 0xf1b443bf in ?? ()
  2    LWP 1244453 "attach-non-stop" (running)
  3    LWP 1244454 "attach-non-stop" (running)
  4    LWP 1244455 "attach-non-stop" (running)
  5    LWP 1244456 "attach-non-stop" (running)
  6    LWP 1244457 "attach-non-stop" (running)
  7    LWP 1244458 "attach-non-stop" (running)
  8    LWP 1244459 "attach-non-stop" (running)
  9    LWP 1244461 "attach-non-stop" (running)
  10   LWP 1244462 "attach-non-stop" (running)
  11   LWP 1244463 "attach-non-stop" (running)
(gdb)
(gdb) interrupt -a
(gdb)
*nothing*

The problem is that attaching installs an inferior continuation,
called when the target reports the initial attach stop, here, in
inf-loop.c:inferior_event_handler:

      /* Do all continuations associated with the whole inferior (not
 a particular thread).  */
      if (inferior_ptid != null_ptid)
do_all_inferior_continuations (0);

However, currently in non-stop mode, inferior_ptid is still null_ptid
when we get here.

If you try to do "set debug infrun 1" to debug the problem, however,
then the attach completes correctly, with GDB reporting a stop for
each thread.

The bug is that we're missing a switch_to_thread/context_switch call
when handling the initial stop, here:

  if (stop_soon == STOP_QUIETLY_NO_SIGSTOP
      && (ecs->event_thread->suspend.stop_signal == GDB_SIGNAL_STOP
  || ecs->event_thread->suspend.stop_signal == GDB_SIGNAL_TRAP
  || ecs->event_thread->suspend.stop_signal == GDB_SIGNAL_0))
    {
      stop_print_frame = true;
      stop_waiting (ecs);
      ecs->event_thread->suspend.stop_signal = GDB_SIGNAL_0;
      return;
    }

Note how the STOP_QUIETLY / STOP_QUIETLY_REMOTE case above that does
call context_switch.

And the reason "set debug infrun 1" "fixes" it, is that the debug path
has a switch_to_thread call.

This patch fixes it by moving the main context_switch call earlier.
It also removes the:

   if (ecs->ptid != inferior_ptid)

check at the same time because:

 #1 - that is half of what context_switch already does

 #2 - deprecated_context_hook is only used in Insight, and all it does
      is set an int.  It won't care if we call it when the current
      thread hasn't actually changed.

A testcase exercising this will be added in a following patch.

gdb/ChangeLog:

PR gdb/27055
* infrun.c (handle_signal_stop): Move main context_switch call
earlier, before STOP_QUIETLY_NO_SIGSTOP.

Automatic date update in version.in

Inferior without argument prints detail of current inferior.

This patch makes the inferior command display information about the
current inferior when called with no argument.  This behavior is similar
to the one of the thread command.

Before patch:

    (gdb) info inferior
      Num  Description       Connection           Executable
    * 1    process 19221     1 (native)           /home/lsix/tmp/a.out
      2    process 19239     1 (native)           /home/lsix/tmp/a.out
    (gdb) inferior 2
    [Switching to inferior 2 [process 19239] (/home/lsix/tmp/a.out)]
    [Switching to thread 2.1 (process 19239)]
    #0  0x0000000000401146 in main ()
    (gdb) inferior
    Argument required (expression to compute).

After patch:

    (gdb) info inferior
      Num  Description       Connection           Executable
    * 1    process 18699     1 (native)           /home/lsix/tmp/a.out
      2    process 18705     1 (native)           /home/lsix/tmp/a.out
    (gdb) inferior 2
    [Switching to inferior 2 [process 18705] (/home/lsix/tmp/a.out)]
    [Switching to thread 2.1 (process 18705)]
    #0  0x0000000000401146 in main ()
    (gdb) inferior
    [Current inferior is 2 [process 18705] (/home/lsix/tmp/a.out)]

gdb/doc/ChangeLog:

* gdb.texinfo (Inferiors Connections and Programs): Document the
inferior command when used without argument.

gdb/ChangeLog:

* NEWS: Add entry for the behavior change of the inferior command.
* inferior.c (inferior_command): When no argument is given to the
inferior command, display info about the currently selected
inferior.

gdb/testsuite/ChangeLog:

* gdb.base/inferior-noarg.c: New test.
* gdb.base/inferior-noarg.exp: New test.

gdb/testsuite: use proc_with_prefix in gdb.base/scope.exp

Fixes:

    Running /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/scope.exp ...
    DUPLICATE: gdb.base/scope.exp: print 'scope0.c'::filelocal_ro
    DUPLICATE: gdb.base/scope.exp: print 'scope0.c'::filelocal_ro
    DUPLICATE: gdb.base/scope.exp: next

gdb/testsuite/ChangeLog:

* gdb.base/scope.exp: Use proc_with_prefix.

Change-Id: Ic40e24a603da6f2a4f8003b74b2ff3040d2b098d

gdb/testsuite: add test for .debug_{rng,loc}lists section without offset array

It is possible for the tables in the .debug_{rng,loc}lists sections to
not have an array of offsets.  In that case, the offset_entry_count
field of the header is 0.  The forms DW_FORM_{rng,loc}listx (reference
by index) can't be used with that table.  Instead, the
DW_FORM_sec_offset form, which references a {rng,loc}list by direct
offset in the section, must be used.  From what I saw, this is what GCC
currently produces.

Add tests for this case.  I didn't see any bug related to this, I just
think that it would be nice to have coverage for this. A new
`-with-offset-array` option is added to the `table` procs, used when
generating {rng,loc}lists, to decide whether to generate the offset
array.

gdb/testsuite/ChangeLog:

* lib/dwarf.exp (rnglists): Add -no-offset-array option to
table proc.
* gdb.dwarf2/rnglists-sec-offset.exp: Add test for
.debug_rnglists table without offset array.
* gdb.dwarf2/loclists-sec-offset.exp: Add test for
.debug_loclists table without offset array.

Change-Id: I8e34a7bf68c9682215ffbbf66600da5b7db91ef7

gdb/dwarf: make read_{loc,rng}list_index return sect_offset

I think it's wrong that read_loclist_index and read_rnglist_index return
a CORE_ADDR.  A CORE_ADDR is an address in the program.  These functions
return offset in sections (.debug_loclists and .debug_rnglists).  I
think sect_offset is more appropriate.

I'm wondering if struct attribute should have a "set_sect_offset"
method, that takes  a sect_offset parameter, or if it's better to be
left as a simple "unsigned".

gdb/ChangeLog:

* dwarf2/read.c (read_loclist_index, read_rnglist_index): Return
a sect_offset.
(read_attribute_reprocess): Adjust.

Change-Id: I0e22e0864130fb490072b41ae099762918b8ad4d

gdb/dwarf: split dwarf2_cu::ranges_base in two

Consider the test case added in this patch.  It defines a compilation
unit with a DW_AT_rnglists_base attribute (used for attributes of form
DW_FORM_rnglistx), but also uses DW_AT_ranges of form
DW_FORM_sec_offset:

    0x00000027: DW_TAG_compile_unit
                  DW_AT_ranges [DW_FORM_sec_offset] (0x0000004c
                     [0x0000000000005000, 0x0000000000006000))
                  DW_AT_rnglists_base [DW_FORM_sec_offset]  (0x00000044)

The DW_AT_rnglists_base does not play a role in reading the DW_AT_ranges of
form DW_FORM_sec_offset, but it should also not do any harm.

This case is currently not handled correctly by GDB.  This is not
something that a compiler is likely to emit, but in my opinion there's
no reason why GDB should fail reading it.

The problem is that in partial_die_info::read and a few other places
where the same logic is replicated, the cu->ranges_base value,
containing the DW_AT_rnglists_base value, is wrongfully added to the
DW_AT_ranges value.

It is quite messy how to decide whether cu->ranges_base should be added
to the attribute's value or not.  But to summarize, the only time we
want to add it is when the attribute comes from a pre-DWARF 5 split unit
file (a .dwo) [1].  In this case, the DW_AT_ranges attribute from the
split unit file will have form DW_FORM_sec_offset, pointing somewhere in
the linked file's .debug_ranges section.  *But* it's not a "true"
DW_FORM_sec_offset, in that it's an offset relative to the beginning of
that CU's contribution in the section, not relative to the beginning of
the section.  So in that case, and only that case, do we want to add the
ranges base value, which we found from the DW_AT_GNU_ranges_base
attribute on the skeleton unit.

Almost all instances of the DW_AT_ranges attribute will be found in the
split unit (on DW_TAG_subprogram, for example), and therefore need to
have the ranges base added.  However, the DW_TAG_compile_unit DIE in the
skeleton may also have a DW_AT_ranges attribute.  For that one, the
ranges base must not be added.  Once the DIEs have been loaded in GDB,
however, the distinction between what's coming from the skeleton and
what's coming from the split unit is not clear.  It is all merged in one
big happy tree.  So how do we know if a given attribute comes from the
split unit or not?

We use the fact that in pre-DWARF 5 split DWARF, DW_AT_ranges is found
on the skeleton's DW_TAG_compile_unit (in the linked file) and never in
the split unit's DW_TAG_compile_unit.  This is why you have this in
partial_die_info::read:

      int need_ranges_base = (tag != DW_TAG_compile_unit
      && attr.form != DW_FORM_rnglistx);

However, with the corner case described above (where we have a
DW_AT_rnglists_base attribute and a DW_AT_ranges attribute of form
DW_FORM_sec_offset) the condition gets it wrong when it encounters an
attribute like DW_TAG_subprogram with a DW_AT_ranges attribute of
DW_FORM_sec_offset form: it thinks that it is necessary to add the base,
when it reality it is not.

The problem boils down to failing to differentiate these cases:

  - a DW_AT_ranges attribute of form DW_FORM_sec_offset in a
    pre-DWARF 5 split unit (in which case we need to add the base)
  - a DW_AT_ranges attribute of form DW_FORM_sec_offset in a DWARF 5
    non-split unit (in which case we must not add the base)

What makes it unnecessarily complex is that the cu->ranges_base field is
overloaded, used to hold the pre-DWARF 5, non-standard
DW_AT_GNU_ranges_base and the DWARF 5 DW_AT_rnglists_base.  In reality,
these two are called "bases" but are not the same thing.  The result is
that we need twisted conditions to try to determine whether or not we
should add the base to the attribute's value.

To fix it, split the field in two distinct fields.  I renamed everything
related to the "old" ranges base to "gnu_ranges_base", to make it clear
that it's about the non-standard, pre-DWARF 5 thing.  And everything
related to the DWARF 5 thing gets renamed "rnglists".  I think it
becomes much easier to reason this way.

The issue described above gets fixed by the fact that the
DW_AT_rnglists_base value does not end up in cu->gnu_ranges_base, so
cu->gnu_ranges_base stays 0.  The condition to determine whether
gnu_ranges_base should be added can therefore be simplified back to:

  tag != DW_TAG_compile_unit

... as it was before rnglistx support was added.

Extend the gdb.dwarf2/rnglists-sec-offset.exp to cover this case.  I
also extended the test case for loclists similarly, just to see if there
would be some similar problem.  There wasn't, but I think it's not a bad
idea to test that case for loclists as well, so I left it in the patch.

[1] https://gcc.gnu.org/wiki/DebugFission

gdb/ChangeLog:

* dwarf2/die.h (struct die_info) <ranges_base>: Split in...
<gnu_ranges_base>: ... this...
<rnglists_base>: ... and this.
* dwarf2/read.c (struct dwarf2_cu) <ranges_base>: Split in...
<gnu_ranges_base>: ... this...
<rnglists_base>: ... and this.
(read_cutu_die_from_dwo): Adjust
(dwarf2_get_pc_bounds): Adjust
(dwarf2_record_block_ranges): Adjust.
(read_full_die_1): Adjust
(partial_die_info::read): Adjust.
(read_rnglist_index): Adjust.

gdb/testsuite/ChangeLog:

* gdb.dwarf2/rnglists-sec-offset.exp: Add test for DW_AT_ranges
of DW_FORM_sec_offset form plus DW_AT_rnglists_base attribute.
* gdb.dwarf2/loclists-sec-offset.exp: Add test for
DW_AT_location of DW_FORM_sec_offset plus DW_AT_loclists_base
attribute

Change-Id: Icd109038634b75d0e6e9d7d1dcb62fb9eb951d83

gdb/testsuite: add .debug_loclists tests

Add tests for the various issues fixed in the previous patches.

Add a new "loclists" procedure to the DWARF assembler, to allow
generating .debug_loclists sections.

gdb/testsuite/ChangeLog:

PR gdb/26813
* lib/dwarf.exp (_handle_DW_FORM): Handle DW_FORM_loclistx.
(loclists): New proc.
* gdb.dwarf2/loclists-multiple-cus.c: New.
* gdb.dwarf2/loclists-multiple-cus.exp: New.
* gdb.dwarf2/loclists-sec-offset.c: New.
* gdb.dwarf2/loclists-sec-offset.exp: New.

Change-Id: I209bcb2a9482762ae943e518998d1f7761f76928

gdb/testsuite: DWARF assembler: add context parameters to _location

The _location proc is used to assemble a location description.  It needs
to know some contextual information:

- size of an address
- size of an offset (into another DWARF section)
- DWARF version

It currently get all this directly from global variables holding the
compilation unit information.  This is fine because as of now, all
location descriptions are generated in the context of creating a
compilation unit.  However, a subsequent patch will generate location
descriptions while generating a .debug_loclists section.  _location
should therefore no longer rely on the current compilation unit's
properties.

Change it to accept these values as parameters instead of accessing the
values for the CU.

No functional changes intended.

gdb/testsuite/ChangeLog:

* lib/dwarf.exp (_location): Add parameters.
(_handle_DW_FORM): Adjust.

Change-Id: Ib94981979c83ffbebac838081d645ad71c221637

gdb/testsuite: add .debug_rnglists tests

Add tests for the various issues fixed in the previous patches.

Add a new "rnglists" procedure to the DWARF assembler, to allow
generating .debug_rnglists sections.  A trivial change is required to
support the DWARF 5 CU header layout.

gdb/testsuite/ChangeLog:

PR gdb/26813
* lib/dwarf.exp (_handle_DW_FORM): Handle DW_FORM_rnglistx.
(cu): Generate header for DWARF 5.
(rnglists): New proc.
* gdb.dwarf2/rnglists-multiple-cus.exp: New.
* gdb.dwarf2/rnglists-sec-offset.exp: New.

Change-Id: I5b297e59c370c60cf671dec19796a6c3b9a9f632

gdb/dwarf: read correct rnglist/loclist header in read_{rng,loc}list_index

When loading the binary from PR 26813 in GDB, we get:

    DW_FORM_rnglistx index pointing outside of .debug_rnglists offset array [in module /home/simark/build/binutils-gdb/gdb/MagicPurse]

... and the symbols fail to load.

In read_rnglist_index and read_loclist_index, we read the header
(documented in sections 7.28 and 7.29 of DWARF 5) of the CU's
contribution to the .debug_rnglists / .debug_loclists sections to
validate that the index we want to read makes sense.  However, we always
read the header at the beginning of the section, rather than the header
for the contribution from which we want to read the index.

To illustrate, here's what the binary from PR 26813 contains.  There are
two compile units:

0x0000000c: DW_TAG_compile_unit 1
              DW_AT_ranges [DW_FORM_rnglistx]: 0x0
              DW_AT_rnglists_base [DW_FORM_sec_offset]: 0xC

0x00003ec9: DW_TAG_compile_unit 2
              DW_AT_ranges [DW_FORM_rnglistx]: 0xB
              DW_AT_rnglists_base [DW_FORM_sec_offset]: 0x85

The layout of the .debug_rnglists is the following:

    [0x00, 0x0B]: header for CU 1's contribution
    [0x0C, 0x0F]: list of offsets for CU 1 (1 element)
    [0x10, 0x78]: range lists data for CU 1

    [0x79, 0x84]: header for CU 2's contribution
    [0x85, 0xB4]: list of offsets for CU 2 (12 elements)
    [0xB5, 0xBD7]: range lists data for CU 2

The DW_AT_rnglists_base attrbute points to the beginning of the list of
offsets for that CU, relative to the start of the .debug_rnglists
section.  That's right after the header for that contribution.

When we try to read the DW_AT_ranges attribute for CU 2,
read_rnglist_index reads the header for CU 1 instead of the one for CU
2.  Since there's only one element in CU 1's offset list, it believes
(wrongfully) that the index 0xB is out of range.

Fix it by reading the header just before where DW_AT_rnglists_base
points to.  With this patch, I am able to load GDB built with clang-11
and -gdwarf-5 in itself, with and without -readnow.

gdb/ChangeLog:

PR gdb/26813
* dwarf2/read.c (read_loclists_rnglists_header): Add
header_offset parameter and use it.
(read_loclist_index): Read header of the current contribution,
not the one at the beginning of the section.
(read_rnglist_index): Likewise.

Change-Id: Ie53ff8251af8c1556f0a83a31aa8572044b79e3d

gdb/dwarf: few fixes for handling DW_FORM_{rng,loc}listx

We hit an assertion when loading the binary from PR 26813.  When fixing
it, execution goes a up bit further but then hits another assert, and
another, and another.  With these fours fixes, I am able to load the
binary and get to the prompt.  An error is shown (index pointing outside
of the section), because the DW_FORM_rnglistx attribute is not read
correctly, but that one is taken care of by the next patch.

The four fixes are:

- attribute::form_requires_reprocessing needs to handle forms
  DW_FORM_rnglistx and DW_FORM_loclistx, because set_unsigned_reprocess
  is called for them in read_attribute_value.

- read_attribute_reprocess must call set_unsigned for them, not
  set_address.  The parameter of set_address is a CORE_ADDR, meaning
  it's for program addresses.  Post-reprocess, DW_FORM_rnglistx and
  DW_FORM_loclistx are offsets into their respective sections
  (.debug_rnglists and .debug_loclists).  set_unsigned is the current
  attribute value setter that fits the best.  But perhaps we should have
  a setter that takes a sect_offset?

- read_attribute_process must call as_unsigned_reprocess instead of
  as_unsigned to get the pre-reprocess value, otherwise we hit the
  assert inside as_unsigned that makes sure the attribute doesn't need
  reprocessing.

- attribute::set_unsigned needs to clear the requires_reprocessing flag,
  otherwise it stays set when reprocessing DW_FORM_rnglistx and
  DW_FORM_loclistx attributes.

There's another assert that we hit once the next patch is applied, but
since it's in the same vein as the changes in this patch, I included it
in this patch:

- attribute::form_is_unsigned must handle form DW_FORM_loclistx,
  otherwise we hit the assert when trying to call set_unsigned for an
  attribute of this form.  DW_FORM_rnglistx is already handled.

gdb/ChangeLog:

PR gdb/26813
* dwarf2/attribute.h (struct attribute) <set_unsigned>: Clear
requires_reprocessing flag.
* dwarf2/attribute.c (attribute::form_is_unsigned): Handle
DW_FORM_loclistx.
(attribute::form_requires_reprocessing): Handle DW_FORM_rnglistx
and DW_FORM_loclistx.
* dwarf2/read.c (read_attribute_reprocess): Use set_unsigned
instead of set_address for DW_FORM_loclistx and
DW_FORM_rnglistx.

Change-Id: I06c156fa3913ca98e4e39085f4ef171645b4bc1e

gdb/dwarf: remove unnecessary check in read_{rng,loc}list_index

In read_rnglist_index and read_loclist_index, we check that both the
start and end of the offset that we read from the offset table are
within the section.  I think it's unecessary to do both: if the end of
the offset is within the section, then surely the start of the offset is
within it.

Remove the check for the start of the offset in both functions.

gdb/ChangeLog:

* dwarf2/read.c (read_loclist_index): Remove bound check for
start of offset.
(read_rnglist_index): Likewise.

Change-Id: I7b57ddf4f8a8a28971738f0e3f3af62108f9e19a

gdb/dwarf: add missing bound check to read_loclist_index

read_rnglist_index has a bound check to make sure that we don't go past
the end of the section while reading the offset, but read_loclist_index
doesn't.  Add it to read_loclist_index.

gdb/ChangeLog:

* dwarf2/read.c (read_loclist_index): Add bound check for the end
of the offset.

Change-Id: Ic4b55c88860fdc3e007740949c78ec84cdb4da60

gdb/dwarf: fix bound check in read_rnglist_index

I think this check in read_rnglist_index is wrong:

      /* Validate that reading won't go beyond the end of the section.  */
      if (start_offset + cu->header.offset_size > rnglist_base + section->size)
        error (_("Reading DW_FORM_rnglistx index beyond end of"
                 ".debug_rnglists section [in module %s]"),
               objfile_name (objfile));

The addition `rnglist_base + section->size` doesn't make sense.
rnglist_base is an offset into `section`, so it doesn't make sense to
add it to `section`'s size.  `start_offset` also is an offset into
`section`, so we should just compare it to just `section->size`.

gdb/ChangeLog:

* dwarf2/read.c (read_rnglist_index): Fix bound check.

Change-Id: If0ff7c73f4f80f79aac447518f4e8f131f2db8f2

gdb/dwarf: change read_loclist_index complaints into errors

Unlike read_rnglists_index, read_loclist_index uses complaints when it
detects an inconsistency (a DW_FORM_loclistx value without a
.debug_loclists section or an offset outside of the section).  I really
think they should be errors, since there's no point in continuing if
this situation happens, we will likely segfault or read garbage.

gdb/ChangeLog:

* dwarf2/read.c (read_loclist_index): Change complaints into
errors.

Change-Id: Ic3a1cf6e682d47cb6e739dd76fd7ca5be2637e10

readelf: Add 'R' and 'D' to "Key to Flags:"

Add "R (retain)" and "D (mbind)" to "Key to Flags:".

PR binutils/27281
* readelf.c (process_section_headers): Add 'R' and 'D' to
"Key to Flags:".
* testsuite/binutils-all/retain1a.d: Updated.

PR27311, ld.bfd (symbol from plugin): undefined reference

A default versioned symbol definition in a shared library is
overridden by an unversioned definition in a regular object file, and
thus should not be reason to make an as-needed library needed.

bfd/
PR 27311
* elflink.c (_bfd_elf_add_default_symbol): Add override parameter.
Use when handling default versioned symbol.  Rename existing
override variable to nondef_override and use for non-default
versioned symbol.
(elf_link_add_object_symbols): Adjust call to suit.  Don't
pull in as-needed libraries when override is set.
ld/
* testsuite/ld-plugin/pr27311.d,
* testsuite/ld-plugin/pr27311.ver,
* testsuite/ld-plugin/pr27311a.c,
* testsuite/ld-plugin/pr27311b.c,
* testsuite/ld-plugin/pr27311c.c: New testcase.
* testsuite/ld-plugin/lto.exp: Run it.  Correct PR14918 and
PR12982 entries.

[gdb/symtab] Fix assert in write_one_signatured_type

When running test-case gdb.dwarf2/fission-reread.exp with target board
cc-with-gdb-index, we run into an abort during the generation of the gdb-index
by cc-with-tweaks.sh:
...
build/gdb/testsuite/cache/gdb.sh: line 1: 27275 Aborted  (core dumped)
...

This can be reproduced on the command line like this:
...
$ gdb -batch ./outputs/gdb.dwarf2/fission-reread/fission-reread \
  -ex 'save gdb-index  ./outputs/gdb.dwarf2/fission-reread'
warning: Could not find DWO TU fission-reread.dwo(0x9022f1ceac7e8b19) \
  referenced by TU at offset 0x0 [in module fission-reread]
warning: Could not find DWO CU fission-reread.dwo(0x807060504030201) \
  referenced by CU at offset 0x561 [in module fission-reread]
Aborted (core dumped)
...

The abort is a segfault due to a using a nullptr psymtab in
write_one_signatured_type.

The problem is that we're trying to write index entries for the type unit
with signature:
...
(gdb) p /x entry->signature
$2 = 0x9022f1ceac7e8b19
...
which is a skeleton type unit:
...
Contents of the .debug_types section:

  Compilation Unit @ offset 0x0:
   Length:        0x4a (32-bit)
   Version:       4
   Abbrev Offset: 0x165
   Pointer Size:  4
   Signature:     0x9022f1ceac7e8b19
   Type Offset:   0x0
 <0><17>: Abbrev Number: 2 (DW_TAG_type_unit)
    <18>   DW_AT_comp_dir    : /tmp/src/gdb/testsuite
    <2f>   DW_AT_GNU_dwo_name: fission-reread.dwo
    <42>   DW_AT_GNU_pubnames: 0x0
    <46>   DW_AT_GNU_pubtypes: 0x0
    <4a>   DW_AT_GNU_addr_base: 0x0
...
referring to a .dwo file, but as the warnings show, the .dwo file is not
found.

Fix this by skipping the type unit in write_one_signatured_type if
psymtab == nullptr.

Tested on x86_64-linux.

gdb/ChangeLog:

2021-02-02  Tom de Vries  <tdevries@suse.de>

PR symtab/24620
* dwarf2/index-write.c (write_one_signatured_type): Skip if
psymtab == nullptr.

gdb/testsuite/ChangeLog:

2021-02-02  Tom de Vries  <tdevries@suse.de>

PR symtab/24620
* gdb.dwarf2/fission-reread.exp: Add test-case.

Automatic date update in version.in

Add Genode target support

* configure.tgt: Add *-*-genode* as a target for AArch64 and x86.

[gdb/testsuite] Fix gdb.dwarf2/fission-reread.exp with .gdb_index

When running test-case gdb.dwarf2/fission-reread.exp with target board
cc-with-gdb-index, we run into:
...
gdb compile failed, warning: Could not find DWO TU \
  fission-reread.dwo(0x9022f1ceac7e8b19) referenced by TU at offset 0x0 \
  [in module outputs/gdb.dwarf2/fission-reread/fission-reread]
...
The problem is that the .dwo file is not found.

There's code added in the .exp file to make sure the .dwo can be found:
...
 # Make sure we can find the .dwo file, regardless of whether we're
 # running in parallel mode.
 gdb_test_no_output "set debug-file-directory [file dirname $binfile]" \
     "set debug-file-directory"
...
This works normally, but not for the gdb invocation done by cc-with-tweaks.sh
for target board cc-with-gdb-index.

Fix this by finding the full path to the .dwo file and passing it
to the compilation.

Tested on x86_64-linux with native and target boards cc-with-gdb-index,
cc-with-debug-names and readnow.

gdb/testsuite/ChangeLog:

2021-02-01  Tom de Vries  <tdevries@suse.de>

* gdb.dwarf2/fission-base.S: Pass -DDWO=$dwo.
* gdb.dwarf2/fission-loclists-pie.S: Same.
* gdb.dwarf2/fission-loclists.S: Same.
* gdb.dwarf2/fission-multi-cu.S: Same.
* gdb.dwarf2/fission-reread.S: Same.
* gdb.dwarf2/fission-base.exp: Use DWO.
* gdb.dwarf2/fission-loclists-pie.exp: Same.
* gdb.dwarf2/fission-loclists.exp: Same.
* gdb.dwarf2/fission-multi-cu.exp: Same.
* gdb.dwarf2/fission-reread.exp: Same.

Wrong operand for SADDR (rl78)

PR 27254
* elf32-rl78.c (rl78_elf_relocate_section): Fix calculation of
offset for the R_RL78_RH_SADDR relocation.

Small updates to the 'how to make a release' document following from the 2.35.2 release

ld --defsym

This makes --defsym support the same expressions as assignment in a
script.  For example, --defsym 'HIDDEN(foo=0)', will define a hidden
visibility foo.

* ldgram.y (defsym_expr): Use assignment rule.
* ldlex.h (ldlex_defsym): Delete.
* ldlex.l (DEFSYMEXP, ldlex_defsym): Delete.

ld script expression parsing

Parsing symbol or file/section names in ld linker scripts is a little
complicated.  Inside SECTIONS, a name might be the start of an
expression or an output section.  Is ".foo=x-y" a fancy section name
or is it the expression ".foo = x - y"?  It isn't possible for a
single lookahead parser to decide, so the answer in this case is
that it's a section name.  This is the reason why everyone writes
linker script assignment expressions with lots of white-space.

However, there are many places where the parser knows for sure that an
expression is expected.  Those could be written without whitespace
given the first change to ldlex.l below.  Unfortunately, that runs
into a lookahead problem.  Optional expressions at the end of an
output section statement require the parser to look ahead one token in
expression context.  For this example from standard scripts
  .interp             : { *(.interp) }
  .note.gnu.build-id  : { *(.note.gnu.build-id) }
at the end of the .interp closing brace, the parser is looking for
a possible memspec, phdr, fill or even an optional comma.  The next
token is a NAME, but in expression context that NAME now doesn't
include '-' as a valid char.  So the lookahead NAME is
".note.gnu.build" with an unexpected "-id" syntax error before the
colon.  The rest of the patch involving ldlex_backup arranges to
discard that NAME token so that it will be rescanned in the proper
script context.

* ldgram.y (section): Call ldlex_backup.  Remove empty action.
* ldlex.h (ldlex_backup): Declare.
* ldlex.l (<EXPRESSION>NAME): Don't use NOCFILENAMECHAR set of
chars, use SYMBOLNAMECHAR.
(ldlex_backup): New function.

gdb: unify parts of the Linux and FreeBSD core dumping code

While reviewing the Linux and FreeBSD core dumping code within GDB for
another patch series, I noticed that the code that collects the
registers for each thread and writes these into ELF note format is
basically identical between Linux and FreeBSD.

This commit merges this code and moves it into the gcore.c file,
which seemed like the right place for generic writing a core file
code.

The function find_signalled_thread is moved from linux-tdep.c despite
not being shared.  A later commit will make use of this function.

There are a couple of minor changes to the FreeBSD target after this
commit, but I believe that these are changes for the better:

(1) For FreeBSD we always used to record the thread-id in the core file by
using ptid_t.lwp ().  In contrast the Linux code did this:

    /* For remote targets the LWP may not be available, so use the TID.  */
    long lwp = ptid.lwp ();
    if (lwp == 0)
      lwp = ptid.tid ();

Both target now do this:

    /* The LWP is often not available for bare metal target, in which case
       use the tid instead.  */
    if (ptid.lwp_p ())
      lwp = ptid.lwp ();
    else
      lwp = ptid.tid ();

Which is equivalent for Linux, but is a change for FreeBSD.  I think
that all this means is that in some cases where GDB might have
previously recorded a thread-id of 0 for each thread, we might now get
something more useful.

(2) When collecting the registers for Linux we collected into a zero
initialised buffer.  By contrast on FreeBSD the buffer is left
uninitialised.  In the new code the buffer is always zero initialised.
I suspect once the registers are copied into the buffer there's
probably no gaps left so this makes no difference, but if it does then
using zeros rather than random bits of GDB's memory is probably a good
thing.

Otherwise, there should be no other user visible changes after this
commit.

Tested this on x86-64/GNU-Linux and x86-64/FreeBSD-12.2 with no
regressions.

gdb/ChangeLog:

* Makefile.in (HFILES_NO_SRCDIR): Add corefile.h.
* gcore.c (struct gcore_collect_regset_section_cb_data): Moved
here from linux-tdep.c and given a new name.  Minor cleanups.
(gcore_collect_regset_section_cb): Likewise.
(gcore_collect_thread_registers): Likewise.
(gcore_build_thread_register_notes): Likewise.
(gcore_find_signalled_thread): Likewise.
* gcore.h (gcore_build_thread_register_notes): Declare.
(gcore_find_signalled_thread): Declare.
* fbsd-tdep.c: Add 'gcore.h' include.
(struct fbsd_collect_regset_section_cb_data): Delete.
(fbsd_collect_regset_section_cb): Delete.
(fbsd_collect_thread_registers): Delete.
(struct fbsd_corefile_thread_data): Delete.
(fbsd_corefile_thread): Delete.
(fbsd_make_corefile_notes): Call
gcore_build_thread_register_notes instead of the now deleted
FreeBSD code.
* linux-tdep.c: Add 'gcore.h' include.
(struct linux_collect_regset_section_cb_data): Delete.
(linux_collect_regset_section_cb): Delete.
(linux_collect_thread_registers): Delete.
(linux_corefile_thread): Call
gcore_build_thread_register_notes.
(find_signalled_thread): Delete.
(linux_make_corefile_notes): Call gcore_find_signalled_thread.

ldgram.y low_level_library_NAME_list

Beginning a new rule hidden inside another rule is horrible.

* ldgram.y: Whitespace fixes.

Re: ld: Add a test for PR ld/27259

* testsuite/ld-elf/pr27259.d: Correct sh_link match.

PR27283 gas for alpha fails to build with gcc 11

PR 27283
* config/tc-alpha.c (insert_operand): Delete dead code.

Automatic date update in version.in

sim: cgen-trace: tweak printf call

GCC warns that we pass a non-string literal as the format string,
so add an explicit "%s" to make it happy.

sim: bpf: fix mainloop extract call

The extract function takes the argbuf, not the scache.

sim: bpf/or1k: fix CGEN_TRACE_EXTRACT name

We renamed these years ago, but it looks like the cgen core missed the
TRACE_EXTRACT function, so these new ports still used the incompatible
common name.  Fix those ports to use the right func.

sim: cgen-accfp: Fix pointer sign warnings

When compiling we get the following warnings:

  common/cgen-accfp.c: In function 'fixsfsi':
  common/cgen-accfp.c:370:18: warning: pointer targets in passing argument 1 of 'sim_fpu_to32i' differ in signedness [-Wpointer-sign]
     sim_fpu_to32i (&res, &op1, sim_fpu_round_near);
                    ^
  common/cgen-accfp.c: In function 'fixdfsi':
  common/cgen-accfp.c:381:18: warning: pointer targets in passing argument 1 of 'sim_fpu_to32i' differ in signedness [-Wpointer-sign]
     sim_fpu_to32i (&res, &op1, sim_fpu_round_near);
                    ^

sim: v850: cleanup build warnings

This port only had one minor warning left in it, so fix it and then
enable -Werror behavior by deleting the macro call.  We'll use the
common default now (which is -Werror).

sim: v850: fix handling of SYS_times

My recent rewrite of the nltvals generator fixed a bug where SYS_times
was not being exported for v850.  But that in turn uncovered this bug
where the SYS_times codepath had a compile error.

sim: moxie: cleanup build warnings

This port only had one minor warning left in it, so fix it and then
enable -Werror behavior by deleting the macro call.  We'll use the
common default now (which is -Werror).

sim: common: change gennltvals helper to Python

This tool is only run by developers and not in a release build,
so rewrite it in Python to make it more maintainable.

Automatic date update in version.in

sim: m68hc11: fix printf size warnings

GCC complains %llu is wrong for signed64, so switch to PRIi64.

sim: m68hc11: localize a few functions

These are only used in this file and lack prototypes, so gcc
complains about it.  Add static everywhere to clean that up.

sim: m68hc11: tweak printf-style funcs

GCC complains that we past non-string literals to a printf style func,
so put a %s in here to keep it quiet.

sim: m68hc11: include stdlib.h for prototypes

These files use abort() & strtod(), so include stdlib.h for them.

sim: watchpoints: change sizeof_pc to sizeof(sim_cia)

Existing ports already have sizeof_pc set to the same size as sim_cia,
so simply make that part of the core code.  We already assume this in
places by way of sim_pc_{get,set}, and this is how it's documented in
the sim-base.h API.

There is code to allow sims to pick different register word sizes from
address sizes, but most ports use the defaults for both (32-bits), and
the few that support multiple register sizes never change the address
size (so address defaults to register).  I can't think of any machine
where the register hardware size would be larger than the address word
size either.  We have ABIs that behave that way (e.g. x32), but the
hardware is still equivalent register sized.

sim: profile: fix bucketing with 64-bit targets

When the target's PC is 64-bits, this shift expands into a range of
8 * 8 - 1 which doesn't work with 32-bit constants.  Force it to be
a 64-bit value all the time and let the compiler truncate it.

sim: m68hc11: stop making hardware conditional

This port doesn't build if these hardware modules are omitted, and
there's no reason we need to make it conditional at build time, so
always enable it.  The hardware devices only get turned on if the
user requests it at runtime via hardware settings.

sim: hw: replace fgets with getline

This avoids fixed sized buffers on the stack.

sim: common: sort nltvals.def

This was largely already done, but I think people didn't quite notice.

sim: readd myself as a maintainer

Automatic date update in version.in

[gdb/breakpoint] Fix stepping past non-stmt line-table entries

Consider the test-case small.c:
...
$ cat -n small.c
     1  __attribute__ ((noinline, noclone))
     2  int foo (char *c)
     3  {
     4    asm volatile ("" : : "r" (c) : "memory");
     5    return 1;
     6  }
     7
     8  int main ()
     9  {
    10    char tpl1[20] = "/tmp/test.XXX";
    11    char tpl2[20] = "/tmp/test.XXX";
    12    int fd1 = foo (tpl1);
    13    int fd2 = foo (tpl2);
    14    if (fd1 == -1) {
    15      return 1;
    16    }
    17
    18    return 0;
    19  }
...

Compiled with gcc-8 and optimization:
...
$ gcc-8 -O2 -g small.c
...

We step through the calls to foo, but fail to visit line 13:
...
12   int fd1 = foo (tpl1);
(gdb) step
foo (c=c@entry=0x7fffffffdea0 "/tmp/test.XXX") at small.c:5
5   return 1;
(gdb) step
foo (c=c@entry=0x7fffffffdec0 "/tmp/test.XXX") at small.c:5
5   return 1;
(gdb) step
main () at small.c:14
14   if (fd1 == -1) {
(gdb)
...

This is caused by the following.  The calls to foo are implemented by these
insns:
....
  4003df:       0f 29 04 24             movaps %xmm0,(%rsp)
  4003e3:       0f 29 44 24 20          movaps %xmm0,0x20(%rsp)
  4003e8:       e8 03 01 00 00          callq  4004f0 <foo>
  4003ed:       48 8d 7c 24 20          lea    0x20(%rsp),%rdi
  4003f2:       89 c2                   mov    %eax,%edx
  4003f4:       e8 f7 00 00 00          callq  4004f0 <foo>
  4003f9:       31 c0                   xor    %eax,%eax
...
with corresponding line table entries:
...
INDEX  LINE   ADDRESS            IS-STMT
8      12     0x00000000004003df Y
9      10     0x00000000004003df
10     11     0x00000000004003e3
11     12     0x00000000004003e8
12     13     0x00000000004003ed
13     12     0x00000000004003f2
14     13     0x00000000004003f4 Y
15     13     0x00000000004003f4
16     14     0x00000000004003f9 Y
17     14     0x00000000004003f9
...

Once we step out of the call to foo at 4003e8, we land at 4003ed, and gdb
enters process_event_stop_test to figure out what to do.

That entry has is-stmt=n, so it's not the start of a line, so we don't stop
there.  However, we do update ecs->event_thread->current_line to line 13,
because the frame has changed (because we stepped out of the function).

Next we land at 4003f2.  Again the entry has is-stmt=n, so it's not the start
of a line, so we don't stop there.  However, because the frame hasn't changed,
we don't update update ecs->event_thread->current_line, so it stays 13.

Next we land at 4003f4.  Now is-stmt=y, so it's the start of a line, and we'd
like to stop here.

But we don't stop because this test fails:
...
  if ((ecs->event_thread->suspend.stop_pc == stop_pc_sal.pc)
      && (ecs->event_thread->current_line != stop_pc_sal.line
          || ecs->event_thread->current_symtab != stop_pc_sal.symtab))
    {
...
because ecs->event_thread->current_line == 13 and stop_pc_sal.line == 13.

Fix this by resetting ecs->event_thread->current_line to 0 if is-stmt=n and
the frame has changed, such that we have:
...
12        int fd1 = foo (tpl1);
(gdb) step
foo (c=c@entry=0x7fffffffdbc0 "/tmp/test.XXX") at small.c:5
5         return 1;
(gdb) step
main () at small.c:13
13        int fd2 = foo (tpl2);
(gdb)
...

Tested on x86_64-linux, with gcc-7 and gcc-8.

gdb/ChangeLog:

2021-01-29  Tom de Vries  <tdevries@suse.de>

PR breakpoints/26063
* infrun.c (process_event_stop_test): Reset
ecs->event_thread->current_line to 0 if is-stmt=n and frame has
changed.

gdb/testsuite/ChangeLog:

2021-01-29  Tom de Vries  <tdevries@suse.de>

PR breakpoints/26063
* gdb.dwarf2/dw2-step-out-of-function-no-stmt.c: New test.
* gdb.dwarf2/dw2-step-out-of-function-no-stmt.exp: New file.

[gdb/testsuite] Fix gdb.opt/solib-intra-step.exp with -m32 and gcc-10

When running test-case gdb.opt/solib-intra-step.exp with target board
unix/-m32 and gcc-10, I run into:
...
(gdb) step^M
__x86.get_pc_thunk.bx () at ../sysdeps/i386/crti.S:68^M
68      ../sysdeps/i386/crti.S: No such file or directory.^M
(gdb) step^M
shlib_second (dummy=0) at solib-intra-step-lib.c:23^M
23        abort (); /* second-hit */^M
(gdb) FAIL: gdb.opt/solib-intra-step.exp: second-hit
...

The problem is that the test-case expects to step past the retry line,
which is optional.

Fix this by removing the state tracking logic from the gdb_test_multiples.  It
makes the test more difficult to understand, and doesn't specifically test for
faulty gdb behaviour.

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

2021-01-29  Tom de Vries  <tdevries@suse.de>

* gdb.opt/solib-intra-step.exp: Remove state tracking logic.

PR27271, c6x-uclinux-ld segfaults linking ld-uClibc-1.0.37.so

bfd/
PR 27271
* elflink.c (bfd_elf_link_record_dynamic_symbol): Don't segfault
on symbols defined in absolute or other special sections.
ld/
* testsuite/ld-tic6x/tic6x.exp: Add pr27271 test.

Automatic date update in version.in

gdb: remove unneeded switch_to_thread from thr_try_catch_cmd

I spotted that every time thr_try_catch_cmd is called GDB has already
switched to the required thread.  The call to switch_to_thread at the
head of thr_try_catch_cmd is therefore redundant.

This commit replaces the call to switch_to_thread with an assertion
that we already have the required thread selected.

I also extended the header comment on thr_try_catch_cmd to make it
clearer when this function could throw an exception.

There should be no user visible changes after this commit.

gdb/ChangeLog:

* thread.c (thr_try_catch_cmd): Replace swith_to_thread with an
assert.  Extend the header comment.

gdb/tui: remove special handling of locator/status window

The locator window, or status window as it is sometimes called is
handled differently to all the other windows.

The reason for this is that the class representing this
window (tui_locator_window) does two jobs, first this class represents
a window just like any other that has space on the screen and fills
the space with content.  The second job is that this class serves as a
storage area to hold information about the current location that the
TUI windows represent, so the class has members like 'addr' and
'line_no', for example which are used within this class, and others
when they want to know which line/address the TUI windows should be
showing to the user.

Because of this dual purpose we must always have an instance of the
tui_locator_window so that there is somewhere to store this location
information.

The result of this is that the locator window must never be deleted
like other windows, which results in some special case code.

In this patch I propose splitting the two roles of the
tui_locator_window class.  The tui_locator_window class will retain
just its window drawing parts, and will be treated just like any other
window.  This should allow all special case code for this window to be
deleted.

The other role, that of tracking the current tui location will be
moved into a new class (tui_location_tracker), of which there will be
a single global instance.  All of the places where we previously use
the locator window to get location information will now be updated to
get this from the tui_location_tracker.

There should be no user visible changes after this commit.

gdb/ChangeLog:

* Makefile.in (SUBDIR_TUI_SRCS): Add tui/tui-location.c.
(HFILES_NO_SRCDIR): Add tui/tui-location.h.
* tui/tui-data.h (TUI_STATUS_WIN): Define.
(tui_locator_win_info_ptr): Delete declaration.
* tui/tui-disasm.c: Add 'tui/tui-location.h' include.
(tui_disasm_window::set_contents): Fetch state from tui_location
global.
(tui_get_begin_asm_address): Likewise.
* tui/tui-layout.c (tui_apply_current_layout): Remove special case
for locator window.
(get_locator_window): Delete.
(initialize_known_windows): Treat locator window just like all the
rest.
* tui/tui-source.c: Add 'tui/tui-location.h' include.
(tui_source_window::set_contents): Fetch state from tui_location
global.
(tui_source_window::showing_source_p): Likewise.
* tui/tui-stack.c: Add 'tui/tui-location.h' include.
(_locator): Delete.
(tui_locator_win_info_ptr): Delete.
(tui_locator_window::make_status_line): Fetch state from
tui_location global.
(tui_locator_window::rerender): Remove check of 'handle',
reindent function body.
(tui_locator_window::set_locator_fullname): Delete.
(tui_locator_window::set_locator_info): Delete.
(tui_update_locator_fullname): Delete.
(tui_show_frame_info): Likewise.
(tui_show_locator_content): Access window through TUI_STATUS_WIN.
* tui/tui-stack.h (tui_locator_window::set_locator_info): Moved to
tui/tui-location.h and renamed to
tui_location_tracker::set_location.
(tui_locator_window::set_locator_fullname): Moved to
tui/tui-location.h and renamed to
tui_location_tracker::set_fullname.
(tui_locator_window::full_name): Delete.
(tui_locator_window::proc_name): Delete.
(tui_locator_window::line_no): Delete.
(tui_locator_window::addr): Delete.
(tui_locator_window::gdbarch): Delete.
(tui_update_locator_fullname): Delete declaration.
* tui/tui-wingeneral.c (tui_refresh_all): Removed special handling
for locator window.
* tui/tui-winsource.c: Add 'tui/tui-location.h' include.
(tui_display_main): Call function on tui_location directly.
* tui/tui.h (enum tui_win_type): Add STATUS_WIN.
* tui/tui-location.c: New file.
* tui/tui-location.h: New file.

[gdb/testsuite] Fix gdb.arch/i386-gnu-cfi.exp

When running test-case gdb.arch/i386-gnu-cfi.exp with target board unix/-m32, I get:
...
(gdb) up 3^M
79      abort.c: No such file or directory.^M
(gdb) FAIL: gdb.arch/i386-gnu-cfi.exp: shift up to the modified frame
...

The preceding backtrace looks like this:
...
(gdb) bt^M
 #0  0xf7fcf549 in __kernel_vsyscall ()^M
 #1  0xf7ce8896 in __libc_signal_restore_set (set=0xffffc3bc) at \
     ../sysdeps/unix/sysv/linux/internal-signals.h:104^M
 #2  __GI_raise (sig=6) at ../sysdeps/unix/sysv/linux/raise.c:47^M
 #3  0xf7cd0314 in __GI_abort () at abort.c:79^M
 #4  0x0804919f in gate (gate=0x8049040 <abort@plt>, data=0x0) at gate.c:3^M
 #5  0x08049176 in main () at i386-gnu-cfi.c:27^M
...
with function gate at position #4, while on another system where the test passes,
I see instead function gate at position #3.

Fix this by capturing the position of function gate in the backtrace, and
using that in the rest of the test instead of hardcoded constant 3.

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

2021-01-28  Tom de Vries  <tdevries@suse.de>

* gdb.arch/i386-gnu-cfi.exp: Capture the position of function gate
in the backtrace, and use that in the rest of the test instead of
hardcoded constant 3.  Use "frame" instead of "up" for robustness.

[gdb/testsuite] Fix g0 search in gdb.arch/i386-sse-stack-align.exp

When running test-case gdb.arch/i386-sse-stack-align.exp on target board
unix/-m32, I run into:
...
(gdb) print (int) g0 ()^M
Invalid data type for function to be called.^M
(gdb) FAIL: gdb.arch/i386-sse-stack-align.exp: print (int) g0 ()
...

Gdb is supposed to use minimal symbol g0:
...
$ nm i386-sse-stack-align | grep g0
08049194 t g0
...
but instead it finds a g0 symbol in the debug info of libm, specifically in
./sysdeps/ieee754/ldbl-96/e_lgammal_r.c.

Fix this by renaming g[0-4] to test_g[0-4].

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

2021-01-28  Tom de Vries  <tdevries@suse.de>

* gdb.arch/i386-sse-stack-align.S: Rename g[0-4] to test_g[0-4].
* gdb.arch/i386-sse-stack-align.c: Same.
* gdb.arch/i386-sse-stack-align.exp: Same.

gdb: rename get_type_arch to type::arch

... and update all users.

gdb/ChangeLog:

* gdbtypes.h (get_type_arch): Rename to...
(struct type) <arch>: ... this, update all users.

Change-Id: I0e3ef938a0afe798ac0da74a9976bbd1d082fc6f

gdb: rename type::{arch,objfile} -> type::{arch_owner,objfile_owner}

I think this makes the names of the methods clearer, especially for the
arch.  The type::arch method (which gets the arch owner, or NULL if the
type is not arch owned) is easily confused with the get_type_arch method
(which returns an arch no matter what).  The name "arch_owner" will make
it intuitive that the method returns NULL if the type is not arch-owned.

Also, this frees the type::arch name, so we will be able to morph the
get_type_arch function into the type::arch method.

gdb/ChangeLog:

* gdbtypes.h (struct type) <arch>: Rename to...
<arch_owner>: ... this, update all users.
<objfile>: Rename to...
<objfile_owner>: ... this, update all users.

Change-Id: Ie7c28684c7b565adec05a7619c418c69429bd8c0

Improve windres's handling of pathnames containing special characters on Windows platforms.

 PR 4356
 * windres.c (quot): Use double quotes to protect strings on
 Windows platforms.

ld: Add a test for PR ld/27259

PR ld/27259
* testsuite/ld-elf/pr27259.d: New file.
* testsuite/ld-elf/pr27259.s: Likewise.

Fix binutils tools so that they can cope with the special /dev/null file when run on Windows systems.

 PR 27252
 * bucomm.c (get_file_size): Add code to handle /dev/null on
 Windows systems.
 * elfedit.c (check_file): Likewise.

gold: Skip address size and segment selector for DWARF5

The .debug_line secton in DWARF5 has a byte for address size and a byte
for segment selector after DWARF version.  Skip them for DWARF5.

PR gold/27246
* dwarf_reader.cc (Sized_dwarf_line_info::read_header_prolog):
Skip address size and segment selector for DWARF5.

gdb/testsuite: unset XDG_CONFIG_HOME

Since this commit:

  commit 64aaad6349d2b2c45063a5383f877ce9a3a0c354
  Date:   Fri Sep 25 14:50:56 2020 +0100

      gdb: use get_standard_config_dir when looking for .gdbinit

GDB has been checking for ${XDG_CONFIG_HOME}/gdb/gdbinit on startup.

Most tests pass -nx to GDB to block loading of gdbinit files, but
there are a few tests (e.g. gdb.base/gdbinit-history.exp) that don't
use -nx and instead setup a fake HOME directory containing a gdbinit
file.

However, since the above commit, if XDG_CONFIG_HOME is set then once
-nx is no longer being passed GDB will load any gdbinit file it finds
in that directory, which could cause the test to fail.

As a concrete example:

  $ mkdir -p fake_xdg_config_home/gdb/
  $ cat <<EOF >fake_xdg_config_home/gdb/gdbinit
  echo goodbye\n
  quit
  EOF
  $ export XDG_CONFIG_HOME=$PWD/fake_xdg_config_home
  $ make check-gdb TESTS="gdb.base/gdbinit-history.exp"

Should result in the test failing.

The solution I propose is to unset XDG_CONFIG_HOME in
default_gdb_init, we already unset a bunch of environment variables in
this proc.

gdb/testsuite/ChangeLog:

* lib/gdb.exp (default_gdb_init): Unset XDG_CONFIG_HOME.

gdb: update comment for execute_command_to_string

The function execute_command_to_string had two header comments, one in
gdbcmd.h and one in top.c.

This commit merges the two comments into one and places this comment
in gdbcmd.h.  The comment in top.c is updated to just reference
gdbcmd.h.

gdb/ChangeLog:

* gdbcmd.h (execute_command_to_string): Update comment.
* top.c (execute_command_to_string): Update header comment.

[gdb/breakpoints] Fix longjmp master breakpoint with separate debug info

When running test-case gdb.base/longjmp.exp with target board unix/-m32, we
run into:
...
(gdb) next^M
Warning:^M
Cannot insert breakpoint 0.^M
Cannot access memory at address 0x7dbf7353^M
^M
__libc_siglongjmp (env=0x804a040 <env>, val=1) at longjmp.c:28^M
28        longjmps++;^M
(gdb) FAIL: gdb.base/longjmp.exp: next over longjmp(1)
...

The failure to access memory happens in i386_get_longjmp_target and is due to
glibc having pointer encryption (aka "pointer mangling" or "pointer guard") of
the long jump buffer.  This is a known problem.

In create_longjmp_master_breakpoint (which attempts to install a master
longjmp breakpoint) a preference scheme is present, which installs a
probe breakpoint if a libc:longjmp probe is present, and otherwise falls back
to setting breakpoints at the names in the longjmp_names array.

But in fact, both the probe breakpoint and the longjmp_names breakpoints are
set.  The latter ones are set when processing libc.so.debug, and the former
one when processing libc.so.  In other words, this is the longjmp variant of
PR26881, which describes the same problem for master exception breakpoints.

This problem only triggers when the glibc debug info package is installed,
which is not due to the debug info itself in libc.so.debug, but due to the
minimal symbols (because create_longjmp_master_breakpoint uses minimal symbols
to translate the longjmp_names to addresses).

The problem doesn't trigger for -m64, because there tdep->jb_pc_offset is not
set.

Fix this similar to commit 1940319c0ef (the fix for PR26881): only install
longjmp_names breakpoints in libc.so/libc.so.debug if installing the
libc:longjmp probe in libc.so failed.

Tested on x86_64-linux.

gdb/ChangeLog:

2021-01-28  Tom de Vries  <tdevries@suse.de>

PR breakpoints/27205
* breakpoint.c (create_longjmp_master_breakpoint_probe)
(create_longjmp_master_breakpoint_names): New function, factored out
of ...
(create_longjmp_master_breakpoint): ... here.  Only try to install
longjmp_names breakpoints in libc.so/libc.so.debug if installing probe
breakpoint in libc.so failed.

PR27259, SHF_LINK_ORDER self-link

This stops ld from endless looping on SHF_LINK_ORDER sh_link loops.

bfd/
PR 27259
* elflink.c (_bfd_elf_gc_mark_extra_sections): Use linker_mark to
prevent endless looping of linked-to sections.
ld/
PR 27259
* ldelf.c (ldelf_before_place_orphans): Use linker_mark to
prevent endless looping of linked-to sections.

[gdb/testsuite] Fix gdb.ada/out_of_line_in_inlined.exp with -m32 and gcc-10

When running test-case gdb.ada/out_of_line_in_inlined.exp with target board
unix/-m32 on a system with gcc-10 default compiler, we run into:
...
(gdb) break foo_o224_021.child1.child2^M
Breakpoint 1 at 0x804ba59: foo_o224_021.child1.child2. (3 locations)^M
(gdb) FAIL: gdb.ada/out_of_line_in_inlined.exp: scenario=all: \
  break foo_o224_021.child1.child2
...

The test does not expect the "3 locations" part.

Fix this by using gdb_breakpoint instead of gdb_test.

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

2021-01-28  Tom de Vries  <tdevries@suse.de>

* gdb.ada/out_of_line_in_inlined.exp: Use gdb_breakpoint.

[gdb/testsuite] Fix ERROR in gdb.dwarf2/dw2-out-of-range-end-of-seq.exp

When running test-case gdb.dwarf2/dw2-out-of-range-end-of-seq.exp on a
system with debug packages installed, I run into:
...
(gdb) maint info line-table^M
  ... <lots of output> ...
ERROR: internal buffer is full.
UNRESOLVED: gdb.dwarf2/dw2-out-of-range-end-of-seq.exp: \
  END with address 1 eliminated
...

Fix this by limiting the output of the command using a regexp.

I also noticed that when making the regexp match nothing, meaning
the command has no output, the test didn't FAIL.  Fixed this by adding a
PASS pattern.

I also noticed that the FAIL pattern didn't work with -m32, fixed that as
well.

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

2021-01-28  Tom de Vries  <tdevries@suse.de>

* gdb.dwarf2/dw2-out-of-range-end-of-seq.exp: Add regexp to
"maint info line-table".  Make PASS pattern more specific.  Make
FAIL pattern work for -m32.

Automatic date update in version.in

Avoid use after free with logging and debug redirect.

This patch addresses PR gdb/27133. Before it, the following succession
of commands would cause gdb to crash:

set logging redirect on
set logging debugredirect on
set logging on

The problem eventually comes down to a use after free. The function
cli_interp_base::set_logging is called with a unique_ptr argument that
holds a pointer to the redirection file. In the problematic use case,
no-one ever took ownership of that pointer (as far as unique_ptr is
concerned), so the call to its dtor at the end of the function causes
the file object to be deleted. Any later use of the pointer to the
redirection file is therefore an error.

This patch ensures that the unique_ptr is released  when required (so it
does not assume ownership anymore). The internal logic of
cli_interp_base::set_logging takes care of freeing the ui_file when it
is not necessary anymore using the saved_output.file_to_delete field.

gdb/ChangeLog:

PR gdb/27133
* cli/cli-interp.c (cli_interp_base::set_logging): Ensure the
unique_ptr is released when the wrapped pointer is kept for later
use.

gdb/testsuite/ChangeLog:

PR gdb/27133
* gdb.base/ui-redirect.exp: Add test case that ensures that
redirecting both logging and debug does not cause gdb to crash.

GDB: aarch64: Add ability to displaced step over a BR/BLR instruction

Enable displaced stepping over a BR/BLR instruction

Displaced stepping over an instruction executes a instruction in a
scratch area and then manually fixes up the PC address to leave
execution where it would have been if the instruction were in its
original location.

The BR instruction does not need modification in order to run correctly
at a different address, but the displaced step fixup method should not
manually adjust the PC since the BR instruction sets that value already.

The BLR instruction should also avoid such a fixup, but must also have
the link register modified to point to just after the original code
location rather than back to the scratch location.

This patch adds the above functionality.
We add this functionality by modifying aarch64_displaced_step_others
rather than by adding a new visitor method to aarch64_insn_visitor.
We choose this since it seems that visitor approach is designed
specifically for PC relative instructions (which must always be modified
when executed in a different location).

It seems that the BR and BLR instructions are more like the RET
instruction which is already handled specially in
aarch64_displaced_step_others.

This also means the gdbserver code to relocate an instruction when
creating a fast tracepoint does not need to be modified, since nothing
special is needed for the BR and BLR instructions there.

Regression tests showed nothing untoward on native aarch64 (though it
took a while for me to get the testcase to account for PIE).

------#####
Original observed (mis)behaviour before was that displaced stepping over
a BR or BLR instruction would not execute the function they called.
Most easily seen by putting a breakpoint with a condition on such an
instruction and a print statement in the functions they called.
When run with the breakpoint enabled the function is not called and
"numargs called" is not printed.
When run with the breakpoint disabled the function is called and the
message is printed.

--- GDB Session
~ [15:57:14] % gdb ../using-blr
Reading symbols from ../using-blr...done.
(gdb) disassemble blr_call_value
Dump of assembler code for function blr_call_value:
...
   0x0000000000400560 <+28>:    blr     x2
...
   0x00000000004005b8 <+116>:   ret
End of assembler dump.
(gdb) break *0x0000000000400560
Breakpoint 1 at 0x400560: file ../using-blr.c, line 22.
(gdb) condition 1 10 == 0
(gdb) run
Starting program: /home/matmal01/using-blr
[Inferior 1 (process 33279) exited with code 012]
(gdb) disable 1
(gdb) run
Starting program: /home/matmal01/using-blr
numargs called
[Inferior 1 (process 33289) exited with code 012]
(gdb)

Test program:
---- using-blr ----
\#include <stdio.h>
typedef int (foo) (int, int);
typedef void (bar) (int, int);
struct sls_testclass {
    foo *x;
    bar *y;
    int left;
    int right;
};

__attribute__ ((noinline))
int blr_call_value (struct sls_testclass x)
{
  int retval = x.x(x.left, x.right);
  if (retval % 10)
    return 100;
  return 9;
}

__attribute__ ((noinline))
int blr_call (struct sls_testclass x)
{
  x.y(x.left, x.right);
  if (x.left % 10)
    return 100;
  return 9;
}

int
numargs (__attribute__ ((unused)) int left, __attribute__ ((unused)) int right)
{
        printf("numargs called\n");
        return 10;
}

void
altfunc (__attribute__ ((unused)) int left, __attribute__ ((unused)) int right)
{
        printf("altfunc called\n");
}

int main(int argc, char **argv)
{
  struct sls_testclass x = { .x = numargs, .y = altfunc, .left = 1, .right = 2 };
  if (argc > 2)
  {
        blr_call (x);
  }
  else
        blr_call_value (x);
  return 10;
}

Remove extra space after @pxref in gdb.texinfo

Internally at AdaCore, documentation is still built with Texinfo 4.13.
This version gave an error when building gdb.texinfo:

../../../binutils-gdb/gdb/doc/gdb.texinfo:27672: @pxref expected braces.
../../../binutils-gdb/gdb/doc/gdb.texinfo:27672: ` {dotdebug_gdb_scripts section,,The @cod...' is too long for expansion; not expanded.

... followed by many more spurious errors that were caused by this
one.

This patch fix the problem by removing the extra space.

I don't know whether it's advisable to try to support this ancient
version of Texinfo (released in 2008 apparently); but in this
particular case the fix is trivial, so I'm checking it in.

gdb/doc/ChangeLog
2021-01-27  Tom Tromey  <tromey@adacore.com>

* gdb.texinfo (Auto-loading extensions): Remove extraneous space.

ld: depend on libctf

Since ld may depend on libctf (if present), and libctf may be relinked
by the installation process, libctf must be installed before ld is,
or the relink may fail if it calls on symbols or symbol versions that do
not exist in any libctf already present on the system.  (If none is
present, the copy in the build tree will be automatically used, but
if one *is* present, it may take precedence and break things.)

(This is a maybe- dependency, so it will work even if libctf is
disabled.)

ChangeLog
2021-01-26  Nick Alcock  <nick.alcock@oracle.com>

PR 27250
* Makefile.def: Add install-libctf dependency to install-ld.
* Makefile.in: Regenerated.

Simplify the code at the end of objcopy's main() function.

 * objcopy.c (copy_main): Remove conditional control of the calls
 to free, simplifying the code and making it easier to detect
 typos.

ld: Fix a typo in testsuite/ld-x86-64/bnd-plt-1.d

Pass -mx86-used-note=no to assembler.

* testsuite/ld-x86-64/bnd-plt-1.d: Fix a typo.

Automatic date update in version.in

nios2: Don't disable relaxation with --gdwarf-N

GCC 11 passes --gdwarf-5 to assembler to enable DWARF5 debug info.  Don't
disable relaxation when --gdwarf-N is specified.  The assembler generated
debug information will treat the sequence of the relaxed instructions as
a single instruction.

PR gas/27243
* config/tc-nios2.c (md_begin): Don't disable relaxation with
--gdwarf-N.
* testsuite/gas/nios2/relax.d: New file.
* testsuite/gas/nios2/relax.s: Likewise.

Use debug_prefixed_printf_cond in windows-nat.c

This changes windows-nat.c and nat/windows-nat.c to use the new
debug_prefixed_printf_cond facility.  I tried this out on a Windows
build and I think it makes the output look a little nicer.

2021-01-26  Tom Tromey  <tromey@adacore.com>

* windows-nat.c (DEBUG_EXEC, DEBUG_EVENTS, DEBUG_MEM)
(DEBUG_EXCEPT): Use debug_prefixed_printf_cond.
(windows_init_thread_list, windows_nat::handle_load_dll)
(windows_nat::handle_unload_dll, windows_nat_target::resume)
(windows_nat_target::resume)
(windows_nat_target::get_windows_debug_event)
(windows_nat_target::interrupt, windows_xfer_memory)
(windows_nat_target::close): Update.
* nat/windows-nat.c (DEBUG_EVENTS): Use
debug_prefixed_printf_cond.
(matching_pending_stop, fetch_pending_stop)
(continue_last_debug_event): Update.