sim: testsuite: setup per-port toolchain settings for multitarget build

Gas does not support multitarget builds -- it still only supports
a single input & output format.  ld is a bit better, but requires
manual flags to select the right output.  This makes it impossible
to run the complete testsuite in a multitarget build.

To address this limitation, create a suite of FOR_TARGET variables
so these can be set to precompiled as & ld programs.  It requires
a bit of setup ahead of time, but it's a one-time cost, and makes
running the full testsuite at once much easier.

Automatic date update in version.in

PR28629 NIOS2 fallout

The test exactly matched wrong output.

PR 28629
* testsuite/gas/nios2/relax.d: Update expected output.

sim: add checks to core headers to prevent incorrect common building

Some of the core sim headers rely on the SIM_AC_OPTION_BITSIZE macro
which can change the size of core types.  Since these haven't been
unified across ports, add checks to make sure they aren't accidentally
included when building for all ports.  This caught the sim-load file
using poisoned headers that it didn't actually need.

sim: unify syscall.o building

Now that we've unified all the syscall tables, this file does not rely
on any port-specific settings, so move it up to building as part of the
common step so we only do it once in a multibuild.

sim: drop unused gentmap & nltvals.def logic

Now that all ports have switched to target-newlib-* files, there's
no need for these files & generating things at build time.  So punt
the logic and make target-newlib-syscall a hard requirement.

sim: mcore: switch to new target-newlib-syscall

Use the new target-newlib-syscall module.  This is needed to merge all
the architectures into a single build, and mcore has a custom syscall
table for its newlib/libgloss port.

sim: riscv: switch to new target-newlib-syscall

Use the new target-newlib-syscall module.  This is needed to merge all
the architectures into a single build, and riscv has a custom syscall
table for its newlib/libgloss port.

sim: cr16: switch to new target-newlib-syscall

Use the new target-newlib-syscall module.  This is needed to merge all
the architectures into a single build, and cr16 has a custom syscall
table for its newlib/libgloss port.

This allows cleaning up the syscall ifdef logic.  We know these will
always exist now.

sim: d10v: switch to new target-newlib-syscall

Use the new target-newlib-syscall module.  This is needed to merge all
the architectures into a single build, and d10v has a custom syscall
table for its newlib/libgloss port.

This allows cleaning up the syscall ifdef logic.  We know these will
always exist now.

sim: sh: switch to new target-newlib-syscall

Use the new target-newlib-syscall module.  This is needed to merge all
the architectures into a single build, and sh has a custom syscall
table for its newlib/libgloss port.

sim: v850: switch to new target-newlib-syscall

Use the new target-newlib-syscall module.  This is needed to merge all
the architectures into a single build, and v850 has a custom syscall
table for its newlib/libgloss port.

This allows cleaning up the syscall ifdef logic.  We know these will
always exist now.

sim: iq2000/lm32/m32c/moxie/rx: switch to new target-newlib-syscall.h

Use the new target-newlib-syscall.h to provide the target syscall
defines.  These code paths are written specifically for the newlib
ABI rather than being generalized, so switching them to the defines
rather than trying to go through the dynamic callback conversion
seems like the best trade-off for now.  Might have to reconsider
this in the future.

sim: nltvals: pull target syscalls out into a dedicated source file

Like we just did for pulling out the errno map, pull out the syscall
maps into a dedicated common file.  Most newlib ports are using the
same syscall map, but not all, which means we have to do a bit more
work to migrate.

This commit adds the maps and switches the ports using the common
default syscall table over to it.  Ports using unique syscall tables
are still using the old targ-map.c logic.

Switching common ports over is easy by checking NL_TARGET, but the
ppc code needs a bit more cleanup here hence its larger diff.

sim: frv: resolve syscalls dynamically

Avoid use of TARGET_<syscall> defines and rely on the callback layers
to resolve these dynamically so we can support multiple syscall layers
instead of assuming the newlib/libgloss numbers all the time.

sim: mn10300: resolve syscalls dynamically

Avoid use of TARGET_<syscall> defines and rely on the callback layers
to resolve these dynamically so we can support multiple syscall layers
instead of assuming the newlib/libgloss numbers all the time.

sim: nltvals: drop i960

This port was dropped from gdb/bfd/sim years ago, so stop including
its syscall constants too.

sim: moxie: fix datadir handling

Expand the value at `make` time rather than configure generation time
so that we handle $(datarootdir) setting properly.

Automatic date update in version.in

gdb: fix typos in configure

The variable names used to restore CFLAGS and LDFLAGS here don't quite
match the names used above, resulting in losing the original CFLAGS and
LDFLAGS.  Fix that.

Change-Id: I9cc2c3b48b1dc30c31a7143563c893fd6f426a0a

sim: hw: mark hw_descriptors const

sim: testsuite: add dedicated flag for init toolchain tests

As we setup more reliable CC_FOR_TARGET variables for each target, the
bfin way of overriding it to stuff custom CFLAGS doesn't scale well.
Add a dedicated CFLAGS_FOR_TARGET_init setting that each set of tests
can setup if they want to add custom options.

sim: testsuite: clean up arch specific toolchain settings

In a multitarget build, we process all targets in order, so make sure
the toolchain settings from one don't leak into the next.

sim: cris: always search for local rvdummy tool

If the board info sets the sim to a basename that is found via $PATH
(which is the default dejagnu behavior), the logic here to use its
dirname to find rvdummy fails because it looks for `./rvdummy`.  So
switch it to always use the local build of rvdummy which is the one
we want to be testing against in the first place.

If we get a request for testing against a different setup, we can
figure out & document the needs at that point, and then setup some
config knobs to control it.

[gdb/testsuite] Fix FAIL in gdb.base/list-missing-source.exp

In commit f8080fb7a44 "[gdb/testsuite] Add gdb.base/include-main.exp" a
file gdb.base/main.c was added, which caused the following regression:
...
(gdb) list^M
<gdb.base/main.c>
(gdb) FAIL: gdb.base/list-missing-source.exp: list
...

The problem is that the test-case does not expect to find a file main.c, but
now it finds gdb.base/main.c.

Fix this by using the more specific file name list-missing-source.c.

Tested on x86_64-linux.

sim: testsuite: fix bits-gen EXEEXT handling

Add missing $(EXEEXT) to dependencies on bits-gen.  These are actually
build-only tools, but automake doesn't allow for build & host tools, so
the rules are re-using EXEEXT.

sim: testsuite: initial support for OS-specific tests

We usually test against the newlib/libgloss environment, but for a
few ports that also support Linux apps, we want to test that logic
too.  A lot of the C code is written such that it works with either
newlib/libgloss or glibc/linux toolchains, but we have some tests
that end up being Linux-specific.  Cris has been using the target
tuple as a rough proxy for this (where cris*-*-elf is assumed to be
newlib/libgloss, and everything else is glibc/linux), but that is a
bit too rough, and it doesn't work in a multitarget build.

So lets create a few stub files that we can do compile tests with
to detect the different setups, and then let tests declare which
one they require (if they require any at all).

sim: testsuite: unify basic C compiler checks

Both bfin & cris ports test the C compiler to see if it works, but in
their own way.  Unify the checks in the common code so we can leverage
them in more ports in the future, and collapse the bfin & cris code.

sim: testsuite: rework sim_init usage

The sim_init function was called by runtest for each test when --tool
was set to sim.  When we changed to --tool '' to collapse the testsuite
dir, the init function was no longer called on every test.  However, it
was still being called explicitly by config/default.exp.  It's not clear
why that explicit call ever existed since, in the past, it meant it was
redundant.

Lets drop the single sim_init call in config/default.exp and move it out
to all our tests.  This replicates the runtest behavior so we can setup
variables on a per-test basis which allows us to recollapse the sim_path
logic back.  We'll also leverage this in the future for toolchain setup.

Also add a few comments clarifying the overall runtime behavior.

sim: cris: fix testsuite hang when sim is missing

If the cris sim hasn't been built yet, trying to run its testsuite
will hang indefinitely.  The common sim APIs already have this, so
copy it over to the cris forks of the test+run functions.

sim: testsuite: fix objdir handling

The tests assume that the cwd is the objdir directory and write its
intermediates to there all the time.  When using runtest's --objdir
setting though, this puts the files in the wrong place.  This isn't
a big problem currently as we never change --objdir, but in order to
support parallel test execution, we're going to start setting that
option, so clean up the code ahead of time.

We also have to tweak some of the cris tests which were making
assumptions about the argv[0] value.

sim: testsuite: rename global_sim_options to SIMFLAGS_FOR_TARGET

Now that all the other toolchain settings have been renamed to match
the dejagnu settings of XXX_FOR_TARGET, rename global_sim_options to
SIMFLAGS_FOR_TARGET too.

sim: testsuite: replace global_ld_options with LDFLAGS_FOR_TARGET

Only a few tests actually use global_ld_options, but we can replace the
sim-specific settings with the dejagnu common LDFLAGS_FOR_TARGET and get
the same result.

Automatic date update in version.in

Fix ifunc test fails on hppa*-*-*

2021-11-26  John David Anglin  <danglin@gcc.gnu.org>

PR ld/27442

ld/ChangeLog:

* ld/testsuite/ld-ifunc/ifunc.exp (contains_irelative_reloc): Adjust
regexp.
Skip static ifunc-using executable test on hppa*-*-*.

gas: Update commit 4780e5e4933

Update

commit 4780e5e4933a2497a5aecc4ceabbbb8e82aaf822
Author: Tom de Vries <tdevries@suse.de>
Date:   Fri Nov 26 09:59:45 2021 +0100

    [gas] Fix file 0 dir with -gdwarf-5

1. Replace i with j in

  for (j = 0; i < NUM_MD5_BYTES; ++j)

2. Pass -W to readelf to force CU: in output due to:

      if (do_wide || strlen (directory) < 76)
printf (_("CU: %s/%s:\n"), directory, file_table[0].name);
      else
printf ("%s:\n", file_table[0].name);

PR gas/28629
* dwarf2dbg.c (out_dir_and_file_list): Fix a typo in commit
4780e5e4933.
* testsuite/gas/elf/dwarf-5-nop-for-line-table.d: Pass -W to
readelf.

sim: testsuite: replace global_as_options with ASFLAGS_FOR_TARGET

Only a few tests actually use global_as_options, but we can replace the
sim-specific settings with the dejagnu common ASFLAGS_FOR_TARGET and get
the same result.

[gdb/testsuite] Add gdb.base/include-main.exp

The test-case gdb.ada/dgopt.exp uses the -gnatD switch, in combination with
-gnatG.

This causes the source file $src/gdb/testsuite/gdb.ada/dgopt/x.adb to be
expanded into $build/gdb/testsuite/outputs/gdb.ada/dgopt/x.adb.dg, and the
debug information should refer to the x.adb.dg file.

That is the case for the .debug_line part:
...
The Directory Table is empty.

 The File Name Table (offset 0x1c):
  Entry Dir     Time    Size    Name
  1     0       0       0       x.adb.dg
...
but not for the .debug_info part:
...
    <11>   DW_AT_name        : $src/gdb/testsuite/gdb.ada/dgopt/x.adb
    <15>   DW_AT_comp_dir    : $build/gdb/testsuite/outputs/gdb.ada/dgopt
...

Filed as PR gcc/103436.

In C we can generate similar debug information, using a source file that does
not contain any code, but includes another one that does:
...
 $ cat gdb/testsuite/gdb.base/include-main.c
 #include "main.c"
...
such that in the .debug_line part we have:
...
 The Directory Table (offset 0x1c):
  1     /home/vries/gdb_versions/devel/src/gdb/testsuite/gdb.base

 The File Name Table (offset 0x57):
  Entry Dir     Time    Size    Name
  1     1       0       0       main.c
...
and in the .debug_info part:
...
    <11>   DW_AT_name        : $src/gdb/testsuite/gdb.base/include-main.c
    <15>   DW_AT_comp_dir    : $build/gdb/testsuite
...

Add a C test-case that mimics gdb.ada/dgopt.exp, that is:
- generate debug info as described above,
- issue a list of a line in include-main.c, while the corresponding
  CU is not expanded yet.

Tested on x86_64-linux.

sim: testsuite: drop unused global_cc_options

Nothing in the testsuite is using this setting, so let's drop it.
Any code that wants to set compiler flags can use CFLAGS_FOR_TARGET
instead to get the same effect.

sim: testsuite: punt unused toolchain variables

These haven't been used in over 20 years.  The sim testsuite used to
run these tools itself directly, but back in ~1999 it switched to the
dejagnu helpers (e.g. target_assemble & target_link), and the dejagnu
logic only utilizes XXX_FOR_TARGET variables.  Punt them here to avoid
confusion with dead code.

gdb: add risc-v disassembler options support

This commit adds support for RISC-V disassembler options to GDB.  This
commit is based on this patch which was never committed:

  https://sourceware.org/pipermail/binutils/2021-January/114944.html

All of the binutils refactoring has been moved to a separate, earlier,
commit, so this commit is pretty straight forward, just registering
the required gdbarch hooks.

Co-authored-by: Simon Cook <simon.cook@embecosm.com>

opcodes/riscv: add disassembler options support to libopcodes

In preparation for the next commit, which will add GDB support for
RISC-V disassembler options, this commit restructures how the
disassembler options are managed within libopcodes.

The implementation provided here is based on this mailing list patch
which was never committed:

  https://sourceware.org/pipermail/binutils/2021-January/114944.html

which in turn took inspiration from the MIPS implementation of the
same feature.

The biggest changes from the original mailing list post are:

  1. The GDB changes have been split into a separate patch, and

  2. The `riscv_option_args_privspec` variable, which held the valid
  priv-spec values is now gone, instead we use the `riscv_priv_specs`
  array from bfd/cpu-riscv.c instead.

Co-authored-by: Simon Cook <simon.cook@embecosm.com>
include/ChangeLog:

* dis-asm.h (disassembler_options_riscv): Declare.

opcodes/ChangeLog:

* riscv-dis.c (enum riscv_option_arg_t): New enum typedef.
(riscv_options): New static global.
(disassembler_options_riscv): New function.
(print_riscv_disassembler_options): Rewrite to use
disassembler_options_riscv.

[gas] Fix file 0 dir with -gdwarf-5

In out_dir_and_file_list, if file 0 is copied from file 1, only the filename
is copied, and the dir and md5 fields are left to their default values.

Fix this by adding the copy of the dir and md5 fields.

gas/ChangeLog:

2021-11-26  Tom de Vries  <tdevries@suse.de>

PR 28629
* dwarf2dbg.c (out_dir_and_file_list): When copying file 1 to file 0,
also copy dir and md5 fields.
* testsuite/gas/i386/dwarf5-line-4.d: Adjust expected output.

sim: mips: avoid _ namespace

Some C libraries export _P symbols in their headers (like older
newlib and its ctype.h), so use P_ instead to avoid conflicts.

ld: fix POSIX shell test usage

POSIX test uses = for compares, not == which is a bashism.

gas: enable silent build rules

ld: fix --disable-multiple-abs-defs alignment in help

Automatic date update in version.in

gdb: ensure extension_language_python is always defined

In this commit:

  commit c6a6aad52d9e839d6a84ac31cabe2b7e1a2a31a0
  Date:   Mon Oct 25 17:25:45 2021 +0100

      gdb/python: make some global variables static

building without Python was broken.  The extension_language_python
global was moved from being always defined, to only being defined when
the HAVE_PYTHON macro was defined.  As a consequence, building without
Python support would result in errors like:

  /usr/bin/ld: extension.o:(.rodata+0x120): undefined reference to `extension_language_python'

This commit fixes the problem by moving the definition of
extension_language_python outside of the HAVE_PYTHON macro protection.

Revert "gdb: add assert in remote_target::wait relating to async being off"

This commit introduced a test failure in gdb.server/attach-flag.exp.
I didn't spot this failure originally as the problem is fixed by this,
as yet unpushed patch:

  https://sourceware.org/pipermail/gdb-patches/2021-November/183768.html

I unfortunately didn't test each patch in the original series
independently.  I'll repost this patch after the above patch has been
merged.

This reverts commit 32b1f5e8d6b8ddd3be6e471c26dd85a1dac31dda.

Fix building the AArch64 assembler and disassembler when assertions are disabled.

PR 28614
* aarch64-asm.c: Replace assert(0) with real code.
* aarch64-dis.c: Likewise.
* aarch64-opc.c: Likewise.

PR gdb/28480: Improve ambiguous member detection

Basic ambiguity detection assumes that when 2 fields with the same name
have the same byte offset, it must be an unambiguous request. This is not
always correct. Consider the following code:

class empty { };

class A {
public:
  [[no_unique_address]] empty e;
};

class B {
public:
  int e;
};

class C: public A, public B { };

if we tried to use c.e in code, the compiler would warn of an ambiguity,
however, since A::e does not demand an unique address, it gets the same
address (and thus byte offset) of the members, making A::e and B::e have the
same address. however, "print c.e" would fail to report the ambiguity,
and would instead print it as an empty class (first path found).

The new code solves this by checking for other found_fields that have
different m_struct_path.back() (final class that the member was found
in), despite having the same byte offset.

The testcase gdb.cp/ambiguous.exp was also changed to test for this
behavior.

coff-go32: consistent 16-byte section alignment

Section alignment for coff-go32 is inconsistent - The '.text' and
'.data' sections are 16-byte aligned, but named sections '.text.*' and
'.data.*' are only 4-byte aligned.  '.gnu.linkonce.r.*' is aligned to
16 bytes, yet '.rodata' and '.rodata.*' are aligned to 4 bytes.  For
'.bss' all input sections are only aligned to 4 bytes.

This primarily can cause trouble when using SSE instructions, which
require their memory operands to be aligned to 16-byte boundaries.

This patch solves the issue simply by setting the section alignment
to 16 bytes, for all code and data sections referenced in the default
linker script.

* coff-go32.c (COFF_SECTION_ALIGNMENT_ENTRIES):  Use partial
name match for .text, .data.  Add entries for .const, .rodata,
.bss, .gnu.linkonce.b.

Re: AArch64: Add support for AArch64 EFI (efi-*-aarch64)

Commit b69c9d41e8 edited bfd/Makefile.in rather than using automake,
which meant a typo in Makefile.am was not discovered and other
differences in Makefile.in are seen with a proper regeneration.  One
difference was lack of an empty line between the pe-aarch64igen.c rule
and the following $(BFD32_LIBS) etc. dependency rule, in the
regenerated file.  Not that it matters for proper "make" behaviour,
but it's nicer with a line between those rules.  Moving the rule
earlier seems to cure the missing empty line.

* Makefile.am (BFD64_BACKENDS): Correct typo.
(BFD_H_DEPS, LOCAL_H_DEPS): Move earlier.  Move rule using these
deps earlier too.
* Makefile.in: Regenerate.
* po/BLD-POTFILES.in: Regenerate.
* po/SRC-POTFILES.in: Regenerate.

Updated French translation for the opcodes directory.

* po/fr.po; Updated French translation.

gdb: rename source_styling_changed observer

In a later commit I plan to add disassembler styling.  In the same way
that we have a source_styling_changed observer I would need to add a
disassembler_styling_changed observer.

However, currently, these observers would only be notified from
cli-style.c:set_style_enabled, and observed in tui-winsource.c,
tui_source_window::style_changed, as a result, having two observers
seems unnecessary right now, so, in this commit, I plan to rename
source_styling_changed to just styling_changed, then, in the later
commit, when disassembler styling is added, I can use the same
observer for both source styling, and disassembler styling.

There should be no user visible changes after this commit.

gdb/python: make some global variables static

Make a couple of global variables static in python/python.c.  To do
this I had to move the definition of extension_language_python to
later in the file.

There should be no user visible changes after this commit.

gdb: add assert in remote_target::wait relating to async being off

While working on another patch I ended up in a situation where I had
async mode disabled (with 'maint set target-async off'), but the async
event token got marked anyway.

In this situation GDB was continually calling into
remote_target::wait, however, the async token would never become
unmarked as the unmarking is guarded by target_is_async_p.

We could just unconditionally unmark the token, but that would feel
like just ignoring a bug, so, instead, lets assert that if
!target_is_async_p, then the async token should not be marked.

This assertion would have caught my earlier mistake.

There should be no user visible changes with this commit.

gdb: simplify remote_target::is_async_p

This commit simplifies remote_target::is_async_p by removing the
target_async_permitted check.

In previous commits I have added additional assertions around the
target_async_permitted flag into target.c, as a result we should now
be confident that if target_can_async_p returns false, a target will
never have async mode enabled.  Given this, it should not be necessary
to check target_async_permitted in remote_target::is_async_p, if this
flag is false ::is_async_p should return false anyway.  There is an
assert to this effect in target_is_async_p.

There should be no user visible change after this commit.

gdb: add asserts in target.c for target_async_permitted

The target_async_permitted flag allows a user to override whether a
target can act in async mode or not.  In previous commits I have moved
the checking of this flag out of the various ::can_async_p methods and
into the common target.c code.

In this commit I will add some additional assertions into
target_is_async_p and target_async.  The rules these assertions are
checking are:

  1. A target that returns false for target_can_async_p should never
  become "async enabled", and so ::is_async_p should always return
  false.  This is being checked in target_is_async_p.

  2. GDB should never try to enable async mode for a target that
  returns false for target_can_async_p, this is checked in
  target_async.

There are a few places where we call the ::is_async_p method directly,
in these cases we will obviously not pass through the assert in
target_is_async_p, however, there are also plenty of places where we
do call target_is_async_p so if GDB starts to misbehave we should
catch it quickly enough.

There should be no user visible changes after this commit.

gdb: hoist target_async_permitted checks into target.c

This commit moves the target_async_permitted check out of each targets
::can_async_p method and into the target_can_async_p wrapper function.

I've left some asserts in the two ::can_async_p methods that I
changed, which will hopefully catch any direct calls to these methods
that might be added in the future.

There should be no user visible changes after this commit.

gdb: introduce a new overload of target_can_async_p

There are a few places where we call the target_ops::can_async_p
member function directly, instead of using the target_can_async_p
wrapper.

In some of these places this is because we need to ask before the
target has been pushed, and in another location (in target.c) it seems
unnecessary to go through the wrapper when we are already in target.c
code.

However, in the next commit I'd like to hoist some common checks out
of target specific code into target.c.  To achieve this, in this
commit, I introduce a new overload of target_can_async_p which takes a
target_ops pointer, and calls the ::can_async_p method directly.  I
then make use of the new overload where appropriate.

There should be no user visible changes after this commit.

ld/testsuite/ld-elfvsb: correctly test "weak hidden symbol DSO last"

The test must be done with the shared object and not with the object
file which is already being tested above.

ld/
* testsuite/ld-elfvsb/elfvsb.exp: use .so file in "weak hidden
  symbol DSO last"

[gdb/cli] Add "set logging enabled", deprecate "set logging on/off"

Before commit 3b6acaee895 "Update more calls to add_prefix_cmd" we had the
following output for "show logging file":
...
$ gdb -q -batch -ex "set trace-commands on" \
    -ex "set logging off" \
    -ex "show logging file" \
    -ex "set logging on" \
    -ex "show logging file"
+set logging off
+show logging file
Future logs will be written to gdb.txt.
+set logging on
+show logging file
Currently logging to "gdb.txt".
...

After that commit we have instead:
...
+set logging off
+show logging file
The current logfile is "gdb.txt".
+set logging on
+show logging file
The current logfile is "gdb.txt".
...

Before the commit, whether logging is enabled or not can be deduced from the
output of the command.  After the commit, the message is unified and it's no
longer clear whether logging is enabled or not.

Fix this by:
- adding a new command "show logging enabled"
- adding a corresponding new command "set logging enabled on/off"
- making the commands "set logging on/off" deprecated aliases of the
  "set logging enabled on/off" command.

Update the docs and testsuite to use "set logging enabled".  Mention the new
and deprecated commands in NEWS.

Tested on x86_64-linux.

[gdb/cli] Fix typo in logging overwrite help text

Currently we have:
...
$ gdb -q -batch -ex "help set logging overwrite"
Set whether logging overwrites or appends to the log file.
If set, logging overrides the log file.
...

Fix overrides -> overwrites typo.

Automatic date update in version.in

gdb: fix help doc for "set index-cache enabled"

When implementing this command, I put "help doc" as a placeholder for
the help string, and forgot to update it.  Change it for a real help
string.

Change-Id: Id23c2142c5073dc570bd8a706e9ec6fa8c40eb09

Revert (part of) "gdb fix for catch-syscall.exp"

This reverts (par of) commit ab198279120fe7937c0970a8bb881922726678f9.
This commit changed what the test expects when catching the execve
syscall based on the behavior seen on a Linux PowerPC machine.  That is,
we get an "entry" event, but no "return" event.  This is not what we get
on Linux with other architectures, though, and it seems like a
PowerPC-specific bug.

Revert the part of the patch related to this, but not the other hunk.

Change-Id: I4248776e4299f10999487be96d4acd1b33639996

Fix an illegal memory access parsing a corrupt sysroff file.

PR 28564
* sysdump.c (getCHARS): Check for an out of bounds read.

gdb: fix crash when reading ECOFF debug information

In commit:

  commit 633cf2548bcd3dafe297e21a1dd3574240280d48
  Date:   Wed May 9 15:42:28 2018 -0600

      Remove cleanups from mdebugread.c

the following change was made in the function parse_partial_symbols in
mdebugread.c:

  -  fdr_to_pst = XCNEWVEC (struct pst_map, hdr->ifdMax + 1);
  -  old_chain = make_cleanup (xfree, fdr_to_pst);
  +  gdb::def_vector<struct pst_map> fdr_to_pst_holder (hdr->ifdMax + 1);
  +  fdr_to_pst = fdr_to_pst_holder.data ();

The problem with this change is that XCNEWVEC calls xcalloc, which in
turn calls calloc, and calloc zero initializes the allocated memory.
In contrast, the new line gdb::def_vector<struct pst_map> specifically
does not initialize the underlying memory.

This is a problem because, later on in this same function, we
increment the n_globals field within 'struct pst_map' objects stored
in the vector.  The incrementing is now being done from an
uninitialized starting point.

In this commit we switch from using gdb::def_vector to using
std::vector, this alone should be enough to ensure that the fields are
initialized to zero.

However, for extra clarity, I have also added initial values in the
'struct pst_map' to make it crystal clear how the struct will start
up.

This issue was reported on the mailing list here:

  https://sourceware.org/pipermail/gdb-patches/2021-November/183693.html

Co-Authored-By: Lightning <lightningth@gmail.com>

Automatic date update in version.in

configure.ac: Check for the readline.h explicitly

When readline development package is missing make fails with
"configure: error: system readline is not new enough" which
might be confusing. This patch checks for the readline.h explicitly
and makes make to warn about the missing package.

AArch64: Add support for AArch64 EFI (efi-*-aarch64).

This adds support for efi-*-aarch64 by virtue of adding a new PEI target
pei-aarch64-little.  This is not a full target and only exists to support EFI
at this time.

This means that this target does not support relocation processing and is mostly
a container format.  This format has been added to elf based aarch64 targets
such that efi images can be made natively on Linux.

However this target is not valid for use with gas but only with objcopy.

With these changes the resulting file is recognized as an efi image by
third party tools:

>  pecli info hello.efi

Metadata
================================================================================
MD5:            598c32a778b0f0deebe977fef8578c4e
SHA1:           4580121edd5cb4dc40f51b28f171fd15250df84c
SHA256:         3154bd7cf42433d1c957f6bf55a17ad8c57ed41b29df2d485703349fd6ff1d5c
Imphash:
Size:           47561 bytes
Type:           PE32+ executable (EFI application) (stripped to external PDB), for MS Windows
Compile Time:   1970-01-01 00:00:00 (UTC - 0x0       )
Entry point:    0x2000 (section .text)

Sections
================================================================================
Name      RWX  VirtSize   VirtAddr   RawAddr   RawSize   Entropy  md5
.text     R-X  0x5bb0     0x2000     0x400     0x5c00      6.39 551fbc264256a3f387de8a891500ae0d
.reloc    R--  0xc        0x8000     0x6000    0x200       0.02 0c45f6d812d079821c1d54c09ab89e1d
.data     RW-  0x1d88     0x9000     0x6200    0x1e00      4.18 5d1137c09f01289dc62bf754f7290db3
.dynamic  RW-  0xf0       0xb000     0x8000    0x200       0.34 5c94ed3206f05a277e6f04fbf131f131
.rela     R--  0xe58      0xc000     0x8200    0x1000      1.87 8b5c6bc30f3acb7ca7bf2e6789d68519
.dynsym   R--  0x138      0xd000     0x9200    0x200       0.96 bdcf5101da51aadc663ca8859f88138c

Imports
================================================================================

Any magic number is based on the Microsoft PE specification [1].

[1] https://docs.microsoft.com/en-us/windows/win32/debug/pe-format

bfd/ChangeLog:

2021-10-21  Tamar Christina  <tamar.christina@arm.com>

PR binutils/26206
* .gitignore (pe-aarch64igen.c): New.
* Makefile.am (pei-aarch64.lo, pe-aarch64igen.lo, pei-aarch64.c,
pe-aarch64igen.c): Add support.
* Makefile.in: Likewise.
* bfd.c (bfd_get_sign_extend_vma): Add pei-aarch64-little.
* coff-aarch64.c: New file.
* coffcode.h (coff_set_arch_mach_hook, coff_set_flags,
coff_write_object_contents) Add aarch64 (aarch64_pei_vec) support.
* config.bfd: Likewise.
* configure: Likewise.
* configure.ac: Likewise.
* libpei.h (GET_OPTHDR_IMAGE_BASE, PUT_OPTHDR_IMAGE_BASE,
GET_OPTHDR_SIZE_OF_STACK_RESERVE, PUT_OPTHDR_SIZE_OF_STACK_RESERVE,
GET_OPTHDR_SIZE_OF_STACK_COMMIT, PUT_OPTHDR_SIZE_OF_STACK_COMMIT,
GET_OPTHDR_SIZE_OF_HEAP_RESERVE, PUT_OPTHDR_SIZE_OF_HEAP_RESERVE,
GET_OPTHDR_SIZE_OF_HEAP_COMMIT, PUT_OPTHDR_SIZE_OF_HEAP_COMMIT,
GET_PDATA_ENTRY, _bfd_peAArch64_bfd_copy_private_bfd_data_common,
_bfd_peAArch64_bfd_copy_private_section_data,
_bfd_peAArch64_get_symbol_info, _bfd_peAArch64_only_swap_filehdr_out,
_bfd_peAArch64_print_private_bfd_data_common,
_bfd_peAArch64i_final_link_postscript,
_bfd_peAArch64i_only_swap_filehdr_out, _bfd_peAArch64i_swap_aouthdr_in,
_bfd_peAArch64i_swap_aouthdr_out, _bfd_peAArch64i_swap_aux_in,
_bfd_peAArch64i_swap_aux_out, _bfd_peAArch64i_swap_lineno_in,
_bfd_peAArch64i_swap_lineno_out, _bfd_peAArch64i_swap_scnhdr_out,
_bfd_peAArch64i_swap_sym_in, _bfd_peAArch64i_swap_sym_out,
_bfd_peAArch64i_swap_debugdir_in, _bfd_peAArch64i_swap_debugdir_out,
_bfd_peAArch64i_write_codeview_record,
_bfd_peAArch64i_slurp_codeview_record,
_bfd_peAArch64_print_ce_compressed_pdata): New.
* peXXigen.c (_bfd_XXi_swap_aouthdr_in, _bfd_XXi_swap_aouthdr_out,
pe_print_pdata, _bfd_XX_print_private_bfd_data_common,
_bfd_XX_bfd_copy_private_section_data, _bfd_XXi_final_link_postscript):
Support COFF_WITH_peAArch64,
* pei-aarch64.c: New file.
* peicode.h (coff_swap_scnhdr_in, pe_ILF_build_a_bfd, pe_ILF_object_p):
Support COFF_WITH_peAArch64.
(jtab): Add dummy entry that traps.
* targets.c (aarch64_pei_vec): New.

binutils/ChangeLog:

2021-10-21  Tamar Christina  <tamar.christina@arm.com>

PR binutils/26206
* NEWS: Add new support.
* objcopy.c (convert_efi_target): Add efi-*-aarch64 support.
* testsuite/binutils-all/aarch64/pei-aarch64-little.d: New test.
* testsuite/binutils-all/aarch64/pei-aarch64-little.s: New test.

include/ChangeLog:

2021-10-21  Tamar Christina  <tamar.christina@arm.com>

PR binutils/26206
* coff/aarch64.h: New file.
* coff/pe.h (IMAGE_FILE_MACHINE_ARM64): New.

binutils debuginfod test

A missing "return" resulted in this non-ELF fail:
x86_64-w64-mingw32  +FAIL: debuginfod (create separate debug info file)

Also, the debuginfod I have installed does not appear to handle
non-native ELF objects, so only run the test when native.

* testsuite/binutils-all/debuginfod.exp: Don't run test unless
native ELF.

Update bug reporting address

https://sourceware.org/bugzilla/ everywhere

bfd/
* configure.ac (ACX_BUGURL): Set to https://sourceware.org/bugzilla/
* po/Make-in (msgid-bugs-address): Likewise.
* README: Report bugs to the above.
* configure: Regenerate.
binutils/
* po/Make-in (msgid-bugs-address): Update.
gas/
* README: Update bug address.  Delete mention of gcc.
* po/Make-in: Update bug address.
gold/
* po/Make-in: Update bug address.
gprof/
* po/Make-in: Update bug address.
ld/
* po/Make-in: Update bug address.
opcodes/
* po/Make-in: Update bug address.

gdb: more compile fixes for gnu-nat.c

This fixes compile errors like

    ../../gdb-11.1/gdb/gnu-nat.c: In function void add_task_commands():
    ../../gdb-11.1/gdb/gnu-nat.c:3204:17: error: no matching function for call to add_cmd(const char [8], command_class, cmd_list_element*&, char*, cmd_list_element**)
     3204 |         &setlist);
          |                 ^
    In file included from ../../gdb-11.1/gdb/completer.h:21,
                     from ../../gdb-11.1/gdb/symtab.h:36,
                     from ../../gdb-11.1/gdb/infrun.h:21,
                     from ../../gdb-11.1/gdb/target.h:42,
                     from ../../gdb-11.1/gdb/inf-child.h:23,
                     from ../../gdb-11.1/gdb/gnu-nat.h:38,
                     from ../../gdb-11.1/gdb/gnu-nat.c:24:
    ../../gdb-11.1/gdb/command.h:160:33: note: candidate: cmd_list_element* add_cmd(const char*, command_class, void (*)(const char*, int), const char*, cmd_list_element**)
      160 | extern struct cmd_list_element *add_cmd (const char *, enum command_class,
          |                                 ^~~~~~~
    ../../gdb-11.1/gdb/command.h:161:30: note:   no known conversion for argument 3 from cmd_list_element* to void (*)(const char*, int)
      161 |       cmd_const_cfunc_ftype *fun,
          |       ~~~~~~~~~~~~~~~~~~~~~~~^~~
    ../../gdb-11.1/gdb/command.h:167:33: note: candidate: cmd_list_element* add_cmd(const char*, command_class, const char*, cmd_list_element**)
      167 | extern struct cmd_list_element *add_cmd (const char *, enum command_class,
          |                                 ^~~~~~~
    ../../gdb-11.1/gdb/command.h:167:33: note:   candidate expects 4 arguments, 5 provided
    ../../gdb-11.1/gdb/gnu-nat.c:3210:18: error: no matching function for call to add_cmd(const char [8], command_class, cmd_list_element*&, char*, cmd_list_element**)
     3210 |         &showlist);
          |                  ^

Change-Id: Ie9029363d3fb40e34e8f5b1ab503745bc44bfe3f

gnu-nat.c: fix calls to add_info_alias

Some time ago add_info_alias was changed (commit
e0f25bd9717c7973197095523db7c1cdc956cea2).  These calls were not updated
and caused errors on compilation.

Change-Id: I354ae4e8b8926d785abc94ec7142471ffd76d2de

Automatic date update in version.in

gdb: pass more const target_waitstatus by reference

While working on target_waitstatus changes, I noticed a few places where
const target_waitstatus objects could be passed by reference instead of
by pointers.  And in some cases, places where a target_waitstatus could
be passed as const, but was not.  Convert them as much as possible.

Change-Id: Ied552d464be5d5b87489913b95f9720a5ad50c5a

gdb: introduce target_waitkind_str, use it in target_waitstatus::to_string

I would like to print target_waitkind values in debug messages, so I
think that a target_waitkind-to-string function would be useful.  While
at it, use it in target_waitstatus::to_string.  This changes the output
of target_waitstatus::to_string a bit, but I think it is for the better.
The debug messages will show a string matching exactly the
target_waitkind enumerator (minus the TARGET_WAITKIND prefix).

As a convenience, make string_appendf return the same reference to
string it got as a parameter.  This allows doing this:

  return string_appendf (str, "foo");

... keeping the code concise.

Change-Id: I383dffc9c78614e7d0668b1516073905e798eef7

gdb: rename target_waitstatus_to_string to target_waitstatus::to_string

Make target_waitstatus_to_string a "to_string" method of
target_waitstatus, a bit like we have ptid_t::to_string already.  This
will save a bit of typing.

Change-Id: Id261b7a09fa9fa3c738abac131c191a6f9c13905

RISC-V: Removed the redundant NULL pointer check in the riscv_update_subset.

If we always use the .option arch to call the riscv_update_subset, then
it is almost impossible that the input string will be NULL.  Therefore,
just remove the redundant NULL pointer check in the riscv_update_subset.

bfd/
* elfxx-riscv.c (riscv_update_subset): Removed the redundant NULL
pointer check.

RISC-V: Replace .option rvc/norvc with .option arch, +c/-c.

Since the .option rvc/norvc directives are obsolete, replace them with
the new proposed diretives: .option arch, +c/-c.  And also reset the
riscv_opts.rvc flag for the .option arch directives.

gas/
* config/tc-riscv.c (s_riscv_option): Reset the riscv_opts.rvc
for the .option arch directives.
* testsuite/gas/riscv/align-1.s: Replace the obsolete .option
rvc/norvc with .option arch, +c/-c.
* testsuite/gas/riscv/c-add-addi.s: Likewise.
* testsuite/gas/riscv/c-nonzero-imm.s: Likewise.
* testsuite/gas/riscv/c-nonzero-reg.s: Likewise.
* testsuite/gas/riscv/c-zero-imm-64.s: Likewise.
* testsuite/gas/riscv/c-zero-imm.s: Likewise.
* testsuite/gas/riscv/c-zero-reg.s: Likewise.
* testsuite/gas/riscv/ext.s: Likewise.
* testsuite/gas/riscv/mapping-01.s: Likewise.
* testsuite/gas/riscv/mapping-02.s: Likewise.
* testsuite/gas/riscv/mapping-03.s: Likewise.
* testsuite/gas/riscv/mapping-04.s: Likewise.
* testsuite/gas/riscv/no-relax-align-2.s: Likewise.
* testsuite/gas/riscv/shamt-32.s: Likewise.
* testsuite/gas/riscv/shamt-64.s: Likewise.

[gdb/build] Fix x86_64 x32 build

A build error on x86_64 with x32 abi was reported here (
https://sourceware.org/pipermail/gdb/2021-November/049787.html ):
...
gdb/nat/amd64-linux-siginfo.c:280:42: error: \
  'struct compat_x32_siginfo_t::<unnamed union>::<unnamed>' has no member \
  named 'si_addr_bnd'
280 | #define cpt_si_lower _sifields._sigfault.si_addr_bnd._lower
| ^~~~~~~~~~~
gdb/nat/amd64-linux-siginfo.c:337:38: note: in expansion of macro 'cpt_si_lower'
337 | to->cpt_si_lower = from_ptrace.cpt_si_lower;
| ^~~~~~~~~~~~
...

The problem is that code added in commit d3d7d1ba3bb "[gdb/tdep] Handle
si_addr_bnd in compat_siginfo_from_siginfo" doesn't compile on an x86_64 x32
setup, because compat_x32_siginfo_t doesn't have the si_addr_bnd fields.

Fix this conservatively by disabling the code for x32.

Tested on x86_64-linux.

RISC-V: PR28610, Fix ASAN heap-buffer-overflow error in riscv_update_subset.

The architecture parser in riscv_update_subset shouldn't check (or access)
the pointer space which doesn't exist.

bfd/
pr 28610
* elfxx-riscv.c (riscv_update_subset): The architecture parser
shouldn't access the pointer space which doesn't exist.

[gdb/symtab] Support .debug_line with DW_FORM_line_strp

I noticed a new gcc option -gdwarf64 and tried it out (using gcc 11.2.1).

With a test-case hello.c:
...
int
main (void)
{
  printf ("hello\n");
  return 0;
}
...
compiled like this:
...
$ gcc -g -gdwarf64 ~/hello.c
...
I ran into:
...
$ gdb -q -batch a.out
DW_FORM_line_strp pointing outside of .debug_line_str section \
  [in module a.out]
...

Debugging gdb revealed that the string offset is:
...
(gdb) up
    objfile=0x182ab70, str_offset=1378684502312,
    form_name=0xeae9b5 "DW_FORM_line_strp")
    at src/gdb/dwarf2/section.c:208
208         error (_("%s pointing outside of %s section [in module %s]"),
(gdb) p /x str_offset
$1 = 0x14100000128
(gdb)
...
which is read when parsing a .debug_line entry at 0x1e0.

Looking with readelf at the 0x1e0 entry, we have:
...
 The Directory Table (offset 0x202, lines 2, columns 1):
  Entry Name
  0     (indirect line string, offset: 0x128): /data/gdb_versions/devel
  1     (indirect line string, offset: 0x141): /home/vries
...
which in a hexdump looks like:
...
  0x00000200 1f022801 00004101 00000201 1f020f02
...

What happens is the following:
- readelf interprets the DW_FORM_line_strp reference to .debug_line_str as
  a 4 byte value, and sees entries 0x00000128 and 0x00000141.
- gdb instead interprets it as an 8 byte value, and sees as first entry
  0x0000014100000128, which is too big so it bails out.

AFAIU, gdb is wrong.  It assumes DW_FORM_line_strp is 8 bytes on the basis
that the corresponding CU is 64-bit DWARF.  However, the .debug_line
contribution has it's own initial_length field, and encodes there that it's
32-bit DWARF.

Fix this by using the correct offset size for DW_FORM_line_strp references
in .debug_line.

Note: the described test-case does trigger this complaint (both with and
without this patch):
...
$ gdb -q -batch -iex "set complaints 10" a.out
During symbol reading: intermixed 32-bit and 64-bit DWARF sections
...

The reason that the CU has 64-bit dwarf is because -gdwarf64 was passed to
gcc.  The reason that the .debug_line entry has 32-bit dwarf is because that's
what gas generates.  Perhaps this is complaint-worthy, but I don't think it
is wrong.

Tested on x86_64-linux, using native and target board dwarf64.exp.

[gdb/testsuite] Add target board dwarf64.exp

Add a new target board dwarf64.exp, that runs test with -gdwarf64.

Tested on x86_64-linux.

[gdb/testsuite] Support .debug_line v5 in dwarf assembler

The v5 section version for .debug_line has:
- two new fields address_size and segment_selector_size
- a different way to encode the directory and filename tables.

Add support for this in the dwarf assembler.

For now, make the v5 directory and filename tables work with the v4 type of
specification in the test-cases by adding duplicate entries at position 0.

This will need to be properly fixed with an intrusive fix that changes how
directory and filename entries are specified in the test-cases, f.i:
...
set diridx [include_dir "${srcdir}/${subdir}"]
set fileidx [file_name "$srcfile" $diridx]
...

Tested on x86_64-linux.

[gdb/testsuite] Factor out _line_finalize_header

Rather than generate dwarf immediately in procs include_dir and file_name,
postpone generation and store the data in variables.  Then handle the
generation in a new proc _line_finalize_header.

Tested on x86-64-linux.

[gdb/testsuite] Support .debug_line v4 in dwarf assembler

The .debug_line header got a new field in v4:
maximum_operations_per_instruction.

Generate this field in the dwarf assembler, for now hardcoding the value to 1,
meaning non-VLIW.

Tested on x86_64-linux.

[gdb/testsuite] Add test-case gdb.dwarf2/dw2-lines.exp

Add a new test-case gdb.dwarf2/dw2-lines.exp that tests various .debug_line
sections.

Tested on x86_64-linux.

[gdb/testsuite] Speed up MACRO_AT_* calls

Currently, for each MACRO_AT_range or MACRO_AT_func in dwarf assembly the
following is done:
- $srcdir/$subdir/$srcfile is compiled to an executable using
  flags "debug"
- a new gdb instance is started
- the new executable is loaded.

This is inefficient, because the executable is identical within the same
Dwarf::assemble call.

Share the gdb instance in the same Dwarf::assemble invocation, which speeds
up a make check with RUNTESTFLAGS like this to catch all dwarf assembly
test-cases:
...
rtf=$(echo $(cd src/gdb/testsuite; find gdb.* -type f -name "*.exp" \
      | xargs grep -l Dwarf::assemble))
...
from:
...
real    1m39.916s
user    1m25.668s
sys     0m21.377s
...
to:
...
real    1m29.512s
user    1m17.316s
sys     0m19.100s
...

Tested on x86_64-linux.

Automatic date update in version.in

gdb/testsuite: Remove duplicates in gdb.base/catch-signal.exp

When running the testsuite I have the following:

    Running .../gdb/testsuite/gdb.base/catch-signal.exp ...
    DUPLICATE: gdb.base/catch-signal.exp: SIGHUP: continue
    DUPLICATE: gdb.base/catch-signal.exp: SIGHUP: continue
    DUPLICATE: gdb.base/catch-signal.exp: 1: continue
    DUPLICATE: gdb.base/catch-signal.exp: 1: continue
    DUPLICATE: gdb.base/catch-signal.exp: SIGHUP SIGUSR2: continue
    DUPLICATE: gdb.base/catch-signal.exp: SIGHUP SIGUSR2: continue

This patch removes DUPLICATE in gdb.base/catch-signal.exp by explicitly
giving names to the offending 'gdb_test "continue"' statements to make
them distinct.

Tested on x86_64-linux.

sim: v850: fix cpu_option testsuite handling

The v850 testsuite code has been testing the $opt variable, but this
was never actually set anywhere globally or v850-specific.  Instead,
this was a random variable leaking out of the sh testsuite code.  As
far as I can tell, it has always been this way.  That means the code
only ever tested the v850 cpu target (which is the default).

This failure can be easily seen in practice by running the v850 code
in isolation and seeing it crash:
$ runtest v850/allinsns.exp
...
Running target unix
Using /usr/share/dejagnu/baseboards/unix.exp as board description file for target.
Using /usr/share/dejagnu/config/unix.exp as generic interface file for target.
Using ../../../sim/testsuite/config/default.exp as tool-and-target-specific interface file.
WARNING: Assuming target board is the local machine (which is probably wrong).
You may need to set your DEJAGNU environment variable.
Running ../../../sim/testsuite/v850/allinsns.exp ...
ERROR: tcl error sourcing ../../../sim/testsuite/v850/allinsns.exp.
ERROR: tcl error code TCL LOOKUP VARNAME opt
ERROR: can't read "opt": no such variable
    while executing
"switch -regexp -- $opt {

Backing up a bit, the reason for this logic in the first place is
because the common sim testsuite code makes an assumption about the
assembler options with cpu_option -- the option and its value are
always separated by an =.  This is not the case with v850.  So tweak
the core sim logic a bit to support omitting the = so that we can
switch v850 to the standard all_machs setting and avoid opt entirely.

Automatic date update in version.in

Fix intermittent failures on the H8, particularly H8/SX tests.

    The upstream GCC tester has  showed spurious execution failures on the
    H8 target for the H8/SX multilibs. I suspected memory corruption or an
    uninitialized variable early as the same binary would sometimes work and
    sometimes it got the wrong result. Worse yet, the point where the test
    determined it was getting the wrong result would change.

    Because it only happened on the H8/SX variant I was able to zero in on
    the "mova" support and the "short form" of those instructions in particular.

    As the code stands it checks if code->op3.type == 0 to try and identify cases
    where op3 wasn't filled in and thus we've got the short form of the mova
    instruction.

    But for the short-form of those instructions we never set any of the "op3"
    data structure. We get whatever was lying around -- it's usually zero and
     thus things usually work, but if the stale data was nonzero, then we'd
    fail to recognize the instruction as a short-form and fail to set up the
    various fields appropriately.

    I initially initialized the op3.type field to zero, but didn't like that
     because it was inconsistent with how other operands were initialized.
    Bringing consistency meant using -1 as the initializer value and adjusting
    the check for short form mova appropriately.

    I've had this in the upstream GCC tester for perhaps a year at this point
    and haven't seen any of the intermittent failures again.

gdbsupport: fix array-view compilation with c++11 && _GLIBCXX_DEBUG

When building with -std=c++11 and -D_GLIBCXX_DEBUG=1, we get some errors
like:

      CXX    unittests/array-view-selftests.o
    In file included from /home/smarchi/src/binutils-gdb/gdb/utils.h:25,
                     from /home/smarchi/src/binutils-gdb/gdb/defs.h:630,
                     from /home/smarchi/src/binutils-gdb/gdb/unittests/array-view-selftests.c:20:
    /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/array-view.h: In instantiation of constexpr gdb::array_view<T> gdb::array_view<T>::slice(gdb::array_view<T>::size_type, gdb::array_view<T>::size_type) const [with T = unsigned char; gdb::array_view<T>::size_type = long unsigned int:
    /home/smarchi/src/binutils-gdb/gdb/unittests/array-view-selftests.c:532:29:   required from here
    /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/array-view.h:192:3: error: body of constexpr function constexpr gdb::array_view<T> gdb::array_view<T>::slice(gdb::array_view<T>::size_type, gdb::array_view<T>::size_type) const [with T = unsigned char; gdb::array_view<T>::size_type = long unsigned int not a return-statement
      192 |   }
          |   ^

This is because constexpr functions in c++11 can only consist of a
single return statement, so we can't have the gdb_assert in there.  Make
the gdb_assert presence conditional to the __cplusplus version, to
enable it only for c++14 and later.

Change-Id: I2ac33f7b4bd1765ddc3ac8d07445b16ac1f340f0

[gdb/build] Check if libsource-highlight is usable

When building gdb with g++ 4.8.5, I ran into:
...
ld: source-cache.o: in function `source_cache::ensure(symtab*)':
source-cache.c:207: undefined reference to \
  srchilite::SourceHighlight::SourceHighlight(std::string const&)
...

[ I configured gdb without explicit settings related to source-highlight, so
we're excercising the enable_source_highlight=auto scenario. ]

The problem is that:
- the source-highlight library is build with system compiler
  g++ 7.5.0 which uses the new libstdc++ library abi (see
  https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html )
- gdb is build using g++ 4.8.5 which uses the old abi.

[ There's a compatibility macro _GLIBCXX_USE_CXX11_ABI, but that doesn't work
for this case.  Instead, it enables the opposite case where the
source-highlight library is build with g++ 4.8.5 and gdb is build with
g++ 7.5.0. ]

Fix this by checking whether the source-highlight library is usable during
configuration.

In the enable_source_highlight=auto scenario, this allows the build to skip
the unusable library and finish successfully.

In the enable_source_highlight=yes scenario, this allows the build to error
out earlier.

Tested on x86_64-linux.

bfd: remove wrong comment in xcofflink.c

This comment was long time ago associated to the function
"xcoff_build_ldsyms" which have since been replaced by
"xcoff_build_ldsym".

* xcofflink.c: Remove wrong comment.