gdb: defer commit resume until all available events are consumed

This patch makes GDB defer commit resume when handling a sequence of
target events.

In fetch_inferior_event, a scoped_restore object is instantiated (if
it's not already) to set the defer_commit_resume flag.  Any resumption
that is the result of handling that event will therefore not be
committed.

If there are other events immediatly consumable, they'll all be handled
while the "defer commit resume flag" is set.  Once do_target_wait returns
false, we know that we have consumed all immediatly available events,
then the "defer commit resume" flag is reset and a commit resume is
issued.

After having handled an event in fetch_inferior_event, we call
mark_infrun_async_event_handler to make sure that fetch_inferior_event
gets called at least once more, to get that final call where
do_target_wait returns no event.

Change-Id: I18112ba19a1ff4986530c660f530d847bb4a1f1d

gdb: add logging in fetch_inferior_event to see the result of do_target_wait

Change-Id: I3a7c3d34d5e13345ce281de052893efefa349892

gdb: add target_ops::supports_displaced_step

A previous patch added some `displaced_step_prepare` and
`displaced_step_finish` methods to allow a target_ops to implement
displaced stepping.  The default implementation is to defer to the
gdbarch.

However, there is still a `gdbarch_supports_displaced_stepping` check in
infrun.c, that decides if we should use displaced stepping or not.  So
if a target_ops implemented displaced stepping, independently of the
gdbarch, displaced stepping wouldn't be used.

Add the target_ops::supports_displaced_step method, with a default
behavior of checking if the gdbarch supports it (which is in sync with
the default implementations of displaced_step_prepare and
displaced_step_finish).

gdb: don't require displaced step copy_insn to be implemented in prepare/finish are

The gdbarch verification currently requires that the gdbarch
displaced_step_prepare and displaced_step_finish methods are provided if
displaced_step_copy_insn is (and not provided if it isn't).

displaced_step_copy_insn is used by the
multiple_displaced_buffer_manager class, but a gdbarch could very well
decide to implement prepare and finish without that, and without
requiring copy_insn.

Remove the dependency in the gdbarch verification between prepare/finish
and copy_insn.  Now, prepare and finish must be both provided or both
not-provided.

Since multiple_displaced_buffer_manager uses the `copy_insn` and `fixup`
gdbarch methods, it now asserts that they are present for the thread
architecture in its `prepare` method.

gdb: add target_ops methods for displaced stepping

Currently, the gdbarch is responsible for preparing the threads for
displaced stepping.  Since some targets specifically provide some
resources for displaced stepping, add some target_ops methods to make it
possible for targets to override the default behavior.  The default
behavior, for targets that don't override it, is to defer to the
gdbarch.

gdb: use two displaced step buffers on amd64-linux

At least as observed with gcc 9, there is enough space at _start to have
two displaced stepping buffers of 16 bytes.

An alternative way is to call mmap in the inferior to allocate one or
more executable pages.  However, this is more intrusive.

gdb: change single_displaced_buffer_manager into multiple_displaced_buffer_manager

single_displaced_buffer_manager, introduced in a previous patch, is
responsible for managing the access to a single displaced step buffer.
We'll want to be able to use more than one, so change it to
multiple_displaced_buffer_manager, which receives a collection of
buffer addresses at construction, instead of a single buffer address.

The callers keep passing a single buffer, however, so there is not
expected behavior change.

gdb: stop trying to prepare displaced steps for an inferior when it returns _UNAVAILABLE

Once we got one _UNAVAILABLE for a given inferior, don't try to prepare
other threads for displaced stepping for that inferior during this
execution of start_step_over.

gdb: move displaced stepping logic to gdbarch, allow starting concurrent displaced steps

Move displaced step logic to gdbarch
====================================

Currently, the task of preparing for a thread to execute a displaced
step is driven by the displaced_step_prepare_throw function.  It does
obviously some calls to the gdbarch to do the specific operations but
the high-level logic is in displaced_step_prepare_throw.  The steps are
roughly:

- Ask the gdbarch for the displaced step buffer location
- Save the existing bytes in the displaced step buffer
- Ask the gdbarch to copy the instruction into the displaced step buffer
- Set the pc of the thread to the beginning of the displaced step buffer

Similarly, the "fixup" phase, executed after the instruction was
successfully single-stepped, is driven by the infrun code (function
displaced_step_fixup).  The steps are roughly:

- Restore the original bytes in the displaced stepping buffer
- Ask the gdbarch to fixup the instruction result (adjust the target's
  registers or memory to do as if the instruction had been executed in
  its original location)

In order to allow some architectures to change how this is done (in
particular to allow using multiple displaced step buffers or sharing
displaced step buffers between threads), this patch makes the whole task
of preparing and finishing a displaced step gdbarch operations.

Two new gdbarch methods are added, with the following sematics:

  - gdbarch_displaced_step_prepare: Prepare for the given thread to
    execute a displaced step.  Upon return, everything should be ready
    for GDB to single step it.
  - gdbarch_displaced_step_finish: Apply any fixup required to
    compensate for the fact that the instruction was executed at
    different place than its original pc. Release any resources that was
    allocated for this displaced step.

The displaced_step_prepare_throw function now pretty much just offloads
to gdbarch_displaced_step_prepare and the displaced_step_finish function
(renamed from displaced_step_fixup) offloads to
gdbarch_displaced_step_finish.

To keep the existing behavior, the logic that was previously implemented
in infrun.c is moved to a new displaced-stepping.c file.  Architectures
currently using displaced stepping are modified to use that new file to
implement the gdbarch methods.

Allow starting concurrent displaced steps
=========================================

Currently, there can only be a single displaced step in progress for
each inferior.  This is enforced in start_step_over:

      /* If this inferior already has a displaced step in process,
 don't start a new one.  */
      if (displaced_step_in_progress (tp->inf))
continue;

Since we want to allow concurrent displaced steps, we need to remove
this constraint.  The core part of GDB handling displaced steps, in
infrun.c, now tries to start as many step-overs as possible.  The
implementation provided by the gdbarch is responsible to decide whether
a given can do a displaced step at this time, and if it is, prepare it.

gdb: rename displaced_step_closure to displaced_step_copy_insn_closure

Since we're going to introduce other "displaced step" functions, make it
clear that it's the return type of the displaced_step_copy_insn family
of functions.

gdb: rename things related to step over chains

Rename step_over_queue_head to global_thread_step_over_chain_head, to
make it more obvious when reading code that we are touching the global
queue.  Rename all functions that operate on it to have "global" in
their name, to make it clear on which chain they operate on.

I also reworded a few comments in gdbthread.h.  They implied that the
step over chain is per-inferior, when in reality there is only one
global chain, as far as I understand.

gdb: tweak format of infrun debug log

Introduce the infrun_log_debug macro and infrun_log_debug_1 helper
function.  This avoids having to repeat `infrun: ` in front of all
messages, and `if (debug_infrun)` at all call sites.

Fix GDB busy loop when interrupting non-stop program (PR 26199)

When interrupting a program in non-stop, the program gets interrupted
correctly, but GDB busy loops (the event loop is always woken up).

Here is how to reproduce it:

 1. Start GDB: ./gdb -nx --data-directory=data-directory -ex "set non-stop 1" --args  /bin/sleep 60
 2. Run the program with "run"
 3. Interrupt with ^C.
 4. Look into htop, see GDB taking 100% CPU

Debugging `handle_file_event`, we see that the event source that wakes
up the event loop is the linux-nat one:

 (top-gdb) p file_ptr.proc
 $5 = (handler_func *) 0xb9cccd <handle_target_event(int, gdb_client_data)>
 ^^^^^^^^^^^^^^^^^^^
 |
 \-- the linux-nat callback

Debugging fetch_inferior_event and do_target_wait, we see that we
don't actually call `wait` on the linux-nat target, because
inferior_matches returns false:

 auto inferior_matches = [&wait_ptid] (inferior *inf)
   {
     return (inf->process_target () != NULL
     && (threads_are_executing (inf->process_target ())
 || threads_are_resumed_pending_p (inf))
     && ptid_t (inf->pid).matches (wait_ptid));
   };

because `threads_are_executing` is false.

What happens is:

 1. User types ctrl-c, that writes in the linux-nat pipe, waking up
    the event source.

 2. linux-nat's wait gets called, the SIGINT event is returned, but
    before returning, it marks the pipe again, in order for wait to
    get called again:

    /* If we requested any event, and something came out, assume there
       may be more.  If we requested a specific lwp or process, also
       assume there may be more.  */
    if (target_is_async_p ()
&& ((ourstatus->kind != TARGET_WAITKIND_IGNORE
     && ourstatus->kind != TARGET_WAITKIND_NO_RESUMED)
    || ptid != minus_one_ptid))
      async_file_mark ();

 3. The SIGINT event is handled, the program is stopped, the stop
    notification is printed.

 4. The event loop is woken up again because of the `async_file_mark`
    of step 2.

 5. Because `inferior_matches` returns false, we never call
    linux-nat's wait, so the pipe stays readable.

 6. Goto 4.

Pedro says:

This commit fixes it by letting do_target_wait call target_wait even
if threads_are_executing is false.  This will normally result in the
target returning TARGET_WAITKIND_NO_RESUMED, and _not_ marking its
event source again.  This results in infrun only calling into the
target only once (i.e., breaking the busy loop).

Note that the busy loop bug didn't trigger in all-stop mode because
all-stop handles this by unregistering the target from the event loop
as soon as it was all stopped -- see
inf-loop.c:inferior_event_handler's INF_EXEC_COMPLETE handling.  If we
remove that non-stop check from inferior_event_handler, and replace
the target_has_execution check for threads_are_executing instead, it
also fixes the issue for non-stop.  I considered that as the final
solution, but decided that the solution proposed here instead is just
simpler and more future-proof design.  With the
TARGET_WAITKIND_NO_RESUMED handling fixes done in the previous
patches, I think it should be possible to always keep the target
registered in the event loop, meaning we could eliminate the
target_async(0) call from inferior_event_handler as well as most of
the target_async(1) calls in the target backends.  That would allow in
the future e.g., the remote target reporting asynchronous
notifications even if all threads are stopped.  I haven't attempted
that, though.

gdb/ChangeLog:
yyyy-mm-dd  Simon Marchi  <simon.marchi@polymtl.ca>
    Pedro Alves  <pedro@palves.net>

PR gdb/26199
* infrun.c (threads_are_resumed_pending_p): Delete.
(do_target_wait): Remove threads_are_executing and
threads_are_resumed_pending_p checks from the inferior_matches
lambda.  Update comments.

Testcase for previous handle_no_resumed fixes

This adds a testcase that covers the scenarios described in the
previous two commits.

gdb/testsuite/ChangeLog:

PR gdb/26199
* gdb.multi/multi-target.c (exit_thread): New.
(thread_start): Break loop if EXIT_THREAD.
* gdb.multi/multi-target.exp (test_no_unwaited_for): New proc.
(top level) Call test_no_resumed.

Make handle_no_resumed transfer terminal

Let's consider the same use case as in the previous commit:

Say you have two inferiors 1 and 2, each connected to a different
target, A and B.

Now say you set inferior 2 running, with "continue &".

Now you select a thread of inferior 1, say thread 1.2, and continue in
the foreground.  All other threads of inferior 1 are left stopped.
Thread 1.2 exits, and thus target A has no other resumed thread, so it
reports TARGET_WAITKIND_NO_RESUMED.

At this point, because the threads of inferior 2 are still executing
the TARGET_WAITKIND_NO_RESUMED event is ignored.

Now, the user types Ctrl-C.  Because GDB had previously put inferior 1
in the foreground, the kernel sends the SIGINT to that inferior.
However, no thread in that inferior is executing right now, so ptrace
never intercepts the SIGINT -- it is never dequeued by any thread.
The result is that GDB's CLI is stuck.  There's no way to get back the
prompt (unless inferior 2 happens to report some event).

The fix in this commit is to make handle_no_resumed give the terminal
to some other inferior that still has threads executing so that a
subsequent Ctrl-C reaches that target first (and then GDB intercepts
the SIGINT).  This is a bit hacky, but seems like the best we can do
with the current design.

I think that putting all native inferiors in their own session would
help fixing this in a clean way, since with that a Ctrl-C on GDB's
terminal will _always_ reach GDB first, and then GDB can decide how to
pause the inferior.  But that's a much larger change.

The testcase added by the following patch needs this fix.

gdb/ChangeLog:

PR gdb/26199
* infrun.c (handle_no_resumed): Transfer terminal to inferior with
executing threads.

Fix handle_no_resumed w/ multiple targets

handle_no_resumed is currently not considering multiple targets.

Say you have two inferiors 1 and 2, each connected to a different
target, A and B.

Now say you set inferior 2 running, with "continue &".

Now you select a thread of inferior 1, say thread 1.2, and continue in
the foreground.  All other threads of inferior 1 are left stopped.
Thread 1.2 exits, and thus target A has no other resumed thread, so it
reports TARGET_WAITKIND_NO_RESUMED.

At this point, if both inferiors were running in the same target,
handle_no_resumed would realize that threads of inferior 2 are still
executing, so the TARGET_WAITKIND_NO_RESUMED event should be ignored.
But because handle_no_resumed only walks the threads of the current
target, it misses noticing that threads of inferior 2 are still
executing.  The fix is just to walk over all threads of all targets.

A testcase covering the use case above will be added in a following
patch.  It can't be added yet because it depends on yet another fix to
handle_no_resumed not included here.

gdb/ChangeLog:

PR gdb/26199
* infrun.c (handle_no_resumed): Handle multiple targets.

Avoid constant stream of TARGET_WAITKIND_NO_RESUMED

If we hit the synchronous execution command case described by
handle_no_resumed, and handle_no_resumed determines that the event
should be ignored, because it found a thread that is executing, we end
up in prepare_to_wait.

There, if the current target is not registered in the event loop right
now, we call mark_infrun_async_event_handler.  With that event handler
marked, the event loop calls again into fetch_inferior_event, which
calls target_wait, which returns TARGET_WAITKIND_NO_RESUMED, and we
end up in handle_no_resumed, again ignoring the event and marking
infrun_async_event_handler.  The result is that GDB is now always
keeping the CPU 100% busy in this loop, even though it continues to be
able to react to input and to real target events, because we still go
through the event-loop.

The problem is that marking of the infrun_async_event_handler in
prepare_to_wait.  That is there to handle targets that don't support
asynchronous execution.  So the correct predicate is whether async
execution is supported, not whether the target is async right now.

gdb/ChangeLog:

PR gdb/26199
* infrun.c (prepare_to_wait): Check target_can_async_p instead of
target_is_async_p.

Fix latent bug in target_pass_ctrlc

We were checking the thr->executing of an exited thread.

gdb/ChangeLog:

PR gdb/26199
* target.c (target_pass_ctrlc): Looking at the inferiors
non-exited threads, not all threads.

Fix spurious unhandled remote %Stop notifications

In non-stop mode, remote targets mark an async event source whose
callback is supposed to result in calling remote_target::wait_ns to
either process the event queue, or acknowledge an incoming %Stop
notification.

The callback in question is remote_async_inferior_event_handler, where
we call inferior_event_handler, to end up in fetch_inferior_event ->
target_wait -> remote_target::wait -> remote_target::wait_ns.

A problem here however is that when debugging multiple targets,
fetch_inferior_event can pull events out of any target picked at
random, for event fairness.  This means that when
remote_async_inferior_event_handler returns, remote_target::wait may
have not been called at all, and thus pending notifications may have
not been acked.  Because async event sources auto-clear, when
remote_async_inferior_event_handler returns the async event handler is
no longer marked, so the event loop won't automatically call
remote_async_inferior_event_handler again to try to process the
pending remote notifications/queue.  The result is that stop events
may end up not processed, e.g., "interrupt -a" seemingly not managing
to stop all threads.

Fix this by making remote_async_inferior_event_handler mark the event
handler again before returning, if necessary.

Maybe a better fix would be to make async event handlers not
auto-clear themselves, make that the responsibility of the callback,
so that the event loop would keep calling the callback automatically.
Or, we could try making so that fetch_inferior_event would optionally
handle events only for the target that it got passed down via
parameter.  However, I don't think now just before branching is the
time to try to do any such change.

gdb/ChangeLog:

PR gdb/26199
* remote.c (remote_target::open_1): Pass remote target pointer as
data to create_async_event_handler.
(remote_async_inferior_event_handler): Mark async event handler
before returning if the remote target still has either pending
events or unacknowledged notifications.

Rename the 'obfd' argument to fbsd_nat_target::find_memory_regions.

The argument is passed as a generic cookie value to the supplied
callback and is not necessarily a pointer to a bfd.

gdb/ChangeLog:

* fbsd-nat.c (fbsd_nat_target::find_memory_regions): Rename 'obfd'
argument to 'data'.

Use read_memory in ada_exception_message_1

Testing using the internal AdaCore test suite showed a regression from
the target string reading changes.  In particular, now
ada_exception_message_1 can get the wrong answer in some cases.  In
particular, when an Ada exception catchpoint is hit, sometimes the
exception name will be incorrect.  The case I was seeing changed from
the correct:

    Catchpoint 2, CONSTRAINT_ERROR (catch C_E) at [...]

to:

    Catchpoint 2, CONSTRAINT_ERROR (catch C_EE) at [...]

I was not able to reproduce this failure with the Fedora gnat.
Perhaps it is related to some local change to gnat; I do not know.

Meanwhile, because ada_exception_message_1 knows the length of the
string to read, we can use read_memory here.  This fixes the bug.

I've updated the test suite to at least exercise this code path.
However, as mentioned above, the new test does not actually provoke
the failure.

gdb/ChangeLog
2020-07-08  Tom Tromey  <tromey@adacore.com>

* ada-lang.c (ada_exception_message_1): Use read_memory.

gdb/testsuite/ChangeLog
2020-07-08  Tom Tromey  <tromey@adacore.com>

* gdb.ada/catch_ex/foo.adb: Pass string to raise.
* gdb.ada/catch_ex.exp: Examine catchpoint text.

Commit: Fix GOLD testsuite failures for 2.35 branch.

* testsuite/script_test_7.sh: Adjust expected address of the .bss
section.
* testsuite/script_test_9.sh: Do not expect the .init section to
immediately follow the .text section in the mapping of sections to
segments.

x86: various XOP insns lack L and/or W bit decoding

While some insns support both XOP.W based operand swapping and 256-bit
operation (XOP.L=1), many others don't support one or both.

For {L,S}LWPCB also fix the so far not decoded ModRM.mod == 3
restriction.

Take the opportunity and replace the custom OP_LWP_E() and OP_LWPCB_E()
routines by suitable other, non-custom operanbd specifiers.

x86: FMA4 scalar insns ignore VEX.L

Just like other VEX-encoded scalar insns do.

Besides a testcase for this behavior also introduce one to verify that
XOP scalar insns don't honor -mavxscalar=256, as they don't ignore
XOP.L.

x86: re-work operand swapping for XOP shift/rotate insns

There's no need for custom operand handling here, except for the VEX.W
controlled operand swapping.

x86: re-work operand handling for 5-operand XOP insns

There's no need for custom operand handling here, except for the VEX.W
controlled operand swapping and the printing of the remaining 4-bit
immediate. VEX.W can be handled just like 4-operand insns.

Also take the opportunity and drop the stray indirection through
vex_w_table[].

x86: re-work operand swapping for FMA4 and 4-operand XOP insns

There's no need for custom operand handling here, except for the VEX.W
controlled operand swapping. The latter can be easily integrated into
OP_REG_VexI4().

powerpc-aix5.2 tests

git commit bbd0c8e20472 broke many of these tests, and there have been
other changes that caused failures too.

* testsuite/lib/ld-lib.exp (ar_simple_create): Pass options before
ar command.
* testsuite/ld-powerpc/aix52.exp: Run for rs6000-aix5.2.  Update
match files.
* testsuite/ld-powerpc/aix-abs-branch-1.dd: Update.
* testsuite/ld-powerpc/aix-core-sec-1.hd: Update.
* testsuite/ld-powerpc/aix-gc-1-32.dd: Update.
* testsuite/ld-powerpc/aix-gc-1-64.dd: Update.
* testsuite/ld-powerpc/aix-glink-1-32.dd: Update.
* testsuite/ld-powerpc/aix-glink-1-64.dd: Update.
* testsuite/ld-powerpc/aix-glink-2-32.dd: Update.
* testsuite/ld-powerpc/aix-glink-2-64.dd: Update.
* testsuite/ld-powerpc/aix-no-dup-syms-1-rel.rd: Update.
* testsuite/ld-powerpc/aix-ref-1-32.od: Update.
* testsuite/ld-powerpc/aix-ref-1-64.od: Update.
* testsuite/ld-powerpc/aix-toc-1-32.dd: Update.
* testsuite/ld-powerpc/aix-toc-1-64.dd: Update.
* testsuite/ld-powerpc/aix-weak-3-32.dd: Update.
* testsuite/ld-powerpc/aix-weak-3-64.dd: Update.
* testsuite/ld-powerpc/aix-abs-branch-1.nd: Delete, replace with..
* testsuite/ld-powerpc/aix-abs-branch-1-32.nd,
* testsuite/ld-powerpc/aix-abs-branch-1-64.nd: ..these new files.
* testsuite/ld-powerpc/aix-abs-reloc-1.nd: Delete, replace with..
* testsuite/ld-powerpc/aix-abs-reloc-1-32.nd,
* testsuite/ld-powerpc/aix-abs-reloc-1-64.nd: ..these new files.
* testsuite/ld-powerpc/aix-abs-reloc-1.od: Delete, replace with..
* testsuite/ld-powerpc/aix-abs-reloc-1-32.od,
* testsuite/ld-powerpc/aix-abs-reloc-1-64.od: ..these new files.
* testsuite/ld-powerpc/aix-export-1-all.dd: Delete, replace with..
* testsuite/ld-powerpc/aix-export-1-all-32.dd,
* testsuite/ld-powerpc/aix-export-1-all-64.dd: ..these new files.
* testsuite/ld-powerpc/aix-export-1-full.dd: Delete, replace with..
* testsuite/ld-powerpc/aix-export-1-full-32.dd,
* testsuite/ld-powerpc/aix-export-1-full-64.dd: ..these new files.
* testsuite/ld-powerpc/aix-export-2.nd: Delete, replace with..
* testsuite/ld-powerpc/aix-export-2-32.nd,
* testsuite/ld-powerpc/aix-export-2-64.nd: ..these new files.
* testsuite/ld-powerpc/aix-gc-1.nd: Delete, replace with..
* testsuite/ld-powerpc/aix-gc-1-32.nd,
* testsuite/ld-powerpc/aix-gc-1-64.nd: ..these new files.
* testsuite/ld-powerpc/aix-glink-3.dd: Delete, replace with..
* testsuite/ld-powerpc/aix-glink-3-32.dd,
* testsuite/ld-powerpc/aix-glink-3-64.dd: ..these new files.
* testsuite/ld-powerpc/aix-lineno-1a.dd: Delete, replace with..
* testsuite/ld-powerpc/aix-lineno-1a-32.dd,
* testsuite/ld-powerpc/aix-lineno-1a-64.dd: ..these new files.
* testsuite/ld-powerpc/aix-lineno-1a.nd: Delete, replace with..
* testsuite/ld-powerpc/aix-lineno-1a-32.nd,
* testsuite/ld-powerpc/aix-lineno-1a-64.nd: ..these new files.
* testsuite/ld-powerpc/aix-lineno-1b.dd: Delete, replace with..
* testsuite/ld-powerpc/aix-lineno-1b-32.dd,
* testsuite/ld-powerpc/aix-lineno-1b-64.dd: ..these new files.
* testsuite/ld-powerpc/aix-lineno-1b.nd: Delete, replace with..
* testsuite/ld-powerpc/aix-lineno-1b-32.nd,
* testsuite/ld-powerpc/aix-lineno-1b-64.nd: ..these new files.
* testsuite/ld-powerpc/aix-no-dup-syms-1-dso.dnd: Delete, replace with..
* testsuite/ld-powerpc/aix-no-dup-syms-1-dso-32.dnd,
* testsuite/ld-powerpc/aix-no-dup-syms-1-dso-64.dnd: ..these new files.
* testsuite/ld-powerpc/aix-no-dup-syms-1-dso.drd: Delete, replace with..
* testsuite/ld-powerpc/aix-no-dup-syms-1-dso-32.drd,
* testsuite/ld-powerpc/aix-no-dup-syms-1-dso-64.drd: ..these new files.
* testsuite/ld-powerpc/aix-no-dup-syms-1-dso.nd: Delete, replace with..
* testsuite/ld-powerpc/aix-no-dup-syms-1-dso-32.nd,
* testsuite/ld-powerpc/aix-no-dup-syms-1-dso-64.nd: ..these new files.
* testsuite/ld-powerpc/aix-no-dup-syms-1-dso.rd: Delete, replace with..
* testsuite/ld-powerpc/aix-no-dup-syms-1-dso-32.rd,
* testsuite/ld-powerpc/aix-no-dup-syms-1-dso-64.rd: ..these new files.
* testsuite/ld-powerpc/aix-weak-1-dso.dnd: Delete, replace with..
* testsuite/ld-powerpc/aix-weak-1-dso-32.dnd,
* testsuite/ld-powerpc/aix-weak-1-dso-64.dnd: ..these new files.
* testsuite/ld-powerpc/aix-weak-1-dso.hd: Delete, replace with..
* testsuite/ld-powerpc/aix-weak-1-dso-32.hd,
* testsuite/ld-powerpc/aix-weak-1-dso-64.hd: ..these new files.
* testsuite/ld-powerpc/aix-weak-1-dso.nd: Delete, replace with..
* testsuite/ld-powerpc/aix-weak-1-dso-32.nd,
* testsuite/ld-powerpc/aix-weak-1-dso-64.nd: ..these new files.
* testsuite/ld-powerpc/aix-weak-1-gcdso.dnd: Delete, replace with..
* testsuite/ld-powerpc/aix-weak-1-gcdso-32.dnd,
* testsuite/ld-powerpc/aix-weak-1-gcdso-64.dnd: ..these new files.
* testsuite/ld-powerpc/aix-weak-1-gcdso.hd: Delete, replace with..
* testsuite/ld-powerpc/aix-weak-1-gcdso-32.hd,
* testsuite/ld-powerpc/aix-weak-1-gcdso-64.hd: ..these new files.
* testsuite/ld-powerpc/aix-weak-1-gcdso.nd: Delete, replace with..
* testsuite/ld-powerpc/aix-weak-1-gcdso-32.nd,
* testsuite/ld-powerpc/aix-weak-1-gcdso-64.nd: ..these new files.
* testsuite/ld-powerpc/aix-weak-2a.nd: Delete, replace with..
* testsuite/ld-powerpc/aix-weak-2a-32.nd,
* testsuite/ld-powerpc/aix-weak-2a-64.nd: ..these new files.
* testsuite/ld-powerpc/aix-weak-2b.nd: Delete, replace with..
* testsuite/ld-powerpc/aix-weak-2b-32.nd,
* testsuite/ld-powerpc/aix-weak-2b-64.nd: ..these new files.
* testsuite/ld-powerpc/aix-weak-2c.nd: Delete, replace with..
* testsuite/ld-powerpc/aix-weak-2c-32.nd,
* testsuite/ld-powerpc/aix-weak-2c-64.nd: ..these new files.
* testsuite/ld-powerpc/aix-weak-2c.od: Delete, replace with..
* testsuite/ld-powerpc/aix-weak-2c-32.od,
* testsuite/ld-powerpc/aix-weak-2c-64.od: ..these new files.

Automatic date update in version.in

arc: Improve error messages when assembling

gas/
xxxx-xx-xx  Claudiu Zissulescu  <claziss@synopsys.com>

* config/tc-arc.c (find_opcode_match): Add error messages.
* testsuite/gas/arc/add_s-err.s: Update test.
* testsuite/gas/arc/asm-errors.err: Likewise.
* testsuite/gas/arc/cpu-em-err.s: Likewise.
* testsuite/gas/arc/hregs-err.s: Likewise.
* testsuite/gas/arc/warn.s: Likewise.

arc: Update vector instructions.

Update vadd2, vadd4h, vmac2h, vmpy2h, vsub4h vector instructions
arguments to discriminate between double/single register operands.

opcodes/
xxxx-xx-xx  Claudiu Zissulescu  <claziss@synopsys.com>

* arc-opc.c (insert_rbd): New function.
(RBD): Define.
(RBDdup): Likewise.
* arc-tbl.h (vadd2, vadd4h, vmac2h, vmpy2h, vsub4h): Update
instructions.

Signed-off-by: Claudiu Zissulescu <claziss@gmail.com>

Re: Use is_xcoff_format in ld testsuite

git commit 7193487fa8 took h8300 out of the notarget list, resulting in
h8300-elf  +FAIL: ld-scripts/section-match-1
h8300-linux  +FAIL: ld-scripts/section-match-1

* testsuite/ld-scripts/section-match-1.d: xfail h8300.

x86: Remove an incorrect AVX2 entry

The upper 16 vector registers were added by AVX512.

PR gas/26212
* doc/c-i386.texi: Remove an incorrect AVX2 entry.

XCOFF ld testsuite fixes

* testsuite/ld-scripts/align.exp: Don't exclude xcoff.  Pass
-bnogc ld option for xcoff.
* testsuite/ld-scripts/provide.exp: Likewise.
* testsuite/ld-scripts/data.exp: Pass -bnogc ld option for xcoff.
* testsuite/ld-scripts/default-script.exp: Likewise.
* testsuite/ld-scripts/defined.exp: Likewise.
* testsuite/ld-scripts/empty-address.exp: Likewise.
* testsuite/ld-scripts/expr.exp: Likewise.
* testsuite/ld-scripts/include.exp: Likewise.
* testsuite/ld-scripts/script.exp: Likewise.
* testsuite/ld-scripts/assign-loc.d: Don't exclude xcoff.
* testsuite/ld-scripts/defined3.d: Likewise.
* testsuite/ld-scripts/defined4.d: Likewise.
* testsuite/ld-scripts/pr18963.d: Likewise.
* testsuite/ld-scripts/sane1.d: Likewise.
* testsuite/ld-scripts/segment-start.d: Likewise.
* testsuite/ld-scripts/include-1.d: Likewise, and relax text vma.
* testsuite/ld-scripts/defined5.d: Update xfail and comment.
* testsuite/ld-scripts/defined5.s: Tweak "defined" to be at
non-zero section offset.
* testsuite/ld-scripts/fill16.d: xfail for xcoff.
* testsuite/ld-scripts/provide-2.d: Accept more symbols.
* testsuite/ld-scripts/provide-4.d: Likewise.
* testsuite/ld-scripts/provide-5.d: Likewise.
* testsuite/ld-scripts/provide-6.d: Likewise.
* testsuite/ld-scripts/provide-7.d: Likewise.
* testsuite/ld-scripts/align.t: Accept xcoff mapped .text and .data.
* testsuite/ld-scripts/defined3.t: Likewise.
* testsuite/ld-scripts/defined4.t: Likewise.
* testsuite/ld-scripts/defined5.t: Likewise.
* testsuite/ld-scripts/fill.t: Likewise.
* testsuite/ld-scripts/include-subdata.t: Likewise.
* testsuite/ld-scripts/provide-1.t: Likewise.
* testsuite/ld-scripts/provide-2.t: Likewise.
* testsuite/ld-scripts/provide-3.t: Likewise.
* testsuite/ld-scripts/provide-4.t: Likewise.
* testsuite/ld-scripts/provide-5.t: Likewise.
* testsuite/ld-scripts/provide-6.t: Likewise.
* testsuite/ld-scripts/provide-7.t: Likewise.
* testsuite/ld-scripts/provide-8.t: Likewise.
* testsuite/ld-scripts/assign-loc.t: Add required xcoff sections.
* testsuite/ld-scripts/sizeof.t: Likewise.
* testsuite/ld-scripts/align2.t: Likewise, and mapped sections.
* testsuite/ld-scripts/align5.t: Likewise.
* testsuite/ld-scripts/default-script.t: Likewise.
* testsuite/ld-scripts/empty-address-1.t: Likewise.
* testsuite/ld-scripts/empty-address-2a.t: Likewise.
* testsuite/ld-scripts/empty-address-2b.t: Likewise.
* testsuite/ld-scripts/empty-address-3a.t: Likewise.
* testsuite/ld-scripts/empty-address-3b.t: Likewise.
* testsuite/ld-scripts/empty-address-3c.t: Likewise.
* testsuite/ld-scripts/include-sections.t: Likewise.
* testsuite/ld-scripts/pr14962.t: Likewise.
* testsuite/ld-scripts/sane1.t: Likewise.

Use is_pecoff_format in ld testsuite

--image-base 0 is not just for x86_64 mingw.  This patch fixes that,
and a case where a changed LDFLAGS leaked out of one script to the next.

* testsuite/ld-scripts/align.exp: Use is_pecoff_format.
* testsuite/ld-scripts/defined.exp: Likewise.
* testsuite/ld-scripts/provide.exp: Likewise.
* testsuite/ld-scripts/weak.exp: Likewise.
* testsuite/ld-scripts/empty-address.exp: Likewise.  Reset LDFLAGS
on exit.
* testsuite/ld-scripts/expr.exp: Set LDFLAGS earlier, and with
--image-base for PE.
* testsuite/ld-scripts/include.exp: Set LDFLAGS for PE.
* testsuite/ld-scripts/script.exp: Use is_pecoff_format, and
set LDFLAGS as well as flags.

Use is_xcoff_format in ld testsuite

* testsuite/ld-checks/checks.exp: Use is_xcoff_format.
* testsuite/ld-powerpc/powerpc.exp: Likewise.
* testsuite/ld-scripts/print-memory-usage.exp: Likewise.
* testsuite/ld-srec/srec.exp: Likewise.
* testsuite/ld-undefined/require-defined.exp: Likewise.
* testsuite/ld-scripts/expr2.d: Likewise.
* testsuite/ld-scripts/section-match-1.d: Only run for ELF.
* testsuite/ld-elfvers/vers.exp: Delete dead code.
* testsuite/ld-elfvsb/elfvsb.exp: Likewise.
* testsuite/ld-elfweak/elfweak.exp: Likewise.

Use is_xcoff_format in gas testsuite

* testsuite/gas/all/gas.exp: Use is_xcoff_format.
* testsuite/gas/ppc/ppc.exp: Likewise.
* testsuite/gas/all/weakref1l.d: Likewise.

Use is_xcoff_format in binutils testsuite

and restrict some other tests using is_*_format.

* testsuite/binutils-all/ar.exp: Use is_xcoff_format.
* testsuite/binutils-all/nm.exp: Likewise.
* testsuite/binutils-all/copy-2.d: Run only for elf and pe targets.
* testsuite/binutils-all/copy-3.d: Run only for elf targets.
* testsuite/binutils-all/set-section-alignment.d: Likewise.
* testsuite/binutils-all/copy-4.d: Don't run for xcoff.

XCOFF binutils testsuite fix

Avoid an UNRESOLVED test due to "Error: the XCOFF file format does not
support arbitrary sections".

* testsuite/lib/binutils-common.exp (is_xcoff_format): New.
* testsuite/binutils-all/objcopy.exp (pr25662): Exclude xcoff.

XCOFF linker script PROVIDE support

Fixes bit rot from git commit b46a87b1606.

* emultempl/aix.em (gld${EMULATION_NAME}_find_exp_assignment): Handle
etree_provided.

XCOFF ld segfaults when running ld testsuite

The binutils XCOFF support doesn't handle random linker scripts very
well at all.  These tweaks to final_link fix segfaults when some
linker created sections are discarded due to "/DISCARD/ : { *(.*) }"
in scripts.  The xcoff_mark change is necessary to not segfault on
symbols defined in scripts, which may be bfd_link_hash_defined yet
have u.def.section set to bfd_und_section_ptr.  (Which might seem odd,
but occurs during early stages of linking before input sections are
mapped.)

* xcofflink.c (xcoff_mark): Don't mark const sections.
(bfd_xcoff_record_link_assignment): Add FIXME.
(_bfd_xcoff_bfd_final_link): Don't segfault on assorted magic
sections being discarded by linker script.

XCOFF deterministic archives

Adds support for "ar -D".

* coff-rs6000.c (xcoff_write_archive_contents_old): Set default
time, uid, gid and mode for deterministic archive.
(xcoff_write_archive_contents_big): Likewise.

XCOFF C_HIDEXT and C_AIX_WEAKEXT classification

If C_HIDEXT and C_AIX_WEAKEXT symbols aren't handled as globals by
coff_classify_symbol then we run into "warning: .. local symbol `some
garbage name' has no section".  These are of course both global
symbols, but C_HIDEXT is like a local in some respects and returning
COFF_SYMBOL_LOCAL for C_HIDEXT keeps nm output looking the same.
Fixes these fails on rs6000-aix5.1:

-FAIL: weakref tests, relocations
-FAIL: weakref tests, global syms
-FAIL: weakref tests, strong undefined syms
-FAIL: weakref tests, weak undefined syms

* coffcode.h (coff_classify_symbol): Handle C_HIDEXT and
C_AIX_WEAKEXT.

sh vxworks tests

These tests were failing only due to not being updated for readelf
output changes.

* testsuite/ld-sh/vxworks1-lib.rd: Update expected output.
* testsuite/ld-sh/vxworks4.d: Likewise.

Stop the GOLD linker from complaining about relocations from .gnu.build.attributes sections to discarded code sections.

* target-reloc.h (Default_comdat_behaviour:get): Ignore discarded
relocs that refer to the .gnu.build.attributes section.

Fix recent failures in the ARM assembler testsuite due to the correction of a spelling mistake.

* testsuite/gas/arm/cde-missing-fp.l: Fix spelling mistake in
expected output.

x86: introduce %BW to avoid going through vex_w_table[]

This parallels %LW and %XW.

Automatic date update in version.in

gdb: Python unwinders, inline frames, and tail-call frames

This started with me running into the bug described in python/22748,
in summary, if the frame sniffing code accessed any registers within
an inline frame then GDB would crash with this error:

  gdb/frame.c:579: internal-error: frame_id get_frame_id(frame_info*): Assertion `fi->level == 0' failed.

The problem is that, when in the Python unwinder I write this:

  pending_frame.read_register ("register-name")

This is translated internally into a call to `value_of_register',
which in turn becomes a call to `value_of_register_lazy'.

Usually this isn't a problem, `value_of_register_lazy' requires the
next frame (more inner) to have a valid frame_id, which will be the
case (if we're sniffing frame #1, then frame #0 will have had its
frame-id figured out).

Unfortunately if frame #0 is inline within frame #1, then the frame-id
for frame #0 can't be computed until we have the frame-id for #1.  As
a result we can't create a lazy register for frame #1 when frame #0 is
inline.

Initially I proposed a solution inline with that proposed in bugzilla,
changing value_of_register to avoid creating a lazy register value.
However, when this was discussed on the mailing list I got this reply:

  https://sourceware.org/pipermail/gdb-patches/2020-June/169633.html

Which led me to look at these two patches:

  [1] https://sourceware.org/pipermail/gdb-patches/2020-April/167612.html
  [2] https://sourceware.org/pipermail/gdb-patches/2020-April/167930.html

When I considered patches [1] and [2] I saw that all of the issues
being addressed here were related, and that there was a single
solution that could address all of these issues.

First I wrote the new test gdb.opt/inline-frame-tailcall.exp, which
shows that [1] and [2] regress the inline tail-call unwinder, the
reason for this is that these two patches replace a call to
gdbarch_unwind_pc with a call to get_frame_register, however, this is
not correct.  The previous call to gdbarch_unwind_pc takes THIS_FRAME
and returns the $pc value in the previous frame.  In contrast
get_frame_register takes THIS_FRAME and returns the value of the $pc
in THIS_FRAME; these calls are not equivalent.

The reason these patches appear (or do) fix the regressions listed in
[1] is that the tail call sniffer depends on identifying the address
of a caller and a callee, GDB then looks for a tail-call sequence that
takes us from the caller address to the callee, if such a series is
found then tail-call frames are added.

The bug that was being hit, and which was address in patch [1] is that
in order to find the address of the caller, GDB ended up creating a
lazy register value for an inline frame with to frame-id.  The
solution in patch [1] is to instead take the address of the callee and
treat this as the address of the caller.  Getting the address of the
callee works, but we then end up looking for a tail-call series from
the callee to the callee, which obviously doesn't return any sane
results, so we don't insert any tail call frames.

The original patch [1] did cause some breakage, so patch [2] undid
patch [1] in all cases except those where we had an inline frame with
no frame-id.  It just so happens that there were no tests that fitted
this description _and_ which required tail-call frames to be
successfully spotted, as a result patch [2] appeared to work.

The new test inline-frame-tailcall.exp, exposes the flaw in patch [2].

This commit undoes patch [1] and [2], and replaces them with a new
solution, which is also different to the solution proposed in the
python/22748 bug report.

In this solution I propose that we introduce some special case logic
to value_of_register_lazy.  To understand what this logic is we must
first look at how inline frames unwind registers, this is very simple,
they do this:

  static struct value *
  inline_frame_prev_register (struct frame_info *this_frame,
                              void **this_cache, int regnum)
  {
    return get_frame_register_value (this_frame, regnum);
  }

And remember:

  struct value *
  get_frame_register_value (struct frame_info *frame, int regnum)
  {
    return frame_unwind_register_value (frame->next, regnum);
  }

So in all cases, unwinding a register in an inline frame just asks the
next frame to unwind the register, this makes sense, as an inline
frame doesn't really exist, when we unwind a register in an inline
frame, we're really just asking the next frame for the value of the
register in the previous, non-inline frame.

So, if we assume that we only get into the missing frame-id situation
when we try to unwind a register from an inline frame during the frame
sniffing process, then we can change value_of_register_lazy to not
create lazy register values for an inline frame.

Imagine this stack setup, where #1 is inline within #2.

  #3 -> #2 -> #1 -> #0
        \______/
         inline

Now when trying to figure out the frame-id for #1, we need to compute
the frame-id for #2.  If the frame sniffer for #2 causes a lazy
register read in #2, either due to a Python Unwinder, or for the
tail-call sniffer, then we call value_of_register_lazy passing in
frame #2.

In value_of_register_lazy, we grab the next frame, which is #1, and we
used to then ask for the frame-id of #1, which was not computed, and
this was our bug.

Now, I propose we spot that #1 is an inline frame, and so lookup the
next frame of #1, which is #0.  As #0 is not inline it will have a
valid frame-id, and so we create a lazy register value using #0 as the
next-frame-id.  This will give us the exact same result we had
previously (thanks to the code we inspected above).

Encoding into value_of_register_lazy the knowledge that reading an
inline frame register will always just forward to the next frame
feels.... not ideal, but this seems like the cleanest solution to this
recursive frame-id computation/sniffing issue that appears to crop
up.

The following two commits are fully reverted with this commit, these
correspond to patches [1] and [2] respectively:

  commit 5939967b355ba6a940887d19847b7893a4506067
  Date:   Tue Apr 14 17:26:22 2020 -0300

      Fix inline frame unwinding breakage

  commit 991a3e2e9944a4b3a27bd989ac03c18285bd545d
  Date:   Sat Apr 25 00:32:44 2020 -0300

      Fix remaining inline/tailcall unwinding breakage for x86_64

gdb/ChangeLog:

PR python/22748
* dwarf2/frame-tailcall.c (dwarf2_tailcall_sniffer_first): Remove
special handling for inline frames.
* findvar.c (value_of_register_lazy): Skip inline frames when
creating lazy register values.
* frame.c (frame_id_computed_p): Delete definition.
* frame.h (frame_id_computed_p): Delete declaration.

gdb/testsuite/ChangeLog:

PR python/22748
* gdb.opt/inline-frame-tailcall.c: New file.
* gdb.opt/inline-frame-tailcall.exp: New file.
* gdb.python/py-unwind-inline.c: New file.
* gdb.python/py-unwind-inline.exp: New file.
* gdb.python/py-unwind-inline.py: New file.

gdb/python: New method to access list of register groups

Add a new method gdb.Architecture.register_groups which returns a new
object of type gdb.RegisterGroupsIterator.  This new iterator then
returns objects of type gdb.RegisterGroup.

Each gdb.RegisterGroup object just wraps a single reggroup pointer,
and (currently) has just one read-only property 'name' that is a
string, the name of the register group.

As with the previous commit (adding gdb.RegisterDescriptor) I made
gdb.RegisterGroup an object rather than just a string in case we want
to add additional properties in the future.

gdb/ChangeLog:

* NEWS: Mention additions to Python API.
* python/py-arch.c (archpy_register_groups): New function.
(arch_object_methods): Add 'register_groups' method.
* python/py-registers.c (reggroup_iterator_object): New struct.
(reggroup_object): New struct.
(gdbpy_new_reggroup): New function.
(gdbpy_reggroup_to_string): New function.
(gdbpy_reggroup_name): New function.
(gdbpy_reggroup_iter): New function.
(gdbpy_reggroup_iter_next): New function.
(gdbpy_new_reggroup_iterator): New function
(gdbpy_initialize_registers): Register new types.
(reggroup_iterator_object_type): Define new Python type.
(gdbpy_reggroup_getset): New static global.
(reggroup_object_type): Define new Python type.
* python/python-internal.h

gdb/testsuite/ChangeLog:

* gdb.python/py-arch-reg-groups.exp: New file.

gdb/doc/ChangeLog:

* gdb.texi (Registers): Add @anchor for 'info registers
<reggroup>' command.
* python.texi (Architectures In Python): Document new
register_groups method.
(Registers In Python): Document two new object types related to
register groups.

gdb/python: Add gdb.Architecture.registers method

This commit adds a new method gdb.Architecture.registers that returns
an object of the new type gdb.RegisterDescriptorIterator.  This
iterator returns objects of the new type gdb.RegisterDescriptor.

A RegisterDescriptor is not a way to read the value of a register,
this is already covered by Frame.read_register, a RegisterDescriptor
is simply a way to discover from Python, which registers are
available for a given architecture.

I did consider just returning a string, the name of each register,
instead of a RegisterDescriptor, however, I'm aware that it we don't
want to break the existing Python API in any way, so if I return just
a string now, but in the future we want more information about a
register then we would have to add a second API to get that
information.  By going straight to a descriptor object now, it is easy
to add additional properties in the future should we wish to.

Right now the only property of a register that a user can access is
the name of the register.

In future we might want to be able to ask the register about is
register groups, or its type.

gdb/ChangeLog:

* Makefile.in (SUBDIR_PYTHON_SRCS): Add py-registers.c
* python/py-arch.c (archpy_registers): New function.
(arch_object_methods): Add 'registers' method.
* python/py-registers.c: New file.
* python/python-internal.h
(gdbpy_new_register_descriptor_iterator): Declare.
(gdbpy_initialize_registers): Declare.
* python/python.c (do_start_initialization): Call
gdbpy_initialize_registers.
* NEWS: Mention additions to the Python API.

gdb/testsuite/ChangeLog:

* gdb.python/py-arch-reg-names.exp: New file.

gdb/doc/ChangeLog:

* python.texi (Python API): Add new section the menu.
(Frames In Python): Add new @anchor.
(Architectures In Python): Document new registers method.
(Registers In Python): New section.

gdb/python: Add architecture method to gdb.PendingFrame

It could be useful to determine the architecture of a frame being
unwound during the frame unwind process, that is, before we have a
gdb.Frame, but when we only have a gdb.PendingFrame.

The PendingFrame already has a pointer to the gdbarch internally, this
commit just exposes an 'architecture' method to Python, and has this
return a gdb.Architecture object (list gdb.Frame.architecture does).

gdb/ChangeLog:

* NEWS: Mention new Python API method.
* python/py-unwind.c (pending_framepy_architecture): New function.
(pending_frame_object_methods): Add architecture method.

gdb/testsuite/ChangeLog:

* gdb.python/py-unwind.py (TestUnwinder::__call__): Add test for
gdb.PendingFrame.architecture method.

gdb/doc/ChangeLog:

* python.texi (Unwinding Frames in Python): Document
PendingFrame.architecture method.

gdb: Remove deprecated_set_gdbarch_data

There are currently two remaining uses of deprecated_set_gdbarch_data,
both of which are needed because during gdbarch initialisation we call
gdbarch_data for a data field that is registered using:

  gdbarch_data_register_post_init (....)

However, in both of these cases, the only thing that the call back
needs from the gdbarch struct is its obstack.  Given this there is
nothing stopping us changing the post-init hooks into pre-init hooks.
The pre-init hooks don't get passed the full gdbarch, they only get
passed its obstack.

The IA64 change is completely untested.  The user-regs change has been
tested a little by locally adding some user-regs to the x86-64 target,
and also by running the RISC-V tests, which do use user-regs.

gdb/ChangeLog:

* gdbarch.c: Regenerate.
* gdbarch.h: Regenerate.
* gdbarch.sh (deprecated_set_gdbarch_data): Delete.
(gdbarch_data): Use internal_error for the case where
deprecated_set_gdbarch_data was originally needed.
* ia64-libunwind-tdep.c (libunwind_descr_init): Update parameters,
and use passed in obstack.
(libunwind_frame_set_descr): Should no longer get back NULL from
gdbarch_data.
(_initialize_libunwind_frame): Register as a pre-init gdbarch data
type.
* user-regs.c (user_regs_init): Update parameters, and use passed
in obstack.
(user_reg_add): Should no longer get back NULL from gdbarch_data.
(_initialize_user_regs): Register as a pre-init gdbarch data type.

[gdb/symtab] Fix line-table end-of-sequence sorting

Consider test-case gdb.dwarf2/dw2-ranges-base.exp.  It has (ignoring
non-sensical entries that are filtered out by buildsym_compunit::record_line)
a line-table for dw2-ranges-base.c like this:
...
 Line Number Statements:
  [0x0000014e]  Extended opcode 2: set Address to 0x4004ba
  [0x00000159]  Advance Line by 10 to 11
  [0x0000015b]  Copy
  [0x0000015c]  Advance PC by 12 to 0x4004c6
  [0x0000015e]  Extended opcode 1: End of Sequence

  [0x00000161]  Extended opcode 2: set Address to 0x4004ae
  [0x0000016c]  Advance Line by 20 to 21
  [0x0000016e]  Copy
  [0x0000016f]  Advance PC by 12 to 0x4004ba
  [0x00000171]  Extended opcode 1: End of Sequence

  [0x00000174]  Extended opcode 2: set Address to 0x4004a7
  [0x0000017f]  Advance Line by 30 to 31
  [0x00000181]  Copy
  [0x00000182]  Advance PC by 7 to 0x4004ae
  [0x00000184]  Extended opcode 1: End of Sequence
...

If we disable the sorting in buildsym_compunit::end_symtab_with_blockvector,
we have the unsorted line table:
...
INDEX  LINE   ADDRESS            IS-STMT
0      11     0x00000000004004ba Y
1      END    0x00000000004004c6 Y
2      21     0x00000000004004ae Y
3      END    0x00000000004004ba Y
4      31     0x00000000004004a7 Y
5      END    0x00000000004004ae Y
...
It contains 3 sequences, 11/END, 21/END and 31/END.

We want to sort the 3 sequences relative to each other, while sorting on
address, to get:
...
INDEX  LINE   ADDRESS            IS-STMT
0      31     0x00000000004004a7 Y
1      END    0x00000000004004ae Y
2      21     0x00000000004004ae Y
3      END    0x00000000004004ba Y
4      11     0x00000000004004ba Y
5      END    0x00000000004004c6 Y
...

However, if we re-enable the sorting, we have instead:
...
INDEX  LINE   ADDRESS            IS-STMT
0      31     0x00000000004004a7 Y
1      21     0x00000000004004ae Y
2      END    0x00000000004004ae Y
3      11     0x00000000004004ba Y
4      END    0x00000000004004ba Y
5      END    0x00000000004004c6 Y
...

This is a regression since commit 3d92a3e313 "gdb: Don't reorder line table
entries too much when sorting", that introduced sorting on address while
keeping entries with the same address in pre-sort order.

Indeed the entries 1 and 2 are in pre-sort order (they map to entries 2 and 5
in the unsorted line table), but entry 1 does not belong in the sequence
terminated by 2.

Fix this by handling End-Of-Sequence entries in the sorting function, such
that they are sorted before other entries with the same address.

Also, revert the find_pc_sect_line workaround introduced in commit 3d92a3e313,
since that's no longer necessary.

Tested on x86_64-linux.

gdb/ChangeLog:

2020-07-06  Tom de Vries  <tdevries@suse.de>

* buildsym.c (buildsym_compunit::end_symtab_with_blockvector): Handle
End-Of-Sequence in lte_is_less_than.
* symtab.c (find_pc_sect_line): Revert change from commit 3d92a3e313
"gdb: Don't reorder line table entries too much when sorting".

gdb/testsuite/ChangeLog:

2020-07-06  Tom de Vries  <tdevries@suse.de>

* gdb.dwarf2/dw2-ranges-base.exp: Test line-table order.

x86: adjust/correct VFRCZ{P,S}{S,D} decoding

The unnecessary XOP.L decoding had caught my eye, together with the not
really expected operand specifiers. Drop this decode step, and instead
make sure XOP.W and XOP.PP don't get ignored. For the latter, do this in
a form applicable to all XOP insns, rather than adding extra table
layers - there are no encodings with the field non-zero. Besides these
two, for the scalar forms XOP.L actually needs to also be zero.

x86: use %LW / %XW instead of going through vex_w_table[]

Since we have these macros, there's no point having unnecessary table
depth.

VFPCLASSP{S,D} are now the first instance of using two %-prefixed
macros, which has pointed out a problem with the implementation. Instead
of using custom code in various case blocks, do the macro accumulation
centralized at the top of the main loop of putop(), and zap the
accumulated macros at the bottom of that loop once it has been
processed.

x86: most VBROADCAST{F,I}{32,64}x* only accept memory operands

VBROADCAST{F,I}32x2 are the only exceptions here.

x86: adjust/correct V*{F,I}{32x8,64x4}

For all of these only the 512-bit forms are valid, so drop 256-bit ones
from the integer insert/extract variants.

Also replace EXxmmq by the more natural (here) EXymm.

x86: drop EVEX table entries that can be made served by VEX ones

By doing the EVEX.W decode first, in various cases VEX table entries can
be re-used.

x86: AVX512 VPERM{D,Q,PS,PD} insns need to honor EVEX.L'L

Just like (where they exist) their AVX counterparts do for VEX.L. For
all of them the 128-bit forms are invalid.

x86: AVX512 extract/insert insns need to honor EVEX.L'L

Just like their AVX counterparts do for VEX.L.

At this occasion also make EVEX.W have the same effect as VEX.W on the
printing of VPINSR{B,W}'s operands, bringing them also in sync with
VPEXTR{B,W}.

x86: honor VEX.W for VCVT{PH2PS,PS2PH}

Unlike for the EVEX-encoded versions, the VEX ones failed to decode
VEX.W. Once the necessary adjustments are done, it becomes obvious that
the EVEX and VEX table entries for VCVTPS2PH are identical and can hence
be folded.

x86: drop EVEX table entries that can be served by VEX ones

The duplication is not only space inefficient, but also risks entries
going out of sync (some of which that I became aware of while doing this
work will get addressed subsequently). Right here note that for
VGF2P8MULB this also addresses the prior lack of EVEX.W decoding (i.e. a
first example of out of sync entries).

This introduces EXxEVexR to some VEX templates, on the basis that this
operand is benign there and only relevant when EVEX encoding ends up
reaching these entries.

x86: replace EXqScalarS by EXqVexScalarS

There's only a single user, that that one can do fine with the
alternative, as the "Vex" aspect of the other operand kind is meaningful
only on 3-operand insns.

While doing this I noticed that I didn't need to do the same adjustment
in the EVEX tables, and voilà - there was a bug, which gets fixed at the
same time (see the testsuite changes).

x86: replace EX{d,q}Scalar by EXxmm_m{d,q}

Along the lines of 4102be5cf925 ("x86: replace EXxmm_mdq by
EXVexWdqScalar"), but in the opposite direction, replace EXdScalar/
EXqScalar by EXxmm_md/EXxmm_mq respectively, rendering d_scalar_mode and
q_scalar_mode unused. The change is done this way to improve telling
apart operands affected here from ones using EXbScalar/EXwScalar, which
work sufficiently differently. Additionally this increases similarity
between several VEX-encoded insns and their EVEX-encoded counterparts.

Fix spelling mistakes in some of the binutils sub-directories.

PR 26204
gas * config/tc-arm.c: Fix spelling mistake.
* config/tc-riscv.c: Likewise.
* config/tc-z80.c: Likewise.
* po/gas.pot: Regenerate.

ld * lexsup.c: Fix spelling mistake.
* po/ld.pot: Regenerate.

opcodes * arc-dis.c: Fix spelling mistake.
* po/opcodes.pot: Regenerate.

Updated translations for various binutils sub-directories

[gdb/tui,c++17] Fix NULL string_view in tui_partial_win_by_name

When building gdb with CFLAGS=-std=gnu17 and CXXFLAGS=-std=gnu++17 and running
test-case gdb.tui/new-layout.exp, we run into:
...
UNRESOLVED: gdb.tui/new-layout.exp: left window box after shrink (ll corner)
FAIL: gdb.tui/new-layout.exp: right window box after shrink (ll corner)
...

In a minimal form, we run into an abort when issuing a winheight command:
...
$ gdb -tui -ex "winheight src - 5"
   <tui stuff>
Aborted (core dumped)
$
...
with this backtrace at the abort:
...
\#0  0x0000000000438db0 in std::char_traits<char>::length (__s=0x0)
     at /usr/include/c++/9/bits/char_traits.h:335
\#1  0x000000000043b72e in std::basic_string_view<char, \
   std::char_traits<char> >::basic_string_view (this=0x7fffffffd4f0, \
   __str=0x0) at /usr/include/c++/9/string_view:124
\#2  0x000000000094971b in tui_partial_win_by_name (name="src")
     at src/gdb/tui/tui-win.c:663
...
due to a NULL comparison which constructs a string_view object from NULL:
...
   657  /* Answer the window represented by name.  */
   658  static struct tui_win_info *
   659  tui_partial_win_by_name (gdb::string_view name)
   660  {
   661    struct tui_win_info *best = nullptr;
   662
   663    if (name != NULL)
...

In gdbsupport/gdb_string_view.h, we either use:
- gdb's copy of libstdc++-v3/include/experimental/string_view, or
- the standard implementation of string_view, when built with C++17 or later
  (which in gcc's case comes from libstdc++-v3/include/std/string_view)

In the first case, there's support for constructing a string_view from a NULL
pointer:
...
      /*constexpr*/ basic_string_view(const _CharT* __str)
      : _M_len{__str == nullptr ? 0 : traits_type::length(__str)},
        _M_str{__str}
      { }
...
but in the second case, there's not:
...
      __attribute__((__nonnull__)) constexpr
      basic_string_view(const _CharT* __str) noexcept
      : _M_len{traits_type::length(__str)},
        _M_str{__str}
      { }
...

Fix this by removing the NULL comparison altogether.

Build on x86_64-linux with CFLAGS=-std=gnu17 and CXXFLAGS=-std=gnu++17, and
tested.

gdb/ChangeLog:

2020-07-06  Tom de Vries  <tdevries@suse.de>

PR tui/26205
* tui/tui-win.c (tui_partial_win_by_name): Don't test for NULL name.

asan: readelf: stack buffer overflow

* readelf.c (print_dynamic_symbol): Don't sprintf to buffer to
find string length.

Automatic date update in version.in

[gdb/build,c++17] Fix use of deprecated std::uncaught_exception

When compiling gdb with -std=gnu++17, we run into:
...
../../gdb/inferior.h: In member function ‘void \
  infcall_suspend_state_deleter::operator()(infcall_suspend_state*) const’:
../../gdb/inferior.h:83:12: error: ‘bool std::uncaught_exception()’ is \
  deprecated [-Werror=deprecated-declarations]
   83 |  if (!std::uncaught_exception ())
...

Fix this by rewriting using std::uncaught_exceptions.

Tested on x86_64-linux with gcc 9.3.1 and -std=gnu17/gnu++17.

Tested with test-case from RFC patch
https://sourceware.org/pipermail/gdb-patches/2020-June/169970.html.

gdb/ChangeLog:

2020-07-05  Tom de Vries  <tdevries@suse.de>

PR build/26187
* inferior.h (struct infcall_suspend_state_deleter): If available, use
std::uncaught_exceptions instead of deprecated
std::uncaught_exception.

Automatic date update in version.in

Tweak version numbers in release-howto

oops - omitted from previous delta

Update version to 2.35.50 and regenerate files

Add markers for binutils 2.35 branch

gdb: make macro_stringify return a gdb::unique_xmalloc_ptr<char>

The change to macro_stringify is straightforward.  This allows removing
the manual memory management in fixup_definition.

gdb/ChangeLog:

* macroexp.h (macro_stringify): Return
gdb::unique_xmalloc_ptr<char>.
* macroexp.c (macro_stringify): Likewise.
* macrotab.c (fixup_definition): Update.

Change-Id: Id7db8988bdbd569dd51c4f4655b00eb26db277cb

gdb: make macro_expand_next return a gdb::unique_xmalloc_ptr<char>

For some reason, macro_expand_next does not return a
gdb::unique_xmalloc_ptr<char>, like its counterparts macro_expand and
macro_expand_once.  This patch fixes that.

macro_buffer::release now returns a gdb::unique_xmalloc_ptr<char> too,
which required updating the other callers.  The `.release (). release
()` in macro_stringify looks a bit funny, but it's because one release
is for the macro_buffer, and the other is for the unique ptr.

I removed the ATTRIBUTE_UNUSED_RESULT on macro_buffer::release, I don't
really understand why it's there.  I don't see how this method could be
called without using the result, that would be an obvious memory leak.
The commit that introduced it (4e4a8b932b7 "Add ATTRIBUTE_UNUSED_RESULT
to macro_buffer") doesn't give any details.

gdb/ChangeLog:

* c-exp.y (scan_macro_expansion): Don't free `expansion`.
(lex_one_token): Update.
* macroexp.c (struct macro_buffer) <release>: Return
gdb::unique_xmalloc_ptr<char>.
(macro_stringify): Update.
(macro_expand): Update.
(macro_expand_next): Return gdb::unique_xmalloc_ptr<char>.
* macroexp.h (macro_expand_next): Likewise.

Change-Id: I67a74d0d479d2c20cdc82161ead7c54cea034f56

gdb: remove callback in macro expand functions

I started to look into changing the callbacks in macroexp.h to use
gdb::function_view.  However, I noticed that the passed lookup function
was always `standard_macro_lookup`, which looks up a macro in a
`macro_scope` object.  Since that doesn't look like a very useful
abstraction, it would be simpler to just pass the scope around and have
the various functions call standard_macro_lookup themselves.  This is
what this patch does.

gdb/ChangeLog:

* macroexp.h (macro_lookup_ftype): Remove.
(macro_expand, macro_expand_once, macro_expand_next): Remove
lookup function parameters, add scope parameter.
* macroexp.c (scan, substitute_args, expand, maybe_expand,
macro_expand, macro_expand_once, macro_expand_next): Likewise.
* macroscope.h (standard_macro_lookup): Change parameter type
to macro_scope.
* macroscope.c (standard_macro_lookup): Likewise.
* c-exp.y (lex_one_token): Update.
* macrocmd.c (macro_expand_command): Likewise.
(macro_expand_once_command): Likewise.

Change-Id: Id2431b1489359e1b0274dc2b81e5ea5d225d730c

Automatic date update in version.in

sim/igen: Fix linker error with -fno-common

GCC 10 enables -fno-common by default.  This resulted in multiple
definition linker errors since a global variable was declared and
defined in a header file:

  ld: libsim.a(idecode.o):sim/v850/idecode.h:71: multiple definition of
  `idecode_issue'; libsim.a(irun.o):sim/v850/idecode.h:71: first defined
  here

  ld: libsim.a(engine.o):sim/v850/idecode.h:71: multiple definition of
  `idecode_issue'; libsim.a(irun.o):sim/v850/idecode.h:71: first defined
  here

  ld: libsim.a(support.o):sim/v850/idecode.h:71: multiple definition of
  `idecode_issue'; libsim.a(irun.o):sim/v850/idecode.h:71: first defined
  here

  ld: libsim.a(semantics.o):sim/v850/idecode.h:71: multiple definition
  of `idecode_issue'; libsim.a(irun.o):sim/v850/idecode.h:71: first
  defined here

sim/igen

PR sim/26194

* lf.h (lf_get_file_type): Declare.
* lf.c (lf_get_file_type): Define.
* gen-idecode.c (print_idecode_issue_function_header): Use
lf_get_file_type() to issue an extern variable declaration in
case of header files.

sim/ppc: Fix linker error with -fno-common

GCC 10 enables -fno-common by default.  This resulted in a multiple
definition linker error since global variables were declared and defined
in a header file:

  ld: ld-insn.o:sim/ppc/ld-insn.h:221: multiple definition of
  `max_model_fields_len'; igen.o:sim/ppc/ld-insn.h:221: first defined here

sim/ppc

* ld-insn.h (last_model, last_model_data, last_model_function,
last_model_internal, last_model_macro, last_model_static):
Delete.
(max_model_fields_len, model_data, model_functions,
model_internal, model_macros, model_static, models): Declare, but do not
define.
* ld-insn.c (last_model, last_model_data, last_model_function,
last_model_internal, last_model_macro, last_model_static,
max_model_fields_len, model_data, model_functions,
model_internal, model_macros, model_static, models): Define.

Fix gdb.base/structs2.exp with Clang

gdb.base/structs2.exp fails to run with Clang, because of:

 gdb compile failed, /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.base/structs2.c:16:14: warning:
       implicit conversion from 'int' to 'signed char' changes value from 130 to
       -126 [-Wconstant-conversion]
   param_reg (130, 120, 33000, 32000);
   ~~~~~~~~~  ^~~
 /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.base/structs2.c:16:24: warning:
       implicit conversion from 'int' to 'short' changes value from 33000 to
       -32536 [-Wconstant-conversion]
   param_reg (130, 120, 33000, 32000);
   ~~~~~~~~~            ^~~~~
 2 warnings generated.

 === gdb Summary ===

 # of untested testcases         1

Fix it by passing actual negative numbers.

gdb/testsuite/ChangeLog:

* gdb.base/structs2.c (main): Adjust second parem_reg call to
explicitly write negative numbers.
* gdb.base/structs2.exp: Adjust expected output.

Fix gdb.base/charset.exp with Clang

gdb.base/charset.exp fails to run with Clang, because of:

 gdb compile failed, /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.base/charset.c:144:20: warning:
       implicit conversion from 'int' to 'char' changes value from 162 to -94
       [-Wconstant-conversion]
11, 162, 17);
    ^~~
 /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.base/charset.c:151:16: warning:
       implicit conversion from 'int' to 'char' changes value from 167 to -89
       [-Wconstant-conversion]
167,
^~~
 /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.base/charset.c:168:16: warning:
       implicit conversion from 'int' to 'char' changes value from 167 to -89
       [-Wconstant-conversion]
167,
^~~
 3 warnings generated.

 === gdb Summary ===

 # of untested testcases         1

Fix it by changing init_string to take unsigned char parameters.

gdb/testsuite/ChangeLog:

* gdb.base/charset.c (init_string): Change all char parameters to
unsigned char parameters.

Remove stale -DNO_PROTOTYPES bits from gdb testsuite

The gdb.base/call-sc.exp, gdb.base/structs.exp and
gdb.base/structs2.exp testcases still try compiling the sources with
-DNO_PROTOTYPES, but the corresponding sources don't have any #ifdef
NO_PROTOTYPES any longer.  Those were removed throughout years ago.

OTOH, gdb.base/ovlymgr.h does check for NO_PROTOTYPES, but no .exp
file compiles it with -DNO_PROTOTYPES.

gdb.base/reread.exp and gdb.base/varargs.exp set a 'prototypes'
global, which is a stale bit left behind when the "try-compiling
without and then with -DNO_PROTOTYPES" logic was around.

gdb/testsuite/ChangeLog:

* gdb.base/call-sc.exp (start_scalars_test): Use
prepare_for_testing and don't try compiling with -DNO_PROTOTYPES.
* gdb.base/overlays.c: Remove references to PARAMS.
* gdb.base/ovlymgr.h (PARAMS): Delete, and remove all references.
* gdb.base/reread.exp: Don't set 'prototypes' global.
* gdb.base/structs.exp (start_structs_test): Use
prepare_for_testing and don't try compiling with -DNO_PROTOTYPES.
* gdb.base/structs2.exp: Don't set 'prototypes' global.  Use
prepare_for_testing and don't try compiling with -DNO_PROTOTYPES.
Don't issue "set width 0".  Remove gdb_stop_suppressing_tests
call.
* gdb.base/varargs.exp: Don't set 'prototypes' global.

Remove stale overlay testcase bits

D10V support was removed years ago, but the gdb.base/d10vovly.c file
stayed behind.  Looking a bit closer, I can't find anywhere that
references gdb.base/m32rovly.c either.

Both gdb.base/m32rovly.c and gdb.base/d10vovly.c seem to be older
copies of gdb.base/ovlymgr.c, that are exactly the same, except for
some cosmetic differences, and for missing _ovly_debug_event.  Note
that gdb.base/ovlymgr.c has the #ifdef __M32R__ bits too.  Note also
that gdb.base/overlays.exp is currently only supported on m32r, and
that uses ovlymgr.c not gdb.base/m32rovly.c.

gdb/testsuite/ChangeLog:

* gdb.base/d10vovly.c: Delete.
* gdb.base/m32rovly.c: Delete.
* gdb.base/ovlymgr.c: Remove all code guarded by __D10V__.

Re: Change readelf's display of symbol names

Fixes some fallout from git commit 0942c7ab94e5.

PR 26028
gas/
* testsuite/gas/ia64/unwind-ilp32.d: Add -T to readelf options.
gold/
* testsuite/Makefile.am (file_in_many_sections.stdout): Add -W
to readelf options.
* testsuite/Makefile.in: Regenerate.
ld/
* testsuite/ld-arm/arm-elf.exp (vxworks1): Pass --wide to readelf
when dumping relocs.
* testsuite/ld-i386/i386.exp (vxworks1): Likewise.
* testsuite/ld-sh/sh-vxworks.exp (vxworks1): Likewise.
* testsuite/ld-sparc/sparc.exp (vxworks1): Likewise.
* testsuite/ld-arm/vxworks1.rd: Adjust to suit.
* testsuite/ld-i386/vxworks1.rd: Adjust.
* testsuite/ld-sh/vxworks1.rd: Adjust.
* testsuite/ld-sparc/vxworks1.rd: Adjust.

Automatic date update in version.in

x86: Add SwapSources

We check register-only source operand to decide if two source operands of
VEX encoded instructions should be swapped.  But source operands in AMX
instructions with two source operands swapped are all register-only
operand.  Add SwapSources to indicate two source operands should be
swapped.

gas/

* config/tc-i386.c (build_modrm_byte): Check vexswapsources to
swap two source operands.

opcodes/

* i386-gen.c (opcode_modifiers): Add VexSwapSources.
* i386-opc.h (VexSwapSources): New.
(i386_opcode_modifier): Add vexswapsources.
* i386-opc.tbl: Add VexSwapSources to BMI2 and BMI instructions
with two source operands swapped.
* i386-tbl.h: Regenerated.

Skip fill-1 gas test for MeP targets.

* testsuite/gas/all/fill-1.d: Skip for MeP targets.

aarch64: Fix segfault on unicode symbols

This patch fixes a segfault which occurs when the AArch64 backend parses
a symbol operand that begins with a register name and ends with a
unicode byte (byte value > 127).

For example, the following input causes the crash:

x0é: udf x0é

gas/ChangeLog:

2020-07-02  Alex Coplan  <alex.coplan@arm.com>

* config/tc-aarch64.c (reg_name_p): Fix cast so that we don't
segfault on negative chars.
* testsuite/gas/aarch64/reglike-label-unicode-segv.d: New test.
* testsuite/gas/aarch64/reglike-label-unicode-segv.s: Input.

gdb: remove unused fetch_inferior_event and inferior_event_handler parameters

I noticed that fetch_inferior_event receives the client_data parameter
from its caller, inferior_event_handler, but doesn't actually need it.
This patch removes it.  In turn, inferior_event_handler doesn't use its
parameter, so remove it too.

The `data` argument used when registering
remote_async_inferior_event_handler is changed to NULL, to avoid
confusion.  It could make people think that the value passed is used
somewhere, when in fact it's not.

gdb/ChangeLog:

* inf-loop.c (inferior_event_handler): Remove client_data param.
* inf-loop.h (inferior_event_handler): Likewise.
* infcmd.c (step_1): Adjust.
* infrun.c (proceed): Adjust.
(fetch_inferior_event): Remove client_data param.
(infrun_async_inferior_event_handler): Adjust.
* infrun.h (fetch_inferior_event): Remove `void *` param.
* linux-nat.c (handle_target_event): Adjust.
* record-btrace.c (record_btrace_handle_async_inferior_event):
Adjust.
* record-full.c (record_full_async_inferior_event_handler):
Adjust.
* remote.c (remote_async_inferior_event_handler): Adjust.

Change-Id: I3c2aa1eb0ea3e0985df096660d2dcd794674f2ea

Change readelf's display of symbol names (when not in --wide mode) so that if they are going to be truncated then "[...]" is displayed at the end.  Add a comment line option to disable this enhancement and restore the old behaviour.

PR 26028
binutils* readelf.c (print_symbol): Handle truncation of symbol names.
(options): Add -T/--silent-truncation option.
(parse_args): Handle the option.
(print_dynamic_symbol): Correct calculation of width available to
display symbol name.
* doc/binutils.texi: Document the -T option to readelf.
* NEWS: Mention the new feature.

gas * testsuite/gas/ia64/group-2.d: Add -T option to readelf
command line.
* testsuite/gas/ia64/unwind.d: Likewise.
* testsuite/gas/mmix/bspec-1.d: Likewise.
* testsuite/gas/mmix/bspec-2.d: Likewise.
* testsuite/gas/mmix/comment-1.d: Likewise.
* testsuite/gas/tic6x/scomm-directive-4.d: Likewise.

ld * testsuite/ld-powerpc/powerpc.exp: Add -T option to readelf
command line when running some tests.
* testsuite/ld-arm/arm-elf.exp: Likewise.
* testsuite/ld-mips-elf/mips-elf.exp: Likewise.
* testsuite/ld-mmix/local1.d: Likewise.
* testsuite/ld-mmix/local3.d: Likewise.
* testsuite/ld-mmix/local5.d: Likewise.
* testsuite/ld-mmix/local7.d: Likewise.
* testsuite/ld-powerpc/powerpc.exp: Likewise.

Make tui_win_info::name pure virtual

It seemed cleaner to me for tui_win_info::name to be pure virtual.
This meant adding a name method to the locator window; but this too
seems like an improvement.

gdb/ChangeLog
2020-07-01  Tom Tromey  <tom@tromey.com>

* tui/tui-data.h (struct tui_win_info) <name>: Now pure virtual.
* tui/tui-stack.h (struct tui_locator_window) <name>: New method.

Remove tui_gen_win_info

This merges the tui_gen_win_info base class with tui_win_info;
renaming the resulting class to tui_win_info.

gdb/ChangeLog
2020-07-01  Tom Tromey  <tom@tromey.com>

* tui/tui-wingeneral.c (tui_win_info::refresh_window): Move from
tui_gen_win_info.
(tui_win_info::make_window): Merge with
tui_gen_win_info::make_window.
(tui_win_info::make_visible): Move from tui_gen_win_info.
* tui/tui-win.c (tui_win_info::max_width): Move from
tui_gen_win_info.
* tui/tui-layout.h (class tui_layout_window) <m_window>: Change
type.
<window_factory>: Likewise.
* tui/tui-layout.c (tui_win_info::resize): Move from
tui_gen_win_info.
(make_standard_window): Change return type.
(get_locator_window, tui_get_window_by_name): Likewise.
(tui_layout_window::apply): Remove a cast.
* tui/tui-data.h (MIN_WIN_HEIGHT): Move earlier.
(struct tui_win_info): Merge with tui_gen_win_info.
(struct tui_gen_win_info): Remove.

Derive tui_locator_window from tui_win_info

tui_locator_window is the last remaining concrete child class of
tui_gen_win_info.  It seems a bit cleaner to me to flatten the
hierarchy a bit; this patch prepares for that by changing
tui_locator_window to derive from tui_win_info.

gdb/ChangeLog
2020-07-01  Tom Tromey  <tom@tromey.com>

* tui/tui-stack.h (struct tui_locator_window): Derive from
tui_win_info.
<do_scroll_horizontal, do_scroll_vertical>: New methods.
<can_box>: New method.

Remove body of tui_locator_window constructor

The tui_locator_window constructor initializes the first character of
two of its members.  However, this is actually an error, since these
were changed to be std::string.  This removes the erroneous code.

gdb/ChangeLog
2020-07-01  Tom Tromey  <tom@tromey.com>

* tui/tui-stack.h (struct tui_locator_window): Remove body.

Don't derive tui_data_item_window from tui_gen_win_info

There's no deep reason that tui_data_item_window should derive from
tui_gen_win_info -- it currently uses a curses window to render, but
that isn't truly needed, and it adds some hacks to other parts of the
TUI.

This patch changes tui_data_item_window so that it doesn't have a base
class, and updates the register window.  This simplifies the code and
enables a subsequent cleanup.

gdb/ChangeLog
2020-07-01  Tom Tromey  <tom@tromey.com>

* tui/tui-regs.c (tui_data_window::display_registers_from)
(tui_data_window::display_registers_from)
(tui_data_window::first_data_item_displayed)
(tui_data_window::delete_data_content_windows): Update.
(tui_data_window::refresh_window, tui_data_window::no_refresh):
Remove.
(tui_data_window::check_register_values): Update.
(tui_data_item_window::rerender): Add parameters.  Update.
(tui_data_item_window::refresh_window): Remove.
* tui/tui-data.h (struct tui_gen_win_info) <no_refresh>: No longer
virtual.
* tui/tui-regs.h (struct tui_data_item_window): Don't derive from
tui_gen_win_info.
<refresh_window, max_height, min_height>: Remove.
<rerender>: Add parameters.
<x, y, visible>: New members.
(struct tui_data_window) <refresh_window, no_refresh>: Remove.
<m_item_width>: New member.

Rename tui_data_item_window::item_no

tui_data_item_window::item_no is misnamed -- it only can be used for a
register, but it references a "display" number as well.  (Based on
other comments I've seen in the past -- most since deleted -- I think
there were plans at one point to display variables in this window as
well.  However, this was never implemented.)

This patch renames this member to be more correct.

gdb/ChangeLog
2020-07-01  Tom Tromey  <tom@tromey.com>

* tui/tui-regs.c (tui_data_window::show_register_group)
(tui_data_window::check_register_values): Update.
* tui/tui-regs.h (struct tui_data_item_window) <regno>: Rename
from item_no.

Remove useless "if' from tui-regs.c

tui_data_window::show_register_group had a useless "if" -- the
condition could never be false.  This patch removes it.

gdb/ChangeLog
2020-07-01  Tom Tromey  <tom@tromey.com>

* tui/tui-regs.c (tui_data_window::show_register_group): Remove
useless "if".