gdb/testsuite: avoid creating files in gdb/testsuite directory

I spotted that the test gdb.dwarf2/dw2-using-debug-str.exp was
creating an output file called debug_str_section in the root
build/gdb/testsuite directory instead of using the
build/gdb/testsuite/output/gdb.dwarf2/dw2-using-debug-str/ directory.

This appears to be caused by a missing '$' character.  We setup a
variable debug_str_section which contains a path within the output
directory, but then when we build the objcopy command we use
'debug_str_section' without a '$' prefix, as a result, we create the
debug_str_section file.

This commit adds the missing '$', the file is now created in the
output directory.

bfd: fix undefined references to aarch64_pe_le_vec

After commit:

  commit c60b3806799abf1d7f6cf5108a1b0e733a950b13
  Date:   Wed Oct 19 10:57:12 2022 +0200

      aarch64-pe support for LD, GAS and BFD

It appears that bfd/Makefile.in and bfd/configure were not regenerated
correctly.  The differences in the configure file are only whitespace,
but in Makefile.in a critical reference to pe-aarch64.lo was missing.

aarch64-pe support for LD, GAS and BFD

Allows aarch64-pe to be targeted natively, not having to use objcopy to convert it from ELF to PE.
Based on initial work by Jedidiah Thompson

Co-authored-by: Jedidiah Thompson <wej22007@outlook.com>
Co-authored-by: Zac Walker <zac.walker@linaro.org>

Binutils: Adding new testcase for addr2line.

* binutils/testsuite/config/default.exp: Set ADDR2LINE and ADDR2LINEFLAGS.
* binutils/testsuite/binutils-all/addr2line.exp: New file.

[gdb/testsuite] Fix ERROR in gdb.python/py-breakpoint.exp

With test-case gdb.python/py-breakpoint.exp I run into:
...
(gdb) ERROR: tcl error sourcing gdb.python/py-breakpoint.exp.
ERROR: can't read "skip_hw_watchpoint_tests_p": no such variable
    while executing
"if {$skip_hw_watchpoint_tests_p} {
        gdb_test_no_output "set can-use-hw-watchpoints 0" ""
    }"
...

Fix this by adding the missing "global skip_hw_watchpoint_tests_p" in two
procs.

Tested on x86_64-linux.

IBM zSystems: Issue error for *DBL relocs on misaligned symbols

Relocs like PC32DBL require a right shift of the symbol value.  There
is no situation where dropping symbol value bits with the right shift
is a good thing.  Hence we now issue an error to detect such problems.

gdb: check for groups with duplicate names in reggroups:add

In the downstream ROCm GDB port, we would create multiple register
groups with duplicate names.  While it did not really hurt, it certainly
wasn't the intent.  And I don't think it ever makes sense to do so.

To catch these, change the assert in reggroups::add to check for
duplicate names.  It's no longer necessary to check for duplicate
reggroup pointers, because adding the same group twice would be caught
by the duplicate name check.

Change-Id: Id216a58acf91f1b314d3cba2d02de73656f8851d
Approved-By: Tom Tromey <tom@tromey.com>

Automatic date update in version.in

x86: Disable AVX-VNNI when disabling AVX2

Since AVX-VNNI requires AVX2, disable AVX-VNNI when disabling AVX2.

* i386-gen.c (cpu_flag_init): Add CpuAVX_VNNI to
CPU_ANY_AVX2_FLAGS.
* i386-init.h: Regenerate.

Remove dead code from py-finishbreakpoint.c

PR python/16324 points out that comparing a frame id to null_frame_id
can never succeed, and proposes simply removing the dead code.  That
is what this patch does.

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

Update tests to use skip_hw_watchpoint_tests to test for HW watchpoint support.

The hardware watchpoint check has been updated in a couple of recent
patches.  This patch updates the hardware watchpoint test in the remaining
gdb tests.

The issue is the PowerPC processors support hardware watchpoints with the
exception of Power 9. The hardware watchpoint support is disabled on
Power 9.  The test skip_hw_watchpoint_tests must be used to correctly
determine if the PowerPC processor supports hardware watchpoints.

This patch fixes 6 test failures in test gdb.threads/watchpoint-fork.exp.

Test gdb.base/watch-vfork.exp runs with can-use-hw-watchpoints set to
true and false.  When the test is run with can-use-hw-watchpoints set to
true, gdb just falls back to using software watchpoints.  The
patch reduces the number of expected passes by 2 since because it now
only runs once with can-use-hw-watchpoints set to false.

Test gdb.mi/mi-watch.exp runs the test with argument hw and sw.  If the
argument is hw and hardware watchpoints are not supported the test exits.
The number of expected passes is cut in half with the patch as it now only
runs the test using software breakpoints.  Previously the pass to use
hardware watchpoints was not skipped and the test actually ran using
software watchpoints.

The following tests run the same with and without the patch.  The tests
are supposed to execute the gdb command "set can-use-hw-watchpoints 0" if
the processor does not support hardware bwatchpoints.  However the command
was not being executed and gdb was falling back to using software
watchpoints since the Power 9 watchpoint resource check fails.  With the
patch, the tests now execute the command and the test runs using software
watchpoints as it did previously.  The tests are:

gdb.base/commands.exp
gdb.base/cond-eval-mode.exp
gdb.base/display.exp
gdb.base/gdb11531.exp
gdb.base/recurse.exp
gdb.base/value-double-free.exp
gdb.base/watch-bitfields.exp
gdb.base/watch-cond-infcall.exp
gdb.base/watch-cond.exp
gdb.base/watchpoint-solib.exp
gdb.base/watchpoints.exp

The following two tests are not supported on the Power 9 system used to
test the changes.  The patch does not change the tests results for these
tests:

gdb.python/py-breakpoint.exp
gdb.mi/mi-watch-nonstop.exp

[gdb/testsuite] Handle header files with local-remote-host.exp

With test-case gdb.base/included.exp and host board local-remote-host.exp with
tentative fix for PR29697 I run into:
...
included.c:18:10: fatal error: included.h: No such file or directory
 #include "included.h"
          ^~~~~~~~~~~~
compilation terminated.
...

Fix this by adding the missing gdb_remote_download calls.

Likewise in a few other test-cases.

Tested on x86_64-linux.

[gdb/testsuite] Fix gdb.server/no-thread-db.exp with local-remote-host.exp

With test-case gdb.server/no-thread-db.exp and host board local-remote-host.exp
with a tentative fix for PR29697 I run into:
...
(gdb) print foo^M
Cannot find thread-local storage for Thread 29613.29613, executable file \
  $HOME/no-thread-db:^M
Remote target failed to process qGetTLSAddr request^M
(gdb) FAIL: gdb.server/no-thread-db.exp: print foo
...

The regexp in the test-case expects the full $binfile pathname, but we have
instead $HOME/no-thread-db.

Fix this by making the regexp less strict.

Tested on x86_64-linux.

[gdb/testsuite] Fix gdb.base/return-nodebug.exp with local-remote-host.exp

With host board local-remote-host.exp and test-case
gdb.base/return-nodebug.exp, I run into:
...
Executing on host: gcc -fno-stack-protector -fdiagnostics-color=never \
  -DTYPE=signed\ char -c -g  -o return-nodebug-signed-char0.o  \
  /home/vries/gdb_versions/devel/src/gdb/testsuite/gdb.base/return-nodebug.c \
  (timeout = 300)
builtin_spawn [open ...]^M
gcc: error: char: No such file or directory
...

Avoid the quoting problem by not using spaces in the define.

Tested on x86_64-linux.

[gdb/testsuite] Fix gdb.server/file-transfer.exp with local-remote-host.exp

When running test-case gdb.server/file-transfer.exp with host
board local-remote-host.exp, I get:
...
Executing on host: cmp -s $outputs/gdb.server/file-transfer/file-transfer \
  down-server    (timeout = 300)
builtin_spawn [open ...]^M
XYZ2ZYX
FAIL: gdb.server/file-transfer.exp: compare intermediate binary file
...

The remote host and remote target cases are handled here together here in proc
test_file_transfer:
...
    if {![is_remote host] && ![is_remote target]} {
       set up_server [standard_output_file $up_server]
       set down_server [standard_output_file $down_server]
    }
...

Fix this by handling them separately.

Tested on x86_64-linux.

[gdb/testsuite] Update boards/README

Update gdb/testsuite/boards/README to reflect recent commit c4c8c27263d
("[gdb/testsuite] Fix host board local-remote-host-notty.exp timeouts"), which
means the board now uses a pseudo-tty, but with editing disabled.

gdb, solib-svr4: support namespaces in DSO iteration

When looking up names, GDB needs to stay within one linker namespace to
find the correct instance in case the same name is provided in more than
one namespace.

Modify svr4_iterate_over_objfiles_in_search_order() to stay within the
namespace of the current_objfile argument.  If no current_objfile is
provided (i.e. it is nullptr), iterate over objfiles in the initial
namespace.

For objfiles that do not have a corresponding so_list to provide the
namespace, assume that the objfile was loaded into the initial namespace.
This would cover the main executable objfile (which is indeed loaded into
the initial namespace) as well as manually added symbol files.

Expected fails:

  - gdb.base/non-lazy-array-index.exp: the expression parser may lookup
    global symbols, which may result in xfers to read auxv for determining
    the debug base as part of svr4_iterate_over_objfiles_in_search_order().

  - gdb.server/non-lazy-array-index.exp: symbol lookup may access the
    target to read AUXV in order to determine the debug base for SVR4
    linker namespaces.

Known issues:

  - get_symbol_address() and get_msymbol_address() search objfiles for a
    'better' match.  This was introduced by

        4b610737f02 Handle copy relocations

    to handle copy relocations but it now causes a wrong address to be
    read after symbol lookup actually cound the correct symbol.  This can
    be seen, for example, with gdb.base/dlmopen.exp when compiled with
    clang.

  - gnu ifuncs are only looked up in the initial namespace.

  - lookup_minimal_symbol() and lookup_minimal_symbol_text() directly
    iterate over objfiles and are not aware of linker namespaces.

gdb: update gnu ifunc resolve

Update elf_gnu_ifunc_resolve_by_cache() and elf_gnu_ifunc_resolve_by_got()
to use gdbarch_iterate_over_objfiles_in_search_order() in order to
restrict the objfile traversal to the initial namespace.

In order to extend this to other namespaces, we'd need to provide context,
e.g. via an objfile inside that namespace.

gdb, symtab: inline find_quick_global_symbol_language

There is only one use of find_quick_global_symbol_language that calls it
for the special symbol "main".

Inline the function as it is probably not correct in the general case
where we may have multiple instances of global symbols with the same name
but different languages in different libraries in different linker
namespaces.

Further, change the objfiles iteration into a call to
gdbarch_iterate_over_objfiles_in_search_order, which would only search the
initial linker namespace, where we expect "main" to be located.

gdb, hppa: remove unused hppa_lookup_stub_minimal_symbol

I stumbled over this while reviewing all objfiles traversals with regards
to impact of linker namespaces.

Recursive grep only finds two occurrences of hppa_lookup_stub_minimal_symbol:
  - the declaration in hppa-tdep.h.
  - the definition in hppa-tdep.c.

There appear to be no calls to this function.  Remove it.

gdb, cp: update add_symbol_overload_list_qualified

Iterate over objfiles in search order using the objfile of the selected
block as current_objfile so the iteration can stay inside the block's
linker namespace.

fixup! gdb, ada: update ada_lookup_simple_minsym

remove get_selected_block()

gdb, ada: update ada_lookup_simple_minsym

Iterate over objfile in search order using the objfile of the context
block as current_objfile so the iteration can stay inside the block's
linker namespace.

gdb, ada: collect standard exceptions in all objfiles

When searching for standard exceptions for Ada, we lookup the minimal
symbol of each exception.  With linker namespaces there can be multiple
instances in different namespaces.  Collect them all.

gdb, python: use gdbarch_iterate_over_objfiles_in_search_order

The implementation of gdb.lookup_objfile() iterates over all objfiles and
compares their name or build id to the user-provided search string.

This will cause problems when supporting linker namespaces as the first
objfile in any namespace will be found.  Instead, use
gdbarch_iterate_over_objfiles_in_search_order to only consider the
namespace of gdb.current_objfile() for the search, which defaults to the
initial namespace when gdb.current_objfile() is None.

gdb, compile: unlink objfile stored in module

When cleaning up after a compile command, we iterate over all objfiles and
unlink the first objfile with the same name as the one we compiled.

Since we already store a pointer to that objfile in the module and use it
to get the name we're comparing against, there's no reason to iterate, at
all.  We can simply use that objfile.

This further avoids potential issues when an objfile with the same name is
loaded into a different linker namespace.

gdb, gdbserver: extend RSP to support namespaces

Introduce a new qXfer:libraries-svr4:read annex key/value pair

    lmid=<namespace identifier>

to be used together with start and prev to provide the namespace of start
and prev to gdbserver.

Unknown key/value pairs are ignored by gdbserver so no new supports check
is needed.

Introduce a new library-list-svr4 library attribute

    lmid

to provide the namespace of a library entry to GDB.

This implementation uses the address of a namespace's r_debug object as
namespace identifier.

This should have incremented the minor version but since unknown XML
attributes are ignored, anyway, and since changing the version results in
a warning from GDB, the version is left at 1.0.

gdbserver: move main_lm handling into caller

When listing SVR4 shared libraries, special care has to be taken about the
first library in the default namespace as that refers to the main
executable.  The load map address of this main executable is provided in
an attribute of the library-list-svr4 element.

Move that code from where we enumerate libraries inside a single namespace
to where we generate the rest of the library-list-svr4 element.  This
allows us to complete the library-list-svr4 element inside one function.

There should be no functional change.

gdb, gdbserver: support dlmopen()

In glibc, the r_debug structure contains (amongst others) the following
fields:

  int r_version:
    Version number for this protocol.  It should be greater than 0.

If r_version is 2, struct r_debug is extended to struct r_debug_extended
with one additional field:

  struct r_debug_extended *r_next;
    Link to the next r_debug_extended structure.  Each r_debug_extended
    structure represents a different namespace.  The first r_debug_extended
    structure is for the default namespace.

1. Change solib_svr4_r_map argument to take the debug base.
2. Add solib_svr4_r_next to find the link map in the next namespace from
the r_next field.
3. Update svr4_current_sos_direct to get the link map in the next namespace
from the r_next field.
4. Don't check shared libraries in other namespaces when updating shared
libraries in a new namespace.
5. Update svr4_same to check the load offset in addition to the name
6. Update svr4_default_sos to also set l_addr_inferior
7. Change the flat solib_list into a per-namespace list using the
namespace's r_debug address to identify the namespace.

Add gdb.base/dlmopen.exp to test this.

To remain backwards compatible with older gdbserver, we reserve the
namespace zero for a flat list of solibs from all namespaces.  Subsequent
patches will extend RSP to allow listing libraries grouped by namespace.

This fixes PR 11839.

Co-authored-by: Lu, Hongjiu <hongjiu.lu@intel.com>

gdb, solib-svr4: remove locate_base()

Whenever we call locate_base(), we clear info->debug_base directly before
the call.  Thus, we never cache the base location as locate_base() had
intended.

Move the svr4_have_link_map_offsets() check into elf_locate_base(), inline
locate_base() at all call sites, and remove it.

gdb, testsuite: extend gdb_test_multiple checks

Check for

    warning: Corrupted shared library list

and for

    Invalid cast.
    warning: Probes-based dynamic linker interface failed.
    Reverting to original interface.

in gdb_test_multiple.

x86: generalize gas documentation for disabling of ISA extensions

As of commit ae89daecb132 ("x86: generalize disabling of sub-
architectures") there's no arbitrary subset of ISAs which can also be
disabled. This should have been reflected in documentation right away.
Since I failed to do so, correct this now.

x86: correct CPU_AMX_{BF16,INT8}_FLAGS

AMX-TILE is a prereq to these, as already correctly expressed by
CPU_ANY_AMX_TILE_FLAGS. Express the dependency also in the reverse
("positive") direction.

Automatic date update in version.in

kfail an Ada test for GCC < 12

I noticed one particular Ada test was failing on Fedora 34, but works
when I switch to GCC 12.  This patch arranges to kfail the test when
an older compiler is used.

I tested this with GCC 11, 12, and 13.  I'm going to check it in.

Remove a nullptr check in DWARF scanner

In scan_attributes, The DWARF scanner checks whether maybe_defer is
nullptr, but this can never happen.  This patch removes the check.

gdbarch-components.py: Remove spurious space from "frame_info_ptr " params

If you run gdbarch.py today, you'll get local modifications compared
to what's in the tree, like:

 --- c/gdb/gdbarch-gen.h
 +++ w/gdb/gdbarch-gen.h
 @@ -315,8 +315,8 @@ extern void set_gdbarch_register_type (struct gdbarch *gdbarch, gdbarch_register
     should match the address at which the breakpoint was set in the dummy
     frame. */

 -typedef struct frame_id (gdbarch_dummy_id_ftype) (struct gdbarch *gdbarch, frame_info_ptr this_frame);
 -extern struct frame_id gdbarch_dummy_id (struct gdbarch *gdbarch, frame_info_ptr this_frame);
 +typedef struct frame_id (gdbarch_dummy_id_ftype) (struct gdbarch *gdbarch, frame_info_ptr  this_frame);
 +extern struct frame_id gdbarch_dummy_id (struct gdbarch *gdbarch, frame_info_ptr  this_frame);
  extern void set_gdbarch_dummy_id (struct gdbarch *gdbarch, gdbarch_dummy_id_ftype *dummy_id);

etc.

The extra space comes from the "frame_info_ptr " param that appears in
a number of gdbarch methods in gdbarch-components.py.  With the extra
space removed, running ./gdbarch.py generates the exact code that's in
the tree already.

Change-Id: If7d20b8c6b2fd9ff466142a01bd2611c9ef9f53e

Change .gdb_index de-duplication implementation

While investigating PR symtab/29179, I found that one Ada test failed
because, although a certain symbol was present in the index, with the
new DWARF reader it pointed to a different CU than was chosen by
earlier versions of gdb.

This patch changes how symbol de-duplication is done, deferring the
process until the entire symbol table has been constructed.  This way,
it's possible to always choose the lower-numbered CU among duplicates,
which is how gdb (implicitly) previously worked.

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

Improve Ada support in .gdb_index

The cooked index work changed how .gdb_index is constructed, and in
the process broke .gdb_index support.  This is PR symtab/29179.

This patch partially fixes the problem.  It arranges for Ada names to
be encoded in the form expected by the index code.  In particular,
linkage names for Ada are emitted, including the "main" name; names
are Ada-encoded; and names are no longer case-folded, something that
prevented operator names from round-tripping correctly.

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

Don't add type linkage names to cooked index

The compiler will sometimes emit a linkage name for a type, like:

    <1d3>   DW_AT_linkage_name: (indirect string, offset: 0x106f): 11__mbstate_t

These names aren't very useful, and this patch changes the DWARF
reader so that they are ignored by the cooked index.

Fix regression in c-linkage-name.exp with gdb index

c-linkage-name.exp started failing with the gdb-index target board due
to an earlier patch.  The problem here is that some linkage names must
be in the index -- but, based on inspection, not C++ linkage names.
This patch updates the code to exclude only these.

Fix null pointer representations

Since "NULL" and "0" are used to represent invalid address in function
"gdbarch_find_by_info" in "binutils-gdb/gdb/arch-utils.c", I modified
them to "nullptr".

gdb: silence unused-but-set-variable warning about yynerrs in cp-name-parser.y

When building with clang 15 on Ubuntu 20.04, I get:

      CXX    cp-name-parser.o
    cp-name-parser.c.tmp:1777:9: error: variable 'cpnameyynerrs' set but not used [-Werror,-Wunused-but-set-variable]
        int yynerrs;
            ^
    /home/smarchi/src/binutils-gdb/gdb/yy-remap.h:58:18: note: expanded from macro 'yynerrs'
    #define yynerrs         GDB_YY_REMAP (yynerrs)
                            ^
    /home/smarchi/src/binutils-gdb/gdb/yy-remap.h:40:29: note: expanded from macro 'GDB_YY_REMAP'
    #define GDB_YY_REMAP(YYSYM) GDB_YY_REMAP_1 (GDB_YY_REMAP_PREFIX, YYSYM)
                                ^
    /home/smarchi/src/binutils-gdb/gdb/yy-remap.h:39:39: note: expanded from macro 'GDB_YY_REMAP_1'
    #define GDB_YY_REMAP_1(PREFIX, YYSYM) GDB_YY_REMAP_2 (PREFIX, YYSYM)
                                          ^
    /home/smarchi/src/binutils-gdb/gdb/yy-remap.h:38:39: note: expanded from macro 'GDB_YY_REMAP_2'
    #define GDB_YY_REMAP_2(PREFIX, YYSYM) PREFIX ## YYSYM
                                          ^
    <scratch space>:45:1: note: expanded from here
    cpnameyynerrs
    ^

This is because clang 15 warns for something like this:

    int n;
    n = 0;
    ++n;

whereas previous versions do not.

yynerrs is defined in yyparse and is there for actions to use.  Since
the actions in cp-name-parser.y don't use it, we get a warning.  We see
this problem on this particular .y file because it uses `%pure-parser`
[1], which makes yynerrs a local rather than a global.

I initially fixed this by using
DIAGNOSTIC_IGNORE_UNUSED_BUT_SET_VARIABLE (like in commit f7aa1a5acc5
("gold: Suppress "unused" variable warning on Clang")), but then I
realized we could suppress the warning in a more fine-grained way using
this in a rule:

    (void) yynerrs;

[1] https://www.gnu.org/software/bison/manual/html_node/Error-Reporting-Function.html

Change-Id: I6cae7a4207c19fe1b719e2ac19be69122ebe3af1

ld/testsuite: consistently add board_ldflags when linking with GCC

Currently, the functions checking if the compiler is available or if a
feature is available add both board_cflags and board_ldflags.
However, functions running the tests only retrieve board_cflags. This
can lead to unexpected errors when mandaratory flags are defined in
board_ldflags and not board_cflags.

ld/ChangeLog:

* testsuite/ld-unique/unique.exp: Add board_ldflags when
linking with GCC.
* testsuite/lib/ld-lib.exp: Likewise.

Allow explicit size specifier for predicate operand of {sq, uq, }{incp, decp}

Omitting predicate size specifier in vector form of {sq, uq, }{decp, incp} is deprecated and will be prohibited in a future release of the aarch64,
see https://developer.arm.com/documentation/ddi0602/2021-09/SVE-Instructions/DECP--vector---Decrement-vector-by-count-of-true-predicate-elements-.

This allows explicit size specifier, e.g. `decp z0.h, p0.h`, for predicate operand of these SVE instructions.
The existing behaviour of not requiring the specifier is preserved.
And the disasembly is with the specifier with this patch.

The GAS tests passed under our local tests.

opcodes/
* aarch64-asm.c: Modify `sve_size_hsd` encoding.
* aarch64-tbl.h (aarch64_opcode_table): Add QUALS's type OP_SVE_Vv_HSD
for decp, incp, sqdecp, sqincp, uqdecp and uqincp.

gas/
* testsuite/gas/aarch64/sve-movprfx_23.s: Update movprfx_23 testcase's
test_sametwo macro, where take the predicate size specifier.
* testsuite/gas/aarch64/sve-movprfx_23.d: Update movprfx_23 testcase's
expected disassembly.
* testsuite/gas/aarch64/sve-movprfx_23.l: Update movprfx_23 testcase's
expected assembler messages.
* testsuite/gas/aarch64/sve.s: Add sve testcase's instructions for
decp, incp, sqdecp, sqincp, uqdecp and uqincp, which take the
predicate size specifier.
* testsuite/gas/aarch64/sve.d: Update sve testcase's expected
disassembly.

Signed-off-by: CaiJingtao <caijingtao@huawei.com>

aarch64: Tweak handling of F_STRICT

Current F_STRICT qualifier checking is enforced after the fact
rather than as part of the match.  This makes it impossible to
have, e.g.:

   QLF2(S_D, S_D)
   QLF2(S_D, NIL)

in the same list.

opcodes/
* aarch64-opc.c (aarch64_find_best_match): Handle F_STRICT here
rather than...
(match_operands_qualifier): ...here.

x86: properly decode EVEX.W for AVX512_4{FMAPS,VNNIW} insns

These require EVEX.W=0. Use %XS to facilitate the checking, even if for
the AVX512_4VNNIW ones this is kind of an abuse (as 's' there stands for
"signed", not "single").

While there also correct the 3rd operand for the AVX512_4VNNIW entries:
Only the memory form is allowed (just like for AVX512_4FMAPS, where the
correct type is already in use).

x86: fold AVX512-VNNI disassembler entries with AVX-VNNI ones

Make %XV also print the separating blank in the VEX case, while making
it do nothing for EVEX-encoded insns. This way the AVX-VNNI entries
can be re-used for AVX512-VNNI, at the same time fixing the lack of
EVEX.W decoding.

For the AVX-VNNI ones further make sure only VEX.66 forms are actually
decoded.

Automatic date update in version.in

More uses of checked_static_cast

This patch changes a few more uses of static_cast to use
checked_static_cast.  In this patch, cast-to-references are converted
by moving the dereference outside of the cast, as checked_static_cast
only handles pointers.

Use checked_static_cast in more places

I looked through all the uses of static_cast<... *> in gdb and
converted many of them to checked_static_cast.

I couldn't test a few of these changes.

PowerPC se_rfmci and VLE, SPE2 and LSP insns with -many

I noticed recently that se_rfmci, a VLE mode instruction, was being
accepted by non-VLE cpus, and also that se_rfmci by itself in a
section did not cause SHF_PPC_VLE to be set.  ie. both testcases added
by this patch fail without the changes to tc-ppc.c here.

Also, VLE, SPE2 and LSP insns were not accepted by the assembler with
-many nor were SPE2 and LSP being disassembled with -Many.

gas/
* config/tc-ppc.c (ppc_setup_opcodes): Wrap long lines.  Add
vle_opcodes when PPC_OPCODE_VLE or PPC_OPCODE_ANY.  Simplify
disassembler index segment checks.  Add LSP and SPE2 opcodes
when PPC_OPCODE_ANY too.
(md_assemble): Correct logic adding PPC_APUINFO_VLE and
SHF_PPC_VLE.
* testsuite/gas/ppc/se_rfmci.s
* testsuite/gas/ppc/se_rfmci.d,
* testsuite/gas/ppc/se_rfmci_bad.d: New tests.
* testsuite/gas/ppc/ppc.exp: Run them.
opcodes/
* ppc-dis.c (print_insn_powerpc): Disassemble SPE2 and LSP insn
when -Many.
* ppc-opc.c (vle_opcodes <se_rfmci>): Comment.

zlib-gabi to zstd woes

So we had a zlib-gabi .debug_info section that increased in size with
zstd, so much so that it was better to leave the section
uncompressed.  Things went horribly wrong when the section was read
again later.  The section was read again off disk using the
uncompressed size.  So you get the zlib section again with some
garbage at the end.  Fix that particular problem by setting the
section flag SEC_IN_MEMORY.  Any future read will get sec->contents.

Also, if the section is to be left uncompressed, the input
SHF_COMPRESSED flag needs to be reset otherwise objcopy will copy it
to output.

Finally, bfd_convert_section_contents needed a small update to handle
zstd compressed sections, and I've deleted bfd_cache_section_contents.

* bfd.c (bfd_convert_section_contents): Handle zstd.
* compress.c (bfd_compress_section_contents): When section
contents are uncompressed set SEC_IN_MEMORY flag,
compress_status to COMRESS_SECTION_NONE, and clear
SHF_COMPRESSED.  Set SEC_IN_MEMORY for compressed contents.
(bfd_get_full_section_contents): Don't check section size
against file size when SEC_IN_MEMORY.
(bfd_cache_section_contents): Delete function.
* elf32-arm.c (elf32_arm_get_synthetic_symtab): Expand
bfd_cache_section_contents here.
* bfd-in2.h: Regenerate.

Automatic date update in version.in

gdb/arm: Don't rely on loop detection to stop unwinding

Setting SP of the next frame to the same address as the current frame
is an ugly way to stop the unwinding.  A cleaner way is to rely on
the frame_unwind_stop_reason function to return UNWIND_OUTERMOST.

Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>

Automatic date update in version.in

[gdb/testsuite] Add boards/README

Add a file gdb/testsuite/boards/README, to make it easier to get a high-level
overview of the various boards.

[gdb/contrib] Handle STRIP_ARGS_{STRIP,KEEP}_DEBUG in cc-with-tweaks.sh

Handle new environment variable STRIP_ARGS_STRIP_DEBUG, defaulting to
--strip-debug in gdb/contrib/cc-with-tweaks.sh, such that we can easily
reproduce the PR29277 assert using:
...
$ export STRIP_ARGS_STRIP_DEBUG=--strip-all
$ make check RUNTESTFLAGS="gdb.base/jit-reader.exp \
    --target_board cc-with-gnu-debuglink"
...

For completeness sake and to avoid confusion about which of the two used strip
invocations the passed args apply to, likewise add STRIP_ARGS_KEEP_DEBUG,
defaulting to --only-keep-debug.

Script checked with shellcheck, no new warnings added.

Tested on x86_64-linux.

[gdb] Fix heap-buffer-overflow in find_program_interpreter

With the test-case included in this patch, we run into:
...
(gdb) target remote localhost:2347^M
`target:twice-connect' has disappeared; keeping its symbols.^M
Remote debugging using localhost:2347^M
warning: Unable to find dynamic linker breakpoint function.^M
GDB will be unable to debug shared library initializers^M
and track explicitly loaded dynamic code.^M
Reading /usr/lib/debug/.build-id/$hex/$hex.debug from remote target...^M
0x00007ffff7dd4550 in ?? ()^M
(gdb) PASS: gdb.server/twice-connect.exp: session=second: gdbserver started
FAIL: gdb.server/twice-connect.exp: found interpreter
...

The problem originates in find_program_interpreter, where
bfd_get_section_contents is called to read .interp, but fails.  The function
returns false but the result is ignored, so find_program_interpreter returns
some random string.

Fix this by checking the result of the call to bfd_get_section_contents.

Tested on x86_64-linux.

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

[gdb/testsuite] Fix gdb.server/unittest.exp with host board local-remote-host.exp

With test-case gdb.server/unittest.exp and host board local-remote-host.exp I
run into:
...
builtin_spawn build/gdbserver/gdbserver --selftest^M
ERROR: : spawn id exp7 not open
    while executing
"expect {
-i exp7 -timeout 10
    -i $server_spawn_id
    -re "Ran ($decimal) unit tests, 0 failed" {
        set num_ran $expect_out(1,string)
        gdb_assert "..."
    ("uplevel" body line 1)
    invoked from within
"uplevel $body" NONE : spawn id exp7 not open
UNRESOLVED: gdb.server/unittest.exp: unit tests
...

The problem is (as fixed for avr in commit df5b8876083 ("gdb/testsuite: better
handle failures in simavr board, reap simavr process")), that gdb_expect through
remote_expect adds a "-i <gdb spawn id> -timeout 10", which is the one causing
the error.

As in aforementioned commit, fix this by using expect instead.

Tested on x86_64-linux.

[gdb/testsuite] Fix host board local-remote-host-notty.exp timeouts

With test-case gdb.server/stop-reply-no-thread-multi.exp and host board
local-remote-host-notty.exp we occasionally run into a silent out, due to
getting:
...
(gdb) kill^M
(gdb) The program is not being run.^M
...
instead of the expected:
...
(gdb) kill^M
The program is not being run.^M
(gdb)
...

Likewise, we occasionally run into a nonsilent timeout:
...
(gdb) disconnect^M
(gdb) You can't do that when your target is `exec'^M
FAIL: gdb.server/stop-reply-no-thread.exp: to_disable=Tthread: t_nonstop=on: \
  disconnect (timeout)
...

Typically, this results in the test-case taking more than two minutes to run.

The problem can be reproduced using just:
...
$ ssh -l $USER 127.0.0.1 gdb -q -ex kill
...

Note that ssh by default uses -T which disables pseudo-tty allocation (as
opposed to -t which forces pseudo-tty allocation):
...
$ ssh -l $USER 127.0.0.1 -T tty
not a tty
$ ssh -l $USER 127.0.0.1 -t tty
/dev/pts/5
Connection to 127.0.0.1 closed.
...
and according to https://stackoverflow.com/a/63241102 the behaviour we're
seeing is specific to using '-T'.

The related host board local-remote-host.exp does use '-t', and the only
difference between the two boards mentioned is whether editing is on or off.

Fix this by:
- moving the content of local-remote-host-notty.exp into
  local-remote-host.exp
- consequently, extending the copyright years in local-remote-host.exp
- including local-remote-host.exp in local-remote-host-notty.exp
  (making local-remote-host-notty.exp use '-t')
- adding -iex "set editing off" to GDBFLAGS in local-remote-host-notty.exp

This results in the test-case taking just 6 seconds to run.

Tested on x86_64-linux.

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

[gdb/testsuite] Disable styling in host board local-remote-host.exp

With test-case gdb.server/stop-reply-no-thread.exp and host board
local-remote-host.exp, I run into:
...
Breakpoint 1, ^[[33mmain^[[m () at ^[[32mstop-reply-no-thread.c^[[m:21^M
21        ^[[01;34mreturn^[[m ^[[35m0^[[m^[[31m;^[[m^M
(gdb) FAIL: gdb.server/stop-reply-no-thread.exp: to_disable=: t_nonstop=off: \
  continue to main
...

The problem is that styling is enabled, and that is causing a regexp mismatch.

With native, styling is disabled in default_gdb_init by doing
'setenv TERM "dumb"', but that only has effect because the build (where we
execute runtest, and consequently the setenv) and the host (where we execute
gdb) are the same.  For this host board however, gdb executes on a remote
host, and the setenv has no effect.

We could try to make some generic way to set TERM on the host, but for the
purposes of this test-case it seems sufficient to just add:
...
set GDBFLAGS "${GDBFLAGS} -iex \"set style enabled off\""
...
so let's go with that for now.

Tested on x86_64-linux.

Use scoped_value_mark in more places

I looked at all the spots using value_mark, and converted all the
straightforward ones to use scoped_value_mark instead.

Regression tested on x86-64 Fedora 34.

gdb/arm: Stop unwinding on error, but do not assert

When it's impossible to read the FPCCR and XPSR, the unwinding is
unpredictable as the it's not possible to determine the correct
frame size or padding.
The only sane thing to do in this condition is to stop the unwinding.

Example session without this patch:

  (gdb) bt
  #0  SVC_Handler () at .../GPIO/GPIO_EXTI/Src/stm32f4xx_it.c:112
  .../gdb/arm-tdep.c:3594: internal-error: arm_m_exception_cache: Assertion `safe_read_memory_unsigned_integer (FPCCR, ARM_INT_REGISTER_SIZE, byte_order, &fpccr)' failed.
  A problem internal to GDB has been detected,
  further debugging may prove unreliable.
  ----- Backtrace -----
  0x5583bfb2a157 gdb_internal_backtrace_1
  ...
  ---------------------

  This is a bug, please report it.  For instructions, see:
  <https://www.gnu.org/software/gdb/bugs/>.

  Aborted (core dumped)

Example session with this patch:

  (gdb) bt
  #0  SVC_Handler () at .../GPIO/GPIO_EXTI/Src/stm32f4xx_it.c:112
  warning: Could not fetch required FPCCR content.  Further unwind is impossible.
  #1  <signal handler called>
  (gdb)

Reviewed-by: Pedro Alves <pedro@palves.net>
Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>

PowerPC SPE disassembly and tests

Where sub and subf forms of an instruction exist we generally
disassemble to the extended insn sub form rather than the underlying
machine subf instruction.  Do so for SPE evsubw and evsubiw too.

spe_ambiguous.d always was a bit too optimistic.  There is no sensible
way to disassemble identical bytes back to different and original
source.  Instead change the test to check -Mraw results.

gas/
* testsuite/gas/ppc/ppc.exp: Run spe_ambiguous test.
* testsuite/gas/ppc/spe.d: Expect evsubw and evsubiw rather than
evsubfw and evsubifw.
* testsuite/gas/ppc/spe_ambiguous.s: Test evnor form equivalent
to evnot.
* testsuite/gas/ppc/spe_ambiguous.d: Test Mraw.
opcodes/
* ppc-opc.c (powerpc_opcodes): Move evsubw before evsubfw and
evsubiw before evsubifw and mark EXT.

e200 LSP support

It has bothered me for a long time that we have disabled LSP (and SPE)
tests.  Also the LSP test comment indicating there is something wrong
with get_powerpc_dialect.  I don't think there is.  Decoding of a VLE
instruction depends on whether the processor is in VLE mode (some
processors support both VLE and standard PPC) which we flag per
section with SHF_PPC_VLE for decoding when disassembling.

Background: Some versions of powerpc e200 have "Lightweight Signal
Processing" support, examples being e200z215 and e200z425.  As far as
I can tell, LSP and SPE are mutually exclusive.  This seems to be
borne out by insn encoding, for example LSP "zvaddih" and SPE "evaddw"
have the same encoding.  So none of the processor descriptions in
ppc_opts ought to have both PPC_OPCODE_LSP and PPC_OPCODE_SPE/2, if we
want disassembly to work.  I also could not find anything to suggest
that the LSP insns are enabled only in VLE mode, which means the LSP
insns should not be in vle_opcodes.

Fix all this by moving the LSP insns to their own table, and add a new
e200z2 cpu entry with LSP support, removing LSP from -me200z4 and from
-mvle.  (Yes, I know, as I said above some of the e200z4 processors
have LSP.  Others have SPE.  It's hard to choose good options.  Think
of z2 as meaning earlier, z4 as later.)  Also add -mlsp to allow
adding the LSP insn set.

include/
* opcode/ppc.h (lsp_opcodes, lsp_num_opcodes): Declare.
(LSP_OP_TO_SEG): Define.
binutils/
* doc/binutils.texi: Update ppc docs.
gas/
* config/tc-ppc.c (ppc_setup_opcodes): Add lsp opcodes to ppc_hash.
* doc/c-ppc.texi: Document e200 and lsp.
* testsuite/gas/ppc/lsp-checks.d: Assemble with -me200z2.
* testsuite/gas/ppc/lsp.d: Likewise, disassembly too.
* testsuite/gas/ppc/ppc.exp: Don't xfail lsp test.
opcodes/
* ppc-dis.c (ppc_opts): Add e200z2 and lsp.  Don't set
PPC_OPCODE_LSP for e200z4 or vle.
(ppc_parse_cpu): Mutually exclude LSP and SPE.
(LSP_OPCD_SEGS): Define.
(lsp_opcd_indices): New array.
(disassemble_init_powerpc): Init lsp_opcd_indices.
(lookup_lsp): New function.
(print_insn_powerpc): Call it.
* ppc-opc.c: Include libiberty.h for ARRAY_SIZE and use throughout.
(vle_opcodes): Move LSP opcodes to..
(lsp_opcodes): ..here, and sort.
(lsp_num_opcodes): New.

PR29677, Field `the_bfd` of `asymbol` is uninitialised

Besides not initialising the_bfd of synthetic symbols, counting
symbols when sizing didn't match symbols created if there were any
dynsyms named "".  We don't want synthetic symbols without names
anyway, so get rid of them.  Also, simplify and correct sanity checks.

PR 29677
* mach-o.c (bfd_mach_o_get_synthetic_symtab): Rewrite.

[gdb/testsuite] Drop unnecessary -Wl,-soname in gdb.base/skip-solib.exp

I noticed in gdb.base/skip-solib.exp:
...
if {[gdb_compile_shlib ${srcdir}/${subdir}/${srcfile_lib} ${binfile_lib} \
        [list debug -Wl,-soname,${libname}.so]] != ""} {
    return -1
}
...
that the -Wl,-soname argument is missing an ldflags= prefix, but adding it
gives us a duplicate:
...
Executing on host: gcc -fno-stack-protector \
  outputs/gdb.base/skip-solib/skip-solib-lib.c.o  -fdiagnostics-color=never \
  -shared -g  -Wl,-soname,libskip-solib.so -Wl,-soname,libskip-solib.so -lm \
  -o outputs/gdb.base/skip-solib/libskip-solib.so    (timeout = 300)
...
so apparently it's taken care of by gdb_compile_shlib.

Drop the inactive and also unnecessary -Wl,-soname,${libname}.so from the
flags list for the gdb_compile_shlib call.

Tested on x86_64-linux.

[gdb/testsuite] Fix gdb.base/infoline-reloc-main-from-zero.exp with PIE

With test-case gdb.base/infoline-reloc-main-from-zero.exp and target board
unix/-fPIE/-pie I run into:
...
gdb compile failed, ld: infoline-reloc-main-from-zero: error: \
  PHDR segment not covered by LOAD segment
collect2: error: ld returned 1 exit status
...

When running with native, I find that the executable is static:
...
$ file infoline-reloc-main-from-zero
infoline-reloc-main-from-zero: ELF 64-bit LSB executable, x86-64, \
  version 1 (SYSV), statically linked, BuildID[sha1]=$hex, with debug_info, \
  not stripped
...
despite not having been compiled with -static.

Fix the compilation by adding -static to the compilation flags.

Tested on x86_64-linux.

[gdb/testsuite] Fix gdb.base/infoline-reloc-main-from-zero.exp with clang

With test-case gdb.base/infoline-reloc-main-from-zero.exp and clang I run into:
...
gdb compile failed, clang-13.0: warning: -e main: 'linker' input unused \
  [-Wunused-command-line-argument]
clang-13.0: warning: -Wl,-Ttext=0x00: 'linker' input unused \
  [-Wunused-command-line-argument]
clang-13.0: warning: -Wl,-N: 'linker' input unused \
  [-Wunused-command-line-argument]
UNTESTED: gdb.base/infoline-reloc-main-from-zero.exp: \
  infoline-reloc-main-from-zero.exp
UNTESTED: gdb.base/infoline-reloc-main-from-zero.exp: failed to compile
...

Fix this by using ldflags instead of additional_flags.

Likewise, fix all occurrences of:
...
$ find gdb/testsuite -name *.exp | xargs grep additional_flags.*Wl
...

Tested on x86_64-linux.

[gdb/testsuite] Fix nopie test-cases with target board unix/-fPIE/-pie

Compilers default to either PIE or no-PIE executables.

In order to test PIE executables with a compiler that produces non-PIE by
default, we can use target board unix/-fPIE/-pie, which set the multilib_flags
of the target board to "-fPIE -pie".

Likewise, we can use target board unix/-fno-PIE/-no-pie with a compiler that
produces PIE by default.

The target board unix/-fno-PIE/-no-pie has a potential problem when compiling
shared libs, because the multilib_flags will override the attempts of
gdb_compile_shlib to compile with -fPIC.  This is taken care of by running the
body of gdb_compile_shlib wrapped in with_PIE_multilib_flags_filtered.

The target board unix/-fPIE/-pie has a problem with nopie compilations.  The
current approach is to do the compilation hoping for the best, and if we find
out that the resulting executable is PIE despite specifying nopie, we error
out with the standard error message "nopie failed to prevent PIE executable".

That however does not work for hard-coded assembly nopie test-cases, which will
just noisily refuse to compile:
...
ld: amd64-disp-step0.o: relocation R_X86_64_32S against `.text' can not be \
  used when making a PIE object; recompile with -fPIE^M
...

Fix this in gdb_compile by filtering out the PIE settings in the target board
multilib_flags when pie or nopie is specified.

Tested on x86_64-linux.

[gdb/testsuite] Factor out with_PIE_multilib_flags_filtered

Factor out new procs with_PIE_multilib_flags_filtered and
with_multilib_flags_filtered from proc gdb_compile_shlib.

Tested on x86_64-linux.

[gdb/testsuite] Add cond_wrap proc

Add a new proc cond_wrap, that can be used to replace the repetitive:
...
    if { $cond } {
wrap {
    <body>
}
    } else {
<body>
    }
...
with the shorter:
...
    cond_wrap $cond wrap {
<body>
    }
...

Tested on x86_64-linux.

gdb: add Torbjörn Svensson to gdb/MAINTAINERS

RISC-V: Zicbo{m,p,z} adjustments to riscv_multi_subset_supports_ext()

The lack thereof did caused gas to issue "internal: unreachable
INSN_CLASS_*" errors when trying to assemble respective insns without
the feature(s) enabled via e.g. ".option arch, ...". Of course a proper
hint towards the missing extension then wasn't given either.

RISC-V: Imply 'Zicsr' from privileged extensions with CSRs

'H', 'Smstateen', 'Sscofpmf' and 'Sstc' are four privileged extensions with
their CSR definitions and 'Smepmp' is a privileged extension with additional
CSR bits.

Volume II: Privileged Architecture of the RISC-V ISA Manual states that the
privileged architecture requires the 'Zicsr' extension.  However, current
GNU Binutils has no direct way whether the program has dependency to the
privileged architecture itself.

As a workaround, we should add implications from privileged extensions that
either add new CSRs, extend existing CSRs or depends on using CSRs.

This commit adds such implications for existing privileged extensions that
satisfy this condition.

gas/ChangeLog:

* testsuite/gas/riscv/march-imply-h.d: New test, at least for 'H'.

bfd/ChangeLog:

* elfxx-riscv.c (riscv_implicit_subsets): Add 'Zicsr'
implicications for privileged extensions 'H', 'Smstateen',
'Sscofpmf', 'Sstc' and 'Smepmp'.

opcodes/riscv-dis.c: Remove last_map_state

Before changing the core disassembler, we take care of minor code clarity
issues and improve readability.

This commit removes unused variable last_map_state (set by the
print_insn_riscv function but not read anywhere else).

opcodes/ChangeLog:

* riscv-dis.c (last_map_state): Remove.
(print_insn_riscv): Remove setting last_map_state.

opcodes/riscv-dis.c: Make XLEN variable static

Before changing the core disassembler, we take care of minor code clarity
issues and improve readability.

Since xlen variable is not (and should not) used outside riscv-dis.c,
this commit makes this variable static.

opcodes/ChangeLog:

* riscv-dis.c (xlen): Make this variable static.

opcodes/riscv-dis.c: Use bool type whenever possible

Before changing the core disassembler, we take care of minor code clarity
issues and improve readability.

This commit replaces uses of int with bool whenever possible.

opcodes/ChangeLog:

* riscv-dis.c (no_aliases) Change type to bool.
(set_default_riscv_dis_options): Use boolean.
(parse_riscv_dis_option_without_args): Likewise.
(riscv_disassemble_insn): Use boolean keywords.

opcodes/riscv-dis.c: Tidying with spacing

Before changing the core disassembler, we take care of minor code clarity
issues and improve readability.

This commit takes care of improper spacing for code clarity.

opcodes/ChangeLog:

* riscv-dis.c (riscv_disassemble_insn): Tidying with spacing.

opcodes/riscv-dis.c: Tidying with comments/clarity

Before changing the core disassembler, we take care of minor code clarity
issues and improve readability.

First, we need to clarify the roles of variables and code portions.

opcodes/ChangeLog:

* riscv-dis.c (xlen): Move before default_isa_spec. Add comment.
(default_isa_spec, default_priv_spec): Add comment.
(riscv_gpr_names, riscv_fpr_names): Likewise.
(parse_riscv_dis_option_without_args): Likewise.
(parse_riscv_dis_option, parse_riscv_dis_options): Likewise.
(maybe_print_address): Likewise.
(riscv_disassemble_insn): Fix comment about the Zfinx "extension".
Add comment about the riscv_multi_subset_supports call.

RISC-V: Test DWARF register number for "fp"

This commit adds "fp" (x8 or s0) to dw-regnums.{s,d}.

gas/ChangeLog:

* testsuite/gas/riscv/dw-regnums.s: Add "fp".
* testsuite/gas/riscv/dw-regnums.d: Likewise.

RISC-V: Move standard hints before all instructions

Because all standard hints must be placed before corresponding instruction
for the disassembler, they may taint basic RVI instruction section.

This commit moves all standard hints before all basic RVI instructions
to improve maintainability.

opcodes/ChangeLog:

* riscv-opc.c (riscv_opcodes): Move all standard hints before all
standard instructions.

RISC-V: Move certain arrays to riscv-opc.c

This is a part of small tidying (declare tables in riscv-opc.c).

include/ChangeLog:

* opcode/riscv.h (riscv_rm, riscv_pred_succ): Move declarations to
opcodes/riscv-opc.c.  New non-static definitions.

opcodes/ChangeLog:

* riscv-opc.c (riscv_rm, riscv_pred_succ): Move from
include/opcode/riscv.h.  Add description.

ld: Add --undefined-version

This cancels a previous --no-undefined-version.
gold has had --undefined-version for a long time.

Automatic date update in version.in

PowerPC, fix gdb.base/watchpoint.exp on Power 9

Test gdb.base/watchpoint.exp generates 4 test errors on Power 9.  The
test uses the test [target_info exists gdb,no_hardware_watchpoints] to
determine if the processor supports hardware watchpoints.  The check
only examines the processor type to determine if it supports hardware
watchpoints.

The PowerPC processors support hardware watchpoints with the
exception of Power 9. The hardware watchpoint support is disabled on
Power 9.  The test skip_hw_watchpoint_tests must be used to correctly
determine if the PowerPC processor supports hardware watchpoints.

This patch replaces the [target_info exists gdb,no_hardware_watchpoints]
with the skip_hw_watchpoint_tests_p check.  With the patch, the test runs
on Power 9 with hardware watchpoint force-disabled.  The test runs on
all other PowerPC processors with and without hardware watchpoints
enabled.

The patch has been tested on Power 9 to verify the test only runs with
hardware breakpoints disabled.  The patch has been tested on X86-64 with
no regression failures.  The test fails on Power 10 due to an internal GDB
error due to resource management.  The resource management issue will be
addressed in another patch.

[gdb/testsuite] Fix gdb.dwarf2/macro-source-path.exp with -m32

With test-case gdb.dwarf2/macro-source-path.exp and target board unix/-m32, I
run into:
...
as: macro-source-path-gcc11-ld238-dw5-filename-641.o: \
  unsupported relocation type: 0x1^M
...

The problem is that we have 64-bit dwarf so the debug_line offset in the
.debug_macro section is an 8-byte entity, emitted using ".8byte":
...
        .section .debug_macro
.Lcu_macros4:
        .2byte        5                 /* version */
        .byte        3                  /* flags */
        .8byte        .LLlines3         /* debug_line offset */
...
but the linker doesn't support 8-byte relocation types on a 32-bit architecture.

This is similar to what was fixed in commit a5ac8e7fa3b
("[gdb/testsuite] Fix 64-bit dwarf test-cases with -m32") for for instance
.debug_abbrev.

Fix this in the same way, by using _op_offset to emit the debug_line offset.

Tested on x86_64-linux with native and target board unix/-m32.

[gdb/testsuite] Fix gdb.dwarf2/entry-value-typedef.exp with -m32

With test-case gdb.dwarf2/entry-value-typedef.exp and target board unix/-m32,
I run into:
...
builtin_spawn -ignore SIGHUP g++ -fno-stack-protector \
  gdb/testsuite/gdb.dwarf2/entry-value-typedef-amd64.S \
  -fdiagnostics-color=never -Lbuild/libiberty -lm -m32 \
  -o outputs/gdb.dwarf2/entry-value-typedef/entry-value-typedef^M
entry-value-typedef.cpp: Assembler messages:^M
entry-value-typedef.cpp:38: Error: bad register name `%rbp'^M
...

The problem is that the test-cases selects an amd64 .S file based on the check:
...
if { [istarget "x86_64-*-linux*"] } {
...
which is also true for target board unix/-m32 on x86_64-linux.

Fix this by adding the missing is_lp64_target check.

Tested on x86_64-linux, using native and target board unix/-m32.

[gdb/testsuite] Fix gdb.mi/mi-disassemble.exp with -m32

With target board unix/-m32 and test-case gdb.mi/mi-disassemble.exp we have:
...
(gdb) ^M
print/x *((unsigned char *) 0x8048485)^M
&"print/x *((unsigned char *) 0x8048485)\n"^M
~"$9 = 0x83\n"^M
^done^M
(gdb) ^M
PASS: gdb.mi/mi-disassemble.exp: get valueof "*((unsigned char *) 0x8048485)"
FAIL: gdb.mi/mi-disassemble.exp: byte at 0x8048485 matches
...
The test-case passes with native.

With native we see in gdb.log that variable longest_insn_bytes is:
...
Longest instruction at 0x0000000000400549 with bytes '48 8b 05 20 01 00 00'
...
and variable split_bytes (added debug puts) ends up as:
...
SPLIT_BYTES: 48 8b 05 20 01 00 00
...

But with unix/-m32 we have longest_insn_byte:
...
Longest instruction at 0x08048481 with bytes '8d 4c 24 04        '
...
and split_bytes ends up as:
...
SPLIT_BYTES: 8d 4c 24 04 {} {} {} {} {} {} {} {}
...
so the trailing whitespace is translated by split to empty bytes, and the
mismatch FAILs are generated for those.

Fix this by stripping the whitespace, which makes us end up with a different
and indeed longer insn:
...
Longest instruction at 0x08048492 with bytes 'dd 05 98 85 04 08'
...

Tested on x86_64-linux, with native and target board unix/-m32.

Automatic date update in version.in

PowerPC, fix test gdb.base/watchpoint-stops-at-right-insn.exp

Test gdb.base/watchpoint-stops-at-right-insn.exp generates 4 test errors
on Power 9.  The test uses the test [target_info exists gdb,
no_hardware_watchpoints] to determine if the processor supports hardware
watchpoints.  The check only examines the processor type to determine if
it supports hardware watchpoints.  Note, the test works fine on Power 10.

The PowerPC processors support hardware watchpoints with the
exception of Power 9. The hardware watchpoint support is disabled on
Power 9.  The test skip_hw_watchpoint_tests must be used to correctly
determine if the PowerPC processor supports hardware watchpoints.

This patch replaces the [target_info exists gdb,no_hardware_watchpoints]
with the skip_hw_watchpoint_tests_p check.  With the patch, the test is
disabled on Power 9 but runs on all other PowerPC processors.

The patch has been tested on Power 9, Power 10 and X86-64 with no
regression failures.

x86: drop "regmask" static variable

Replace its two uses by more direct checks, paralleling what's already
there for SIMD registers.

[gdb/symtab] Factor out elf_symfile_read_dwarf2

Factor out elf_symfile_read_dwarf2 from elf_symfile_read.  NFC.

Tested on x86_64-linux.

[gdb/testsuite] Fix ctf test-cases on openSUSE Tumbleweed

When running test-case gdb.base/ctf-constvars.exp on openSUSE Tumbleweed (with
system gcc version 12, providing gcc -gctf support, enabling the ctf test-cases
in the gdb testsuite), I run into:
...
(gdb) print vox^M
'vox' has unknown type; cast it to its declared type^M
(gdb) FAIL: gdb.base/ctf-constvars.exp: print vox
...

There are two causes for this:
- the linker flags are missing --ctf-variables, so the information for variable
  vox is missing (reported in PR29468), and
- the executable contains some dwarf2 due to some linked-in glibc objects,
  so the ctf info is ignored (reported in PR29160).

By using:
- -Wl,--ctf-variable,
- -Wl,--strip-debug, and
we can make the test-case and some similar test-cases pass.

Tested on x86_64-linux.

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

[gdb/testsuite] Silence warnings about obsolete -gstabs

When running test-case gdb.base/gdbindex-stabs.exp on openSUSE Tumbleweed (with
gcc 12) I get:
...
gdb compile failed, gdb/testsuite/gdb.base/gdbindex-stabs.c: warning: \
  STABS debugging information is obsolete and not supported anymore
...

Silence the warning by passing quiet to gdb_compile.  Likewise in two other
test-cases.

[gdb/testsuite] Replace remaining -gt with -gctf

With test-cases gdb.base/cvexpr.exp and gdb.base/whatis.exp I run into:
...
gdb compile failed, gcc: error: unrecognized debug output level 't'
...

This is due to using additional_flags=-gt.

Commit ffb3f587933 ("CTF: multi-CU and archive support") replaced
additional_flags=-gt with additional_flags=-gctf in gdb.ctf/*.exp and
gdb.base/ctf-*.exp.

Do the same in these two test-cases.

Tested on x86_64-linux.

[gdb/testsuite] Fix gdb.base/infoline-reloc-main-from-zero.exp with recent ld

On openSUSE Tumbleweed (with ld 2.39) and test-case
gdb.base/infoline-reloc-main-from-zero.exp, I get:
...
gdb compile failed, ld: warning: infoline-reloc-main-from-zero has a LOAD \
  segment with RWX permissions
UNTESTED: gdb.base/infoline-reloc-main-from-zero.exp: \
  infoline-reloc-main-from-zero.exp
...

Fix this by compiling with -Wl,--no-warn-rwx-segments.

Tested on x86_64-linux.

[gdb/testsuite] Fix gdb.base/nested-subp{2,3}.exp with recent ld

On openSUSE Tumbleweed (with ld 2.39) I get for test-case
gdb.base/nested-subp2.exp:
...
gdb compile failed, ld: warning: tmp.o: requires executable stack \
  (because the .note.GNU-stack section is executable)
...

Fix this by compiling with -Wl,--no-warn-execstack.

Likewise in gdb.base/nested-subp3.exp

Tested on x86_64-linux.

[gdb/testsuite] Remove unnecessary perror in some test-cases

On openSUSE Tumbleweed I noticed:
...
UNTESTED: gdb.dwarf2/fission-absolute-dwo.exp: fission-absolute-dwo.exp
ERROR: failed to compile fission-absolute-dwo
...

The ERROR is unnecessary, given that an UNTESTED is already emitted.

Furthermore, it could be argued that it is incorrect because it's not a
testsuite error to not be able to compile something, and UNTESTED or
UNSUPPORTED is more appropriate.

Remove the perror call, likewise in fission-relative-dwo.exp.

Tested on x86_64-linux.