Fix no-Python build

A build without Python will currently fail, because
selftests::test_python uses gdb_python_initialized, which is only
conditionally defined.

This patch fixes the build by making test_python also be conditionally
defined.  I chose this approach because the selftest will fail if
Python is not enabled, so it didn't seem useful to leave it defined.

RISC-V: Update the assembler insn testcase.

Since the 0x57 is preserved for the vadd.vv instruction in the integration
branch, remove it to make sure the testcase can work.

gas/
* testsuite/gas/riscv/insn.d: Remove 0x57 since it is preserved
for vadd.vv instruction.
* testsuite/gas/riscv/insn.s: Likewise.

MIPS: don't use get_symbol_name() for section parsing.  With s_change_section() later calling obj_elf_section(), it seems better to pre-parse the section name by the same function that will be used there. This way no differences in what is accepted will result.

gas * config/tc-mips.c (s_change_section): Use obj_elf_section_name to
parse the section name.

ia64: don't use get_symbol_name() for section parsing.  With cross_section() later calling obj_elf_section(), it seems better to pre-parse the section name by the same function that will be used there. This way no differences in what is accepted will result.

gas * config/tc-ia64.c (cross_section): Use obj_elf_section_name to
parse the section name.

[gdb/testsuite] Fix gdb.gdb/selftest.exp

With a gdb build with CFLAGS "-O2 -g -flto=auto", I run into:
...
 #7  gdb_main (args=0x7fffffffd220) at src/gdb/main.c:1368^M
 #8  main (argc=<optimized out>, argv=<optimized out>) at src/gdb/gdb.c:32^M
 (gdb) FAIL: gdb.gdb/selftest.exp: backtrace through signal handler
...
which means that this regexp in proc test_with_self fails:
...
  -re "#0.*(read|poll).*in main \\(.*\\) at .*gdb\\.c.*$gdb_prompt $" {
...

The problem is that gdb_main has been inlined into main, and consequently the
backtrace uses:
...
 #x  <fn> ...
...
instead of
...
 #x  <address> in <fn> ...
...

Fix this by updating the regexp to not require "in" before " main".

Tested on x86_64-linux.

Re: Deprecate a.out support for NetBSD targets

* config.bfd: Correct m68-*-*bsd* obsolete target match.

[gdb/testsuite] Fix test name in gdb.base/batch-exit-status.exp

When running gdb.base/batch-exit-status.exp I noticed that the test name
contains a newline:
...
PASS: gdb.base/batch-exit-status.exp: : No such file or directory\.^M
: No such file or directory\.: [lindex $result 2] == 0
...

The mistake is that I passed an output regexp argument to a parameter
interpreted as testname prefix.  Fix this by passing a testname prefix
instead.

Add support for checking output, to be able to handle the output regexp
argument.

Tested on x86_64-linux.

Automatic date update in version.in

[gdb/testsuite] Set sysroot earlier in local-board.exp

When running test-case gdb.base/batch-exit-status.exp for native, it passes.
But with target board cc-with-debug-names, we 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 sysroot" -batch ""^M
: No such file or directory.^M
PASS: gdb.base/batch-exit-status.exp: \
  : No such file or directory\.: [lindex $result 2] == 0
FAIL: gdb.base/batch-exit-status.exp: \
  : No such file or directory\.: [lindex $result 3] == $expect_status
...

The difference between the passing and failing case is that with native we
have (leaving out set height/width for brevity):
...
$ gdb -batch ""; echo $?
: No such file or directory.
1
...
and with target board cc-with-debug-names:
...
$ gdb -ex "set sysroot" -batch ""; echo $?
: No such file or directory.
0
...

The difference is expected.  GDB returns the exit status of the last executed
command.  In the former case that's 'file ""', which fails.  In the latter case,
that's 'set sysroot', which succeeds.

Fix this by setting sysroot using -iex instead of -ex in local-board.exp, such
that we have the expected:
...
$ gdb -iex "set sysroot" -batch ""; echo $?
: No such file or directory.
1
...

Tested on x86_64-linux.

Automatic date update in version.in

sim: run: change help short option to -h

It's unclear why -H was picked over the more standard -h, but since
-h is still not used, just change -H to -h to match pretty much every
other tool in the sourceware tree.

Automatic date update in version.in

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

The test-case gdb.gdb/python-selftest.exp:
- patches the gdb_python_initialized variable in gdb to 0
- checks that the output of a python command is "Python not initialized"

Reimplement gdb.gdb/python-selftest.exp as unittest, using:
- execute_command_to_string to capture the output
- try/catch to catch the "Python not initialized" exception.

Tested on x86_64-linux.

[gdb/testsuite] Fix DUPLICATE in gdb.base/global-var-nested-by-dso.exp

Fix DUPLICATE in gdb.base/global-var-nested-by-dso.exp by naming commands more
uniquely.

[gdb/testsuite] Fix DUPLICATE in gdb.base/skip-solib.exp

Fix DUPLICATE in gdb.base/skip-solib.exp by using with_test_prefix.

Also fix indentation style and long lines, remove outdated question/answer
bits, and use multi_line.

[gdb/testsuite] Fix handling of nr_args < 3 in mi_gdb_test

The documentation of mi_gdb_test states that the command, pattern and message
arguments are mandatory:
...
 # mi_gdb_test COMMAND PATTERN MESSAGE [IPATTERN] -- send a command to gdb;
 #   test the result.
...

However, this is not checked, and when mi_gdb_test is called with less than 3
arguments, it passes or fails silently.

Fix this by using the following semantics:
- if there are 1 or 2 arguments, use the command as the message.
- if there is 1 argument, use ".*" as the pattern.
- if there are no or too much arguments, error out.

Fix a PATH issue in gdb.mi/mi-logging.exp, introduced by using the command as
message.  Fix a few other trivial-looking FAILs.

There are 11 less trivial-looking FAILs left in gdb.mi in test-cases:
- mi-nsmoribund.exp
- mi-breakpoint-changed.exp
- mi-break.exp.

Tested on x86_64-linux.

[gdb/testsuite] Add string_list_to_regexp

A regexp pattern with escapes like this is hard to read:
...
set re "~\"\[$\]$decimal = 1\\\\n\"\r\n\\^done"
...

We can make it more readable by spacing out parts (which allows us to also use
the curly braces where that's convenient):
...
set re [list "~" {"} {[$]} $decimal " = 1" "\\\\" "n" {"} "\r\n" "\\^" "done"]
set re [join $re ""]
...
or by using string_to_regexp:
...
set re [list \
            [string_to_regexp {~"$}] \
            $decimal \
            [string_to_regexp " = 1\\n\"\r\n^done"]]
set re [join $re ""]
...
Note: we have to avoid applying string_to_list to decimal, which is already a
regexp.

Add a proc string_list_to_regexp to make it easy to do both:
...
set re [list \
            [string_list_to_regexp ~ {"} $] \
            $decimal \
            [string_list_to_regexp " = 1" \\ n {"} \r\n ^ done]]
...

Also add a test-case gdb.testsuite/string_to_regexp.exp.

[gdb/testsuite] Handle unrecognized command line option in gdb_compile_test

When running the gdb testsuite with gnatmake-4.8, I get many fails of the
following form:
...
gcc: error: unrecognized command line option '-fgnat-encodings=all'^M
gnatmake: "gdb.ada/O2_float_param/foo.adb" compilation error^M
compiler exited with status 1
compilation failed: gcc ... gdb.ada/O2_float_param/foo.adb
gcc: error: unrecognized command line option '-fgnat-encodings=all'
gnatmake: "gdb.ada/O2_float_param/foo.adb" compilation error
FAIL: gdb.ada/O2_float_param.exp: scenario=all: compilation foo.adb
...

Fix this by marking the test unsupported instead, such that we have:
...
UNSUPPORTED: gdb.ada/O2_float_param.exp: scenario=all: compilation foo.adb \
  (unsupported option '-fgnat-encodings=all')
...

Tested on x86_64-linux.

PowerPC, sanity check r_offset in relocate_section

        * elf32-ppc.c (offset_in_range): New function.
(ppc_elf_vle_split16): Sanity check r_offset before accessing
section contents.  Return status.
        (ppc_elf_relocate_section): Sanity check r_offset before
        accessing section contents.  Don't segfault on NULL howto.

Re: gas: Use the directory name in .file 0

PR gas/28266
* testsuite/gas/elf/dwarf-5-file0-2.s: Use %object rather than
@object, .4byte instead of .long, and .asciz instead of .string.

etc: switch to automake

There's no content in here currently, so switching to automake is
pretty easy with a stub file.

etc: rename configure.in to configure.ac

The .in name has been deprecated for a long time in favor of .ac.

gas: Use the directory name in .file 0

DWARF5 allows .file 0 to take an optional directory name.  Set the entry
0 of the directory table to the directory name in .file 0.

PR gas/28266
* dwarf2dbg.c (get_directory_table_entry): Add an argument for
the directory name in .file 0 and use it, instead of PWD.
(allocate_filenum): Pass NULL to get_directory_table_entry.
(allocate_filename_to_slot): Pass the incoming dirname to
get_directory_table_entry.
* testsuite/gas/elf/dwarf-5-file0-2.d: New file.
* testsuite/gas/elf/dwarf-5-file0-2.s: Likewise.
* testsuite/gas/elf/elf.exp: Run dwarf-5-file0-2.

Automatic date update in version.in

gdb: Enable target rx-*-*linux.

I added rx-*-linux in binutils few yaers ago.
But missing this changes,

[gdb/testsuite] Fix gdb.base/coredump-filter-build-id.exp with older eu-unstrip

On openSUSE Leap 42.3 with eu-unstrip 0.158, we run into:
...
(gdb) PASS: gdb.base/coredump-filter-build-id.exp: save corefile
First line of eu-unstrip: \
  0x400000+0x202000 f4ae8502bd6a14770182382316bc595e9dc6f08b@0x400284 - - [exe]
FAIL: gdb.base/coredump-filter-build-id.exp: gcore dumped mapping with build-id
...

The test expects an actual file name instead of '[exe]', but that only got
introduced with eu-unstrip 0.161.  Before it printed '[exe]' or '[pie]'.

Fix this by updating the regexp.

Tested on x86_64-linux.

[gdb/testsuite] Fix various issues in gdb.mi/mi-sym-info.exp

I noticed this failure in gdb.mi/mi-sym-info.exp with gcc-4.8:
...
FAIL: gdb.mi/mi-sym-info.exp: -symbol-info-functions --max-results 1 \
  (unexpected output)
...
due to function f2 instead of f3 being listed.

AFAICT, this is caused by a difference in debug info:
...
$ readelf -wi outputs/gdb.mi/mi-sym-info/mi-sym-info1.o \
  | egrep "DW_AT_name.*: f[1-3]"
    <72>   DW_AT_name        : f1
    <a1>   DW_AT_name        : f2
    <d0>   DW_AT_name        : f3
...
vs:
...
$ readelf -wi outputs/gdb.mi/mi-sym-info/mi-sym-info1.o \
  | egrep "DW_AT_name.*: f[1-3]"
    <f4>   DW_AT_name        : f3
    <123>   DW_AT_name        : f2
    <152>   DW_AT_name        : f1
...
and the command documentation does not mention an imposed order, so fix this
by allowing f2 as well.

Doing this fix, it made sense to do a refactoring of adding f2_re and f3_re
variables, in order to write (?:$f2_re|$f3_re), and I applied the same pattern
overall.

Furthermore, I found a silent FAIL due to calling mi_gdb_proc with 2 args, fix
by updating the regexp.

Then I ran with clang and found another FAIL, fix by updating the regexp.

Tested on x86_64-linux with gcc-4.8.5, gcc-7.5.0, gcc-11.2.1, clang-7.0.1 and
clang-12.0.1.

[gdb/testsuite] Reimplement gdb.gdb/complaints.exp as unittest

When building gdb with "-Wall -O2 -g -flto=auto", I run into:
...
(gdb) call clear_complaints()^M
No symbol "clear_complaints" in current context.^M
(gdb) FAIL: gdb.gdb/complaints.exp: clear complaints
...

The problem is that lto has optimized away the clear_complaints function
and consequently the selftest doesn't work.

Fix this by reimplementing the selftest as a unit test.

Factor out two new functions:
- void
  execute_fn_to_ui_file (struct ui_file *file, std::function<void(void)> fn);
- std::string
  execute_fn_to_string (std::function<void(void)> fn, bool term_out);
and use the latter to capture the complaints output.

Tested on x86_64-linux.

gdb/python: remove all uses of Py_TPFLAGS_HAVE_ITER

Python 2 has a bit flag Py_TPFLAGS_HAVE_ITER which can be passed as
part of the tp_flags field when defining a new object type.  This flag
is not defined in Python 3 and so we define it to 0 in
python-internal.h (when IS_PY3K is defined).

The meaning of this flag is that the object has the fields tp_iter and
tp_iternext.  Note the use of "has" here, the flag says nothing about
the values in those fields, just that the type object has the fields.

In early versions of Python 2 these fields were no part of the
PyTypeObject struct, they were added in version 2.2 (see
https://docs.python.org/release/2.3/api/type-structs.html).  And so,
there could be a some code compiled out there which has a PyTypeObject
structure within it that doesn't even have the tp_iter and tp_iternext
fields, attempting to access these fields would be undefined
behaviour.

And so Python added the Py_TPFLAGS_HAVE_ITER flag.  If the flag is
present then Python is free to access the tp_iter and tp_iternext
fields.

If we consider GDB then we always assume that the tp_iter and
tp_iternext fields are part of PyTypeObject.  If someone was crazy
enough to try and compile GDB against Python 2.1 then we'd get lots of
build errors saying that we were passing too many fields when
initializing PyTypeObject structures.  And so, I claim, we can be sure
that GDB will always be compiled with a version of Python that has the
tp_iter and tp_iternext fields in PyTypeObject.

Next we can look at the Py_TPFLAGS_DEFAULT flag.  In Python 2, each
time additional fields are added to PyTypeObject a new Py_TPFLAGS_*
flag would be defined to indicate whether those flags are present or
not.  And, those new flags would be added to Py_TPFLAGS_DEFAULT.  And
so, in the latest version of Python 2 the Py_TPFLAGS_DEFAULT flag
includes Py_TPFLAGS_HAVE_ITER (see
https://docs.python.org/2.7/c-api/typeobj.html).

In GDB we pass Py_TPFLAGS_DEFAULT as part of the tp_flags for all
objects we define.

And so, in this commit, I propose to remove all uses of
Py_TPFLAGS_HAVE_ITER from GDB, it's simply not needed.

There should be no user visible changes after this commit.

sim: accept -EB/-EL short options

Many GNU tools accept -EB/-EL as short options for selecting big &
little endian modes.  While the sim has an -E option, it requires
spelling out "big" and "little".  Adding support for -EB & -EL is
thus quite trivial, so lets round it out to be less annoying.

sim: ppc: drop support for std-config.h overrides

Only the ppc arch supports this kind of source file override logic.
All the others expose knobs via configure flags, and for some of
these, the ppc code does as well.  For others, it doesn't make sense
to ever change them.  Since it's unlikely anyone is using this, drop
it all to simplify the code (and to get us a little closer to the
common sim code).

sim: ppc: enable use of gnulib

All other sim arches are using this now, so finish up the logic in
the ppc arch to enable gnulib usage here too.

sim: drop old O_NDELAY & FNBLOCK support

We use these older names inconsistently in the sim codebase, and time
has moved on long ago, so drop support for these non-standard names.
POSIX provides O_NONBLOCK for us, so use it everywhere.

sim: dv-sockser: enable for mingw targets too

We have enough functionality from gnulib now to build sockser on
all platforms.

Non-blocking I/O is supported when F_GETFL/F_SETFL are unavailable,
but we can address that in a follow up commit.  This mirrors what
is done in other places in the sim already.

sim: cgen: workaround Windows VOID define

The cgen framework provides a "VOID" type for code to use, but this
defines ends up conflicting with the standard Windows VOID define.
Since they actually define to the same thing ("void"), undef it here
to fix the Windows build.

We might want to reconsider the need for "VOID" in cgen, but that
will take larger discussion & coordination with the cgen project.

sim: dv-sockser: move sim-main.h include after system includes

The sim-main.h header is a bit of a dumping ground.  Every arch can
(and many do) define all sorts of weird & common names that end up
conflicting with system headers.  So including it before the system
headers sets us up for pain.  v850 is a good example of this -- when
building for mingw, we see weird failures:

$ i686-w64-mingw32-gcc ... -c -o dv-sockser.o ../../../../sim/v850/../common/dv-sockser.c
In file included from ../../../../sim/v850/sim-main.h:11,
                 from ../../../../sim/v850/../common/dv-sockser.c:24:
../../../../sim/v850/../common/sim-base.h:97:32: error: expected ')' before '->' token
  97 | # define STATE_CPU(sd, n) ((sd)->cpu[0])
     |                                ^~

While gcc is unhelpful at first, running it through the preprocessor
by hand shows more details:

$ i686-w64-mingw32-gcc ... -E -dD -o dv-sockser.i ../../../../sim/v850/../common/dv-sockser.c
$ i686-w64-mingw32-gcc -c dv-sockser.i
In file included from /usr/i686-w64-mingw32/usr/include/minwindef.h:163,
                 from /usr/i686-w64-mingw32/usr/include/windef.h:9,
                 from /usr/i686-w64-mingw32/usr/include/windows.h:69,
                 from /usr/i686-w64-mingw32/usr/include/winsock2.h:23,
                 from ../../gnulib/import/sys/socket.h:684,
                 from ../../gnulib/import/netinet/in.h:43,
                 from ../../../../sim/v850/../common/dv-sockser.c:39:
/usr/i686-w64-mingw32/usr/include/winnt.h:4803:25: error: expected ')' before '->' token
 4803 |       DWORD State;
      |                         ^
      |                         )

This is because v850 sets up this common name:

All of this needs cleaning up someday, but since the dv-sockser code
definitely should be fixed in this way, lets do that now and unblock
the v850 code.

sim: mips: delete unused PSIZE define

It's unclear what this define is for as it appears to be unused, and
has never been used in the history of the mips sim.  Delete it to tidy
up, and to fix build errors for Windows targets that have a standard
"PSIZE" struct in their system headers.  This doesn't show up yet as
most sim files don't include many system headers, but enabling sockser
code for mingw uncovers the conflict.

Unfortunately the error produced by gcc is inscrutable, but running
it through the preprocessor manually manages to provide a pointer to
the underlying issue.

$ i686-w64-mingw32-gcc ... -c -o dv-sockser.o ../../../../sim/mips/../common/dv-sockser.c
<command-line>: error: expected identifier or '(' before numeric constant
In file included from /usr/i686-w64-mingw32/usr/include/windows.h:71,
                 from /usr/i686-w64-mingw32/usr/include/winsock2.h:23,
                 from ../../gnulib/import/sys/socket.h:684,
                 from ../../gnulib/import/netinet/in.h:43,
                 from ../../../../sim/mips/../common/dv-sockser.c:39:
/usr/i686-w64-mingw32/usr/include/wingdi.h:2934:59: error: unknown type name 'LPSIZE'; did you mean 'LPSIZEL'?
 2934 |   WINGDIAPI WINBOOL WINAPI GetAspectRatioFilterEx(HDC hdc,LPSIZE lpsize);
      |                                                           ^~~~~~
      |                                                           LPSIZEL
...

$ i686-w64-mingw32-gcc ... -E -dD -o dv-sockser.i ../../../../sim/mips/../common/dv-sockser.c
$ i686-w64-mingw32-gcc -c dv-sockser.i
In file included from /usr/i686-w64-mingw32/usr/include/windows.h:69,
                 from /usr/i686-w64-mingw32/usr/include/winsock2.h:23,
                 from ../../gnulib/import/sys/socket.h:684,
                 from ../../gnulib/import/netinet/in.h:43,
                 from ../../../../sim/mips/../common/dv-sockser.c:39:
/usr/i686-w64-mingw32/usr/include/windef.h:104:9: error: expected identifier or '(' before numeric constant
  104 | } SIZE,*PSIZE,*LPSIZE;
      |         ^~

sim: ppc: switch to common warning flags

Now that the ppc code has been cleaned up enough to use the same set
of warning flags as the common code, delete the ppc-specific configure
logic so we can leverage what the common code already defined for us.

sim: ppc: enable -Wpointer-sign warnings

When compiling with --enable-werror and CFLAGS="-O0 -g -Wall", we run into:
...
src/sim/ppc/hw_memory.c: In function 'hw_memory_init_address':
src/sim/ppc/hw_memory.c:204:7: error: pointer targets in passing argument 4 \
  of 'device_find_integer_array_property' differ in signedness \
  [-Werror=pointer-sign]
       &new_chunk->size);
       ^
...

Fix these by adding an explicit pointer cast.  It's a bit ugly to use APIs
based on signed integers to read out unsigned values, but in practice, this
is par for the course in the ppc code.

We already use signed APIs and assign the result to unsigned values a lot:
see how device_find_integer_property returns a signed integer (cell), but
then assign it to unsigned types.  The array APIs are not used that often
which is why we don't see many warnings, and we disable warnings when we
assign signed integers to unsigned integers in general.

The dtc/libfdt project (which is the standard in other projects) processes
the fdt blob as a series of bytes without any type information.  Typing is
left to the caller.  They have core APIs that read/write bytes, and a few
helper functions to cast/convert those bytes to the right value (e.g. u32).
In this ppc sim code, the core APIs use signed integers, and the callers
convert to unsigned, usually implicitly.

We could add some core APIs to the ppc sim that deal with raw bytes and then
add some helpers to convert to the right type, but that seems like a lot of
lifting for what boils down to a cast, and is effectively equivalent to all
the implicit assignments we use elsewhere.  Long term, a lot of the ppc code
should either get converted to existing sim common code, or we should stand
up proper APIs in the common code first, or use standard libraries to do all
the processing (e.g. libfdt).  Either way, this device.c code would all get
deleted, and callers (like these hw_*.c files) would get converted.  Which
is also why we go with a cast rather new (but largely unused) APIs.

sim: ppc: enable -Wmissing-declarations & -Wmissing-prototypes

This aligns with common code which already uses this flag.  We have
to add another local prototype to fix the failure, and add another
local decl for the SIM_DESC type.  Unwinding these will require a
lot more work & conversions in the process, so going with the decl
for now unblocks the warning unification.

sim: microblaze: replace custom basic types with common ones

The basic "byte" type conflicts with Windows headers, and we already
have common types that provide the right sizes.  So replace these with
the common ones to avoid issues.

  CC     dv-sockser.o
In file included from /usr/i686-w64-mingw32/usr/include/wtypes.h:8,
                 from /usr/i686-w64-mingw32/usr/include/winscard.h:10,
                 from /usr/i686-w64-mingw32/usr/include/windows.h:97,
                 from /usr/i686-w64-mingw32/usr/include/winsock2.h:23,
                 from ../../gnulib/import/sys/socket.h:684,
                 from ../../gnulib/import/netinet/in.h:43,
                 from .../build/sim/../../../sim/microblaze/../common/dv-sockser.c:39:
/usr/i686-w64-mingw32/usr/include/rpcndr.h:63:25: error: conflicting types for 'byte'; have 'unsigned char'
   63 |   typedef unsigned char byte;
      |                         ^~~~
In file included from .../buildsim/../../../sim/microblaze/sim-main.h:21,
                 from .../buildsim/../../../sim/microblaze/../common/dv-sockser.c:24:
.../buildsim/../../../sim/microblaze/microblaze.h:94:25: note: previous declaration of 'byte' with type 'byte' {aka 'char'}
   94 | typedef char            byte;
      |                         ^~~~
make: *** [Makefile:513: dv-sockser.o] Error 1

RISC-V: Pretty print values formed with lui and addiw.

The disassembler has support to pretty print values created by an lui/addi
pair, but there is no support for addiw.  There is also no support for
c.addi and c.addiw.  This patch extends the pretty printing support to
handle these 3 instructions in addition to addi.  Existing testcases serve
as tests for the new feature.

opcodes/
* riscv-dis.c (maybe_print_address): New arg wide.  Sign extend when
wide is true.
(print_insn_args): Fix calls to maybe_print_address.  Add checks for
c.addi, c.addiw, and addiw, and call maybe_print_address for them.

gas/
* testsuite/gas/riscv/insn.d: Update for disassembler change.
* testsuite/gas/li32.d, testsuite/gas/li64.d: Likwise.
* testsuite/gas/lla64.d: Likewise.

sim: ppc: align format string settings with common code

This copies logic used in the common sim warning configure code to fix
build errors for mingw targets.  Turning format warnings on triggers
a failure in the debug.c file, so apply a minor fix at the same time.

sim: ppc: drop unnecessary config includes

This file is compiled for the --host & --build system which leads to
including the configure generated config.h in both environments.
This obviously doesn't work when the two targets don't look alike at
all and can cause build failures here (e.g. a mingw host & a linux
build).  Since we don't actually need any config settings in this
very simple file, drop the includes entirely.

Automatic date update in version.in

gnulib: import various network functions

Some sim ports use these to provide networking functionality via the
dv-sockser module or via direct emulation for a few ports.

Gdb seems to build just fine still too.

Fix unit test build on Windows

Like Tom de Vries' earlier patch to fix the no-CXX_STD_THREAD case in
maint.c, this patch fixes a similar problem in
parallel-for-selftests.c.  This fixes a build failure on Windows.

PowerPC64, sanity check r_offset in relocate_section

This hardens the powerpc64 linker code transformations.

* elf64-ppc.c (is_8byte_reloc, offset_in_range): New functions.
(ppc64_elf_relocate_section): Sanity check r_offset before
accessing section contents for various code transformations.

PowerPC64: Avoid useless work on R_PPC64_TPREL34

_bfd_elf_ppc_at_tprel_transform doesn't handle prefix instructions,
and I'm not inclined to implement code editing for them.

* elf64-ppc.c (ppc64_elf_relocate_section): Don't attempt tprel
transform for R_PPC64_TPREL34.

gdb: make thread_suspend_state::stop_pc optional

Currently the stop_pc field of thread_suspect_state is a CORE_ADDR and
when we want to indicate that there is no stop_pc available we set
this field back to a special value.

There are actually two special values used, in post_create_inferior
the stop_pc is set to 0.  This is a little unfortunate, there are
plenty of embedded targets where 0 is a valid pc value.  The more
common special value for stop_pc though, is set in
thread_info::set_executing, where the value (~(CORE_ADDR) 0) is used.

This commit changes things so that the stop_pc is instead a
gdb::optional.  We can now explicitly reset the field to an
uninitialised state, we also have asserts that we don't read the
stop_pc when its in an uninitialised state (both in
gdbsupport/gdb_optional.h, when compiling with _GLIBCXX_DEBUG
defined, and in thread_info::stop_pc).

One situation where a thread will not have a stop_pc value is when the
thread is stopped as a consequence of GDB being in all stop mode, and
some other thread stopped at an interesting event.  When GDB brings
all the other threads to a stop those other threads will not have a
stop_pc set (thus avoiding an unnecessary read of the pc register).

Previously, when GDB passed through handle_one (in infrun.c) the
threads executing flag was set to false and the stop_pc field was left
unchanged, i.e. it would (previous) have been left as ~0.

Now, handle_one leaves the stop_pc with no value.

This caused a problem when we later try to set these threads running
again, in proceed() we compare the current pc with the cached stop_pc.
If the thread was stopped via handle_one then the stop_pc would have
been left as ~0, and the compare (in proceed) would (likely) fail.
Now however, this compare tries to read the stop_pc when it has no
value and this would trigger an assert.

To resolve this I've added thread_info::stop_pc_p() which returns true
if the thread has a cached stop_pc.  We should only ever call
thread_info::stop_pc() if we know that there is a cached stop_pc,
however, this doesn't mean that every call to thread_info::stop_pc()
needs to be guarded with a call to thread_info::stop_pc_p(), in most
cases we know that the thread we are looking at stopped due to some
interesting event in that thread, and so, we know that the stop_pc is
valid.

After running the testsuite I've seen no other situations where
stop_pc is read uninitialised.

There should be no user visible changes after this commit.

[gdb/build] Fix build with undefined CXX_STD_THREAD

When building gdb on openSUSE Leap 42.3, we trigger the case that
CXX_STD_THREAD is undefined, and run into:
...
gdb/maint.c: In function 'void maintenance_show_worker_threads \
  (ui_file*, int, cmd_list_element*, const char*)':
gdb/maint.c:877:14: error: 'gdb::thread_pool' has not been declared
         gdb::thread_pool::g_thread_pool->thread_count ());
              ^
Makefile:1647: recipe for target 'maint.o' failed
make[1]: *** [maint.o] Error 1
...

Fix this by handling the undefined CXX_STD_THREAD case in
maintenance_show_worker_threads, such that we get:
...
$ gdb -q -batch -ex "maint show worker-thread"
The number of worker threads GDB can use is 0.
...

Tested on x86_64-linux.

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

sim: update configure target list

Fix sorting of the list, and update the globs to match the list used
in gdb's configure script.

gdb: cris: enable sim integration

The sim side is already ready to go for cris, so wire it up.

gdb: aarch64: enable sim integration

The sim side is already ready to go for aarch64, so wire it up.

gdb: sim: consolidate configure settings

Moving all the sim settings to one section makes it easier to track,
and makes it easier to keep it aligned with the sim target tests.
The gdb logic was duplicating this when handling different OS targets
instead of having a single cpu check.  Now it's more obvious that the
sim is tied to a cpu and not related to the OS.

Automatic date update in version.in

Remove unused declaration from gdbserver/win32-low.h

I noticed that gdbserver/win32-low.h has an unused declaration.  This
code was changed a while ago, but this declaration slipped through.
This patch removes it.  Tested by rebuilding.

gdb: make use of std::string in utils.c

Replace some of the manual string management (malloc/free) with
std::string when creating commands in utils.c.

Things are a little bit messy as, creating the prefix commands (using
add_basic_prefix_cmd and add_show_prefix_cmd), doesn't copy the doc
string, while creating the actual set/show commands (using
add_setshow_enum_cmd) does copy the doc string.

As a result, I have retained the use of xstrprintf when creating the
prefix command doc strings, but switched to using std::string when
creating the actual set/show commands.

There should be no user visible changes after this commit.

Revert: [AArch64] MTE corefile support

        bfd     * elf.c (elfcore_make_memtag_note_section): New function.
                (elfcore_grok_note): Handle NT_MEMTAG note types.

        binutils* readelf.c (get_note_type): Handle NT_MEMTAG note types.

        include * elf/common.h (NT_MEMTAG): New constant.
                (NT_MEMTAG_TYPE_AARCH_MTE): New constant.

gdb: use bool instead of int in struct internal_problem

Change struct internal_problem (gdb/utils.c) to use bool instead of
int, update the 3 static instances of this structure that we create to
use true/false instead of 1/0.

I've also updated the comments on struct internal_problem as the
existing comment doesn't seem to be referring to the structure, it
talks about returning something, which doesn't make sense in this
context.

There should be no user visible changes after this commit.

gdb: make thread_info::executing private

Rename thread_info::executing to thread_info::m_executing, and make it
private.  Add a new get/set member functions, and convert GDB to make
use of these.

The only real change of interest in this patch is in thread.c where I
have deleted the helper function set_executing_thread, and now just
use the new set function thread_info::set_executing.  However, the old
helper function set_executing_thread included some code to reset the
thread's stop_pc, so I moved this code into the new function
thread_info::set_executing.  However, I don't believe there is
anywhere that this results in a change of behaviour, previously the
executing flag was always set true through a call to
set_executing_thread anyway.

Fix an illegal memory access triggered by an atempt to disassemble a corrupt xtensa binary.

PR 28305
* elf32-xtensa.c (elf_xtensa_do_reloc): Add check for put of range
reloc.

gdb/python: new function to add values into GDB's history

The guile API has (history-append! <value>) to add values into GDB's
history list.  There is currently no equivalent in the Python API.

This commit adds gdb.add_history(<value>) to the Python API, this
function takes <value> a gdb.Value (or anything that can be passed to
the constructor of gdb.Value), and adds the value it represents to
GDB's history list.  The index of the newly added value is returned.

Fix illegal memory access triggered by an attempt to disassemble a corrupt RISC-V binary.

PR 28303
* elfxx-riscv.c (riscv_elf_add_sub_reloc): Add check for out of
range relocs.

[gdb/testsuite] Handle internal-error in gdb_unload

When reverting commit 5a20fadc841 and using gdb_unload instead of runto "bar"
to trigger the internal-error in test-case
gdb.dwarf2/locexpr-data-member-location.exp, we run into:
...
ERROR: couldn't unload file in $gdb (timeout).
...
and the test-case takes about 1 minute.

Fix this by handling internal-error in gdb_unload, such that we have:
...
ERROR: Couldn't unload file in $gdb (GDB internal error).
ERROR: Could not resync from internal error (eof)
...
within 2 seconds.

Tested on x86_64-linux.

PR28307, segfault in ppc64_elf_toc64_reloc

Adds missing bfd_reloc_offset_in_range checks to various relocation
special_functions.

PR 28307
* elf32-ppc.c (ppc_elf_addr16_ha_reloc): Range check reloc offset.
* elf64-ppc.c (ppc64_elf_ha_reloc, ppc64_elf_brtaken_reloc): Likewise.
(ppc64_elf_toc64_reloc, ppc64_elf_prefix_reloc): Likewise.

Automatic date update in version.in

[gdb/testsuite] Handle internal-error in gdb_run_cmd

When reverting commit 5a20fadc841 the test-case
gdb.dwarf2/locexpr-data-member-location.exp fails like this:
...
FAIL: gdb.dwarf2/locexpr-data-member-location.exp: running to bar in runto \
  (GDB internal error)
ERROR: Could not resync from internal error (eof)
...
and takes 1 minute to run.

The long running time is caused by running into a timeout in gdb_run_cmd, at
this point:
...
(gdb) run ^M
The program being debugged has been started already.^M
Start it from the beginning? (y or n) y^M
/home/vries/gdb_versions/devel/src/gdb/gdbtypes.c:5583: internal-error: \
  Unexpected type field location kind: 4^M
A problem internal to GDB has been detected,^M
further debugging may prove unreliable.^M
Quit this debugging session? (y or n)
...

Fix this by detecting the internal-error in gdb_run_cmd.  We don't handle it
in gdb_run_cmd, but stash the gdb output back into the buffer using
-notransfer, and let the caller proc runto deal with it.

After the fix, the test-case just takes 2 seconds.

Tested on x86_64-linux.

gdb: rename gdb/testsuite/gdb.arch/riscv64-unwind-prologue-with-ld-lw.c

A previous commit added the
gdb.arch/riscv64-unwind-prologue-with-ld-lw.exp testcase, but one of its
associated file was named after a previous version of the test.

This commit fixes this and makes sure that all the files linked to this
testcase share the same prefix in the name.

Tested on riscv64 GNU/Linux.

[gdb/testsuite] Handle eof in gdb_internal_error_resync

Before commit 5a20fadc841 the test-case
gdb.dwarf2/locexpr-data-member-location.exp fails like this:
...
FAIL: gdb.dwarf2/locexpr-data-member-location.exp: running to bar in runto \
  (GDB internal error)
ERROR: : spawn id exp9 not open
    while executing
"expect {
-i exp9 -timeout 10
            -re "Quit this debugging session\\? \\(y or n\\) $" {
                send_gdb "n\n" answer
                incr count
            }
            -re "Create ..."
    ("uplevel" body line 1)
    invoked from within
"uplevel $body" NONE : spawn id exp9 not open
ERROR: Could not resync from internal error (timeout)
...

Fix the:
...
ERROR: : spawn id exp9 not open
...
by handling eof in gdb_internal_error_resync, such that we have instead:
...
FAIL: gdb.dwarf2/locexpr-data-member-location.exp: running to bar in runto \
  (GDB internal error)
ERROR: Could not resync from internal error (eof)
...

Tested on x86_64-linux.

Remove some complaints.h includes

There are a few includes of complaints.h that aren't necessary.  This
patch removes them.  Tested by rebuilding.

Fix an illegal memory access triggered by disassembling corrupt s390x binaries.

PR 28304
* elfxx-score7.c (score_elf_gprel15_reloc): If there is no output bfd
treat the reloc as undefined.

Fix potential use on an uninitialised vairable in the MCore assembler.

Fix potential uninitialised variable in microblaze assembler code.

Add a sanity check to the init_nfp6000_mecsr_sec() function in the NFP disassembler.

gdbtypes.c: Add the case for FIELD_LOC_KIND_DWARF_BLOCK

The case for FIELD_LOC_KIND_DWARF_BLOCK was missing for
switch TYPE_FIELD_LOC_KIND. Thas caused an internal-error
under some circumstances.

Fixes bug 28030.

Automatic date update in version.in

Automatic date update in version.in

[gdb/testsuite] Check avx support in gdb.arch/amd64-disp-step-avx.exp

On a machine on Open Build Service I'm running into a SIGILL for test-case
gdb.arch/amd64-disp-step-avx.exp:
...
Program received signal SIGILL, Illegal instruction.^M
test_rip_vex2 () at gdb.arch/amd64-disp-step-avx.S:40^M
40              vmovsd ro_var(%rip),%xmm0^M
(gdb) FAIL: gdb.arch/amd64-disp-step-avx.exp: vex2: \
  continue to test_rip_vex2_end
...
The SIGILL happens when trying to execute the first avx instruction in the
executable.

I can't directly access the machine, but looking at the log for test-case
gdb.arch/i386-avx.exp, it seems that there's no avx support:
...
Breakpoint 1, main (argc=1, argv=0x7fffffffd6b8) at gdb.arch/i386-avx.c:68^M
68        if (have_avx ())^M
(gdb) print have_avx ()^M
$1 = 0^M
...

Fix this by:
- adding a gdb_caching_proc have_avx, similar to have_mpx, using the have_avx
  function from gdb.arch/i386-avx.c
- using proc have_avx in both gdb/testsuite/gdb.arch/amd64-disp-step-avx.exp
  and gdb/testsuite/gdb.arch/i386-avx.exp.

Tested on my x86_64-linux laptop with avx support, where both test-cases pass.

gdb/testsuite/ChangeLog:

2021-09-04  Tom de Vries  <tdevries@suse.de>

PR testsuite/26950
* gdb/testsuite/gdb.arch/i386-avx.c (main): Remove call to have_avx.
(have_avx): Move ...
* gdb/testsuite/lib/gdb.exp (have_avx): ... here.  New proc.
* gdb/testsuite/gdb.arch/amd64-disp-step-avx.exp: Use have_avx.
* gdb/testsuite/gdb.arch/i386-avx.exp: Same.

gnulib: import sys_wait

A few sims use this to emulate process syscalls.
Gdb builds seem to still be fine.

Automatic date update in version.in

Use CORE_ADDR as return type from x86_dr_low_get_addr

On a Windows build locally, watchpoints started failing.  I tracked
this down to x86_dr_low_get_addr returning an 'unsigned long'... in
this particular build, this is a 32-bit type, but the inferior is a
64-bit program.

This patch fixes the problem by changing the return type.  No other
change is required, because this matches the function pointer in
struct x86_dr_low_type.

Test case reproducing PR28030 bug

The original reproducer for PR28030 required use of a specific
compiler version - gcc-c++-11.1.1-3.fc34 is mentioned in the PR,
though it seems probable that other gcc versions might also be able to
reproduce the bug as well.  This commit introduces a test case which,
using the DWARF assembler, provides a reproducer which is independent
of the compiler version.  (Well, it'll work with whatever compilers
the DWARF assembler works with.)

To the best of my knowledge, it's also the first test case which uses
the DWARF assembler to provide debug info for a shared object.  That
being the case, I provided more than the usual commentary which should
allow this case to be used as a template when a combo shared
library / DWARF assembler test case is required in the future.

I provide some details regarding the bug in a comment near the
beginning of locexpr-dml.exp.

This problem was difficult to reproduce; I found myself constantly
referring to the backtrace while trying to figure out what (else) I
might be missing while trying to create a reproducer.  Below is a
partial backtrace which I include for posterity.

 #0  internal_error (
    file=0xc50110 "/ironwood1/sourceware-git/f34-pr28030/bld/../../worktree-pr28030/gdb/gdbtypes.c", line=5575,
    fmt=0xc520c0 "Unexpected type field location kind: %d")
    at /ironwood1/sourceware-git/f34-pr28030/bld/../../worktree-pr28030/gdbsupport/errors.cc:51
 #1  0x00000000006ef0c5 in copy_type_recursive (objfile=0x1635930,
    type=0x274c260, copied_types=0x30bb290)
    at /ironwood1/sourceware-git/f34-pr28030/bld/../../worktree-pr28030/gdb/gdbtypes.c:5575
 #2  0x00000000006ef382 in copy_type_recursive (objfile=0x1635930,
    type=0x274ca10, copied_types=0x30bb290)
    at /ironwood1/sourceware-git/f34-pr28030/bld/../../worktree-pr28030/gdb/gdbtypes.c:5602
 #3  0x0000000000a7409a in preserve_one_value (value=0x24269f0,
    objfile=0x1635930, copied_types=0x30bb290)
    at /ironwood1/sourceware-git/f34-pr28030/bld/../../worktree-pr28030/gdb/value.c:2529
 #4  0x000000000072012a in gdbscm_preserve_values (
    extlang=0xc55720 <extension_language_guile>, objfile=0x1635930,
    copied_types=0x30bb290)
    at /ironwood1/sourceware-git/f34-pr28030/bld/../../worktree-pr28030/gdb/guile/scm-value.c:94
 #5  0x00000000006a3f82 in preserve_ext_lang_values (objfile=0x1635930,
    copied_types=0x30bb290)
    at /ironwood1/sourceware-git/f34-pr28030/bld/../../worktree-pr28030/gdb/extension.c:568
 #6  0x0000000000a7428d in preserve_values (objfile=0x1635930)
    at /ironwood1/sourceware-git/f34-pr28030/bld/../../worktree-pr28030/gdb/value.c:2579
 #7  0x000000000082d514 in objfile::~objfile (this=0x1635930,
    __in_chrg=<optimized out>)
    at /ironwood1/sourceware-git/f34-pr28030/bld/../../worktree-pr28030/gdb/objfiles.c:549
 #8  0x0000000000831cc8 in std::_Sp_counted_ptr<objfile*, (__gnu_cxx::_Lock_policy)2>::_M_dispose (this=0x1654580)
    at /usr/include/c++/11/bits/shared_ptr_base.h:348
 #9  0x00000000004e6617 in std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release (this=0x1654580) at /usr/include/c++/11/bits/shared_ptr_base.h:168
 #10 0x00000000004e1d2f in std::__shared_count<(__gnu_cxx::_Lock_policy)2>::~__shared_count (this=0x190bb88, __in_chrg=<optimized out>)
    at /usr/include/c++/11/bits/shared_ptr_base.h:705
 #11 0x000000000082feee in std::__shared_ptr<objfile, (__gnu_cxx::_Lock_policy)2>::~__shared_ptr (this=0x190bb80, __in_chrg=<optimized out>)
    at /usr/include/c++/11/bits/shared_ptr_base.h:1154
 #12 0x000000000082ff0a in std::shared_ptr<objfile>::~shared_ptr (
    this=0x190bb80, __in_chrg=<optimized out>)
    at /usr/include/c++/11/bits/shared_ptr.h:122
 #13 0x000000000085ed7e in __gnu_cxx::new_allocator<std::_List_node<std::shared_ptr<objfile> > >::destroy<std::shared_ptr<objfile> > (this=0x114bc00,
    __p=0x190bb80) at /usr/include/c++/11/ext/new_allocator.h:168
 #14 0x000000000085e88d in std::allocator_traits<std::allocator<std::_List_node<std::shared_ptr<objfile> > > >::destroy<std::shared_ptr<objfile> > (__a=...,
    __p=0x190bb80) at /usr/include/c++/11/bits/alloc_traits.h:531
 #15 0x000000000085e50c in std::__cxx11::list<std::shared_ptr<objfile>, std::allocator<std::shared_ptr<objfile> > >::_M_erase (this=0x114bc00, __position=
  std::shared_ptr<objfile> (expired, weak count 1) = {get() = 0x1635930})
    at /usr/include/c++/11/bits/stl_list.h:1925
 #16 0x000000000085df0e in std::__cxx11::list<std::shared_ptr<objfile>, std::allocator<std::shared_ptr<objfile> > >::erase (this=0x114bc00, __position=
  std::shared_ptr<objfile> (expired, weak count 1) = {get() = 0x1635930})
    at /usr/include/c++/11/bits/list.tcc:158
 #17 0x000000000085c748 in program_space::remove_objfile (this=0x114bbc0,
    objfile=0x1635930)
    at /ironwood1/sourceware-git/f34-pr28030/bld/../../worktree-pr28030/gdb/progspace.c:210
 #18 0x000000000082d3ae in objfile::unlink (this=0x1635930)
    at /ironwood1/sourceware-git/f34-pr28030/bld/../../worktree-pr28030/gdb/objfiles.c:487
 #19 0x000000000082e68c in objfile_purge_solibs ()
    at /ironwood1/sourceware-git/f34-pr28030/bld/../../worktree-pr28030/gdb/objfiles.c:875
 #20 0x000000000092dd37 in no_shared_libraries (ignored=0x0, from_tty=1)
    at /ironwood1/sourceware-git/f34-pr28030/bld/../../worktree-pr28030/gdb/solib.c:1236
 #21 0x00000000009a37fe in target_pre_inferior (from_tty=1)
    at /ironwood1/sourceware-git/f34-pr28030/bld/../../worktree-pr28030/gdb/target.c:2496
 #22 0x00000000007454d6 in run_command_1 (args=0x0, from_tty=1,
    run_how=RUN_NORMAL)
    at /ironwood1/sourceware-git/f34-pr28030/bld/../../worktree-pr28030/gdb/infcmd.c:437

I'll note a few points regarding this backtrace:

Frame #1 is where the internal error occurs.  It's caused by an
unhandled case for FIELD_LOC_KIND_DWARF_BLOCK.  The fix for this bug
adds support for this case.

Frame #22 - it's a partial backtrace - shows that GDB is attempting to
(re)run the program.  You can see the exact command sequence that was
used for reproducing this problem in the PR (at
https://sourceware.org/bugzilla/show_bug.cgi?id=28030), but in a
nutshell, after starting the program and advancing to the appropriate
source line, GDB was asked to step into libstdc++; a "finish" command
was issued, returning a value.  The fact that a value was returned is
very important.  GDB was then used to step back into libstdc++.  A
breakpoint was set on a source line in the library after which a "run"
command was issued.

Frame #19 shows a call to objfile_purge_solibs.  It's aptly named.

Frame #7 is a call to the destructor for one of the objfile solibs; it
turned out to be the one for libstdc++.

Frames #6 thru #3 show various value preservation frames.  If you look
at preserve_values() in gdb/value.c, the value history is preserved
first, followed by internal variables, followed by values for the
extension languages (python and guile).

[gdb/testsuite] Add untested case in gdb.gdb/complaints.exp

When building gdb with "-Wall -O2 -g -flto=auto", I run into:
...
(gdb) call clear_complaints()^M
No symbol "clear_complaints" in current context.^M
(gdb) FAIL: gdb.gdb/complaints.exp: clear complaints
...

The problem is that lto has optimized away clear_complaints, and consequently
the selftests cannot run.

Fix this by:
- using info function to detect presence of clear_complaints
- handling the absence of clear_complaints by calling untested
...
(gdb) UNTESTED: gdb.gdb/complaints.exp: \
  Cannot find clear_complaints, skipping test
...

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

2021-09-03  Tom de Vries  <tdevries@suse.de>

* gdb.gdb/complaints.exp: Use untested if clear_complaints cannot
be found.

gdb: Enable finish command and inferior calls for _Float16 on amd64 and i386.

Values of type _Float16 and _Float16 _Complex can now be used on CPUs with
AVX512-FP16 support. Return values of those types are located in XMM0.
Compiler support for gcc and clang is in progress, see e.g.:
https://gcc.gnu.org/pipermail/gcc-patches/2021-July/574117.html

gdb/ChangeLog:
2021-07-21  Felix Willgerodt  <Felix.Willgerodt@intel.com>

* amd64-tdep.c (amd64_classify): Classify _Float16 and
_Float16 _Complex as AMD64_SSE.
* i386-tdep.c (i386_extract_return_value): Read _Float16 and
_Float16 _Complex from xmm0.

gdb/testsuite/ChangeLog:
2021-07-21  Felix Willgerodt  <Felix.Willgerodt@intel.com>

* gdb.arch/x86-avx512fp16-abi.c: New file.
* gdb.arch/x86-avx512fp16-abi.exp: New file.

Add half support for AVX512 register view.

This adds support for the half datatype, FP16, to the AVX512 register printing.

gdb/ChangeLog:
2020-07-21  Felix Willgerodt  <Felix.Willgerodt@intel.com>

* i386-tdep.c (i386_zmm_type) <v32_half>: New field.
(i386_ymm_type) <v16_half>: New field.
(i386_gdbarch_init): Add set_gdbarch_half_format.
* features/i386/64bit-avx512.xml: Add half type.
* features/i386/64bit-avx512.c: Regenerated.
* features/i386/64bit-sse.xml: Add half type.
* features/i386/64bit-sse.c: Regenerated.

gdb/testsuite/ChangeLog:
2021-07-21  Felix Willgerodt  <Felix.Willgerodt@intel.com>

* gdb.arch/x86-avx512fp16.c: New file.
* gdb.arch/x86-avx512fp16.exp: New file.
* lib/gdb.exp (skip_avx512fp16_tests): New function.

gdb, i386: Enable AVX512-bfloat16 for i386 targets.

Values of type bfloat16 can also be used on 32-bit targets, which was missed
in the original enablement.  This also adjusts the testcase to pass with
"unix/-m32", where only the lower 8 AVX registers are available.

gdb/ChangeLog:
2021-07-21  Felix Willgerodt  <Felix.Willgerodt@intel.com>

* features/i386/32bit-sse.xml: Add bfloat16 type.
* features/i386/32bit-sse.c: Regenerated.

gdb/testsuite/ChangeLog:
2021-07-21  Felix Willgerodt  <Felix.Willgerodt@intel.com>

* gdb.arch/x86-avx512bf16.exp: Only use x/z/ymm 0-7.

[gdb/testsuite] Add untested case in selftest_setup

When building gdb with "-Wall -O2 -g -flto=auto", I run into:
...
FAIL: gdb.gdb/python-helper.exp: breakpoint in captured_main \
  (got interactive prompt)
FAIL: gdb.gdb/python-helper.exp: run until breakpoint at captured_main
WARNING: Couldn't test self
...
and similar in gdb.gdb/selftest.exp.

The first FAIL in more detail:
...
(gdb) break captured_main^M
Function "captured_main" not defined.^M
Make breakpoint pending on future shared library load? (y or [n]) n^M
(gdb) FAIL: gdb.gdb/python-helper.exp: breakpoint in captured_main \
  (got interactive prompt)
...

The problem is that lto has optimized away the captured_main function
and consequently the selftests dependent on that cannot run.

Fix this by:
- using gdb_breakpoint to detect failure to set the breakpoint
- handling the failure to set a breakpoint by calling untested
- not emitting the warning if we've already got untested
such that we have:
...
(gdb) UNTESTED: gdb.gdb/python-helper.exp: Cannot set breakpoint at \
  captured_main, skipping testcase.
...

gdb/testsuite/ChangeLog:

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

* lib/selftest-support.exp: Emit untested when not being able to set
breakpoint.

ld testsuite tidy

Fixes a few issues:
1) If you use "-fsanitize=address,undefined" in CFLAGS, the Makefile
attempt to trim off -fsanitize options left us with ",undefined".
2) ld_compile adds CFLAGS_FOR_TARGET itself, no need to pass it.
3) CFLAGS might be needed linking bootstrap test.

* Makefile.am (CFLAGS_FOR_TARGET, CXXFLAGS_FOR_TARGET): Trim off
all -fsanitize=*.
* Makefile.in: Regenerate.
* testsuite/ld-bootstrap/bootstrap.exp: Use CFLAGS when linking.
* testsuite/ld-cdtest/cdtest.exp: Use CFLAGS_FOR_TARGET when
linking.
* testsuite/ld-auto-import/auto-import.exp: Don't pass
CFLAGS_FOR_TARGET to ld_compile.
* testsuite/ld-cygwin/exe-export.exp: Likewise.
* testsuite/ld-elfvers/vers.exp: Likewise.
* testsuite/ld-elfvsb/elfvsb.exp: Likewise.
* testsuite/ld-elfweak/elfweak.exp: Likewise.
* testsuite/ld-gc/gc.exp: Likewise.
* testsuite/ld-pe/pe-compile.exp: Likewise.
* testsuite/ld-pe/pe-run.exp: Likewise.
* testsuite/ld-pe/pe-run2.exp: Likewise.
* testsuite/ld-plugin/plugin.exp: Likewise.
* testsuite/ld-shared/shared.exp: Likewise.
* testsuite/ld-elfcomm/elfcomm.exp: Likewise, and don't allow
nios2 testing to trash CFLAGS_FOR_TARGET.
* testsuite/ld-scripts/crossref.exp: Don't pass options in
CC_FOR_TARGET, do so in CFLAGS_FOR_TARGET instead.
* testsuite/ld-srec/srec.exp: Likewise, and for CXX.

CC_FOR_TARGET et al

The top level Makefile, the ld Makefile and others, define
CC_FOR_TARGET to be a compiler for the binutils target machine.  This
is the compiler that should be used for almost all tests with C
source.  There are _FOR_TARGET versions of CFLAGS, CXX, and CXXFLAGS
too.  This was all supposed to work with the testsuite .exp files
using CC for the target compiler, and CC_FOR_HOST for the host
compiler, with the makefiles passing CC=$CC_FOR_TARGET and
CC_FOR_HOST=$CC to the runtest invocation.

One exception to the rule of using CC_FOR_TARGET is the native-only ld
bootstrap test, which uses the newly built ld to link a copy of
itself.  Since the files being linked were created with the host
compiler, the boostrap test should use CC and CFLAGS, in case some
host compiler option provides needed libraries automatically.
However, bootstrap.exp used CC where it should have used CC_FOR_HOST.
I set about fixing that problem, then decided that playing games in
the makefiles with CC was a bad idea.  Not only is it confusing, but
other dejagnu code knows about CC_FOR_TARGET.  See dejagnu/target.exp.

So this patch gets rid of the makefile variable renaming and changes
all the .exp files to use the correct _FOR_TARGET variables.
CC_FOR_HOST and CFLAGS_FOR_HOST disappear.  A followup patch will
correct bootstrap.exp to use CFLAGS, and a number of other things I
noticed.

binutils/
* testsuite/lib/binutils-common.exp (run_dump_test): Use
CC_FOR_TARGET and CFLAGS_FOR_TARGET rather than CC and CFLAGS.
ld/
* Makefile.am (check-DEJAGNU): Don't set CC to CC_FOR_TARGET
and similar.  Pass variables with unchanged names.  Don't set
CC_FOR_HOST or CFLAGS_FOR_HOST.
* Makefile.in: Regenerate.
* testsuite/config/default.exp: Update default CC and similar.
(compiler_supports, plug_opt): Use CC_FOR_TARGET.
* testsuite/ld-cdtest/cdtest.exp: Replace all uses of CC with
CC_FOR_TARGET, and similarly for CFLAGS, CXX and CXXFLAGS.
* testsuite/ld-auto-import/auto-import.exp: Likewise.
* testsuite/ld-cygwin/exe-export.exp: Likewise.
* testsuite/ld-elf/dwarf.exp: Likewise.
* testsuite/ld-elf/indirect.exp: Likewise.
* testsuite/ld-elf/shared.exp: Likewise.
* testsuite/ld-elfcomm/elfcomm.exp: Likewise.
* testsuite/ld-elfvers/vers.exp: Likewise.
* testsuite/ld-elfvsb/elfvsb.exp: Likewise.
* testsuite/ld-elfweak/elfweak.exp: Likewise.
* testsuite/ld-gc/gc.exp: Likewise.
* testsuite/ld-ifunc/ifunc.exp: Likewise.
* testsuite/ld-mn10300/mn10300.exp: Likewise.
* testsuite/ld-pe/pe-compile.exp: Likewise.
* testsuite/ld-pe/pe-run.exp: Likewise.
* testsuite/ld-pe/pe-run2.exp: Likewise.
* testsuite/ld-pie/pie.exp: Likewise.
* testsuite/ld-plugin/lto.exp: Likewise.
* testsuite/ld-plugin/plugin.exp: Likewise.
* testsuite/ld-scripts/crossref.exp: Likewise.
* testsuite/ld-selective/selective.exp: Likewise.
* testsuite/ld-sh/sh.exp: Likewise.
* testsuite/ld-shared/shared.exp: Likewise.
* testsuite/ld-srec/srec.exp: Likewise.
* testsuite/ld-undefined/undefined.exp: Likewise.
* testsuite/ld-unique/unique.exp: Likewise.
* testsuite/ld-x86-64/tls.exp: Likewise.
* testsuite/lib/ld-lib.exp: Likewise.
libctf/
* Makefile.am (check-DEJAGNU): Don't set CC to CC_FOR_TARGET.
Pass CC and CC_FOR_TARGET.  Don't set CC_FOR_HOST.
* Makefile.in: Regenerate.
* testsuite/config/default.exp: Update default CC and similar.
* testsuite/lib/ctf-lib.exp (run_native_host_cmd): Use CC rather
than CC_FOR_HOST.
(run_lookup_test): Use CC_FOR_TARGET and CFLAGS_FOR_TARGET.

pj: asan: out of bounds, ubsan: left shift of negative

* pj-dis.c: Include libiberty.h.
(print_insn_pj): Don't index op->arg past array bound.  Don't
left shift negative int.

ubsan: alpha: member access within null pointer

* elf64-alpha.c (elf64_alpha_relax_with_lituse): Avoid UB.

ubsan: libctf: applying zero offset to null pointer

* ctf-open.c (init_symtab): Avoid ubsan error.

haiku tidy

--enable-maintainer-mode showed a number of files needing to be
regenerated, and in the case of ld/Makefile.in that the file was
regenerated by hand.  Nothing to see here really.

ld/
* Makefile.am (ALL_64_EMULATION_SOURCES): Sort haiku entry.
* Makefile.in: Regenerate.
* po/BLD-POTFILES.in: Regenerate.
libctf/
* configure: Regenerate.
zlib/
* configure: Regenerate.

gold: --export-dynamic-symbol: don't imply -u

to match GNU ld.

gold/
* archive.cc (Library_base::should_include_member): Don't handle
--export-dynamic-symbol.
* symtab.cc (Symbol_table::do_add_undefined_symbols_from_command_line):
Likewise.

Automatic date update in version.in

Add support for the haiku operating system.  These are the os support patches we have been grooming and maintaining for quite a few years over on git.haiku-os.org.  All of these architectures are working and most have been stable for quite some time.

Fix the V850 assembler's generation of relocations for the st.b instruction.

PR 28292
gas * config/tc-v850.c (handle_lo16): Also accept
BFD_RELOC_V850_LO16_SPLIT_OFFSET.
* testsuite/gas/v850/split-lo16.s: Add extra line.
* testsuite/gas/v850/split-lo16.d: Update expected disassembly.

opcodes * v850-opc.c (D16): Use BFD_RELOC_V850_LO16_SPLIT_OFFSET in place
of BFD_RELOC_16.

SHT_SYMTAB_SHNDX handling

.symtab_shndx section contents is an array, one entry for each symbol
in .symtab, present when the number of symbols exceeds a little less
than 64k.  Since the mapping is 1-1 with symbols there is no need to
keep both dest_index and destshndx_index in elf_sym_strtab.  Instead,
just make sure that the shndx pointers to the swap functions are kept
NULL when .symtab_shndx does not exist.  Also, strtabcount in the
linker's elf hash table is incremented in lock-step with the output
symcount, so that can disappear too.

PTR_ADD and NPTR_ADD for bfd.h

This defines a couple of macros used to avoid ubsan complaints about
calculations involving NULL pointers.  PTR_ADD should be used in the
case where it is known that the offset is always zero with a NULL
pointer, and you'd like to know if a non-zero offset is ever used.
NPTR_ADD should be rarely used, but is defined for cases where a
non-zero offset is expected and should be ignored if the pointer is
NULL.

bfd/
* bfd-in.h (PTR_ADD, NPTR_ADD): Define.
* bfd-in2.h: Regenerate.
* elf-eh-frame.c (adjust_eh_frame_local_symbols): Avoid NULL
pointer calculations.
* elflink.c (_bfd_elf_strip_zero_sized_dynamic_sections): Likewise.
(bfd_elf_add_dt_needed_tag, elf_finalize_dynstr): Likewise.
(elf_link_add_object_symbols, elf_link_input_bfd): Likewise.
(bfd_elf_final_link, bfd_elf_gc_record_vtinherit): Likewise.
binutils/
* objdump.c (disassemble_section): Use PTR_ADD for rel_ppend.