Fix ARMv8.4 for hw watchpoint and breakpoint

Just like my previoius patch for ARMv8.1 and v8.2 (49ecef2a7da2ee9df4),
this adds ARMv8.4 debug arch as being compatible for hw watchpoint
and breakpoints.

Refactor code slightly in nat/aarch64-linux-hw-point.c (aarch64_linux_get_debug_reg_capacity)

Since the two locations which check the debug arch are the same code currently, it is
a good idea to factor it out to a new function and just use that function from
aarch64_linux_get_debug_reg_capacity. This is also the first step to support
ARMv8.4 debug arch.

Fixes for gdb.mi/mi-break.exp

Update the expected pattern for two of the tests.

Matching pattern \" doesn't work.  Use .*  to match the \* pattern.

[gdb/tui] Fix breakpoint display functionality

In commit 81e6b8eb208 "Make tui-winsource not use breakpoint_chain", a loop
body was transformed into a lambda function body:
...
-      for (bp = breakpoint_chain;
-           bp != NULL;
-           bp = bp->next)
+      iterate_over_breakpoints ([&] (breakpoint *bp) -> bool
...
and consequently:
- a continue was replaced by a return, and
- a final return was added.

Then in commit 240edef62f0 "gdb: remove iterate_over_breakpoints function", we
transformed back to a loop body:
...
-      iterate_over_breakpoints ([&] (breakpoint *bp) -> bool
+      for (breakpoint *bp : all_breakpoints ())
...
but without reverting the changes that introduced the two returns.

Consequently, breakpoints no longer show up in the tui source window.

Fix this by reverting the changes that introduced the two returns.

Build on x86_64-linux, tested with all .exp test-cases that contain
tuiterm_env.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28483

Fix test step-and-next-inline.cc

The test expect the runto_main to stop at the first line of the function.
Depending on the optimization level, gdb may stop in the prolog or after
the prolog at the first line.  To ensure the test stops at the first line
of main, have it explicitly stop at a break point on the first line of the
function.

On PowerPC, the test passes when compiled with no optimization but fails
with all levels of optimization due to gdb stopping in the prolog.

Fix latent Ada bug when accessing field offsets

The "add accessors for field (and call site) location" patch caused a
gdb crash when running the internal AdaCore testsuite.  This turned
out to be a latent bug in ada-lang.c.

The immediate cause of the bug is that find_struct_field
unconditionally uses TYPE_FIELD_BITPOS.  This causes an assert for a
dynamic type.

This patch fixes the problem by doing two things.  First, it changes
find_struct_field to use a dummy value for the field offset in the
situation where the offset is not actually needed by the caller.  This
works because the offset isn't used in any other way -- only as a
result.

Second, this patch assures that calls to find_struct_field use a
resolved type when the offset is needed.  For
value_tag_from_contents_and_address, this is done by resolving the
type explicitly.  In ada_value_struct_elt, this is done by passing
nullptr for the out parameters when they are not needed (the second
call in this function already uses a resolved type).

Note that, while we believe the parent field probably can't occur at a
variable offset, the patch still updates this code path, just in case.

I've updated an existing test case to reproduce the crash.
I'm checking this in.

-Waddress warning in ldelf.c

ldelf.c: In function 'ldelf_after_open':
ldelf.c:1049:43: warning: the comparison will always evaluate as 'true' for the address of 'elf_header' will never be NULL [-Waddress]
 1049 |           && elf_tdata (abfd)->elf_header != NULL
      |                                           ^~
In file included from ldelf.c:37:
../bfd/elf-bfd.h:1957:21: note: 'elf_header' declared here
 1957 |   Elf_Internal_Ehdr elf_header[1];      /* Actual data, but ref like ptr */

* ldelf.c (ldelf_after_open): Remove useless elf_header test.

Avoid -Waddress warnings in readelf

Mainline gcc:
readelf.c: In function 'find_section':
readelf.c:349:8: error: the comparison will always evaluate as 'true' for the pointer operand in 'filedata->section_headers + (sizetype)((long unsigned int)i * 80)' must not be NULL [-Werror=address]
  349 |   ((X) != NULL                                                          \
      |        ^~
readelf.c:761:9: note: in expansion of macro 'SECTION_NAME_VALID'
  761 |     if (SECTION_NAME_VALID (filedata->section_headers + i)
      |         ^~~~~~~~~~~~~~~~~~

This will likely be fixed in gcc, but inline functions are nicer than
macros.

* readelf.c (SECTION_NAME, SECTION_NAME_VALID),
(SECTION_NAME_PRINT, VALID_SYMBOL_NAME, VALID_DYNAMIC_NAME),
(GET_DYNAMIC_NAME): Delete.  Replace with..
(section_name, section_name_valid, section_name_print),
(valid_symbol_name, valid_dynamic_name, get_dynamic_name): ..these
new inline functions.  Update use throughout file.

Automatic date update in version.in

PR28417, std::string no longer allows accepting nullptr_t

PR 28417
* incremental.cc (Sized_relobj_incr::do_section_name): Avoid
std:string undefined behaviour.
* options.h (Search_directory::Search_directory): Likewise.

Re: PR27625, powerpc64 gold __tls_get_addr calls

My previous PR27625 patch had a problem or two.  For one, the error
"__tls_get_addr call lacks marker reloc" on processing some calls
before hitting a call without markers typically isn't seen.  Instead a
gold assertion fails.  Either way it would be a hard error, which
triggers on a file contained in libphobos.a when running the gcc
testsuite.  A warning isn't even appropriate since the call involved
is one built by hand without any of the arg setup relocations that
might result in linker optimisation.

So this patch reverts most of commit 0af4fcc25dd5, instead entirely
ignoring the problem of mis-optimising old-style __tls_get_addr calls
without marker relocs.  We can't handle them gracefully without
another pass over relocations before decisions are made about GOT
entries in Scan::global or Scan::local.  That seems too costly, just
to link object files from 2009.  What's more, there doesn't seem to be
any way to allow the libphobos explicit __tls_get_addr call, but not
old TLS sequences without marker relocs.  Examining instructions
before the __tls_get_addr call is out of the question: program flow
might reach the call via a branch.  Putting an R_PPC64_TLSGD marker
with zero sym on the call might be a solution, but current linkers
will then merrily optimise away the call!

PR gold/27625
* powerpc.cc (Powerpc_relobj): Delete no_tls_marker_, tls_marker_,
and tls_opt_error_ variables and accessors.  Remove all uses.

Use std::string in print_one_catch_syscall

This changes print_one_catch_syscall to use std::string, removing a
bit of manual memory management.

Use unique_xmalloc_ptr in breakpoint

This changes struct breakpoint to use unique_xmalloc_ptr in a couple
of spots, removing a bit of manual memory management.

Use unique_xmalloc_ptr in bp_location

This changes struct bp_location to use a unique_xmalloc_ptr, removing
a bit of manual memory management.

Use unique_xmalloc_ptr in watchpoint

This changes struct watchpoint to use unique_xmalloc_ptr in a couple
of places, removing a bit of manual memory management.

Use unique_xmalloc_ptr in exec_catchpoint

This changes struct exec_catchpoint to use a unique_xmalloc_ptr,
removing a bit of manual memory management.

Use unique_xmalloc_ptr in solib_catchpoint

This changes struct solib_catchpoint to use a unique_xmalloc_ptr,
removing a bit of manual memory management.

Make c-exp.y work with Bison 3.8+

When using Bison 3.8, we get this error:

    ../../gdb/c-exp.y:3455:1: error: 'void c_print_token(FILE*, int, YYSTYPE)' defined but not used [-Werror=unused-function]

That's because bison 3.8 removed YYPRINT support:
https://savannah.gnu.org/forum/forum.php?forum_id=10047

Accordingly, this patch only defines that function for Bison < 3.8.

Change-Id: I3cbf2f317630bb72810b00f2d9b2c4b99fa812ad

Automatic date update in version.in

[gdb/testsuite] Reimplement gdb.gdb/python-interrupts.exp as unittest

The test-case gdb.gdb/python-interrupts.exp:
- runs to captured_command_loop
- sets a breakpoint at set_active_ext_lang
- calls a python command
- verifies the command triggers the breakpoint
- sends a signal and verifies the result

The test-case is fragile, because (f.i. with -flto) it cannot be guaranteed
that captured_command_loop and set_active_ext_lang are available for setting
breakpoints.

Reimplement the test-case as unittest, using:
- execute_command_to_string to capture the output
- try/catch to catch the "Error while executing Python code" exception
- a new hook selftests::hook_set_active_ext_lang to raise the signal

Tested on x86_64-linux.

Check index in type::field

This changes gdb to check the index that is passed to type::field.
This caught one bug in the Ada code when running the test suite
(actually I found the bug first, then realized that the check would
have helped), so this patch fixes that as well.

Regression tested on x86-64 Fedora 34.

Fix Rust lex selftest when using libiconv

The Rust lex selftest fails on our Windows build.  I tracked this down
to a use of UTF-32 as a parameter to convert_between_encodings.  Here,
iconv_open succeeds, but the actual conversion of a tab character
fails with EILSEQ.  I suspect that "UTF-32" is being interpreted as
big-endian, as changing the call to use "UTF-32LE" makes it work.
This patch implements this fix.

Fix format_pieces selftest on Windows

The format_pieces selftest currently fails on Windows hosts.

The selftest doesn't handle the "%ll" -> "%I64" rewrite that the
formatter may perform, but also gdbsupport was missing a configure
check for PRINTF_HAS_LONG_LONG.  This patch fixes both issues.

Fix bug in dynamic type resolution

A customer-reported problem led us to a bug in dynamic type
resolution.  resolve_dynamic_struct will recursively call
resolve_dynamic_type_internal, passing it the sub-object for the
particular field being resolved.  While it offsets the address here,
it does not also offset the "valaddr" -- the array of bytes describing
the memory.

This patch fixes the bug, by offsetting both.  A test case is included
that can be used to reproduce the bug.

Always use std::function for self-tests

Now that there is a register_test variant that accepts std::function,
it seems to me that the 'selftest' struct and accompanying code is
obsolete -- simply always using std::function is simpler.  This patch
implements this idea.

Fix PR gdb/17917 Lookup build-id in remote binaries

GDB doesn't support loading debug files using build-id from remote
target filesystems.

This is the case when gdbserver attached to a process and a gdb target
remote occurs over tcp.

With this change we make build-id lookups possible:

    (gdb) show debug-file-directory
    The directory where separate debug symbols are searched for is "/usr/local/lib/debug".
    (gdb) set debug-file-directory /usr/lib/debug
    (gdb) show sysroot
    The current system root is "target:".
    (gdb) target extended-remote :46615
    Remote debugging using :46615
    warning: Can not parse XML target description; XML support was disabled at compile time
    Reading /usr/sbin/mariadbd from remote target...
    warning: File transfers from remote targets can be slow. Use "set sysroot" to access files locally instead.
    Reading /usr/sbin/mariadbd from remote target...
    Reading symbols from target:/usr/sbin/mariadbd...
    Reading /usr/lib/debug/.build-id/6e/0a874dca5a7ff831396ddc0785d939a192efe3.debug from remote target...
    Reading /usr/lib/debug/.build-id/6e/0a874dca5a7ff831396ddc0785d939a192efe3.debug from remote target...
    Reading symbols from target:/usr/lib/debug/.build-id/6e/0a874dca5a7ff831396ddc0785d939a192efe3.debug...
    Reading /lib/x86_64-linux-gnu/libpcre2-8.so.0 from remote target...
    ...

Before this change, the lookups would have been (GNU gdb (GDB) Fedora 10.2-3.fc34):

    (gdb) target extended-remote :46615
    Remote debugging using :46615
    Reading /usr/sbin/mariadbd from remote target...
    warning: File transfers from remote targets can be slow. Use "set sysroot" to access files locally instead.
    Reading /usr/sbin/mariadbd from remote target...
    Reading symbols from target:/usr/sbin/mariadbd...
    Reading /usr/sbin/0a874dca5a7ff831396ddc0785d939a192efe3.debug from remote target...
    Reading /usr/sbin/.debug/0a874dca5a7ff831396ddc0785d939a192efe3.debug from remote target...
    Reading /usr/lib/debug//usr/sbin/0a874dca5a7ff831396ddc0785d939a192efe3.debug from remote target...
    Reading /usr/lib/debug/usr/sbin//0a874dca5a7ff831396ddc0785d939a192efe3.debug from remote target...
    Reading target:/usr/lib/debug/usr/sbin//0a874dca5a7ff831396ddc0785d939a192efe3.debug from remote target...
    Missing separate debuginfo for target:/usr/sbin/mariadbd
    Try: dnf --enablerepo='*debug*' install /usr/lib/debug/.build-id/6e/0a874dca5a7ff831396ddc0785d939a192efe3.debug
    (No debugging symbols found in target:/usr/sbin/mariadbd)

Observe it didn't look for
/usr/lib/debug/.build-id/6e/0a874dca5a7ff831396ddc0785d939a192efe3.debug
on the remote target (where it is) and expected them to be installed
locally.

As a minor optimization, this also changes the build-id lookup such that
if sysroot is empty, no second lookup of the same location is performed.

Change-Id: I5181696d271c325a25a0805a8defb8ab7f9b3f55
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=17917

Fix a potential illegal memory access when testing for a special LTO symbol name.

bfd * linker.c (_bfd_generic_link_add_one_symbol): Test for a NULL
name before checking to see if the symbol is __gnu_lto_slim.
* archive.c (_bfd_compute_and_write_armap): Likewise.
binutils
* nm.c (filter_symbols): Test for a NULL name before checking to
see if the symbol is __gnu_lto_slim.
* objcopy.c (filter_symbols): Likewise.

Automatic date update in version.in

CTF: incorrect underlying type setting for enumeration types

A bug was filed against the incorrect underlying type setting for
an enumeration type, which was caused by a copy and paste error.
This patch fixes the problem by setting it by calling objfile_int_type,
which was originally dwarf2_per_objfile::int_type, with ctf_type_size bits.
Also add error checking on ctf_func_type_info call.

Automatic date update in version.in

PR28459, readelf issues bogus warning

I'd missed the fact that the .debug_rnglists dump doesn't exactly
display the contents of the section.  Instead readelf rummages through
.debug_info looking for DW_AT_ranges entries, then displays the
entries in .debug_rnglists pointed at, sorted.  A simpler dump of the
actual section contents might be more useful and robust, but it was
likely done that way to detect overlap and holes.

Anyway, the headers in .debug_rnglists besides the first are ignored,
and limiting to the unit length of the first header fails if there is
more than one unit.

PR 28459
* dwarf.c (display_debug_ranges): Don't constrain data to length
in header.

Automatic date update in version.in

ld: Adjust pr28158.rd for glibc 2.34

Adjust pr28158.rd for glibc 2.34:

$ readelf -W --dyn-syms tmpdir/pr28158

Symbol table '.dynsym' contains 4 entries:
   Num:    Value          Size Type    Bind   Vis      Ndx Name
     0: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT  UND
     1: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __libc_start_main@GLIBC_2.34 (2)
     2: 0000000000000000     0 NOTYPE  WEAK   DEFAULT  UND __gmon_start__
     3: 000000000040401c     4 OBJECT  GLOBAL DEFAULT   23 foo@VERS_2.0 (3)
$

vs older glibc:

$ readelf -W --dyn-syms tmpdir/pr28158

Symbol table '.dynsym' contains 4 entries:
   Num:    Value          Size Type    Bind   Vis      Ndx Name
     0: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT  UND
     1: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __libc_start_main@GLIBC_2.2.5 (3)
     2: 0000000000000000     0 NOTYPE  WEAK   DEFAULT  UND __gmon_start__
     3: 000000000040401c     4 OBJECT  GLOBAL DEFAULT   23 foo@VERS_2.0 (2)

$

* testsuite/ld-elf/pr28158.rd: Adjusted for glibc 2.34.

Automatic date update in version.in

Automatic date update in version.in

Powerpc: Add support for openat and fstatat syscalls

[gdb] update ppc-linux-tdep.c

Add argument to ppc_canonicalize_syscall for the wordsize.
Add syscall entries for the openat and fstatat system calls.

[gdb/testsuite] Add .debug_loc support in dwarf assembler

Add .debug_loc support in the dwarf assembler, and use it in new test-case
gdb.dwarf2/loc-sec-offset.exp (which is based on
gdb.dwarf2/loclists-sec-offset.exp).

Tested on x86_64-linux.

[GOLD] Re: PowerPC64: Don't pretend to support multi-toc

We can't get at section->address() until everything is laid out, so
trying to generalise the offset calculation rather than using a value
of 0x8000 (the old object->toc_base_offset()) was bound to fail.
got->g_o_t() is a little better than a hard-coded 0x8000.

* powerpc.cc (Target_powerpc::Scan::local, global): Don't use
toc_pointer() here.

[GOLD] Two GOT sections for PowerPC64

Split .got into two piece, one with the header and entries for small
model got entries, the other with entries for medium/large model got
entries.  The idea is to better support mixed pcrel/non-pcrel code
where non-pcrel small-model .toc entries need to be within 32k of the
toc pointer.

* target.h (Target::tls_offset_for_local): Add got param.
(Target::tls_offset_for_global): Likewise.
(Target::do_tls_offset_for_local, do_tls_offset_for_global): Likewise.
* output.h (Output_data_got::Got_entry::write): Add got param.
* output.cc (Output_data_got::Got_entry::write): Likewise, pass to
tls_offset_for_local/global calls.
(Output_data_got::do_write): Adjust to suit.
* s390.cc (Target_s390::do_tls_offset_for_local): Likewise.
(Target_s390::do_tls_offset_for_global): Likewise.
* powerpc.cc (enum Got_type): Extend with small types, move from
class Target_powerpc.
(Target_powerpc::biggot_): New.
(Traget_powerpc::do_tls_offset_for_local, do_tls_offset_for_global,
got_size, got_section, got_base_offset): Handle biggot_.
(Target_powerpc::do_define_standard_symbols): Adjust.
(Target_powerpc::make_plt_section, do_finalize_sections): Likewise.
(Output_data_got_powerpc::Output_data_got_powerpc): Only make
64-bit header for small got section.
(Output_data_got_powerpc::g_o_t): Only return a result for small
got section.
(Output_data_got_powerpc::write): Only write small got section
header.
(Target_powerpc::Scan::local, global): Select small/big Got_type
and section to suit reloc.
(Target_powerpc::Relocate::relocate): Similarly.
(Sort_toc_sections): Rewrite.

[GOLD] PowerPC64: Don't pretend to support multi-toc

Code in powerpc.cc is pretending to support a per-object toc pointer
value, but powerpc gold has no real support for multi-toc.  This patch
removes the pretense, tidying quite a lot in preparation for a
followup patch.  If multi-toc is ever to be supported, don't revert
this patch but start by adding object parameter to toc_pointer() and
an object to Branch_stub_key.

* powerpc.cc (Powerpc_relobj::toc_base_offset): Delete.
(Target_powerpc::toc_pointer): New function.  Use throughout.
(Target_powerpc::got_base_offset): New function.  Use throughout..
(Output_data_got_powerpc::got_base_offset): ..in place of
this.  Delete.
(Output_data_got_powerpc::Output_data_got_powerpc): Init
header_index_ to -1u for 64-bit, and make header here.
(Output_data_got_powerpc::set_final_data_size, reserve_ent): Don't
make 64-bit header here.
(Output_data_got_powerpc::g_o_t): Return toc pointer offset in
section for 64-bit.  Use throughout.
(Stub_table): Remove toc_base_off_ from Branch_stub_key, and
object param on add_long_branch_entry and find_long_branch_entry.
Adjust all uses.

Re: s12z/disassembler: call memory_error_func when appropriate

Adjust for commit ba7c18a48457.

* testsuite/gas/s12z/truncated.d: Update expected output.

Automatic date update in version.in

[gdb/exp] Improve <error reading variable> message

When printing a variable x in a subroutine foo:
...
subroutine foo (x)
  integer(4) :: x (*)
  x(3) = 1
end subroutine foo
...
where x is an array with unknown bounds, we get:
...
$ gdb -q -batch outputs/gdb.fortran/array-no-bounds/array-no-bounds \
  -ex "break foo" \
  -ex run \
  -ex "print x"
Breakpoint 1 at 0x4005cf: file array-no-bounds.f90, line 18.

Breakpoint 1, foo (x=...) at array-no-bounds.f90:18
18        x(3) = 1
$1 = <error reading variable>
...

Improve the error message by printing the details of the error, such that we
have instead:
...
$1 = <error reading variable: failed to get range bounds>
...

This is a change in gdb/valprint.c, and grepping through the sources reveals
that this is a common pattern.

Tested on x86_64-linux.

PPC fix for stfiwx instruction (and additional stores with primary opcode of 31)

[gdb] Fix address being recorded in rs6000-tdep.c, ppc_process_record_op31.

The GDB record function was recording the variable addr that was passed in
rather than the calculated effective address (ea) by the
ppc_process_record_op31 function.

gdb: improve error reporting from the disassembler

If the libopcodes disassembler returns a negative value then this
indicates that the disassembly failed for some reason.  In disas.c, in
the function gdb_disassembler::print_insn we can see how this is
handled; when we get a negative value back, we call the memory_error
function, which throws an exception.

The problem here is that the address used in the memory_error call is
gdb_disassembler::m_err_memaddr, which is set in
gdb_disassembler::dis_asm_memory_error, which is called from within
the libopcodes disassembler through the
disassembler_info::memory_error_func callback.

However, for this to work correctly, every time the libopcodes
disassembler returns a negative value, the libopcodes disassembler
must have first called the memory_error_func callback.

My first plan was to make m_err_memaddr a gdb::optional, and assert
that it always had a value prior to calling memory_error, however, a
quick look in opcodes/*-dis.c shows that there _are_ cases where a
negative value is returned without first calling the memory_error_func
callback, for example in arc-dis.c and cris-dis.c.

Now, I think that a good argument can be made that these disassemblers
must therefore be broken, except for the case where we can't read
memory, we should always be able to disassemble the memory contents to
_something_, even if it's just '.word 0x....'.  However, I certainly
don't plan to go and fix all of the disassemblers.

What I do propose to do then, is make m_err_memaddr a gdb::optional,
but now, instead of always calling memory_error, I add a new path
which just calls error complaining about an unknown error.  This new
path is only used if m_err_memaddr doesn't have a value (indicating
that the memory_error_func callback was not called).

To test this I just augmented one of the disassemblers to always
return -1, before this patch I see this:

  Dump of assembler code for function main:
     0x000101aa <+0>: Cannot access memory at address 0x0

And after this commit I now see:

  Dump of assembler code for function main:
     0x000101aa <+0>: unknown disassembler error (error = -1)

This doesn't really help much, but that's because there's no way to
report non memory errors out of the disasembler, because, it was not
expected that the disassembler would ever report non memory errors.

[gdb/testsuite] Fix gdb.fortran/call-no-debug.exp with native-gdbserver

When running test-case gdb.fortran/call-no-debug.exp with target board
native-gdbserver, I run into:
...
(gdb) PASS: gdb.fortran/call-no-debug.exp: print string_func_ (&'abcdefg', 3)
call (integer) string_func_ (&'abcdefg', 3)^M
$2 = 0^M
(gdb) FAIL: gdb.fortran/call-no-debug.exp: call (integer) string_func_ (&'abcdefg', 3)
...

The problem is that gdb_test is used to match inferior output.

Fix this by using gdb_test_stdio.

Tested on x86_64-linux.

[gdb/testsuite] Require use_gdb_stub == 0 where appropriate

When running with target board native-gdbserver, we run into a number of FAILs
due to use of the start command (and similar), which is not supported when
use_gdb_stub == 1.

Fix this by:
- requiring use_gdb_stub == 0 for the entire test-case, or
- guarding some tests in the test-case with use_gdb_stub == 0.

Tested on x86_64-linux.

[gdb/testsuite] Fix test name in gdb.python/python.exp

When running test-case gdb.python/python.exp, we have:
...
PASS: gdb.python/python.exp: starti via gdb.execute, not from tty
PASS: gdb.python/python.exp: starti via interactive input
...

The two tests are instances of the same test, with different values for
starti command argument from_tty, so it's strange that the test names are so
different.

This is due to using a gdb_test nested in a gdb_test_multiple, with the inner
one using a different test name than the outer one.  [ That could still make
sense if both produced passes, but that's not the case here. ]

Fix this by using $gdb_test_name, such that we have:
...
PASS: gdb.python/python.exp: starti via gdb.execute, not from tty
PASS: gdb.python/python.exp: starti via gdb.execute, from tty
...

Also make this more readable by using variables.

Tested on x86_64-linux.

[gdb/testsuite] Fix gdb.base/batch-exit-status.exp with native-gdbserver

When running test-case gdb.base/batch-exit-status.exp with target board
native-gdbserver, I run into (added missing double quotes for clarity):
...
builtin_spawn $build/gdb/testsuite/../../gdb/gdb -nw -nx \
  -data-directory $build/gdb/testsuite/../data-directory \
  -iex "set height 0" -iex "set width 0" \
  -ex "set auto-connect-native-target off" \
  -iex "set sysroot" -batch ""^M
: No such file or directory.^M
PASS: gdb.base/batch-exit-status.exp: 1x: \
  No such file or directory: [lindex $result 2] == 0
FAIL: gdb.base/batch-exit-status.exp: 1x: \
  No such file or directory: [lindex $result 3] == $expect_status
...

As in commit a02a90c114c "[gdb/testsuite] Set sysroot earlier in
local-board.exp", the problem is the use of -ex for
"set auto-connect-native-target off", which makes that the last command to
be executed, and consequently determines the return status.

Fix this by using -iex instead.

Tested on x86_64-linux.

[gdb/testsuite] Remove quit in gdb.arch/i386-mpx.exp

When running test-case gdb.arch/i386-mpx.exp with target board
native-gdbserver, I run into:
...
(gdb) PASS: gdb.arch/i386-mpx.exp: verify size for bnd0
Remote debugging from host ::1, port 42328^M
quit^M
A debugging session is active.^M
^M
        Inferior 1 [process 19679] will be killed.^M
^M
Quit anyway? (y or n) monitor exit^M
Please answer y or n.^M
A debugging session is active.^M
^M
        Inferior 1 [process 19679] will be killed.^M
^M
Quit anyway? (y or n) WARNING: Timed out waiting for EOF in server after monitor exit
...

The problem is that the test-case sends a quit at the end (without verifying
the result of this in any way):
...
send_gdb "quit\n"
...

Fix this by removing the quit.

Tested on x86_64-linux.

Automatic date update in version.in

Automatic date update in version.in

[ARM] Add support for M-profile MVE extension

This patch adds support for the M-profile MVE extension, which includes the
following:

- New M-profile XML feature m-profile-mve
- MVE vector predication status and control register (VPR)
- p0 pseudo register (contained in the VPR)
- q0 ~ q7 pseudo vector registers
- New feature bits
- Documentation update

Pseudo register p0 is the least significant bits of vpr and can be accessed
as $p0 or displayed through $vpr.  For more information about the register
layout, please refer to [1].

The q0 ~ q7 registers map back to the d0 ~ d15 registers, two d registers
per q register.

The register dump looks like this:

(gdb) info reg all
r0             0x0                 0
r1             0x0                 0
r2             0x0                 0
r3             0x0                 0
r4             0x0                 0
r5             0x0                 0
r6             0x0                 0
r7             0x0                 0
r8             0x0                 0
r9             0x0                 0
r10            0x0                 0
r11            0x0                 0
r12            0x0                 0
sp             0x0                 0x0 <__Vectors>
lr             0xffffffff          -1
pc             0xd0c               0xd0c <Reset_Handler>
xpsr           0x1000000           16777216
d0             0                   (raw 0x0000000000000000)
d1             0                   (raw 0x0000000000000000)
d2             0                   (raw 0x0000000000000000)
d3             0                   (raw 0x0000000000000000)
d4             0                   (raw 0x0000000000000000)
d5             0                   (raw 0x0000000000000000)
d6             0                   (raw 0x0000000000000000)
d7             0                   (raw 0x0000000000000000)
d8             0                   (raw 0x0000000000000000)
d9             0                   (raw 0x0000000000000000)
d10            0                   (raw 0x0000000000000000)
d11            0                   (raw 0x0000000000000000)
d12            0                   (raw 0x0000000000000000)
d13            0                   (raw 0x0000000000000000)
d14            0                   (raw 0x0000000000000000)
d15            0                   (raw 0x0000000000000000)
fpscr          0x0                 0
vpr            0x0                 [ P0=0 MASK01=0 MASK23=0 ]
s0             0                   (raw 0x00000000)
s1             0                   (raw 0x00000000)
s2             0                   (raw 0x00000000)
s3             0                   (raw 0x00000000)
s4             0                   (raw 0x00000000)
s5             0                   (raw 0x00000000)
s6             0                   (raw 0x00000000)
s7             0                   (raw 0x00000000)
s8             0                   (raw 0x00000000)
s9             0                   (raw 0x00000000)
s10            0                   (raw 0x00000000)
s11            0                   (raw 0x00000000)
s12            0                   (raw 0x00000000)
s13            0                   (raw 0x00000000)
s14            0                   (raw 0x00000000)
s15            0                   (raw 0x00000000)
s16            0                   (raw 0x00000000)
s17            0                   (raw 0x00000000)
s18            0                   (raw 0x00000000)
s19            0                   (raw 0x00000000)
s20            0                   (raw 0x00000000)
s21            0                   (raw 0x00000000)
s22            0                   (raw 0x00000000)
s23            0                   (raw 0x00000000)
s24            0                   (raw 0x00000000)
s25            0                   (raw 0x00000000)
s26            0                   (raw 0x00000000)
s27            0                   (raw 0x00000000)
s28            0                   (raw 0x00000000)
s29            0                   (raw 0x00000000)
s30            0                   (raw 0x00000000)
s31            0                   (raw 0x00000000)
q0             {u8 = {0x0 <repeats 16 times>}, u16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0, 0x0, 0x0}, u64 = {0x0, 0x0}, f32 = {0x0, 0x0, 0x0, 0x0}, f64 = {0x0, 0x0}}
q1             {u8 = {0x0 <repeats 16 times>}, u16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0, 0x0, 0x0}, u64 = {0x0, 0x0}, f32 = {0x0, 0x0, 0x0, 0x0}, f64 = {0x0, 0x0}}
q2             {u8 = {0x0 <repeats 16 times>}, u16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0, 0x0, 0x0}, u64 = {0x0, 0x0}, f32 = {0x0, 0x0, 0x0, 0x0}, f64 = {0x0, 0x0}}
q3             {u8 = {0x0 <repeats 16 times>}, u16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0, 0x0, 0x0}, u64 = {0x0, 0x0}, f32 = {0x0, 0x0, 0x0, 0x0}, f64 = {0x0, 0x0}}
q4             {u8 = {0x0 <repeats 16 times>}, u16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0, 0x0, 0x0}, u64 = {0x0, 0x0}, f32 = {0x0, 0x0, 0x0, 0x0}, f64 = {0x0, 0x0}}
q5             {u8 = {0x0 <repeats 16 times>}, u16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0, 0x0, 0x0}, u64 = {0x0, 0x0}, f32 = {0x0, 0x0, 0x0, 0x0}, f64 = {0x0, 0x0}}
q6             {u8 = {0x0 <repeats 16 times>}, u16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0, 0x0, 0x0}, u64 = {0x0, 0x0}, f32 = {0x0, 0x0, 0x0, 0x0}, f64 = {0x0, 0x0}}
q7             {u8 = {0x0 <repeats 16 times>}, u16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0, 0x0, 0x0}, u64 = {0x0, 0x0}, f32 = {0x0, 0x0, 0x0, 0x0}, f64 = {0x0, 0x0}}
p0             0x0                 0

Built and regtested with a simulator.

[1] https://developer.arm.com/documentation/ddi0553/bn

Co-Authored-By: Luis Machado <luis.machado@linaro.org>

[ARM] Refactor pseudo register numbering

The pseudo register handling for ARM uses some hardcoded constants to
determine types and names.  In preparation to the upcoming MVE support
patch (that will add another pseudo register), this patch refactors and
reorganizes things in order to simplify handling of future pseudo registers.

We keep track of the first pseudo register number in a group and the number of
pseudo registers in that group.

Right now we only have the S and Q pseudo registers.

[ARM] Small refactoring of arm gdbarch initialization

This is in preparation to MVE support, where we will define another
pseudo register. We need to define the pseudo register numbers *after*
accounting for all the registers in the XML description, so move
the call to tdesc_use_registers up.

If we don't do it, GDB's register count won't consider registers contained
in the XML but ignored by GDB, throwing the register numbering off.

[ARM] Refactor some constants

In preparation for the MVE extension patch, this one refactors some of
the register-related constants we have for ARM.

Basically I'm separating counting constants from numbering constants.

For example, ARM_A1_REGNUM is a numbering constant, whereas ARM_NUM_ARG_REGS
is a counting constant.

[gdb/testsuite] Fix FAIL in gdb.mi/mi-var-child-f.exp

When running test-case gdb.mi/mi-var-child-f.exp on openSUSE Tumbleweed
(with glibc 2.34) I run into:
...
(gdb) ^M
PASS: gdb.mi/mi-var-child-f.exp: mi runto prog_array
Expecting: ^(-var-create array \* array[^M
]+)?(\^done,name="array",numchild="[0-9]+",value=".*",type=.*,has_more="0"[^M
]+[(]gdb[)] ^M
[ ]*)
-var-create array * array^M
&"Attempt to use a type name as an expression.\n"^M
^error,msg="-var-create: unable to create variable object"^M
(gdb) ^M
FAIL: gdb.mi/mi-var-child-f.exp: create local variable array (unexpected output)
...

The problem is that the name array is used both:
- as the name for a local variable
- as the name of a type in glibc, in file malloc/dynarray-skeleton.c, as included
  by nss/nss_files/files-hosts.c.

Fix this by ignoring the shared lib symbols.

Likewise in a couple of other fortran tests.

Tested on x86_64-linux.

z80/disassembler: call memory_error_func when appropriate

If a call to the read_memory_func fails then we should call the
memory_error_func to notify the user of the disassembler of the
address that was a problem.

Without this GDB will report all memory errors as being at address
0x0.

opcodes/ChangeLog:

* z80-dis.c (fetch_data): Call memory_error_func if the
read_memory_func call fails.

s12z/disassembler: call memory_error_func when appropriate

If a call to the read_memory_func fails then we should call the
memory_error_func to notify the user of the disassembler of the
address that was a problem.

Without this GDB will report all memory errors as being at address
0x0.

opcodes/ChangeLog:

* s12z-disc.c (abstract_read_memory): Call memory_error_func if
the read_memory_func call fails.

[gdb/testsuite] Fix double debug info in gdb.dwarf2/dw2-ref-missing-frame.exp

A mistake slipped in in commit a5ea23036d8 "[gdb/testsuite] Use function_range
in gdb.dwarf2/dw2-ref-missing-frame.exp".

Before the commit the main file was compiled with debug info, and the two
others not:
...
if {[prepare_for_testing_full "failed to prepare" \
        [list $testfile {} $srcfile {} $srcfuncfile {} \
             $srcmainfile debug]]} {
...

After the commit, all were compiled with debug info, and consequently, there
are two versions of debug info for $srcfuncfile.  This shows up as a FAIL when
running the test-case with target boards readnow and cc-with-debug-names.

Fix this by using prepare_for_testing_full, as before.

Tested on x86_64-linux.

Fixes: a5ea23036d8 ("[gdb/testsuite] Use function_range in
       gdb.dwarf2/dw2-ref-missing-frame.exp")

[gdb/testsuite] Use require for ensure_gdb_index

Replace:
...
if { [ensure_gdb_index $binfile] == -1 } {
    return -1
}
...
with:
...
require {ensure_gdb_index $binfile} != -1
...
and consequently, add a missing UNTESTED message.

Tested on x86_64-linux, both with native and target board readnow.

[gdb/testsuite] Handle readnow in ensure_gdb_index

When running test-case gdb.base/with-mf.exp with target board readnow, I run
into:
...
FAIL: gdb.base/with-mf.exp: check if index present
...
This is since commit 6010fb0c49e "[gdb/testsuite] Fix full buffer in
gdb.rust/dwindex.exp".

Before that commit, the proc ensure_gdb_index would treat the line:
...
.gdb_index: faked for "readnow"^M
...
as proof that an index is already present (which is incorrect).

Now, instead it generates aforementioned FAIL and continues to generate an
index.

Fix this by explicitly handling the readnow case in proc ensure_gdb_index,
such that we bail out instead.

Tested on x86_64-linux.

[gdb/testsuite] Fix gdb.dwarf2/gdb-add-index-symlink.exp

The test-case gdb.dwarf2/gdb-add-index-symlink.exp interpretes a failure to
add an index as a failure to add an index for a symlink:
...
if { [ensure_gdb_index $symlink] == -1 } {
    fail "Unable to call gdb-add-index with a symlink to a symfile"
    return -1
}
...

However, it's possible that the gdb-add-index also fails with a regular
file.  Add a check for that situation.

Tested on x86_64-linux.

[gdb/testsuite] Add proc require in lib/gdb.exp

Add a new proc require in lib/gdb.exp, and use it to shorten:
...
if { [gdb_skip_xml_test] } {
    # Valgrind gdbserver requires gdb with xml support.
    untested "missing xml support"
    return 0
}
...
into:
...
require gdb_skip_xml_test 0
...

Tested on x86_64-linux, both with and without a trigger patch that forces
gdb_skip_xml_test to return 1.

bfd: Remove use of void pointer arithmetic

This is not valid in ISO C. Instead, use a pointer to bfd_byte.

* peicode.h (pe_bfd_object_p): Remove use of void pointer
arithmetic.

Automatic date update in version.in

Automatic date update in version.in

[gdb] Make execute_command_to_string return string on throw

The pattern for using execute_command_to_string is:
...
  std::string output;
  output = execute_fn_to_string (fn, term_out);
...

This results in a problem when using it in a try/catch:
...
  try
    {
      output = execute_fn_to_string (fn, term_out)
    }
  catch (const gdb_exception &e)
    {
      /* Use output.  */
    }
...

If an expection was thrown during execute_fn_to_string, then the output
remains unassigned, while it could be worthwhile to known what output was
generated by gdb before the expection was thrown.

Fix this by returning the string using a parameter instead:
...
  execute_fn_to_string (output, fn, term_out)
...

Also add a variant without string parameter, to support places where the
function is used while ignoring the result:
...
  execute_fn_to_string (fn, term_out)
...

Tested on x86_64-linux.

[gdb/testsuite] Add check-readmore

Consider the gdb output:
...
27        return SYSCALL_CANCEL (nanosleep, requested_time, remaining);^M
(gdb) ^M
Thread 2 "run-attach-whil" stopped.^M
...

When trying to match the gdb prompt using gdb_test which uses '$gdb_prompt $',
it may pass or fail.

This sort of thing needs to be fixed (see commit b0e2f96b56b), but there's
currently no way to reliably find this type of FAILs.

We have check-read1, but that one actually make the test pass reliably.

We need something like the opposite of check-read1: something that makes
expect read a bit slower, or more exhaustively.

Add a new test target check-readmore that implements this.

There are two methods of implementing this in read1.c:
- the first method waits a bit before doing a read
- the second method does a read and then decides whether to
  return or to wait a bit and do another read, and so on.

The second method is potentially faster, has less risc of timeout and could
potentially detect more problems.  The first method has a simpler
implementation.

The second method is enabled by default.  The default waiting period is 10
miliseconds.

The first method can be enabled using:
...
$ export READMORE_METHOD=1
...
and the waiting period can be specified in miliseconds using:
...
$ export READMORE_SLEEP=9
...

Also a log file can be specified using:
...
$ export READMORE_LOG=$(pwd -P)/LOG
...

Tested on x86_64-linux.

Testing with check-readmore showed these regressions:
...
FAIL: gdb.base/bp-cmds-continue-ctrl-c.exp: run: stop with control-c (continue)
FAIL: gdb.base/bp-cmds-continue-ctrl-c.exp: attach: stop with control-c (continue)
...

I have not been able to find a problem in the test-case, and I think it's the
nature of both the test-case and readmore that makes it run longer.  Make
these pass by increasing the alarm timeout from 60 to 120 seconds.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27957

[gdb/testsuite] Fix fortran module tests with stressed cpu

When running these test-cases:
- gdb.fortran/info-modules.exp
- gdb.fortran/module.exp
- gdb.mi/mi-fortran-modules.exp
in conjunction with:
...
$ stress -c $(($(cat /proc/cpuinfo | grep -c "^processor") + 1))
...
I run into timeouts.

Fix this by using:
- "set auto-solib-add off" to avoid symbols of shared libs
  (which doesn't work for libc, now that libpthread_name_p has been
  updated to  match libc)
- "nosharedlibrary" to avoid symbols of libc

Tested on x86_64-linux.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28133

PR28415, invalid read in xtensa_read_table_entries

PR 28415
PR 28416
* elf32-xtensa.c (xtensa_read_table_entries): Handle error
return from retrieve_contents.

Automatic date update in version.in

[gdb/testsuite] Fix gdb.base/info-types-c++.exp with stressed cpu

When running test-case gdb.base/info-types-c++.exp in conjunction with:
...
$ stress -c $(($(cat /proc/cpuinfo | grep -c "^processor") + 1))
...
we get:
...
FAIL: gdb.base/info-types-c++.exp: info types (timeout)
...

Fix this by setting auto-solib-add to off.

Tested on x86_64-linux.

[gdb/testsuite] Fix gdb.base/info_sources_2.exp with check-read1

When running test-case gdb.base/info_sources_2.exp with check-read1, I run
into:
...
FAIL: gdb.base/info_sources_2.exp: args: : info sources  (timeout)
...

Fix this by consuming a "$src1, $src2, ..., $srcn: line bit by bit rather than
as one whole line.

Also add the missing handling of "Objfile has no debug information".

Tested on x86_64-linux.

[gdb/testsuite] Fix gdb.mi/gdb2549.exp with check-read1

When running test-case gdb.mi/gdb2549.exp with check-read1, I run into:
...
FAIL: gdb.mi/gdb2549.exp: register values x (timeout)
...

Fix this by applying the same fix as for "register values t" in commit
478e490a4df "[gdb/testsuite] Fix gdb.mi/gdb2549.exp with check-read1".

Tested on x86_64-linux.

[gdb/testsuite] Fix gdb.base/bt-on-error-and-warning.exp with check-read1

When running test-case gdb.base/bt-on-error-and-warning.exp with check-read1,
I run into:
...
(gdb) maint internal-error foobar^M
src/gdb/maint.c:82: internal-error: foobar^M
A problem internal to GDB has been detectedFAIL: \
  gdb.base/bt-on-error-and-warning.exp: problem=internal-error, mode=on: \
  scan for backtrace (GDB internal error)
Resyncing due to internal error.
,^M
...

The corresponding gdb_test_multiple in the test-case contains:
...
           -early -re "^A problem internal to GDB has been detected,\r\n" {
               incr header_lines
               exp_continue
           }
...
but instead this one triggers in gdb_test_multiple:
...
        -re ".*A problem internal to GDB has been detected" {
            fail "$message (GDB internal error)"
            gdb_internal_error_resync
            set result -1
        }
...

Fix this by likewise shortening the regexp to before the comma.

Tested on x86_64-linux.

[gdb/testsuite] Add nopie in two test-cases

When running test-case gdb.dwarf2/dw2-restrict.exp on openSUSE Leap 15.2 with
gcc-PIE installed (switching compiler default to -fPIE/-pie), I get:
...
gdb compile failed, ld: outputs/gdb.dwarf2/dw2-restrict/dw2-restrict0.o: \
  warning: relocation in read-only section `.text'
ld: warning: creating DT_TEXTREL in a PIE
UNTESTED: gdb.dwarf2/dw2-restrict.exp: failed to prepare
...

This is due to using a hardcoded .S file that was generated with -fno-PIE.

Fix this by adding the missing nopie.

Likewise in gdb.arch/amd64-tailcall-noret.exp.

Tested on x86_64-linux.

Automatic date update in version.in

[gdb/testsuite] Fix gdb.threads/check-libthread-db.exp with glibc 2.34

When running test-case gdb.threads/check-libthread-db.exp on openSUSE
Tumbleweed (with glibc 2.34) I get:
...
(gdb) continue^M
Continuing.^M
[Thread debugging using libthread_db enabled]^M
Using host libthread_db library "/lib64/libthread_db.so.1".^M
Stopped due to shared library event:^M
  Inferior loaded /lib64/libm.so.6^M
    /lib64/libc.so.6^M
(gdb) FAIL: gdb.threads/check-libthread-db.exp: user-initiated check: continue
...

The check expect the inferior to load libpthread, but since glibc 2.34
libpthread has been integrated into glibc, and consequently it's no longer
a dependency:
...
$ ldd outputs/gdb.threads/check-libthread-db/check-libthread-db
        linux-vdso.so.1 (0x00007ffe4cae4000)
        libm.so.6 => /lib64/libm.so.6 (0x00007f167c77c000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f167c572000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f167c86e000)
...

Fix this by updating the regexp to expect libpthread or libc.

Tested on x86_64-linux.

[gdb/testsuite] Fix gdb.guile/scm-type.exp with gcc 4.8

With gcc 7.5.0, I get:
...
(gdb) guile (print (type-range (field-type (type-field (value-type \
  (value-dereference f)) "items"))))^M
= (0 0)^M
(gdb) PASS: gdb.guile/scm-type.exp: lang_cpp: test_range: \
  on flexible array member: $cmd
...
but with gcc 4.8.5, I get instead:
...
(gdb) guile (print (type-range (field-type (type-field (value-type \
  (value-dereference f)) "items"))))^M
= (0 -1)^M
(gdb) FAIL: gdb.guile/scm-type.exp: lang_cpp: test_range: \
  on flexible array member: $cmd
...

There's a difference in debug info.  With gcc 4.8.5, we have:
...
 <2><224>: Abbrev Number: 15 (DW_TAG_member)
    <225>   DW_AT_name        : items
    <22b>   DW_AT_type        : <0x231>
 <1><231>: Abbrev Number: 4 (DW_TAG_array_type)
    <232>   DW_AT_type        : <0x105>
 <2><23a>: Abbrev Number: 16 (DW_TAG_subrange_type)
    <23b>   DW_AT_type        : <0x11a>
    <23f>   DW_AT_upper_bound : 0xffffffffffffffff
...
and with gcc 7.5.0, we have instead:
...
 <2><89f>: Abbrev Number: 12 (DW_TAG_member)
    <8a0>   DW_AT_name        : items
    <8a6>   DW_AT_type        : <0x8ac>
 <1><8ac>: Abbrev Number: 17 (DW_TAG_array_type)
    <8ad>   DW_AT_type        : <0x29d>
 <2><8b5>: Abbrev Number: 41 (DW_TAG_subrange_type)
 <2><8b6>: Abbrev Number: 0
...

As mentioned in commit 858c8f2c1b9 "gdb/testsuite: adjust
gdb.python/flexible-array-member.exp expected pattern":
...
Ideally, GDB would present a consistent and documented value for an
array member declared with size 0, regardless of how the debug info
looks like.
...

As in gdb.python/flexible-array-member.exp, change the test to accept the two
values.

Tested on x86_64-linux.

gdb: add accessors for field (and call site) location

Add accessors for the various location values in struct field.  This
lets us assert that when we get a location value of a certain kind (say,
bitpos), the field's location indeed contains a value of that kind.

Remove the SET_FIELD_* macros, instead use the new setters directly.
Update the FIELD_* macros used to access field locations to go through
the getters.  They will be removed in a subsequent patch.

There are places where the FIELD_* macros are used on call_site_target
structures, because it contains members of the same name (loc_kind and
loc).  For now, I have replicated the getters/setters in
call_site_target.  But we could perhaps eventually factor them in a
"location" structure that can be used at both places.

Note that the field structure, being zero-initialized, defaults to a
bitpos location with value 0.  While writing this patch, I tried to make
it default to an "unset" location, to catch places where we would miss
setting a field's location.  However, I found that some places relied on
the default being "bitpos 0", so I left it as-is.  This change could
always be done as follow-up work, making these places explicitly set the
"bitpos 0" location.

I found two issues to fix:

 - I got some failures in the gdb.base/infcall-nested-structs-c++.exp
   test.  They were caused by two functions in amd64-tdep.c using
   TYPE_FIELD_BITPOS before checking if the location is of the bitpos
   kind, which they do indirectly through `field_is_static`.  Simply
   move getting the bitpos below the field_is_static call.

 - I got a failure in gdb.xml/tdesc-regs.exp.  It turns out that in
   make_gdb_type_enum, we set enum field values using SET_FIELD_BITPOS,
   and later access them through FIELD_ENUMVAL.  Fix that by using
   set_loc_enumval to set the value.

Change-Id: I53d3734916c46457576ba11dd77df4049d2fc1e8

RISC-V: Support aliases for Zbs instructions

Add aliases for the non-immediate mnemonics of b{set,clr,inv,ext} to
yencode the respective immediate insn b{set,clr,inv,ext}i when the
second source operand is an immediate.

2021-01-11  Philipp Tomsich  <philipp.tomsich@vrull.eu>

    gas/
* testsuite/gas/riscv/b-ext.d: Add tests.
* testsuite/gas/riscv/b-ext.s: Likewise.
* testsuite/gas/riscv/b-ext-64.d: Likewise.
* testsuite/gas/riscv/b-ext-64.s: Likewise.
    opcodes/
        * riscv-opc.c (riscv_opcodes): Add aliases for Zbs.

Suggested-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Philipp Tomsich <philipp.tomsich@vrull.eu>

RISC-V: Add support for Zbs instructions

This change adds the Zbs instructions from the Zbs 1.0.0 specification.
See
  https://github.com/riscv/riscv-bitmanip/releases/tag/1.0.0
for the frozen specification.

2021-01-09  Philipp Tomsich  <philipp.tomsich@vrull.eu>

    bfd/
* elfxx-riscv.c (riscv_supported_std_z_ext): Added zbs.
    gas/
* config/tc-riscv.c (riscv_multi_subset_supports): Handle INSN_CLASS_ZBS.
* testsuite/gas/riscv/b-ext.d: Test Zbs instructions.
* testsuite/gas/riscv/b-ext.s: Likewise.
* testsuite/gas/riscv/b-ext-64.d: Likewise.
* testsuite/gas/riscv/b-ext-64.s: Likewise.
    include/
* opcode/riscv-opc.h: Added MASK/MATCH/DECLARE_INSN for Zbs.
* opcode/riscv.h (riscv_insn_class): Added INSN_CLASS_ZBS.
    opcodes/
* riscv-opc.c (riscv_supported_std_z_ext): Add zbs.

Signed-off-by: Philipp Tomsich <philipp.tomsich@vrull.eu>

RISC-V: Update extension version for Zb[abc] to 1.0.0

2021-10-06  Philipp Tomsich  <philipp.tomsich@vrull.eu>

    bfd/
* elfxx-riscv.c (riscv_supported_std_z_ext): Update the version
number for zba, zbb and zbc to 1.0.0

Signed-off-by: Philipp Tomsich <philipp.tomsich@vrull.eu>
Version-changes: 3
- Updated version numbers for zba, zbb and zbc to 1.0.0

RISC-V: Split Zb[abc] into commented sections

The Zb[abc] opcodes are bundled just below the Privileged opcodes in
riscv_opcodes, possibly giving the appearance that they are part of
the Privileged spec for an uninitiated reader.  This separates them
out and adds comments above each section to clearly identify them as
Zba, Zbb or Zbc opcodes.

2021-10-04  Philipp Tomsich  <philipp.tomsich@vrull.eu>

    opcodes/
* riscv-opc.c: Split of Zb[abc] instructions and add comments.

Signed-off-by: Philipp Tomsich <philipp.tomsich@vrull.eu>

PR28423, use-after-free in objdump

XCOFF archives use a bi-directional linked list for file members.  So
one member points to both the previous member and the next member.
Members may not be sequentially ordered in the file.  This of course
is over-engineered nonsense and an attractive target for fuzzers.
(There is even a free list of members!)  The testcase in PR28423 is an
XCOFF archive with one member pointing to itself, which results in
lots of bad behaviour.  For example, "ar t" never terminates.

The use-after-free with "objdump -r" happens like this:  The first
archive element is opened, its symbols are read and "canonicalized"
for objdump, then relocations are read and printed.  Those relocations
use the canonicalized symbols, and also happen to be cached by the
coff bfd backend support.  objdump frees the symbols.  The next
archive element is then opened.  This must be done before the first
element is closed, because finding the next element uses data held in
the currect element.  Unfortunately the next element happens to be the
original, so we aren't opening, we're reopening a bfd which has cached
data.  When the relocations are printed they use the cached copy
containing references to the freed canonical symbols.

This patch adds a little sanity checking to the XCOFF "open next
archive file" support, so that it rejects archive members pointing at
themselves.  That is sufficient to cure this problem.  Anything more
is overkill.  If someone deliberately fuzzes an XCOFF archive with an
element loop then reports an "ar" bug when it runs forever, they will
find their bug report closed WONTFIX.

PR 28423
* coff-rs6000.c (_bfd_xcoff_read_ar_hdr): Save size occupied
by member name in areltdata.extra_size.
(_bfd_xcoff_openr_next_archived_file): Sanity check nextoff.
* coff64-rs6000.c (xcoff64_openr_next_archived_file): Call
_bfd_xcoff_openr_next_archived_file.

PR28422, build_id use-after-free

This fixes a bug in commit 5d9bbb73c1df.  All fields preserved from a
bfd in struct bfd_preserve need to be cleared in bfd_reinit.

PR 28422
* format.c (bfd_reinit): Clear build_id.

Change ridiculous section size error

Rather than reporting "memory exhausted", report "file truncated".
You can hit this error on small fuzzed object files, or on files that
are actually truncated.  In either case sizes can be such that an out
of memory error is a little confusing.

* compress.c (bfd_get_full_section_contents): Set
bfd_error_file_truncated rather than bfd_error_no_memory when
section size exceeds file size.

[gdb/testsuite] Fix FAIL in gdb.base/annota1.exp

On openSUSE tumbleweed I run into:
...
FAIL: gdb.base/annota1.exp: run until main breakpoint (timeout)
...
due to a message related to libthread_db:
...
^Z^Zstarting^M
[Thread debugging using libthread_db enabled]^M
Using host libthread_db library "/lib64/libthread_db.so.1".^M
^M
^Z^Zframes-invalid^M
...
which is not matched by the regexp.

Fix this by updating the regexp.

Tested on x86_64-linux.

[gdb/testsuite] Refactor regexp in gdb.base/annota1.exp

Refactor regexp in gdb.base/annota1.exp to reduce indentation and repetition.

Tested on x86_64-linux.

Automatic date update in version.in

gdb/doc: improve 'show print elements' description

The documentation for 'show print elements' contains the line:

  If the number is 0, then the printing is unlimited.

However, this line is now out of date as can be seen by this GDB
session:

  (gdb) set print elements 0
  (gdb) show print elements
  Limit on string chars or array elements to print is unlimited.

The value 0 does indeed mean unlimited, and this is described in the
'set print elements' section, however, for 'show print elements' the
user will never see the value 0, so lets just remove that bit from the
docs.

[gdb/testsuite] Fix FAIL in gdb.tui/corefile-run.exp

When running test-case gdb.tui/corefile-run.exp on openSUSE Tumbleweed,
I run into:
...
PASS: gdb.tui/corefile-run.exp: load corefile
FAIL: gdb.tui/corefile-run.exp: run until the end
...

What's going on is easier to see when also doing dump_screen if
check_contents passes, and inspecting state at the preceding PASS:
...
 +-------------------------------------------------------------------------+
 exec No process In:                                           L??   PC: ??
 [New LWP 16629]
 [Thread debugging using libthread_db enabled]
 Using host libthread_db library "/lib64/libthread_db.so.1".
 Core was generated by `/data/gdb_versions/devel/build/gdb/testsuite/output
 s/gdb.tui/corefile-run/corefi'.
 Program terminated with signal SIGTRAP, Trace/breakpoint trap.
 #0  main ()
 --Type <RET> for more, q to quit, c to continue without paging--
...

The problem is that we're getting a pagination prompt, and the subsequent run
command is interpreted as an answer to that prompt.

Fix this by:
- detecting the gdb prompt in response to "load corefile", such that
  we detect the failure earlier, and
- doing a "set pagination off" in Term::clean_restart.

Tested on x86_64-linux.

PR28420, ecoff fuzzing failures

PR 28420
* coff-mips.c (mips_adjust_reloc_in): Replace abort with error
message and return.
* ecoff.c (ecoff_slurp_reloc_table): Remove assertion and aborts,
instead handle errors gracefully.

PR28402, fail to allocate line number array

This fixes a situation where the COFF code allocated memory for
internal representaion arrays before reading the external file data.
That meant the allocation didn't have any sanity check against file
size.

PR 28402
* coffcode.h (buy_and_read): Malloc rather than alloc memory.
(coff_slurp_line_table): Read native line number info before
allocating memory for internal line number array.  Adjust error
paths to suit.  Remove now unnecessary line number count check.
(coff_slurp_reloc_table): Adjust to suit buy_and_read change.

PR28403, null pointer dereference in disassemble_bytes

Indexing of symbol and howto arrays wasn't checked in aout targets.

PR 28403
* aout-ns32k.c (MY (reloc_howto)): Sanity check howto_table index.
Make r_index unsigned.
(MY_swap_std_reloc_in): Make r_index unsigned.
* aoutx.h (MOVE_ADDRESS): Sanity check symbol r_index.
(aout_link_input_section_std): Make r_index unsigned.
(aout_link_input_section_ext): Likewise.
* i386lynx.c (MOVE_ADDRESS): Sanity check symbol r_index.
(swap_ext_reloc_in, swap_std_reloc_in): Make r_index unsigned.
* pdp11.c (MOVE_ADDRESS): Sanity check symbol r_index.

PR28401, invalid section name lookup

The PR28401 testcase has a section named "", ie. an empty string.
This results in some silly behaviour in load_debug_section, and
dump_dwarf_section.  Fix that.  Note that this patch doesn't correct
the main complaint in PR28401, "failed to allocate", since malloc
failures on sections having huge bogus sizes are to be expected.  We
can't safely catch all such cases by comparing with file size, for
example, where sections contain compressed data.

PR 28401
* objdump.c (load_debug_section): Don't attempt to retrieve
empty name sections.
(dump_dwarf_section): Likewise.

Automatic date update in version.in

[gdb/testsuite] Make tui testing less verbose

Currently, tui testing is rather verbose.  When using these RUNTESTFLAGS to
pick up all tui tests (17 in total):
...
rtf=$(echo $(cd src/gdb/testsuite/; find gdb.* -type f -name *.exp* \
  | xargs grep -l tuiterm_env) )
...
we have:
...
$ wc -l gdb.log
120592 gdb.log
...

Most of the output is related to controlling the tui screen, but that does
not give a top-level sense of how the test-case progresses.

Put differently: a lot of bandwith is used to describe how we arrive at a
certain tui screen state.  But we don't actually always show the state we
arrive at, unless there's a FAIL.

And if there's say, a PASS that should actually be FAILing, it's hard to
detect.

Fix this by:
- dropping the -log on the call to verbose in _log.  We still can get the
  same info back using runtest -v.
- dumping the screen or box that we're checking, also when the test passes.

Brings down verbosity to something more reasonable:
...
$ wc -l gdb.log
3221 gdb.log
...

Tested on x86_64-linux.

[gdb/testsuite] Add Term::dump_box in lib/tuiterm.exp

Factor out new proc Term::get_region and use it to implement a
new proc Term::dump_box, similar to Term::dump_screen.

Tested on x86_64-linux.