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

Remove tui_data_window::name

The "name" member of tui_data_window was set, but never used.  This
removes it.

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

* tui/tui-regs.c (tui_data_window::show_register_group): Update.
* tui/tui-regs.h (struct tui_data_item_window) <name>: Remove.

Move some code out of tui-data.h

This moves some code out of tui-data.h, to more closely related
places.  Some unused forward declarations are also removed.

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

* tui/tui-stack.c (SINGLE_KEY): Move from tui-data.h
* tui/tui-winsource.h (enum tui_line_or_address_kind)
(struct tui_line_or_address): Move from tui-data.h.
* tui/tui-win.c (DEFAULT_TAB_LEN): Move from tui-data.h.
* tui/tui-data.h (DEFAULT_TAB_LEN): Move to tui-win.c.
(tui_cmd_window, tui_source_window_base, tui_source_window)
(tui_disasm_window): Don't declare.
(enum tui_line_or_address_kind, struct tui_line_or_address): Move
to tui-winsource.h.
(SINGLE_KEY): Move to tui-stack.c.

Remove tui_expand_tabs

tui_expand_tabs only has a single caller.  This patch removes this
function, in favor of a tab-expanding variant of string_file.  This
simplifies the code somewhat.

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

* tui/tui-regs.h (struct tui_data_item_window) <content>: Now a
std::string.
* tui/tui-regs.c (class tab_expansion_file): New.
(tab_expansion_file::write): New method.
(tui_register_format): Change return type.  Use
tab_expansion_file.
(tui_get_register, tui_data_window::display_registers_from)
(tui_data_item_window::rerender): Update.
* tui/tui-io.h (tui_expand_tabs): Don't declare.
* tui/tui-io.c (tui_expand_tabs): Remove.

Use complete_on_enum in tui_reggroup_completer

tui_reggroup_completer has an "XXXX" comment suggesting the use of
complete_on_enum.  This patch implements this suggestion.

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

* tui/tui-regs.c (tui_reggroup_completer): Use complete_on_enum.

Automatic date update in version.in

Recognize -1 as a tombstone value in .debug_line

LLD from 11 onwards (https://reviews.llvm.org/D81784) uses -1 to
represent a relocation in .debug_line referencing a discarded symbol.
Recognize -1 to fix gdb.base/break-on-linker-gcd-function.exp when the
linker is a newer LLD.

gdb/ChangeLog:

* dwarf2/read.c (lnp_state_machine::check_line_address): Test -1.

PR26188, buff overflow in coff_find_nearest_line_with_names

PR 26188
* coffgen.c (coff_find_nearest_line_with_names): Sanity check
raw syment index before dereferencing.

Allow reference form for DW_AT_associated and DW_AT_allocated attributes

Currently, GDB rejects the (die) reference form while it accepts exprloc
form. It is allowed in DWARF standard. "Table 7.5: Attribute encodings"
in DWARF5 standard. Flang compiler assigns (die) reference to
DW_AT_associated and DW_AT_allocated for some cases.

gdb/ChangeLog

* dwarf2/read.c (set_die_type): Removed conditions to restrict
forms for DW_AT_associated and DW_AT_allocated attributes,
which is already checked in function attr_to_dynamic_prop.

Re: Remove x86 NaCl target support

Fixes accidental breakage of vxworks by commit bbd19b19e4.

* elf32-i386.c (elf_backend_object_p): Undef for vxworks.

obsolete xc16x

The xc16x md_apply_fix code is just so broken that in my opinion the
target should never have been accepted, and from a quick look at
commit logs for the target it appears that no one has ever contributed
fixes for anything.  This target has just been a 14 year burden on
global binutils and cgen maintainers.  That's not how free software is
supposed to work.

bfd/
* config.bfd: Obsolete xc16x.
gas/
* config/tc-xc16x.c (md_apply_fix): Add FIXME.

gas eqv-dot test fails

* testsuite/gas/all/eqv-dot.d: xfail targets that set linkrelax
in data sections, and mep.

Automatic date update in version.in

Update readline/README to mention patchlevel

This updates readline/README to mention the current patchlevel, and
the "git am" approach to importing new upstream patches.

readline/ChangeLog
2020-06-30  Tom Tromey  <tom@tromey.com>

* README: Update instructions.

problems restoring the history file are not signaled correctly to the calling application

reading history entries with timestamps can result in joined entries

fix problems moving back beyond start of history

Readline-8.0 patch 1: fix file descriptor leak with zero-length history file

Fix test breakages caused by removal of gdb_py_test_multiple.

Tom de Vries detected that some python tests were broken as
they were still using gdb_py_test_multiple that was replaced
by gdb_test_multiline.  Repair these tests by using the new function.

gdb/testsuite/ChangeLog
2020-06-30  Philippe Waroquiers  <philippe.waroquiers@skynet.be>

* gdb.python/py-breakpoint.exp: use gdb_test_multiline instead
of gdb_py_test_multiple.
* gdb.python/py-cmd.exp: Likewise.
* gdb.python/py-events.exp: Likewise.
* gdb.python/py-function.exp: Likewise.
* gdb.python/py-inferior.exp: Likewise.
* gdb.python/py-infthread.exp: Likewise.
* gdb.python/py-linetable.exp: Likewise.
* gdb.python/py-parameter.exp: Likewise.
* gdb.python/py-value.exp: Likewise.

Remove x86 NaCl target support

NaCl has been deprecated:

https://developer.chrome.com/native-client/migration

and NaCl will completely disappear in 2021:

https://lists.llvm.org/pipermail/llvm-dev/2020-April/141107.html

Remove x86 NaCl target support from bfd, binutils, gas and ld.

bfd/

* archures.c (bfd_mach_i386_nacl): Removed.
(bfd_mach_i386_i386_nacl): Likewise.
(bfd_mach_x86_64_nacl): Likewise.
(bfd_mach_x64_32_nacl): Likewise.
* config.bfd: Remove *-*-nacl* targets.
* configure.ac: Remove x86 NaCl target vectors.
* cpu-i386.c (bfd_arch_i386_onebyte_nop_fill): Removed.
(bfd_x64_32_nacl_arch): Likewise.
(bfd_x86_64_nacl_arch): Likewise.
(bfd_i386_nacl_arch): Likewise.
(bfd_x64_32_arch_intel_syntax): Updated.
* elf32-i386.c: Don't include "elf-nacl.h".
(elf_i386_nacl_plt): Removed.
(elf_i386_nacl_plt0_entry): Likewise.
(elf_i386_nacl_plt_entry): Likewise.
(elf_i386_nacl_pic_plt0_entry): Likewise.
(elf_i386_nacl_pic_plt_entry): Likewise.
(elf_i386_nacl_eh_frame_plt): Likewise.
(elf_i386_nacl_plt): Likewise.
(elf32_i386_nacl_elf_object_p): Likewise.
(elf_i386_get_synthetic_symtab): Updated.
(elf_i386_link_setup_gnu_properties): Likewise.
* elf64-x86-64.c: Don't include "elf-nacl.h".
(elf_x86_64_nacl_plt): Removed.
(elf64_x86_64_nacl_elf_object_p): Likewise.
(elf_x86_64_nacl_plt0_entry): Likewise.
(elf_x86_64_nacl_plt_entry): Likewise.
(elf_x86_64_nacl_eh_frame_plt): Likewise.
(elf_x86_64_nacl_plt): Likewise.
(elf32_x86_64_nacl_elf_object_p): Likewise.
(elf_x86_64_get_synthetic_symtab): Updated.
(elf_x86_64_link_setup_gnu_properties): Likewise.
* elfxx-x86.c (_bfd_x86_elf_link_setup_gnu_properties): Likewise.
* targets.c: Remove x86 NaCl target vectors.
* bfd-in2.h: Regenerated.
* configure: Likewise.

binutils/

* NEWS: Mention x86 NaCl target support removal.
* dwarf.c (init_dwarf_regnames_by_bfd_arch_and_mach): Remove
x86 NaCl target support.
* testsuite/binutils-all/elfedit-1.d: Likewise.
* testsuite/binutils-all/i386/i386.exp: Likewise.
* testsuite/binutils-all/x86-64/objects.exp: Likewise.
* testsuite/binutils-all/x86-64/pr23494a-x32.d: Likewise.
* testsuite/binutils-all/x86-64/pr23494a.d: Likewise.
* testsuite/binutils-all/x86-64/pr23494b-x32.d: Likewise.
* testsuite/binutils-all/x86-64/pr23494b.d: Likewise.
* testsuite/binutils-all/x86-64/pr23494c-x32.d: Likewise.
* testsuite/binutils-all/x86-64/pr23494c.d: Likewise.
* testsuite/binutils-all/x86-64/pr23494d-x32.d: Likewise.
* testsuite/binutils-all/x86-64/pr23494d.d: Likewise.
* testsuite/binutils-all/x86-64/pr23494e-x32.d: Likewise.
* testsuite/binutils-all/x86-64/pr23494e.d: Likewise.
* testsuite/binutils-all/x86-64/x86-64.exp: Likewise.

gas/

* NEWS: Mention x86 NaCl target support removal.
* config/tc-i386.c: Remove x86 NaCl target support.
* config/tc-i386.h: Likewise.
* configure.tgt: Likewise.
* testsuite/gas/i386/i386.exp: Likewise.
* testsuite/gas/i386/iamcu-1.d: Likewise.
* testsuite/gas/i386/iamcu-2.d: Likewise.
* testsuite/gas/i386/iamcu-3.d: Likewise.
* testsuite/gas/i386/iamcu-4.d: Likewise.
* testsuite/gas/i386/iamcu-5.d: Likewise.
* testsuite/gas/i386/k1om.d: Likewise.
* testsuite/gas/i386/l1om.d: Likewise.

ld/

* Makefile.am (ALL_EMULATION_SOURCES): Remove eelf_i386_nacl.c,
eelf32_x86_64_nacl.c, eelf_x86_64_nacl.c.
Remove x86 NaCl dep files.
* NEWS: Mention x86 NaCl target support removal.
* configure.tgt: Remove x86 NaCl target support.
* testsuite/ld-elf/binutils.exp: Likewise.
* testsuite/ld-elf/elf.exp: Likewise.
* testsuite/ld-elfvers/vers.exp: Likewise.
* testsuite/ld-i386/align-branch-1.d: Likewise.
* testsuite/ld-i386/export-class.exp: Likewise.
* testsuite/ld-i386/i386.exp: Likewise.
* testsuite/ld-i386/load1.d: Likewise.
* testsuite/ld-i386/pie1.d: Likewise.
* testsuite/ld-i386/pr12570a.d: Likewise.
* testsuite/ld-i386/pr12570b.d: Likewise.
* testsuite/ld-i386/pr19636-1d.d: Likewise.
* testsuite/ld-i386/pr19636-1l.d: Likewise.
* testsuite/ld-i386/pr19636-2c.d: Likewise.
* testsuite/ld-i386/pr19636-2d.d: Likewise.
* testsuite/ld-i386/pr19636-2e.d: Likewise.
* testsuite/ld-i386/pr20244-1a.d: Likewise.
* testsuite/ld-i386/pr20244-1b.d: Likewise.
* testsuite/ld-i386/pr20244-2a.d: Likewise.
* testsuite/ld-i386/pr20244-2b.d: Likewise.
* testsuite/ld-i386/pr20244-2c.d: Likewise.
* testsuite/ld-i386/pr20244-4a.d: Likewise.
* testsuite/ld-i386/pr20244-4b.d: Likewise.
* testsuite/ld-i386/pr21884.d: Likewise.
* testsuite/ld-ifunc/binutils.exp: Likewise.
* testsuite/ld-ifunc/ifunc-10-i386.d: Likewise.
* testsuite/ld-ifunc/ifunc-10-x86-64.d: Likewise.
* testsuite/ld-ifunc/ifunc-11-i386.d: Likewise.
* testsuite/ld-ifunc/ifunc-11-x86-64.d: Likewise.
* testsuite/ld-ifunc/ifunc-12-i386.d: Likewise.
* testsuite/ld-ifunc/ifunc-12-x86-64.d: Likewise.
* testsuite/ld-ifunc/ifunc-13-i386.d: Likewise.
* testsuite/ld-ifunc/ifunc-13-x86-64.d: Likewise.
* testsuite/ld-ifunc/ifunc-14a-i386.d: Likewise.
* testsuite/ld-ifunc/ifunc-14a-x86-64.d: Likewise.
* testsuite/ld-ifunc/ifunc-14b-i386.d: Likewise.
* testsuite/ld-ifunc/ifunc-14b-x86-64.d: Likewise.
* testsuite/ld-ifunc/ifunc-14c-i386.d: Likewise.
* testsuite/ld-ifunc/ifunc-14c-x86-64.d: Likewise.
* testsuite/ld-ifunc/ifunc-14d-i386.d: Likewise.
* testsuite/ld-ifunc/ifunc-14d-x86-64.d: Likewise.
* testsuite/ld-ifunc/ifunc-14e-i386.d: Likewise.
* testsuite/ld-ifunc/ifunc-14e-x86-64.d: Likewise.
* testsuite/ld-ifunc/ifunc-14f-i386.d: Likewise.
* testsuite/ld-ifunc/ifunc-14f-x86-64.d: Likewise.
* testsuite/ld-ifunc/ifunc-15-i386.d: Likewise.
* testsuite/ld-ifunc/ifunc-15-x86-64.d: Likewise.
* testsuite/ld-ifunc/ifunc-16-i386-now.d: Likewise.
* testsuite/ld-ifunc/ifunc-16-i386.d: Likewise.
* testsuite/ld-ifunc/ifunc-16-x86-64-now.d: Likewise.
* testsuite/ld-ifunc/ifunc-16-x86-64.d: Likewise.
* testsuite/ld-ifunc/ifunc-17a-i386.d: Likewise.
* testsuite/ld-ifunc/ifunc-17a-x86-64.d: Likewise.
* testsuite/ld-ifunc/ifunc-17b-i386.d: Likewise.
* testsuite/ld-ifunc/ifunc-17b-x86-64.d: Likewise.
* testsuite/ld-ifunc/ifunc-18a-i386.d: Likewise.
* testsuite/ld-ifunc/ifunc-18a-x86-64.d: Likewise.
* testsuite/ld-ifunc/ifunc-18b-i386.d: Likewise.
* testsuite/ld-ifunc/ifunc-18b-x86-64.d: Likewise.
* testsuite/ld-ifunc/ifunc-19a-i386.d: Likewise.
* testsuite/ld-ifunc/ifunc-19a-x86-64.d: Likewise.
* testsuite/ld-ifunc/ifunc-19b-i386.d: Likewise.
* testsuite/ld-ifunc/ifunc-19b-x86-64.d: Likewise.
* testsuite/ld-ifunc/ifunc-2-i386-now.d: Likewise.
* testsuite/ld-ifunc/ifunc-2-i386.d: Likewise.
* testsuite/ld-ifunc/ifunc-2-local-i386-now.d: Likewise.
* testsuite/ld-ifunc/ifunc-2-local-i386.d: Likewise.
* testsuite/ld-ifunc/ifunc-2-local-x86-64-now.d: Likewise.
* testsuite/ld-ifunc/ifunc-2-local-x86-64.d: Likewise.
* testsuite/ld-ifunc/ifunc-2-x86-64-now.d: Likewise.
* testsuite/ld-ifunc/ifunc-2-x86-64.d: Likewise.
* testsuite/ld-ifunc/ifunc-20-i386.d: Likewise.
* testsuite/ld-ifunc/ifunc-20-x86-64.d: Likewise.
* testsuite/ld-ifunc/ifunc-21-i386.d: Likewise.
* testsuite/ld-ifunc/ifunc-21-x86-64.d: Likewise.
* testsuite/ld-ifunc/ifunc-22-i386.d: Likewise.
* testsuite/ld-ifunc/ifunc-22-x86-64.d: Likewise.
* testsuite/ld-ifunc/ifunc-5a-i386.d: Likewise.
* testsuite/ld-ifunc/ifunc-5a-local-i386.d: Likewise.
* testsuite/ld-ifunc/ifunc-5a-local-x86-64.d: Likewise.
* testsuite/ld-ifunc/ifunc-5a-x86-64.d: Likewise.
* testsuite/ld-ifunc/ifunc-5b-i386.d: Likewise.
* testsuite/ld-ifunc/ifunc-5b-local-i386.d: Likewise.
* testsuite/ld-ifunc/ifunc-5b-local-x86-64.d: Likewise.
* testsuite/ld-ifunc/ifunc-5b-x86-64.d: Likewise.
* testsuite/ld-ifunc/ifunc-5r-local-i386.d: Likewise.
* testsuite/ld-ifunc/ifunc-5r-local-x86-64.d: Likewise.
* testsuite/ld-ifunc/ifunc-6a-i386.d: Likewise.
* testsuite/ld-ifunc/ifunc-6a-x86-64.d: Likewise.
* testsuite/ld-ifunc/ifunc-6b-i386.d: Likewise.
* testsuite/ld-ifunc/ifunc-6b-x86-64.d: Likewise.
* testsuite/ld-ifunc/ifunc-7a-i386.d: Likewise.
* testsuite/ld-ifunc/ifunc-7a-x86-64.d: Likewise.
* testsuite/ld-ifunc/ifunc-7b-i386.d: Likewise.
* testsuite/ld-ifunc/ifunc-7b-x86-64.d: Likewise.
* testsuite/ld-ifunc/ifunc-8-i386.d: Likewise.
* testsuite/ld-ifunc/ifunc-8-x86-64.d: Likewise.
* testsuite/ld-ifunc/ifunc-9-i386.d: Likewise.
* testsuite/ld-ifunc/ifunc-9-x86-64.d: Likewise.
* testsuite/ld-ifunc/pr17154-i386-now.d: Likewise.
* testsuite/ld-ifunc/pr17154-i386.d: Likewise.
* testsuite/ld-ifunc/pr17154-x86-64-now.d: Likewise.
* testsuite/ld-ifunc/pr17154-x86-64.d: Likewise.
* testsuite/ld-plugin/lto.exp: Likewise.
* testsuite/ld-x86-64/align-branch-1.d: Likewise.
* testsuite/ld-x86-64/dwarfreloc.exp: Likewise.
* testsuite/ld-x86-64/line.exp: Likewise.
* testsuite/ld-x86-64/load1a.d: Likewise.
* testsuite/ld-x86-64/load1b.d: Likewise.
* testsuite/ld-x86-64/load1c.d: Likewise.
* testsuite/ld-x86-64/load1d.d: Likewise.
* testsuite/ld-x86-64/pie3.d: Likewise.
* testsuite/ld-x86-64/pr18160.d: Likewise.
* testsuite/ld-x86-64/pr19013-x32.d: Likewise.
* testsuite/ld-x86-64/pr19013.d: Likewise.
* testsuite/ld-x86-64/pr19636-2d.d: Likewise.
* testsuite/ld-x86-64/pr19636-2l.d: Likewise.
* testsuite/ld-x86-64/pr20253-1b.d: Likewise.
* testsuite/ld-x86-64/pr20253-1d.d: Likewise.
* testsuite/ld-x86-64/pr20253-1f.d: Likewise.
* testsuite/ld-x86-64/pr20253-1h.d: Likewise.
* testsuite/ld-x86-64/pr20253-1j.d: Likewise.
* testsuite/ld-x86-64/pr20253-1l.d: Likewise.
* testsuite/ld-x86-64/pr21884.d: Likewise.
* testsuite/ld-x86-64/pr22393-3a.rd: Likewise.
* testsuite/ld-x86-64/pr22393-3b.rd: Likewise.
* testsuite/ld-x86-64/tlsgd10.dd: Likewise.
* testsuite/ld-x86-64/tlsgd5.dd: Likewise.
* testsuite/ld-x86-64/tlsgd8.dd: Likewise.
* testsuite/ld-x86-64/x86-64.exp: Likewise.
* emulparams/elf32_x86_64_nacl.sh: Removed.
* emulparams/elf_i386_nacl.sh: Likewise.
* emulparams/elf_x86_64_nacl.sh: Likewise.
* testsuite/ld-i386/emit-relocs-nacl.rd: Likewise.
* testsuite/ld-i386/load1-nacl.d: Likewise.
* testsuite/ld-i386/pie1-nacl.d: Likewise.
* testsuite/ld-i386/plt-nacl.pd: Likewise.
* testsuite/ld-i386/plt-pic-nacl.pd: Likewise.
* testsuite/ld-i386/pr17709-nacl.rd: Likewise.
* testsuite/ld-i386/pr19636-1d-nacl.d: Likewise.
* testsuite/ld-i386/pr19636-2c-nacl.d: Likewise.
* testsuite/ld-i386/pr19636-2d-nacl.d: Likewise.
* testsuite/ld-i386/pr19636-2e-nacl.d: Likewise.
* testsuite/ld-i386/pr19827-nacl.rd: Likewise.
* testsuite/ld-i386/pr21884-nacl.d: Likewise.
* testsuite/ld-i386/pr21884-nacl.t: Likewise.
* testsuite/ld-i386/tlsbin-nacl.rd: Likewise.
* testsuite/ld-i386/tlsbin2-nacl.rd: Likewise.
* testsuite/ld-i386/tlsbindesc-nacl.rd: Likewise.
* testsuite/ld-i386/tlsdesc-nacl.rd: Likewise.
* testsuite/ld-i386/tlsgdesc-nacl.rd: Likewise.
* testsuite/ld-i386/tlsnopic-nacl.rd: Likewise.
* testsuite/ld-i386/tlspic-nacl.rd: Likewise.
* testsuite/ld-i386/tlspic2-nacl.rd: Likewise.
* testsuite/ld-x86-64/ilp32-4-nacl.d: Likewise.
* testsuite/ld-x86-64/load1a-nacl.d: Likewise.
* testsuite/ld-x86-64/load1b-nacl.d: Likewise.
* testsuite/ld-x86-64/load1c-nacl.d: Likewise.
* testsuite/ld-x86-64/load1d-nacl.d: Likewise.
* testsuite/ld-x86-64/pie3-nacl.d: Likewise.
* testsuite/ld-x86-64/plt-nacl.pd: Likewise.
* testsuite/ld-x86-64/pr17709-nacl.rd: Likewise.
* testsuite/ld-x86-64/pr19013-nacl.d: Likewise.
* testsuite/ld-x86-64/pr19636-2d-nacl.d: Likewise.
* testsuite/ld-x86-64/pr19827-nacl.rd: Likewise.
* testsuite/ld-x86-64/pr21884-nacl.d: Likewise.
* testsuite/ld-x86-64/pr21884-nacl.t: Likewise.
* testsuite/ld-x86-64/split-by-file-nacl.rd: Likewise.
* testsuite/ld-x86-64/tlsbin-nacl.rd: Likewise.
* testsuite/ld-x86-64/tlsbin2-nacl.rd: Likewise.
* testsuite/ld-x86-64/tlsbindesc-nacl.rd: Likewise.
* testsuite/ld-x86-64/tlsdesc-nacl.pd: Likewise.
* testsuite/ld-x86-64/tlsdesc-nacl.rd: Likewise.
* testsuite/ld-x86-64/tlsgdesc-nacl.rd: Likewise.
* testsuite/ld-x86-64/tlspic-nacl.rd: Likewise.
* testsuite/ld-x86-64/tlspic2-nacl.rd: Likewise.
* Makefile.in: Regenerated.
* po/BLD-POTFILES.in: Likewise.

Fix bug in quirk_rust_enum

Tom de Vries pointed out that some Rust tests were failing after the
variant part rewrite.  He sent an executable, which helped track down
this bug.

quirk_rust_enum was passing 1 to alloc_rust_variant in one case.
However, a comment earlier says:

      /* We don't need a range entry for the discriminant, but we do
 need one for every other field, as there is no default
 variant.  */

In this case, we must pass -1 for this parameter.  That is what this
patch implements.

gdb/ChangeLog
2020-06-30  Tom Tromey  <tromey@adacore.com>

* dwarf2/read.c (quirk_rust_enum): Correctly call
alloc_rust_variant for default-less enum.

Do not define basic_string_view::to_string

gdb's copy of basic_string_view includes a to_string method.  However,
according to cppreference, this is not a method on the real
std::basic_string_view:

https://en.cppreference.com/w/cpp/string/basic_string_view

This difference matters because gdb_string_view.h will use the
standard implementation when built with a C++17 or later.  This caused
PR build/26183.

This patch fixes the problem by changing the method to be a standalone
helper function, and then rewriting the uses.  Tested by rebuilding
with a version of GCC that defaults to C++17.

(Note that the build still is not clean; and also I noticed that the
libstdc++ string_view forbids the use of nullptr ... I wonder if gdb
violates that.)

gdb/ChangeLog
2020-06-30  Tom Tromey  <tromey@adacore.com>

PR build/26183:
* ada-lang.c (ada_lookup_name_info::ada_lookup_name_info): Use
gdb::to_string.

gdbsupport/ChangeLog
2020-06-30  Tom Tromey  <tromey@adacore.com>

PR build/26183:
* gdb_string_view.h (basic_string_view::to_string): Remove.
(gdb::to_string): New function.

Add support for attributes using DW_FORM_GNU_strp_alt

* dwarf.c (read_and_display_attr_value): Support
DW_FORM_GNU_strp_alt when used with DW_AT_dwo_name and
DW_AT_comp_dir.

[gdb/testsuite] Handle early_flags in gdb_default_target_compile

In gdb_default_target_compile, we use dejagnu's default_target_compile, unless
we need support for languages that are not yet support in the used dejagnu
version, in which case we use a local default_target_compile:
gdb_default_target_compile_1.

However, there's another reason to use the local default_target_compile: when
early_flags is used, because there's no dejagnu release available yet
supporting this.

Fix this by detecting and handling early_flags in gdb_default_target_compile.

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

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

PR testsuite/26175
* lib/future.exp (gdb_default_target_compile): Detect and handle
early_flags.

solaris XPASS ld-elf/group1

* testsuite/ld-elf/group1.d: Don't xfail all solaris targets, just
ix86 and x86_64.

Don't xfail nds32 for ld-elf/reloc-discard test

* testsuite/ld-elf/reloc-discard.d: Don't xfail nds32.

Fix nds32*-elf XPASS readelf -wiaoRlL dw5

The underlying fail was probably fixed with git commit fbaf61ad5.

* testsuite/binutils-all/readelf.exp (readelf_dump_test): Remove
xfail for nds32.

microblaze-linux XPASS ld-elf/var1

microblaze-linux uses the standard ELF script, microblaze-elf its own
script lacking an input section pattern needed to make this test pass.
Add the missing pattern for .data, in line with most other sections
that do have .* patterns.

* scripttempl/elfmicroblaze.sc (.data): Add .data.* entry.
* testsuite/ld-elf/var1.d: Don't xfail microblaze.

RISC-V: Support debug and float CSR as the unprivileged ones.

The unprivileged CSR should be controlled by other specific specs rather
than the privileged spec.  For example, the debug CSR should be controlled
by the debug spec, and the float CSR should be controlled by the float
spec.  User may use assembler options to choose what the debug and other
specs they want, or may encode the versions of specs into the architecture
string directly.  Since we haven't decided which one is better, we set the
defined and aborted versions of unprivileged CSR to PRIV_SPEC_CLASS_NONE
in the include/opcode/riscv-opc.h, to tell assembler don't check priv spec
versions for them.  However, these PRIV_SPEC_CLASS_NONE will be changed
to FLOAT_SPEC_CLASS_* and DEBUG_SPEC_CLASS_* in the future.

gas/
* config/tc-riscv.c (riscv_csr_class_check): Removed.  Move the
checking into riscv_csr_address.
(riscv_csr_version_check): Likewise.
(riscv_csr_address): New function.  Return the suitable CSR address
after checking the ISA dependency and versions.  Issue warnings if
we find any conflict and -mcsr-check is set.  CSR_CLASS_F and
CSR_CLASS_DEBUG are unprivileged CSR for now, so don't check the
priv spec versions for them.
(reg_csr_lookup_internal): Call riscv_csr_address to find the
suitable CSR address.

* testsuite/gas/riscv/priv-reg-fail-fext.d: Remove -mpriv-spec=1.11.
* testsuite/gas/riscv/priv-reg-fail-read-only-01.d: Likewise.
* testsuite/gas/riscv/priv-reg-fail-rv32-only.d: Likewise.
* testsuite/gas/riscv/priv-reg-fail-fext.l:  We don't care the
priv spec warnings here.  These warnings are added by accident.
Remove them and only focus on the ISA dependency warnings.
* testsuite/gas/riscv/priv-reg-fail-rv32-only.l: Likewise.
* testsuite/gas/riscv/priv-reg-fail-read-only-01.l: Likewise.
* testsuite/gas/riscv/priv-reg-fail-version-1p9.l: Updated since
dscratch0 and dscratch1 are regarded as the unprivileged CSR rather
than the privileged ones.
* testsuite/gas/riscv/priv-reg-fail-version-1p9p1.l: Likewise.
* testsuite/gas/riscv/priv-reg-fail-version-1p10.l: Likewise.
* testsuite/gas/riscv/priv-reg-fail-version-1p11.l: Likewise.
* testsuite/gas/riscv/priv-reg.s: Likewise.  Add missing debug CSR.
* testsuite/gas/riscv/priv-reg-version-1p9.d: Likewise.
* testsuite/gas/riscv/priv-reg-version-1p9p1.d: Likewise.
* testsuite/gas/riscv/priv-reg-version-1p10.d: Likewise.
* testsuite/gas/riscv/priv-reg-version-1p11.d: Likewise.
* testsuite/gas/riscv/csr-dw-regnums.d: Likewise.
* testsuite/gas/riscv/csr-dw-regnums.s: Likewise.

include/
* opcode/riscv-opc.h: Support the unprivileged CSR.  The versions
of the unprivileged CSR should be PRIV_SPEC_CLASS_NONE for now.
* opcode/riscv.h (enum riscv_csr_class): Add CSR_CLASS_DEBUG.

opcodes/
* riscv-dis.c (print_insn_args, case 'E'): Updated.  Let the
unprivileged CSR can also be initialized.

RISC-V: Cleanup the include/opcode/riscv-opc.h.

The include/opcode/riscv-opc.h file is no longer automatically generated,
so we remove the misleading comments and add new ones.  Besides, the CAUSE_*
macros and DECLARE_CAUSE are unused for binutils and gdb.  Therefore, remove
them, too.

include/
* opcode/riscv-opc.h: Cleanup and remove the unused macros.

Automatic date update in version.in

gdb: fix documentation of gdbarch_displaced_step_copy_insn

I spotted something that looks wrong in the doc of
gdbarch_displaced_step_copy_insn.

It says that if the function returns NULL, it means that it has emulated
the behavior of the instruction and written the result to REGS.
However, it says below that the function may return NULL to indicate
that the instruction can't be single-stepped out-of-line, in which case
the core steps the instruction in-line.  The two are contradictory.

The right one is the latter, if the function returns NULL, the core
falls back to in-line stepping. I checked all the implementations of
this function and they all agree with this.

gdb/ChangeLog:

* gdbarch.sh (displaced_step_copy_insn): Update doc.
* gdbarch.h: Re-generate.

Change-Id: I98163cdd38970cde4c77680e249b10f5d2d5bf9b

gdb/testsuite: better handle failures in simavr board, reap simavr process

This patch makes a few adjustments to the simavr.exp to handle tests
that error out more gracefully.  I put all the changes in the same patch
because right now it's in a very bad shape, so it's very painful to do
small incremental adjustements.  I found that with these changes, it
becomes reasonably stable.

For example, the gdb.base/step-over-syscall.exp test is a bit buggy
(stuff for another patch...), in that it calls gdb_load (through
clean_restart) with a file that doesn't exist.  The gdb_load
implementation in simavr.exp gets called with a file that doesn't exist,
and simavr (expectedly) fails to start.

When this happens, we currently leave the $simavr_spawn_id variable set.
However, because the simavr process has terminated, its spawn id is
closed.  When the next test tries to close the previous connection to
simavr, it fails to, and this error is thrown:

    ERROR: close: spawn id exp86 not open
        while executing
    "close -i $simavr_spawn_id"
        (procedure "gdb_load" line 18)
        invoked from within

In other words, any test ran after step-over-syscall.exp will have
simavr.exp's gdb_load fail on it.

This patch tries to make sure that simavr.exp's gdb_load only leaves
simavr_spawn_id set if everything went fine.  If we couldn't start
simavr, don't see the expected output, or fail to connect to it, we
close the spawn id (if needed) and unset simavr_spawn_id.

As an additional precaution, I added a catch around the "close the
previous connection" code.  Ideally, this shouldn't be necessary, but I
bet there are other similar scenarios where we might try to close an
already close spawn id.  So I think displaying a warning is better than
messing up all following tests.

Also, the board never wait'ed for the simavr process, resulting in tons
of zombie simavr processes hanging around.  This patch adds some calls
to "wait" whenever we close the connection (or realize it is already
closed), which seems to fix the problem.

Finally I switched a `gdb_expect` to bare `expect`, where we wait for
the "listening" message from simavr.  I found it necessary because
gdb_expect (through remote_expect) adds a `-i <gdb spawn id> -timeout
10`.  So if for some reason the GDB process has crashed in the mean
time, this expect will unexpectedly error out with a `spawn id <gdb
spawn id> not open`.  Therefore, change `gdb_expect` to `expect` so that
we only deal with simavr's spawn id here.

Here are the results on TESTS="gdb.base/*.exp" before:

    # of expected passes 4816
    # of unexpected failures 4433
    # of known failures 2
    # of unresolved testcases 300
    # of untested testcases 143
    # of unsupported tests 7
    # of paths in test names 2
    # of duplicate test names 10

and after:

    # of expected passes 21957
    # of unexpected failures 1564
    # of expected failures 8
    # of unknown successes 1
    # of known failures 31
    # of unresolved testcases 532
    # of untested testcases 153
    # of unsupported tests 28
    # of paths in test names 2
    # of duplicate test names 32

I tested using simavr's current master (7c254e2081b5).

gdb/testsuite/ChangeLog:

* boards/simavr.exp (gdb_load): Catch errors when closing
previous connection.  Close connection, wait for process and
unset simavr_spawn_id on failure.

Change-Id: I695fc765e1c22e1d1dc0b08e0f5141244986b868

x86: Support VEX base opcode length > 1

Intel AMX instructions with 8-bit immediate opcode extension without
operands:

tilerelease, 0, 0x49c0, None, 2, CpuAMX_TILE|Cpu64, Vex|VexOpcode=1|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { 0 }

Update build_vex_prefix to support VEX base opcode length > 1.

* tc-i386.c (build_vex_prefix): Support VEX base opcode length > 1.
(md_assemble): Don't process ImmExt without operands.

tic6x: Call _bfd_elf_add_dynamic_tags

Update tic6x linker tests to expect C6000_DSBT_BASE, C6000_DSBT_SIZE and
C6000_DSBT_INDEX dynamic tags immediately before NULL dynamic tag.

bfd/

* elf32-tic6x.c (elf32_tic6x_size_dynamic_sections): Call
_bfd_elf_add_dynamic_tags.

ld/

* testsuite/ld-tic6x/shlib-1.rd: Move C6000_DSBT_BASE,
C6000_DSBT_SIZE and C6000_DSBT_INDEX dynamic tags to the last.
* testsuite/ld-tic6x/shlib-1b.rd: Likewise.
* testsuite/ld-tic6x/shlib-1r.rd: Likewise.
* testsuite/ld-tic6x/shlib-1rb.rd: Likewise.
* testsuite/ld-tic6x/shlib-app-1.rd: Likewise.
* testsuite/ld-tic6x/shlib-app-1b.rd: Likewise.
* testsuite/ld-tic6x/shlib-app-1r.rd: Likewise.
* testsuite/ld-tic6x/shlib-app-1rb.rd: Likewise.
* testsuite/ld-tic6x/shlib-noindex.rd: Likewise.
* testsuite/ld-tic6x/static-app-1.rd: Likewise.
* testsuite/ld-tic6x/static-app-1b.rd: Likewise.
* testsuite/ld-tic6x/static-app-1r.rd: Likewise.
* testsuite/ld-tic6x/static-app-1rb.rd: Likewise.

[gdb/testsuite] Emit unresolved for unknown proc

Since commit 26783bce15 "[gdb/testsuite] Don't abort testrun for invalid
command in test-case" we don't abort the testrun when encountering an invalid
command.  However, since we don't report errors in the summary, there's a
chance that the error goes unnoticed.

Make the invalid command error more visible by marking the test-case
unresolved, such that we have f.i.:
...
PASS: gdb.python/py-breakpoint.exp: test_bkpt_internal: Test watchpoint write
UNRESOLVED: gdb.python/py-breakpoint.exp: test_bkpt_eval_funcs: \
  testcase aborted due to invalid command name: gdb_py_test_multiple
ERROR: tcl error sourcing py-breakpoint.exp.
ERROR: invalid command name "gdb_py_test_multiple"
    while executing
  ...
                === gdb Summary ===

nr of expected passes            56
nr of unresolved testcases       1
...

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

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

* lib/gdb.exp (unknown): Make test-case unresolved.

[gdbserver] Add missing include of gdbsupport/agent.h

The file gdbserver/ax.h contains:
...
 #ifdef IN_PROCESS_AGENT
 #define debug_threads debug_agent
 #endif
...
but does not declare debug_agent.

Fix this by adding an include of gdbsupport/agent.h.

[ If this fix would have been in place before commit 8118159c69 "[gdbserver] Fix
Wlto-type-mismatch for debug_agent", we would have simply run into this build
breaker with a regular, non-lto build:
...
src/gdbserver/ax.cc:28:5: error: conflicting declaration 'int debug_agent'
 int debug_agent = 0;
     ^~~~~~~~~~~
In file included from src/gdbserver/ax.h:25:0,
                 from src/gdbserver/ax.cc:20:
src/gdbsupport/agent.h:47:13: note: previous declaration as 'bool debug_agent'
 extern bool debug_agent;
             ^~~~~~~~~~~
... ]

Tested on x86_64-linux.

gdbserver/ChangeLog:

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

* ax.h: Include gdbsupport/debug_agent.h.

[gdb/testsuite] Expect conformation question in gdb.server/solib-list.exp

Before commit a8654e7d78 'Fixes PR 25475: ensure exec-file-mismatch "ask"
always asks in case of mismatch', there was a difference in behaviour in
test-case gdb.server/solib-list.exp.

If the executable did not contain debug info (as is usually the case), gdb
would detect a mismatch but not ask for confirmation:
...
(gdb) target remote localhost:2346^M
Remote debugging using localhost:2346^M
warning: Mismatch between current exec-file solib-list^M
and automatically determined exec-file /lib64/ld-2.26.so^M
exec-file-mismatch handling is currently "ask"^M
Reading symbols from /lib64/ld-2.26.so...^M
Reading symbols from /usr/lib/debug/lib64/ld-2.26.so.debug...^M
0x00007ffff7dd7ea0 in _start () at rtld.c:745^M
745     }^M
(gdb) PASS: gdb.server/solib-list.exp: non-stop 0: target remote
...

If the executable did contain debug info (as happens to be the case for
openSUSE), gdb would detect a mismatch and ask for confirmation:
...
(gdb) PASS: gdb.server/solib-list.exp: non-stop 0: file binfile
target remote localhost:2346^M
Remote debugging using localhost:2346^M
warning: Mismatch between current exec-file solib-list^M
and automatically determined exec-file /lib64/ld-2.26.so^M
exec-file-mismatch handling is currently "ask"^M
Load new symbol table from "/lib64/ld-2.26.so"? (y or n) y^M
Reading symbols from /lib64/ld-2.26.so...^M
Reading symbols from /usr/lib/debug/lib64/ld-2.26.so.debug...^M
0x00007ffff7dd7ea0 in _start () at rtld.c:745^M
745     }^M
(gdb) PASS: gdb.server/solib-list.exp: non-stop 0: target remote
...

After commit a8654e7d78, the confirmation is now also asked in case there's
no debug info.

Tighten the test-case by verifying that the confirmation question is asked, as
suggested in the log message of commit a8654e7d78:
...
we can remove the bypass introduced by Tom in 6b9374f1, in order to always
answer to the 'load' question.
...

gdb/testsuite/ChangeLog:

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

PR gdb/25475
* gdb.server/solib-list.exp: Verify that the symbol reload
confirmation question is asked.

gas/testsuite: test-case for PR25331 (mmix reloc fixup bug)

The bug manifested "only" for a 64-bit host:

pr25331.c: Assembler messages:
pr25331.c:430: Error: internal error: fixup not contained within frag
failed with: <pr25331.c: Assembler messages:
pr25331.c:430: Error: internal error: fixup not contained within frag>, no expected output
FAIL: gas/mmix/pr25331

gas:
PR gas/25331
* testsuite/gas/mmix/pr25331.d, testsuite/gas/mmix/pr25331.s: New test.

gas: Fix mmix fixups and TC_FX_SIZE_SLACK, PR25331

Finally; sorry for the delay.  There were a few false starts, where I
misinterpreted the error-messages and the comment that Alan added:
it's not the fix size that's too large (and the frag too small), it's
stating the wrong size of what will be "fixed up" - that of the actual
target value, not the size of the field that needs to be adjusted.
Comments added for clarity.

Test-suite committed separately.

gas:
PR gas/25331
* config/tc-mmix.c (md_assemble) <fixup for
BFD_RELOC_MMIX_BASE_PLUS_OFFSET>: This fixup affects 1 byte, not 8.
Also, set its fx_no_overflow.
(md_convert_frag) <case ENCODE_RELAX (STATE_PUSHJSTUB, STATE_ZERO)>:
Similarly this fixup affects 4 bytes, not 8 and needs its
fx_no_overflow set.
* config/tc-mmix.h (TC_FX_SIZE_SLACK): Don't define.

binutils/dwarf.c: Correct an `index' global shadowing error for pre-4.8 GCC

In older gcc, shadowing a function name with a local variable name is
flagged as an error, certainly a bug but which is usually worked
around in binutils:

gcc -DHAVE_CONFIG_H -I. -I$SRC/binutils  -I. -I$SRC/binutils -I../bfd -I$SRC/binutils/../bfd -I$SRC/binutils/../include -DLOCALEDIR="\"/usr/local/share/locale\"" -Dbin_dummy_emulation=bin_vanilla_emulation  -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Werror -I$SRC/binutils/../zlib -g -O2 -MT dwarf.o -MD -MP -MF $depbase.Tpo -c -o dwarf.o $SRC/binutils/dwarf.c &&\
mv -f $depbase.Tpo $depbase.Po
cc1: warnings being treated as errors
$SRC/binutils/dwarf.c: In function 'display_debug_str_offsets':
$SRC/binutils/dwarf.c:6913: error: declaration of 'index' shadows a global declaration
/usr/include/string.h:309: error: shadowed declaration is here
make[4]: *** [dwarf.o] Error 1

See also GCC PR c/53066.  This is just another one that crept in since
I and others last had to use an old version.  The name "idx" was used
in the preceding function, display_debug_addr.  Also, it was declared
c99 style (after a statement in the block).  Committed as obvious.

binutils:
* dwarf.c (display_debug_str_offsets): Rename local variable
index to idx.  Move to top of function.

asan: _bfd_pei_slurp_codeview_record use of uninit value

Fixes some seriously careless code.  bfd_bread return value is
(bfd_size_type)-1 on error.  "if (bfd_bread (...) < 4)" does not check
for an error since bfd_size_type is unsigned.  In any case, I think we
should be reading and checking the requested length.

* peXXigen.c (_bfd_XXi_slurp_codeview_record): Properly check
return value of bfd_bread.  Don't read more than requested length.
Sanity check length.  Properly terminate file name.

C++ comments

binutils isn't c99 (yet).  This replaces or removes some C++ style
comments.

bfd/
* arc-got.h: Use C style comments.
* coff-z80.c: Likewise.
* elf32-csky.c: Likewise.
* peXXigen.c: Likewise.
* elf32-m32c.c (m32c_elf_relax_delete_bytes): Remove commented out
code.
binutils/
* dwarf.c: Use C style comments.
* resrc.c: Likewise.
gas/
* config/tc-s12z.c: Use C style comments.
* config/tc-z80.c: Likewise.
* config/tc-xtensa.c (emit_ld_r_n): Remove commented out code.
include/
* coff/internal.h: Use C style comments.
* coff/pe.h: Likewise.
* elf/ppc64.h: Likewise.
opcodes/
* arm-dis.c: Use C style comments.
* cr16-opc.c: Likewise.
* ft32-dis.c: Likewise.
* moxie-opc.c: Likewise.
* tic54x-dis.c: Likewise.
* s12z-opc.c: Remove useless comment.
* xgate-dis.c: Likewise.

x86_64 k1om tests

On x86_64-nacl we currently see
FAIL: Absolute non-overflowing relocs
FAIL: ld-x86-64/protected2-k1om
FAIL: ld-x86-64/protected3-k1om

This limits the tests as per the l1om variants.

* testsuite/ld-x86-64/abs-k1om.d: Run only on x86_64-*-linux*.
* testsuite/ld-x86-64/protected2-k1om.d: Likewise.
* testsuite/ld-x86-64/protected3-k1om.d: Likewise.

Automatic date update in version.in

Remove "cmd_type" function

The cmd_type function only has a single caller, which is in the CLI
implementation code.  This patch removes the function, and moves the
cmd_types enum definition from command.h to cli-decode.h, fixing an 18
year old FIXME.

gdb/ChangeLog
2020-06-28  Tom Tromey  <tom@tromey.com>

* command.h (cmd_types): Remove.
(cmd_type): Don't declare.
* cli/cli-decode.h (enum cmd_types): Uncomment.  No longer a
typedef.
* cli/cli-cmds.c (setting_cmd): Use cmd->type directly.
* cli/cli-decode.c (cmd_type): Remove.