objcopy: avoid "shadowing" of remove() function name

remove() is a standard library function (declared in stdio.h), which
triggers a "shadows a global declaration" warning with some gcc versions.

RISC-V: drop stray INSN_ALIAS flags

FENCE.TSO isn't an alias. ZIP and UNZIP in the long run likely are, but
presently they aren't. This fixes disassembly of these insns with
-Mno-aliases.

RISC-V: re-arrange opcode table for consistent alias handling

For disassembly to pick up aliases in favor of underlying insns (helping
readability in the common case), the aliases need to come ahead of the
"base" insns. Slightly more code movement is needed because of insns
with the same name needing to stay next to each other.

Note that the "rorw" alias entry also has the missing INSN_ALIAS added
here.

Clone a few testcases to exercise -Mno-aliases some more, better
covering the differences between the default and that disassembly mode.

x86: correct build dependencies in opcodes/

With the command in the rule merely being "echo", i386-tbl.h won't be
rebuilt if missing, when at the same time i386-init.h is present and
up-to-date. Use a pattern rule instead to express the multiple targets
correctly (the &: rule separator is supported only by GNU make 4.3 and
newer). Note that now, for the opposite case to work (i386-tbl.h is
up-to-date but i386-init.h is missing), i386-init.h also needs
mentioning as a dependency somewhere: Add a fake dependency for
i386-opc.lo ("fake" because i386-opc.c doesn't include that header).

At the same time use $(AM_V_GEN) in the actual rule, replacing the
earlier (open-coded) "echo". And while there also drop a duplicate
dependency of i386-gen.o on i386-opc.h.

x86: improve match_template()'s diagnostics

At the example of

extractps $0, %xmm0, %xmm0
insertps $0, %xmm0, %eax

(both having respectively the same mistake of using the wrong kind of
destination register) it is easy to see that current behavior is far
from ideal: The former results in "unsupported instruction" for 32-bit
code simply because the 2nd template we have is a Cpu64 one. Instead we
should aim at emitting the "best" possible error, which will typically
be the one where we passed the largest number of checks. Generalize the
original "specific_error" approach by making it apply to the entire
matching loop, utilizing that line numbers increase as we pass further
checks.

x86/Intel: restrict suffix derivation

While in some cases deriving an AT&T-style suffix from an Intel syntax
memory operand size specifier is necessary, in many cases this is not
only pointless, but has led to the introduction of various workarounds:
Excessive use of IgnoreSize and NoRex64 as well as the ToDword and
ToQword attributes. Suppress suffix derivation when we can clearly tell
that the memory operand's size isn't going to be needed to infer the
possible need for the low byte/word opcode bit or an operand size prefix
(0x66 or REX.W).

As a result ToDword and ToQword can be dropped entirely, plus a fair
number of IgnoreSize and NoRex64 can also be got rid of. Note that
IgnoreSize needs to remain on legacy encoded SIMD insns with GPR
operand, to avoid emitting an operand size prefix in 16-bit mode. (Since
16-bit code using SIMD insns isn't well tested, clone an existing
testcase just enough to cover a few insns which are potentially
problematic but are being touched here.)

Note that while folding the VCVT{,T}S{S,D}2SI templates, VCVT{,T}SH2SI
isn't included there. This is to fulfill the request of not allowing L
and Q suffixes there, despite the inconsistency with VCVT{,T}S{S,D}2SI.

LoongArch: Update ELF e_flags handling according to specification.

  Update handling of e_flags according to the documentation
  update [1] (discussions [2][3]).

  Object file bitness is now represented in the EI_CLASS byte.
  The e_flags field is now interpreted as follows:

  e_flags[2:0]: Base ABI modifier

  - 0x1: soft-float
  - 0x2: single-precision hard-float
  - 0x3: double-precision hard-float

  e_flags[7:6]: ELF object ABI version

  - 0x0: v0
  - 0x1: v1

  [1]: https://github.com/loongson/LoongArch-Documentation/blob/main/docs/LoongArch-ELF-ABI-EN.adoc#e_flags-identifies-abi-type-and-version
  [2]: https://github.com/loongson/LoongArch-Documentation/pull/61
  [3]: https://github.com/loongson/LoongArch-Documentation/pull/47

gprofng: fix cppcheck warnings

gprofng/ChangeLog
2022-09-29  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

* common/hwcdrv.c: Fix cppcheck warning.
* src/ABS.h: Likewise.
* src/CompCom.cc: Likewise.

[gdb/testsuite] Fix gdb.mi/mi-sym-info.exp on openSUSE Tumbleweed

On openSUSE Tumbleweed, I run into:
...
FAIL: gdb.mi/mi-sym-info.exp: List all functions from debug information only
...

The problem is in matching this string:
...
{name="_start",type="void (void)",description="void _start(void);"}
...
using regexp fun_re, which requires a line field:
...
set fun_re \
    "\{line=\"$decimal\",name=${qstr},type=${qstr},description=${qstr}\}"
...

Fix this by making the line field optional in fun_re.

Tested on x86_64-linux.

RISC-V: Add privileged extensions without instructions/CSRs

Currently, GNU Binutils does not support following privileged extensions:

-   'Smepmp'
-   'Svnapot'
-   'Svpbmt'

as they do not provide new CSRs or new instructions ('Smepmp' extends the
privileged architecture CSRs but does not define the CSR itself).  However,
adding them might be useful as we no longer have to "filter" ISA strings
just for toolchains (if full ISA string is given by a vendor, we can
straightly use it).

And there's a fact that supports this theory: there's already an
(unprivileged) extension which does not provide CSRs or instructions (but
only an architectural guarantee): 'Zkt' (constant timing guarantee for
certain subset of RISC-V instructions).

This simple commit simply adds three privileged extensions listed above.

bfd/ChangeLog:

* elfxx-riscv.c (riscv_supported_std_s_ext): Add 'Smepmp',
'Svnapot' and 'Svpbmt' extensions.

gdb: Remove unused extra_lines variable

Clang generates a warning if there is a variable that is set but not used
otherwise ("-Wunused-but-set-variable").  On the default configuration, it
causes a build failure (unless "--disable-werror" is specified).

The only extra_lines use in arrange_linetable function is removed on the
commit 558802e4d1c5dcbd0df7d2c6ef62a6deac247a2f
("gdb: change subfile::line_vector to an std::vector").  So, this variable
should be removed to prevent a build failure.

[gdb/testsuite] Add aranges to gdb.dwarf2/dw2-dir-file-name.exp

Since commit 52b920c5d20 ("[gdb/testsuite] Fix gdb.dwarf2/dw2-dir-file-name.exp
for ppc64le"), the test-case fails with target board cc-with-debug-names, due
to missing .debug_aranges info.

Add the missing .debug_aranges info.

Also add a file_id option to Dwarf::assemble, to make it possible to contribute
to an already open file.

Tested on x86_64-linux.

[gdb/c++] Print destructor the same for gcc and clang

Consider the test-case contained in this patch.

With g++ (7.5.0) we have for "ptype A":
...
type = class A {
  public:
    int a;

    A(void);
    ~A();
}
...
and with clang++ (13.0.1):
...
type = class A {
  public:
    int a;

    A(void);
    ~A(void);
}
...
and we observe that the destructor is printed differently.

There's a difference in debug info between the two cases: in the clang case,
there's one artificial parameter, but in the g++ case, there are two, and
these similar cases are handled differently in cp_type_print_method_args.

This is due to this slightly convoluted bit of code:
...
  i = staticp ? 0 : 1;
  if (nargs > i)
    {
      while (i < nargs)
        ...
    }
  else if (varargs)
    gdb_printf (stream, "...");
  else if (language == language_cplus)
    gdb_printf (stream, "void");
...

The purpose of "i = staticp ? 0 : 1" is to skip the printing of the implicit
this parameter.

In commit 5f4d1085085 ("c++/8218: Destructors w/arguments"), skipping of other
artificial parameters was added, but using a different method: rather than
adjusting the potential loop start, it skips the parameter in the loop.

The observed difference in printing is explained by whether we enter the loop:
- in the clang case, the loop is not entered and we print "void".
- in the gcc case, the loop is entered, and nothing is printed.

Fix this by rewriting the code to:
- always enter the loop
- handle whether arguments need printing in the loop
- keep track of how many arguments are printed, and
  use that after the loop to print void etc.
such that we have the same for both gcc and clang:
...
    A(void);
    ~A(void);
...

Note that I consider the discussion of whether we want to print:
- A(void) / ~A(void), or
- A() / ~A()
out-of-scope for this patch.

Tested on x86_64-linux.

PR29626, Segfault when disassembling ARM code

PR 29626
* arm-dis.c (mapping_symbol_for_insn): Return false on zero
symtab_size.  Delete later symtab_size test.

Automatic date update in version.in

gdb: make target_auxv_parse static and rename

It is only used in auxv.c.  Also, given it is not strictly a wrapper
around target_ops::auxv (since 27a48a9223d0 "Add auxv parsing to the
architecture vector."), I think that the name prefixed with target is a
bit misleading.  Rename to just parse_auxv.

Change-Id: I41cca055b92c8ede37c258ba6583746a07d8f77e

gdb: make fprint_target_auxv static

It's only used in auxv.c.

Change-Id: I4992d9aae37b6631a074ab99bbab2f619725b642

gdb: constify auxv parse functions

Constify the input parameters of the various auxv parse functions, they
don't need to modify the raw auxv data.

Change-Id: I13eacd5ab8e925ec2b5c1f7722cbab39c41516ec

gdb: constify target_stack::is_pushed

The target_ops parameters here can be made const.

Change-Id: Ibc18b17d6b21d06145251a03e68aca90538117d6

Constify target_desc declarations

This patch changes various global target_desc declarations to const, thereby
correcting a prominent source of ODR violations in PowerPC-related target code.
The majority of files/changes are mechanical const-ifications accomplished by
regenerating the C files in features/.

This also required manually updating mips-linux-tdep.h,  s390-linux-tdep.h,
nios2-tdep.h, s390-tdep.h, arch/ppc-linux-tdesc.h, arch/ppc-linux-common.c,
and rs6000-tdep.c.

Patch tested against the sourceware trybot, and fully regression tested against
our (Red Hat's) internal  test infrastructure on Rawhide aarch64, s390x, x86_64,
and powerpcle.

With this patch, I can finally enable LTO in our GDB package builds. [Tested
with a rawhide scratch build containing this patch.]

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

cleanup: Add missing feature/ XML files to Makefile

This patch adds some missing .xml files to features/Makefile so that when the
directory's C files are regenerated, all files are appropriately remade.

This has demonstrated that there have been several "misses" in regenerating
files in this directory. Namely, arm-secext.c and sparc{32,64}-solaris.c. For
the former case, there was what essentially amounts to a typo regarding the
create feature function's name. In the later case, this file has missed at least
one important update in July, 2020, when allocate_target_description was
changed to return a unique pointer.

Those corrections are included.

Add -B to the help output from gprof, and add suitable documentation.

PR 29627
* gprof.c (usage): Add -B.
* gprof.texi (synopsis): Add -B.
(Output Options): Add entry for -B.

Automatic date update in version.in

Fix GDB build: ELF support check & -lzstd

GDB fails to build for me, on Ubuntu 20.04.  I get:

 ...
   CXXLD  gdb
 /usr/bin/ld: linux-tdep.o: in function `linux_corefile_thread(thread_info*, linux_corefile_thread_data*)':
 /home/pedro/gdb/binutils-gdb/src/gdb/linux-tdep.c:1831: undefined reference to `gcore_elf_build_thread_register_notes(gdbarch*, thread_info*, gdb_signal, bfd*, std::unique_ptr<char, gdb::xfree_deleter<char> >*, int*)'
 /usr/bin/ld: linux-tdep.o: in function `linux_make_corefile_notes(gdbarch*, bfd*, int*)':
 /home/pedro/gdb/binutils-gdb/src/gdb/linux-tdep.c:2117: undefined reference to `gcore_elf_make_tdesc_note(bfd*, std::unique_ptr<char, gdb::xfree_deleter<char> >*, int*)'
 collect2: error: ld returned 1 exit status
 make[2]: *** [Makefile:2149: gdb] Error 1
 make[2]: Leaving directory '/home/pedro/gdb/binutils-gdb/build/gdb'
 make[1]: *** [Makefile:11847: all-gdb] Error 2
 make[1]: Leaving directory '/home/pedro/gdb/binutils-gdb/build'
 make: *** [Makefile:1004: all] Error 2

Those undefined functions exist in gdb/gcore-elf.c, which is only
included in the build if GDB's configure thinks that the target you're
configuring for is an ELF target.  GDB's configure thinks my system
isn't ELF, which is incorrect.

For the ELF support check, gdb/config.log shows:

 configure:17387: checking for ELF support in BFD
 configure:17407: gcc -o conftest -I/home/pedro/gdb/binutils-gdb/src/gdb/../include -I../bfd -I/home/pedro/gdb/binutils-gdb/src/gdb/../bfd -g3 -O0      -L../bfd -L../libiberty  -lzstd   conftest.c -lbfd -liberty -lz  -lncursesw -lm -ldl  >&5
 /usr/bin/ld: ../bfd/libbfd.a(compress.o): in function `decompress_contents':
 /home/pedro/gdb/binutils-gdb/src/bfd/compress.c:42: undefined reference to `ZSTD_decompress'
 /usr/bin/ld: /home/pedro/gdb/binutils-gdb/src/bfd/compress.c:44: undefined reference to `ZSTD_isError'
 /usr/bin/ld: ../bfd/libbfd.a(compress.o): in function `bfd_compress_section_contents':
 /home/pedro/gdb/binutils-gdb/src/bfd/compress.c:195: undefined reference to `ZSTD_compress'
 /usr/bin/ld: /home/pedro/gdb/binutils-gdb/src/bfd/compress.c:198: undefined reference to `ZSTD_isError'
 collect2: error: ld returned 1 exit status
 configure:17407: $? = 1
 ...
 configure:17417: result: no

Note how above, in the gcc command line, "-lzstd" appears before
"-lbfd".  That explain the link failure.  It should appear after, like
-lz does.

This commit fixes it, by moving ZSTD_LIBS from LDFLAGS to LIBS, next
to -lz, in GDB_AC_CHECK_BFD, and regenerating gdb/configure.

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

gdb: remove trailing spaces in README

Change-Id: Ic7f8e415acd1bff6194cf08ed646bff45571f165

Treat Character as a discrete type in Ada

A user noticed that gdb would assert when printing a certain array
with array-indexes enabled.  This turned out to be caused by the array
having an index type of Character, which is completely valid in Ada.
This patch changes the Ada support to recognize Character as a
discrete type, and adds some tests.

Because this is Ada-specific and was also reviewed internally, I am
checking it in.

The help document of size misses an option.

PR 29628
* size.c (usage): Add -f.
* doc/binutils.texi (size): Add -f.

ld/testsuite: force warnings when dealing with execstack tests

Binutils can be configured to avoid printing the execstack or RWD
segment warnings. In this case, the first test of PR ld/29072 will fail.
Fix that by always manually forcing the warnings for it.

ld/ChangeLog:

* testsuite/ld-elf/elf.exp (PR ld/29072): Force execstack and
RWD segment warnings.

Re: egrep in binutils

Multi-line patterns for grep are not supported on some old versions
of grep.

binutils/
* embedspu.sh: Replace multi-line grep with sed.
ld/
* testsuite/ld-elfvers/vers.exp: Replace multi-line grep with sed.

Renenerate {gdb,gdbserver}/configure

Pick up config/lib-ld.m4 changes from:

 commit 67d1991b785bdfef1d70cddfa0202b99b43ccce9
 Author:     Alan Modra <amodra@gmail.com>
 AuthorDate: Wed Sep 28 13:37:31 2022 +0930
 Commit:     Alan Modra <amodra@gmail.com>
 CommitDate: Wed Sep 28 13:37:31 2022 +0930

     egrep in binutils

Change-Id: Ifc84d30f1fca015e80bafa80f9a35616b0077220

The help document of as misses some many options

PR 29623
* as.c (show_usage): Document the --dump-config,
--gdwarf-cie-version, --hash-size, --multibyte-handling,
and --reduce-memory-overheads options.
* config/tc-i386.c (md_show_usage): Document the -O option.
* doc/as.texi: Document the --dump-config, --emulation,
--hash-size, and --reduce-memory-overheads options.

egrep in binutils

Apparently some distros have a nagging egrep that helpfully tells you
egrep is deprecated and to use "grep -E".  The nag message causes a ld
testsuite failure.  What's more the advice isn't that good.  The "-E"
flag may not be available with older versions of grep.

This patch fixes bare invocation of egrep within binutils, replacing
it with the autoconf $EGREP or with grep.

config/
* lib-ld.m4 (AC_LIB_PROG_LD_GNU): Require AC_PROG_EGREP and
invoke $EGREP.
(AC_LIB_PROG_LD): Likewise.
binutils/
* configure: Regenerate.
* embedspu.sh: Replace egrep with grep.
gold/
* testsuite/Makefile.am (flagstest_compress_debug_sections.check):
Replace egrep with grep.
* testsuite/Makefile.in: Regenerate.
* testsuite/bnd_ifunc_1.sh: Replace egrep with $EGREP.
* testsuite/bnd_ifunc_2.sh: Likewise.
* testsuite/bnd_plt_1.sh: Likewise.
* testsuite/discard_locals_test.sh: Likewise.
* testsuite/gnu_property_test.sh: Likewise.
* testsuite/no_version_test.sh: Likewise.
* testsuite/pr18689.sh: Likewise.
* testsuite/pr26936.sh: Likewise.
* testsuite/retain.sh: Likewise.
* testsuite/split_i386.sh: Likewise.
* testsuite/split_s390.sh: Likewise.
* testsuite/split_x32.sh: Likewise.
* testsuite/split_x86_64.sh: Likewise.
* testsuite/ver_test_pr16504.sh: Likewise.
intl/
* configure: Regenerate.
ld/
* testsuite/ld-elfvers/vers.exp (test_ar): Replace egrep with grep.

regen bfd/configure

asan: _bfd_stab_section_find_nearest_line segv

The segv was on "info->strs[strsize - 1] = 0;" with strsize zero.  OK,
if strsize is zero we don't have any filenames in stabs so no useful
info.

* syms.c (_bfd_stab_section_find_nearest_line): Exit if either
stabsize or strsize is zero.

asan: segv in _bfd_archive_close_and_cleanup

Uninitialised arelt_data->parent_cache led to this segv.

* pdb.c (pdb_get_elt_at_index): Clear arelt_data.

Automatic date update in version.in

sim: Link ZSTD_LIBS

This fixes linker errors in a `../../configure --enable-targets
--enable-sim; make all-gdb` build.

gold: Suppress "unused" variable warning on Clang

Clang generates a warning if there is a variable that is set but not used
otherwise ("-Wunused-but-set-variable").  On the default configuration, it
causes a build failure (unless "--disable-werror" is specified).

Because the cause of this error is in the Bison-generated code
($(srcdir)/gold/yyscript.y -> $(builddir)/gold/yyscript.c),
this commit suppresses this warning ("-Wunused-but-set-variable") by placing
DIAGNOSTIC_IGNORE_UNUSED_BUT_SET_VARIABLE macro at the end of user
prologue on yyscript.y.

* yyscript.y: Suppress -Wunused-but-set-variable warning on
the Bison-generated code.

libctf: Add ZSTD_LIBS to LIBS so that ac_cv_libctf_bfd_elf can be true

binutils, gdb: support zstd compressed debug sections

PR29397 PR29563: Add new configure option --with-zstd which defaults to
auto.  If pkgconfig/libzstd.pc is found, define HAVE_ZSTD and support
zstd compressed debug sections for most tools.

* bfd: for addr2line, objdump --dwarf, gdb, etc
* gas: support --compress-debug-sections=zstd
* ld: support ELFCOMPRESS_ZSTD input and --compress-debug-sections=zstd
* objcopy: support ELFCOMPRESS_ZSTD input for
  --decompress-debug-sections and --compress-debug-sections=zstd
* gdb: support ELFCOMPRESS_ZSTD input.  The bfd change references zstd
  symbols, so gdb has to link against -lzstd in this patch.

If zstd is not supported, ELFCOMPRESS_ZSTD input triggers an error.  We
can avoid HAVE_ZSTD if binutils-gdb imports zstd/ like zlib/, but this
is too heavyweight, so don't do it for now.

```
% ld/ld-new a.o
ld/ld-new: a.o: section .debug_abbrev is compressed with zstd, but BFD is not built with zstd support
...

% ld/ld-new a.o --compress-debug-sections=zstd
ld/ld-new: --compress-debug-sections=zstd: ld is not built with zstd support

% binutils/objcopy --compress-debug-sections=zstd a.o b.o
binutils/objcopy: --compress-debug-sections=zstd: binutils is not built with zstd support

% binutils/objcopy b.o --decompress-debug-sections
binutils/objcopy: zstd.o: section .debug_abbrev is compressed with zstd, but BFD is not built with zstd support
...
```

PR29617, ld segfaults when bfd_close fails

PR 29617
* ldmain.c (main): Don't access output_bfd after bfd_close.

Automatic date update in version.in

gdb/testsuite: update field names in gdb-gdb.py.in

Patches that renamed the type::length and type::target_type fields
didn't update gdb-gdb.py.in accordingly, do that.

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

gdb/testsuite: use gdb_test in gdb.gdb/python-helper.exp

If some command in there gives the wrong answer, we currently have to
wait for a timeout for the test to continue.  For instance, I currently
see:

    print *val->type
    $1 = Python Exception <class 'gdb.error'>: Cannot take address of method length.

    (outer-gdb) FAIL: gdb.gdb/python-helper.exp: pretty print type (timeout)

We can avoid this and modernize the test at the same time by using the
-prompt option of gdb_test.

gdb_test_no_output currently accepts a -prompt_re option (the variable
name passed to parse_args defines the option name), but I think
it's a typo.  It's supposed to be -prompt, like gdb_test.  I can't find
anything using -prompt_re using grep.  Change it to just "prompt".

Change-Id: Icc0a9a0ef482e62460c708bccdd544c11d711eca

gdb/testsuite: bump duration for the whole test in do_self_tests

When running gdb.gdb/python-helper.exp, I get some timeouts:

    continue
    Continuing.
    print 1

    FAIL: gdb.gdb/python-helper.exp: hit breakpoint in outer gdb (timeout)

At this time, GDB is actually processing the stop and reading in some
CUs.  selftest_setup does bump the timeout, but it's not for the whole
test.

Since debugging GDB with GDB is (unfortunately) a bit slow, bump the
timeout for the whole duration of the setup and body.  On my optimized
build, the command takes just a bit more than the current timeout of 10
seconds.  But it's much slower if running the test on an unoptimized
build, so I think it's necessary to bump the timeout for that in any
case.

Change-Id: I4d38285870e76c94f9d0bfdb60648a2e7f2cfa5d

binutils/testsuite: handle the different install names of c++filt

c++filt is always named cxxfilt in a build directory, but in a install
directory it would be named either cxxfilt or c++filt (depending on
the host).  Handle this last case in testsuite.

binutils/ChangeLog:
        *  testsuite/config/default.exp (CXXFILE): if cxxfilt not found,
        try c++filt.

binutils/testsuite: skip gentestdlls related tests if missing

When launching the testsuite through runtest outside the build tree,
gentestdlls might not be available, this binary being created by make
check.
Simply untested the related tests instead of crashing.

binutils/ChangeLog:

* testsuite/binutils-all/objdump.exp: Skip dotnet tests if
gentestdlls is not available.

[gdb/testsuite] Fix gdb.dwarf2/dw2-unspecified-type-foo.c with -m32

When running test-case gdb.dwarf2/dw2-unspecified-type-foo.c with target board
unix/-m32, I run into:
...
(gdb) PASS: gdb.dwarf2/dw2-unspecified-type.exp: ptype foo
p ((int (*) ()) foo) ()^M
$1 = -135698472^M
...

Add the missing "return 0" in foo, which fixes this.

Tested on x86_64-linux.

PR29613, use of uninitialized value in objcopy

PR 29613
* elf.c (_bfd_elf_write_secondary_reloc_section): Trim sh_size
back to relocs written.  Use better types for vars.

PR29542, PowerPC gold internal error in get_output_view,

We were attempting to set a BSS style section contents.

PR 29542
* powerpc.cc (Output_data_plt_powerpc::do_write): Don't set .plt,
.iplt or .lplt section contents when position independent.

stab nearest_line bfd_malloc_and_get_section

bfd_malloc_and_get_section performs some sanity checks on the section
size before allocating memory.  This patch avails the stab
nearest_line code of that sanity checking, and tidies up memory
afterward.

* coffgen.c (_bfd_coff_close_and_cleanup): Call _bfd_stab_cleanup.
* elf.c (_bfd_elf_close_and_cleanup): Likewise.
* syms.c (_bfd_stab_section_find_nearest_line): Set *pinfo earlier.
Use bfd_malloc_and_get_section.  Free malloc'd buffers on failure.
Malloc indextable.
(_bfd_stab_cleanup): New function.
* libbfd-in.h (_bfd_stab_cleanup): Declare.
* libbfd.h: Regnerate.

PKG_CHECK_MODULES for msgpack and jansson

Using AS_IF rather than shell "if" is recommended for conditionals
that contain non-trivial autoconf macros, because autoconf will emit
any AC_REQUIREd autoconf macro expansions outside of the conditional.
This makes them available elsewhere in the configure script.

binutils/
* configure.ac (msgpack): Use "AS_IF" rather than "if".
* configure: Regenerate.
ld/
* configure.ac (jansson): Use "AS_IF" rather than "if".
* configure: Regenerate.

Automatic date update in version.in

Automatic date update in version.in

gdb/source.c: Fix undefined behaviour dereferencing empty string

When a source file's dirname is solely made up of directory separators
we end up trying to dereference the last character of an empty string
with std::string::back, which results in undefined behaviour. A typical
use case where this can happen is when the root directory "/" is used as
a compilation directory.

With libstdc++.so.6.0.28 we get no out-of-bounds checks and the byte
preceding the storage of the empty string is returned. The character
value of this byte depends on heap implementation and usage, but when
this byte happens to hold the value of the directory separator character
we go on to call std::string::pop_back on the empty string which results
in an out_of_range exception which terminates GDB.

Fix this by using path_join. prepare_path_for_appending ensures that the
filename component is relative.

The testsuite has been run before and after the change and no
regressions were found.

gdbserver: remove unused for loop

In this commit,

  commit cf6c1e710ee162a5adb0ae47acb731f2bfecc956
  Date:   Mon Jul 11 20:53:48 2022 +0800

    gdbserver: remove unused variable

I removed an unused variable in handle_v_run.  Pedro then pointed out
that the for loop after it was also unused.  After a period of smoke
testing, no exceptions were found.

Tested on x86_64-linux.

The problem with warning in elf_object_p

elfcode.h can emit three warnings in elf_object_p for various things,
"section extending past end of file", "corrupt string table index",
and "program header with invalid alignment".  The problem with doing
this is that the warning can be emitted for multiple possible targets
as each one is tried.  I was looking at a fuzzer testcase that had an
object file with 6144 program headers, 5316 of which had invalid
alignment.  It would be bad enough to get 5316 messages all the same,
but this object was contained in an archive and resulted in 4975776
repeats.

Some trimming can be done by not warning if the bfd is already marked
read_only, as is done for the "section extending past end of file"
warning, but that still results in an unacceptable number of
warnings for object files in archives.  Besides that, it is just wrong
to warn about a problem detected by a target elf_object_p other than
the one that actually matches.  At some point we might have more
target specific warnings.

So what to do?  One obvious solution is to remove the warnings.
Another is to poke any warning strings into the target xvec, emitting
them if that xvec is the final one chosen.  This also has the benefit
of solving the archive problem.  A warning when recursing into
_bfd_check_format for the first element of the archive (to find the
correct target for the archive) will still be on the xvec at the point
that target is chosen for the archive.  However, target xvecs are
read-only.  Thus the need for per_xvec_warn to logically extend
bfd_target with a writable field.  I've made per_xvec_warn one larger
than bfd_target_vector to provide one place for user code that makes
private copies of target xvecs.

* elfcode.h (elf_swap_shdr_in, elf_object_p): Stash potential
warnings in _bfd_per_xvec_warn location.
* format.c (clear_warnmsg): New function.
(bfd_check_format_matches): Call clear_warnmsg before trying
a new xvec.  Print warnings for the successful non-archive
match.
* targets.c: Include libiberty.h.
(_bfd_target_vector_entries): Use ARRAY_SIZE.
(per_xvec_warn): New.
(_bfd_per_xvec_warn): New function.
* Makefile.am (LIBBFD_H_FILES): Add targets.c.
* Makefile.in: Regenerate.
* libbfd.h: Regenerate.

Re: bfd_cleanup for object_p

Bits still missing from commit cb001c0d283d.

* aoutx.h (aout_@var{size}_some_aout_object_p): Correct synopsis.
* i386lynx.c (lynx_core_file_p): Correct return type.
* ptrace-core.c (ptrace_unix_core_file_p): Likewise.

Automatic date update in version.in

Support AT_USRSTACKBASE and AT_USRSTACKLIM.

FreeBSD's kernel has recently added two new ELF auxiliary vector
entries to describe the location of the user stack for the initial
thread in a process.

This change displays the proper name and description of these entries
in 'info auxv'.

RISC-V: Add Zawrs ISA extension support

This patch adds support for the Zawrs ISA extension
("wrs.nto" and "wrs.sto" instructions).

The specification can be found here:
https://github.com/riscv/riscv-zawrs/blob/main/zawrs.adoc

Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>

gdb/testsuite/tui: start GDB with "set filename-display basename"

The test gdb.tui/tui-missing-src.exp fails on my CI machine, and I
concluded that it is caused by the long source directory name:

  /home/jenkins/workspace/binutils-gdb_master_linuxbuild/platform/jammy-amd64/target_board/unix/src/binutils-gdb

The long name causes some particular redrawing that doesn't happen for
shorter directories, and causes a Term::command call to return too
early.

This can be reproduced by cloning the binutils-gdb repo in a directory
with a name similar to the one shown above.

    $ pwd
    /home/simark/workspace/binutils-gdb_master_linuxbuild/platform/jammy-amd64/target_board/unix/src/binutils-gdb/build/gdb
    $ make check-read1 TESTS="gdb.tui/tui-missing-src.exp"
    FAIL: gdb.tui/tui-missing-src.exp: checking if inside f2 ()
    FAIL: gdb.tui/tui-missing-src.exp: f2.c must be displayed in source window
    FAIL: gdb.tui/tui-missing-src.exp: check source box is empty after return
    FAIL: gdb.tui/tui-missing-src.exp: Back in main

Note that using "make check" instead of "make check-read1" only shows
the last 2 failures for me.

When running gdb.tui/tui-missing-src.exp in a directory with a shorter
name, the terminal looks like this by the time the "checking if inside
f2" test runs:

    Screen Dump (size 80 columns x 24 rows, cursor at column 6, row 23):
        0 +-...ld/binutils-gdb-noasan/gdb/testsuite/outputs/gdb.tui/tui-missing-src/f2.c-+
        1 |        1                                                                     |
        2 |        2  int                                                                |
        3 |        3  f2 (int x)                                                         |
        4 |        4  {                                                                  |
        5 |  >     5    x <<= 1;                                                         |
        6 |        6    return x+5;                                                      |
        7 |        7  }                                                                  |
        8 |        8                                                                     |
        9 |        9                                                                     |
       10 |       10                                                                     |
       11 |       11                                                                     |
       12 |       12                                                                     |
       13 |       13                                                                     |
       14 +------------------------------------------------------------------------------+
       15 multi-thre Thread 0x7ffff7cc07 In: f2                  L5    PC: 0x555555555143
       16     at /home/simark/build/binutils-gdb-noasan/gdb/testsuite/outputs/gdb.tui/tui-
       17 missing-src/main.c:6
       18 (gdb) next
       19 (gdb) step
       20 f2 (x=4)
       21     at /home/simark/build/binutils-gdb-noasan/gdb/testsuite/outputs/gdb.tui/tui-
       22 missing-src/f2.c:5
       23 (gdb)
    PASS: gdb.tui/tui-missing-src.exp: checking if inside f2 ()

When running the `Term::command "step"` just before, GDB writes the
"step", which makes the `wait_for` proc go in the "looking for the
prompt" mode, to know when the command's execution is complete.  As some
new output appears, lines that must disappear are deleted using the
"Delete Line" operation [1] and some new ones are drawn.  The source
window gets redrawn with the contents of the f2.c file.  Then, GDB
writes the prompt (at line 23 above), which satisfies `wait_for`, which
then returns.  The state of the terminal is therefore correct for the
"check if inside f2" and "f2.c must be displayed in the source window"
tests.

In the non-working case, the terminal looks like this by the time the
"check if inside f2" test runs:

     Screen Dump (size 80 columns x 24 rows, cursor at column 6, row 17):
        0 +------------------------------------------------------------------------------+
        1 |                                                                              |
        2 |                                                                              |
        3 |                                                                              |
        4 |                                                                              |
        5 |                                                                              |
        6 |                                                                              |
        7 |               [ No Source Available ]                                        |
        8 |                                                                              |
        9 |                                                                              |
       10 |                                                                              |
       11 |                                                                              |
       12 |                                                                              |
       13 |                                                                              |
       14 +------------------------------------------------------------------------------+
       15 multi-thre Thread 0x7ffff7cc1b In: main                L7    PC: 0x555555555128
       16 sing-src/main.c:6
       17 (gdb) ary breakpoint 1, main ()
       18     at /home/simark/workspace/binutils-gdb_master_linuxbuild/platform/jammy-amd6
       19 4/target_board/unix/src/binutils-gdb/build/gdb/testsuite/outputs/gdb.tui/tui-mis
       20 sing-src/main.c:6
       21 (gdb) next
       22 (gdb) step
       23
    FAIL: gdb.tui/tui-missing-src.exp: checking if inside f2 ()

What happened is: GDB wrote the "step" command, which make the
`wait_for` proc go in its "looking for the prompt" mode.  However,
curses decided to redraw whatever scrolled up to line 17 using some
standard character insertion operations:

    +++ Cursor Down (1), cursor: (16, 0) -> (17, 0)
    +++ Inserting string '('
    +++   Inserted char '(', cursor: (17, 0) -> (17, 1)
    +++ Inserted string '(', cursor: (17, 0) -> (17, 1)
    +++ Inserting string 'g'
    +++   Inserted char 'g', cursor: (17, 1) -> (17, 2)
    +++ Inserted string 'g', cursor: (17, 1) -> (17, 2)
    +++ Inserting string 'd'
    +++   Inserted char 'd', cursor: (17, 2) -> (17, 3)
    +++ Inserted string 'd', cursor: (17, 2) -> (17, 3)
    +++ Inserting string 'b'
    +++   Inserted char 'b', cursor: (17, 3) -> (17, 4)
    +++ Inserted string 'b', cursor: (17, 3) -> (17, 4)
    +++ Inserting string ')'
    +++   Inserted char ')', cursor: (17, 4) -> (17, 5)
    +++ Inserted string ')', cursor: (17, 4) -> (17, 5)
    +++ Inserting string ' '
    +++   Inserted char ' ', cursor: (17, 5) -> (17, 6)
    +++ Inserted string ' ', cursor: (17, 5) -> (17, 6)

And that causes `wait_for` to think the "step" command is complete.
This is wrong, as the prompt at line 17 isn't the prompt drawn after the
completion of the "step" command.  The subsequent tests now run with a
partially updated screen (what is shown above) and obviously fail.

The ideal way to fix this would be for `wait_for` to be smarter, to
avoid it confusing the different prompts drawn.

However, I would also like to reduce the variations in TUI test results
due to the directories (source and build) in which tests are ran.  TUI
tests are more prone to differences in test results due to variations in
directory names than other tests, as it makes curses take different
redrawing decisions.  So in this patch, I propose to make TUI tests use
"set filename-display basename", which makes GDB omit directory names
when it prints file names.  This way, regardless of where you run the
tests, you should get the same results (all other things being equal).

Doing this happens to fix my failures and makes my CI happy (which in
turns makes me happy).  To be clear, I understand that this does not fix
the root issue of `proc wait_for` being confused.  However, it makes TUI
test runs be more similar for everyone, such that there's less chance of
TUI tests randomly failing for somebody.  If some other change triggers
the `wait_for` problem again in the future, hopefully everybody will see
the problem and we can work on getting it fixed more easily than if just
one unlucky person sees the problem.

Note that there are other reasons why TUI tests could vary, like
different curses library versions taking different re-drawing decisions.
However, I think my change is a good step towards more stable test
results.

[1] https://vt100.net/docs/vt510-rm/DL.html

Change-Id: Ib18da83317e7b78a46f77892af0d2e39bd261bf5

gdb/csky add cskyv2-linux.xml for cskyv2-linux.c

Add cskyv2-linux.xml for re-generating cskyv2-linux.c if needed.
Also update cskyv2-linux.c.

pdb: _bfd_generic_close_and_cleanup

Every format that might appear inside a generic archive needs to call
_bfd_generic_close_and_cleanup, so that the archive element lookup
htab can be tidied on closing an element.  Otherwise you get stale
entries in the htab pointing at freed and perhaps reused memory,
resulting in segfaults when the archive is closed.

Calling _bfd_generic_close_and_cleanup on close means tdata needs to
be set up too, since pdb claims to be of format bfd_archive.

* pdb.c (pdb_close_and_cleanup): Define as
_bfd_generic_close_and_cleanup.
(pdb_archive_p): Set up tdata for bfd_archive format.

Don't attempt to compress bss sections

It doesn't make sense to try to compress a section without contents
since those sections take no space on disk.  Compression can only
increase the disk image size.

* coffgen.c (make_a_section_from_file): Exclude !SEC_HAS_CONTENTS
sections from compression and decompression.
* elf.c (_bfd_elf_make_section_from_shdr): Likewise.

Automatic date update in version.in

gdb/testsuite/lib/future.exp: follow dejagnu default_target_compile

GDB's testsuite can override dejagnu's default_target_compile if the
system provided dejagnu installation does not provide support to compile
languages GDB needs.

Recent version of dejagnu (1.6.3, installed on RHEL-9) includes ba60272
"Establish a default C compiler by evaluating [find_gcc] if no other
compiler is given."[1].  This commit removed calls such as
`set_board_info compiler  "[find_gcc]"` from the various baseboards
and has default_target_compile call `find_gcc` itself to find a compiler
if none was specified by the board description.

On systems with dejagnu-1.6.3, if GDB's overrides is needed to support
languages still unknown to dejagnu, we end up in the following
situation:
  - The system board files do not set the C compiler anymore,
  - GDB's replacement for default_target_compile assumes that the
    compiler should have been set up by the board file.

In this situation, no one sets the C compiler for the board and as a
result many test are not compiled and not executed:

    [...]
    Running .../gdb/testsuite/gdb.base/bt-on-error-and-warning.exp ...
    gdb compile failed, default_target_compile: No compiler to compile with
    Running .../gdb/testsuite/gdb.base/dprintf-non-stop.exp ...
    gdb compile failed, default_target_compile: No compiler to compile with
    Running .../gdb/testsuite/gdb.base/structs3.exp ...
    gdb compile failed, default_target_compile: No compiler to compile with
    [...]

We are observing this error with ROCgdb[2], a downstream port of GDB
supporting AMD GPUs.  This port needs to use GDB's override of
default_target_compile to compile HIP programs since dejagnu does not
provide support for this language yet.

This patch changes gdb_default_target_compile_1 in a similar way
default_target_compile has been updated so both implementations remain
compatible.  Even if this is not strictly required by GDB just yet,
I believe keeping both implementations in sync desirable.

Using board files provided with dejagnu <=1.6.2 is still supported: if
the compiler is set by the board file, gdb_default_target_compile_1 uses
it and does not need `find_gcc`.

Patch tested on x86_64 RHEL-9 and ubuntu-20.04 on top of GDB and ROCgdb.

[1] http://git.savannah.gnu.org/gitweb/?p=dejagnu.git;a=commit;h=ba60272a5ac6f6a7012acca03f596a6ed003f044
[2] https://github.com/ROCm-Developer-Tools/ROCgdb

Change-Id: Ibff52684d9cab8243a7c6748ecbd29f50c37e669

RISC-V: Add T-Head MemPair vendor extension

T-Head has a range of vendor-specific instructions.
Therefore it makes sense to group them into smaller chunks
in form of vendor extensions.

This patch adds the XTheadMemPair extension, a collection of T-Head specific
two-GP-register memory operations.
The 'th' prefix and the "XTheadMemPair" extension are documented in a PR
for the RISC-V toolchain conventions ([1]).

[1] https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/19

Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com>
Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>

RISC-V: Add support for literal instruction arguments

This patch introduces support for arbitrary literal instruction
arguments, that are not encoded in the opcode.

A typical use case for this feature would be an instruction that
applies an implicit shift by a constant value on an immediate
(that is a real operand). With this patch it is possible to make
this shift visible in the dissasembly and support such artificial
parameter as part of the asssembly code.

Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com>
Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>

RISC-V: Add T-Head MemIdx vendor extension

T-Head has a range of vendor-specific instructions.
Therefore it makes sense to group them into smaller chunks
in form of vendor extensions.

This patch adds the XTheadMemIdx extension, a collection of T-Head specific
GPR memory access instructions.
The 'th' prefix and the "XTheadMemIdx" extension are documented in a PR
for the RISC-V toolchain conventions ([1]).

In total XTheadCmo introduces the following 44 instructions
(BU,HU,WU only for loads (zero-extend instead of sign-extend)):

* {L,S}{D,W,WU,H,HU,B,BU}{IA,IB} rd, rs1, imm5, imm2
* {L,S}R{D,W,WU,H,HU,B,BU} rd, rs1, rs2, imm2
* {L,S}UR{D,W,WU,H,HU,B,BU} rd, rs1, rs2, imm2

[1] https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/19

Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com>
Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>

RISC-V: Add T-Head FMemIdx vendor extension

T-Head has a range of vendor-specific instructions.
Therefore it makes sense to group them into smaller chunks
in form of vendor extensions.

This patch adds the XTheadFMemIdx extension, a collection of
T-Head-specific floating-point memory access instructions.
The 'th' prefix and the "XTheadFMemIdx" extension are documented
in a PR for the RISC-V toolchain conventions ([1]).

[1] https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/19

Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com>
Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>

RISC-V: Add T-Head MAC vendor extension

T-Head has a range of vendor-specific instructions.
Therefore it makes sense to group them into smaller chunks
in form of vendor extensions.

This patch adds the XTheadMac extension, a collection of
T-Head-specific multiply-accumulate instructions.
The 'th' prefix and the "XTheadMac" extension are documented
in a PR for the RISC-V toolchain conventions ([1]).

[1] https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/19

Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com>
Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>

RISC-V: Add T-Head CondMov vendor extension

T-Head has a range of vendor-specific instructions.
Therefore it makes sense to group them into smaller chunks
in form of vendor extensions.

This patch adds the XTheadCondMov extension, a collection of
T-Head-specific conditional move instructions.
The 'th' prefix and the "XTheadCondMov" extension are documented
in a PR for the RISC-V toolchain conventions ([1]).

[1] https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/19

Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com>
Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>

RISC-V: Add T-Head Bitmanip vendor extension

T-Head has a range of vendor-specific instructions.
Therefore it makes sense to group them into smaller chunks
in form of vendor extensions.

This patch adds the XThead{Ba,Bb,Bs} extensions, a collection of
T-Head-specific bitmanipulation instructions.
The 'th' prefix and the "XThead{Ba,Bb,Bs}" extension are documented
in a PR for the RISC-V toolchain conventions ([1]).

[1] https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/19

Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com>
Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>

RISC-V: Add support for arbitrary immediate encoding formats

This patch introduces support for arbitrary signed or unsigned immediate
encoding formats. The formats have the form "XsN@S" and "XuN@S" with N
being the number of bits and S the LSB position.

For example an immediate field of 5 bytes that encodes a signed value
and is stored in the bits 24-20 of the instruction word can use the
format specifier "Xs5@20".

Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com>
Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>

RISC-V: Add T-Head SYNC vendor extension

T-Head has a range of vendor-specific instructions.
Therefore it makes sense to group them into smaller chunks
in form of vendor extensions.

This patch adds the XTheadSync extension, a collection of
T-Head-specific multi-processor synchronization instructions.
The 'th' prefix and the "XTheadSync" extension are documented in a PR
for the RISC-V toolchain conventions ([1]).

[1] https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/19

Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com>
Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>

RISC-V: Add T-Head CMO vendor extension

T-Head has a range of vendor-specific instructions.
Therefore it makes sense to group them into smaller chunks
in form of vendor extensions.

This patch adds the XTheadCmo extension, a collection of T-Head specific
cache management operations.
The 'th' prefix and the "XTheadCmo" extension are documented in a PR
for the RISC-V toolchain conventions ([1]).

In total XTheadCmo introduces the following 21 instructions:

* DCACHE.{C,CI,I}ALL
* DCACHE.{C,CI,I}{PA,VA,SW} rs1
* DCACHE.C{PAL1,VAL1} rs1
* ICACHE.I{ALL,ALLS}
* ICACHE.I{PA,VA} rs1
* L2CACHE.{C,CI,I}ALL

Contrary to Zicbom, the XTheadCmo instructions don't have a constant
displacement, therefore we have a different syntax for the arguments.
To clarify this is intended behaviour, there is a set of negative test
for Zicbom-style arguments in x-thead-cmo-fail.s.

[1] https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/19

v2:
- Add missing DECLARE_INSN() list
- Fix ordering

Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com>
Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>

RISC-V: Add generic support for vendor extensions

This patch introduces changes that allow the integration of vendor ISA
extensions:
* Define a list of vendor extensions (riscv_supported_vendor_x_ext)
  where vendor extensions can be added
* Introduce a section with a table in the documentation where vendor
  extensions can be added

To add a vendor extension that consists of instructions only,
the following things need to be done:
* Add the extension to the riscv_supported_vendor_x_ext list
* Add lookup entry in riscv_multi_subset_supports
* Documenting the extension in c-riscv.texti
* Add test cases for all instructions
* Add MATCH*/MASK* constants and DECLARE_INSN() for all instructions
* Add new instruction class to enum riscv_insn_class
* Define the instructions in riscv_opcodes
* Additional changes if necessary (depending on the instructions)

Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com>
Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>

[gdb/symtab] Add all_comp_units/all_type_units views on all_units

Add all_comp_units/all_type_units views on all_units.

Having the views allows us to:
- easily get the number of CUs or TUs in all_units, and
- easily access the nth CU or TU.

This minimizes the use of tu_stats.nr_tus.

Tested on x86_64-linux.

[gdb/symtab] Rename all_comp_units to all_units

Mechanically rename all_comp_units to all_units:
...
$ sed -i 's/all_comp_units/all_units/' gdb/dwarf2/*
...

Tested on x86_64-linux.

opcodes: SH fix bank register disassemble.

* sh-dis.c (print_insn_sh): Enforce bit7 of LDC Rm,Rn_BANK and STC
Rm_BANK,Rn is always 1.

include: Add macro to ignore -Wunused-but-set-variable

"-Wunused-but-set-variable" warning option can be helpful to track variables
that are written but not read thereafter.  But it can be harmful if some of
the code is auto-generated and we have no ways to deal with it.

The particular example is Bison-generated code.

The new DIAGNOSTIC_IGNORE_UNUSED_BUT_SET_VARIABLE macro can be helpful on
such cases. A typical use of this macro is to place this macro before the
end of user prologues on Bison (.y) files.

include/ChangeLog:

    * diagnostics.h (DIAGNOSTIC_IGNORE_UNUSED_BUT_SET_VARIABLE): New.

include: Add macro to ignore -Wuser-defined-warnings

User-defined warnings (on Clang, "-Wuser-defined-warnings") can be harmful
if we have specified "-Werror" and we have no control to disable the warning
ourself.  The particular example is Gnulib.

Gnulib generates a warning if the system version of certain functions
are used (to redirect the developer to use Gnulib version).  However,
it can be harmful if we cannot easily replace them (e.g. the target is in
the standard C++ library).

The new DIAGNOSTIC_IGNORE_USER_DEFINED_WARNINGS macro can be helpful on such
cases.  A typical use of this macro is to place this macro before including
certain system headers.

include/ChangeLog:

* diagnostics.h (DIAGNOSTIC_IGNORE_USER_DEFINED_WARNINGS): New.

gdb/python: restrict the names accepted by gdb.register_window_type

I noticed that, from Python, I could register a new TUI window that
had whitespace in its name, like this:

  gdb.register_window_type('my window', MyWindowType)

however, it is not possible to then use this window in a new TUI
layout, e.g.:

  (gdb) tui new-layout foo my window 1 cmd 1
  Unknown window "my"
  (gdb) tui new-layout foo "my window" 1 cmd 1
  Unknown window ""my"
  (gdb) tui new-layout foo my\ window 1 cmd 1
  Unknown window "my\"

GDB clearly uses the whitespace to split the incoming command line.

I could fix this by trying to add a mechanism by which we can use
whitespace within a window name, but it seems like an easier solution
if we just forbid whitespace within a window name.  Not only is this
easier, but I think this is probably the better solution, identifier
names with spaces in would mean we'd need to audit all the places a
window name could be printed and ensure that the use of a space didn't
make the output ambiguous.

So, having decided to disallow whitespace, I then thought about other
special characters.  We currently accept anything as a window name,
and I wondered if this was a good idea.

My concerns were about how special characters used in a window name
might cause confusion, for example, we allow '$' in window names,
which is maybe fine now, but what if one day we wanted to allow
variable expansion when creating new layouts?  Or what about starting
a window name with '-'?  We already support a '-horizontal' option,
what if we want to add more in the future?  Or use of the special
character '{' which has special meaning within a new layout?

In the end I figured it might make sense to place some restrictive
rules in place, and then relax the rules later if/when users complain,
we can consider each relaxation as its requested.

So, I propose that window names should match this regular expression:

  [a-zA-Z][-_.a-zA-Z0-9]*

There is a chance that there is user code in the wild which will break
with the addition of this change, but hopefully adapting to the new
restrictions shouldn't be too difficult.

gdb/testsuite: Add test to step through function epilogue

The testsuite implicitly tests GDB's ability to step through epilogues
in multiple tests, without doing it explicitly anywhere.  This is
unfortunate, as clang does not emit epilogue information, so using clang
on our testsuite makes many tests fail.  This patch adds a central,
explicit test for walking through the epilogue so we can safely remove
this from other tests and have them working with clang.

The test created attempts to step through a simple epilogue, an
epilogue that ends on another epilogue, and epilogues leading to other
function calls.

gdb.base/skip.exp: Use finish to exit functions

gdb.base/skip.exp was making use of a fixed number of step commands to
exit some functions.  This caused some problems when using clang to test
GDB, as GDB would need fewer steps to reach the desired spots.  For
instance, when testing in the section "step after disabling 3", the log
looks like this:

    Breakpoint 4, main () at binutils-gdb/gdb/testsuite/gdb.base/skip.c:32
    32        x = baz ((bar (), foo ()));
    (gdb) step
    bar () at binutils-gdb/gdb/testsuite/gdb.base/skip1.c:21
    21        return 1;
    (gdb) PASS: gdb.base/skip.exp: step after disabling 3: step 1
    step
    foo () at binutils-gdb/gdb/testsuite/gdb.base/skip.c:42
    42        return 0;
    (gdb) PASS: gdb.base/skip.exp: step after disabling 3: step 2
    step
    main () at binutils-gdb/gdb/testsuite/gdb.base/skip.c:34
    34        test_skip_file_and_function ();
    (gdb) step
    test_skip_file_and_function () at binutils-gdb/gdb/testsuite/gdb.base/skip.c:59
    59        test_skip ();
    (gdb) FAIL: gdb.base/skip.exp: step after disabling 3: step 3
    step
    test_skip () at binutils-gdb/gdb/testsuite/gdb.base/skip.c:48
    48      }
    (gdb) PASS: gdb.base/skip.exp: step after disabling 3: step 4
    step
    test_skip_file_and_function () at binutils-gdb/gdb/testsuite/gdb.base/skip.c:60
    60        skip1_test_skip_file_and_function ();
    (gdb) FAIL: gdb.base/skip.exp: step after disabling 3: step 5

This shows that the feature is working but because the inferior lands in
a different location, it registers as a failure.  Seeing as along with
this difference, there are also some differences that depend on gcc
versions (where gdb might stop back at line 32 before entering foo), it
would not be easy to test for this behavior using steps and analzing
where the inferior stops at each point. On the other hand, using
gdb_step_until is not feasible because we'd possibly gloss over stepping
into baz and rendering the whole test useless.  Instead, skip.exp now
uses finish to leave functions, synchronizing through compilers and
compiler versions.  Some test names were also changed to be a bit more
descriptive.  The new log looks like this, independently of compiler used:

    Breakpoint 4, main () at binutils-gdb/gdb/testsuite/gdb.base/skip.c:32
    32        x = baz ((bar (), foo ()));
    (gdb) step
    bar () at binutils-gdb/gdb/testsuite/gdb.base/skip1.c:21
    21        return 1;
    (gdb) PASS: gdb.base/skip.exp: step after disabling 3: step into bar
    finish
    Run till exit from #0  bar () at binutils-gdb/gdb/testsuite/gdb.base/skip1.c:21
    main () at binutils-gdb/gdb/testsuite/gdb.base/skip.c:32
    32        x = baz ((bar (), foo ()));
    Value returned is $2 = 1
    (gdb) PASS: gdb.base/skip.exp: step after disabling 3: return from bar
    step
    foo () at binutils-gdb/gdb/testsuite/gdb.base/skip.c:42
    42        return 0;
    (gdb) PASS: gdb.base/skip.exp: step after disabling 3: step into foo
    finish
    Run till exit from #0  foo () at binutils-gdb/gdb/testsuite/gdb.base/skip.c:42
    main () at binutils-gdb/gdb/testsuite/gdb.base/skip.c:32
    32        x = baz ((bar (), foo ()));
    Value returned is $3 = 0
    (gdb) PASS: gdb.base/skip.exp: step after disabling 3: Return from foo
    step
    34        test_skip_file_and_function ();
    (gdb) PASS: gdb.base/skip.exp: step after disabling 3: step and skip baz

fix gdb.base/jit-elf.exp when testing with clang

When using clang as the compiler for the target, gdb.base/jit-elf.exp
was failing because the filename displayed when GDB attached to the
inferior was only showing up as with a relative path, like so:

       (gdb) attach 3674146
       Attaching to program: /home/blarsen/Documents/gdb-build/gdb/testsuite/outputs/gdb.base/jit-elf/jit-elf-main, process 3674146
       Reading symbols from /lib64/libm.so.6...
       Reading symbols from .gnu_debugdata for /lib64/libm.so.6...
       (No debugging symbols found in .gnu_debugdata for /lib64/libm.so.6)
       Reading symbols from /lib64/libc.so.6...
       (No debugging symbols found in /lib64/libc.so.6)
       Reading symbols from /lib64/ld-linux-x86-64.so.2...
       [Thread debugging using libthread_db enabled]
       Using host libthread_db library "/lib64/libthread_db.so.1".
       0x00000000004013ff in main (argc=3, argv=0x7fffffffd820) at ../../../common/git-repos/binutils-gdb/gdb/testsuite/gdb.base/jit-elf-main.c:118
       118|  WAIT_FOR_GDB; i = 0;  /* gdb break here 1 */
       (gdb) FAIL: gdb.base/jit-elf.exp: attach: one_jit_test-2: break here 1: attach

While gcc's output is as follows:

       (gdb) attach 3592961
       Attaching to program: /home/blarsen/Documents/gdb-build/gdb/testsuite/outputs/gdb.base/jit-elf/jit-elf-main, process 3592961
       Reading symbols from /lib64/libm.so.6...
       Reading symbols from .gnu_debugdata for /lib64/libm.so.6...
       (No debugging symbols found in .gnu_debugdata for /lib64/libm.so.6)
       Reading symbols from /lib64/libc.so.6...
       (No debugging symbols found in /lib64/libc.so.6)
       Reading symbols from /lib64/ld-linux-x86-64.so.2...
       [Thread debugging using libthread_db enabled]
       Using host libthread_db library "/lib64/libthread_db.so.1".
       main (argc=3, argv=0x7fffffffd860) at /home/blarsen/Documents/gdb-build/gdb/testsuite/../../../common/git-repos/binutils-gdb/gdb/testsuite/gdb.base/jit-elf-main.c:118
       118|  WAIT_FOR_GDB; i = 0;  /* gdb break here 1 */
       (gdb) PASS: gdb.base/jit-elf.exp: attach: one_jit_test-2: break here 1: attach

This difference only happens when GDB's configure is ran using a
relative path, but seeing as testing the full path is not important for
this specific test, it feels worth fixing anyway.  To fix the false
positive, the regexp for checking where gdb has stopped was relaxed a
little to allow the relative path.

gdb/testsuite: fix gdb.base/msym-bp-shl when running with Clang

When trying to test gdb.base/msym-bp-shl.exp using clang, it would have
many failures because one of the version of the foo function was being
optimized away. Adding __attribute__ ((used)) to it fixed this.

gdb/testsuite: fix testing gdb.base/skip-inline.exp with clang

When testing gdb.base/skip-inline.exp using clang, we get failures
when trying to step out of functions, since clang requires one fewer
step when compared to gcc.  The inferior gets increasingly out of sync
as the test continues because of this difference, which generates those
failures.

This commit fixes this by switching those hardcoded steps to
gdb_step_until, to guarantee that the inferior is always synced to what
the test expects.  This approach does not work for the parts that use
step 2 or step 3, so when we identify that clang is being used, those
tests are skipped.

Change gdb.base/skip-solib.exp deal with lack of epilogue information

When running gdb.base/skip-solib.exp, the backtrace tests could fail with
compilers that associated epilogue instructions with the last statement
line of the function, instead of associating it with the closing brace,
despite the feature being fully functional.  As an example, when testing
skipping the function square, the testsuite would show

Breakpoint 1, main () at (...)/binutils-gdb/gdb/testsuite/gdb.base/skip-solib-main.c:5
5         return square(0);
(gdb) step
0x00007ffff7cef560 in __libc_start_call_main () from /lib64/libc.so.6
(gdb) PASS: gdb.base/skip-solib.exp: ignoring solib file: step
bt
 #0  0x00007ffff7cef560 in __libc_start_call_main () from /lib64/libc.so.6
 #1  0x00007ffff7cef60c in __libc_start_main_impl () from /lib64/libc.so.6
 #2  0x0000000000401065 in _start ()
(gdb) FAIL: gdb.base/skip-solib.exp: ignoring solib file: bt

Which means that the feature is working, the testsuite is just
mis-identifying it.  To avoid this problem, the skipped function calls
have been sent to a line before `return`, so epilogues won't factor in.

gdb/testsuite: Add a proc to test where compiler links the epilogue

Different compilers link the epilogue of functions to different lines.
As an example, gcc links it to the closing brace of the function,
whereas clang links it to the last statement of the function.  This
difference is important for the testsuite, since the where GDB will land
after a step can be wildly different.  Where possible, this dependency
should be side-stepped in the testsuite, but it isn't always possible,
so this commit adds a gdb_caching_proc that is able to detect where the
epilogue is linked, so tests can react accordingly.

ld/testsuite: allow to force another directory for gcc linker

Add a new variable "ld_testsuite_tmpdir" to enable manual configuration
of the -B flag added to gcc calls. This flag ensure that gcc is invoking
the linker and the assembler we want to test.

When launching the testsuite outside of the build tree, the links made
by the testsuite in tmpdir/ld will point to nothing. Thus, even with the
PATH correctly setup towards the linker directory, gcc might end up
falling back to its default linker. Hence this variable to ensure that
gcc, whatever happens, is using the linker we want.

ld/ChangeLog:

* testsuite/config/default.exp: Allow to change -B flag with
ld_testsuite_bindir variable.

ld/testsuite: skip bootstrap.exp when OFILES are missing

OFILES are normally provided through an environment variable set by
Makefiles. However, when launching the testsuite directly through
runtest outside the build tree, it can be hard to retrieve them.
Thus, they can be missing.
Instead of letting tcl raise an error when trying to access this
OFILES variable, skip bootstrap.exp if it doesn't exist.

ld/ChangeLog:

* testsuite/ld-bootstrap/bootstrap.exp: Skip if OFILES is
missing

RISC-V: Remove "b" operand type from disassembler

There are a few operand types not used by any RISC-V instructions.

-   Cx
-   Vf
-   Ve
-   [
-   ]
-   b

But most of them has a reasoning to keep them:

-   Cx     : Same as "Ct" except it has a constraint to have rd == rs2
     (similar to "Cw").  Although it hasn't used, its role is clear
     enough to implement a new instruction with this operand type.
-   Vf, Ve : Used by vector AMO instructions (not ratified and real
     instructions are not upstreamed yet).
-   [, ]   : Unused tokenization symbols.  Reserving them is not harmful
     and a vendor may use this symbol for special purposes.

... except "b".  I could not have found any reference to this operand type
except it works like the "s" operand type.  Historically, it seems... it's
just unused from the beginning.  Its role is not clear either.

On such cases, we should vacate this room for the new operand type with
much clearer roles.

opcodes/ChangeLog:

* riscv-dis.c (print_insn_args): Remove 'b' operand type.

RISC-V: Add macro-only operands to validate_riscv_insn

Although they are not (and should not be) reachable, following macro-only
operands are parsed in the `validate_riscv_insn' function and ignored.
That function also notes that they are macro-only.

-   "A"
-   "B"
-   "I"

Following this convention, this commit adds three remaining macro-only
operands to this function.  By doing this, we could instead choose to reject
those operands from appearing in regular instructions later.

-   "c"   (used by call, tail and jump macros)
-   "VM"  (used by vmsge.vx and vmsgeu.vx macros)
-   "VT"  (likewise)

gas/ChangeLog:

* config/tc-riscv.c (validate_riscv_insn): Add "c", "VM" and "VT"
macro-only operand types.

gprofng: fix -Wduplicated-cond warning

gprofng/ChangeLog
2022-09-21  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

* src/collctrl.cc: Fix -Wduplicated-cond warning.

Automatic date update in version.in

bfd BLD-POTFILES.in dependencies

A file that consists of a list of files doesn't depend on those files
being built.  This patch came from trying to avoid a maintainer-mode
make -j bug, where the recipe for targmatch.h was being run twice in
parallel.  Typical output shown below.

make[2]: Entering directory '/build/gas/all/bfd'
  GEN      bfdver.h
  GEN      elf32-target.h
  GEN      elf64-target.h
  GEN      targmatch.h
Making info in po
make[3]: Entering directory '/build/gas/all/bfd/po'
cd .. && make po/SRC-POTFILES.in
cd .. && make po/BLD-POTFILES.in
make[4]: Entering directory '/build/gas/all/bfd'
  GEN      elf32-aarch64.c
  GEN      elf64-aarch64.c
  GEN      elf32-ia64.c
  GEN      elf64-ia64.c
  GEN      elf32-loongarch.c
  GEN      elf64-loongarch.c
  GEN      elf32-riscv.c
  GEN      elf64-riscv.c
  GEN      peigen.c
  GEN      pepigen.c
  GEN      pex64igen.c
  GEN      pe-aarch64igen.c
  GEN      targmatch.h
make[4]: Entering directory '/build/gas/all/bfd'
  CCLD     doc/chew.stamp
mv: cannot stat 'targmatch.new': No such file or directory
make[4]: *** [Makefile:2325: targmatch.h] Error 1

* Makefile.am (po/BLD-POTFILES.in): Don't depend on $(BLD_POTFILES).
(po/SRC-POTFILES.in): Don't depend on $(SRC_POTFILES).

gdbsupport: move fileio_errno_to_host to fileio.{h,cc} and rename

gdb_bfd.c and remote.c contain identical implementations of a
fileio_error -> errno function.  Factor that out to
gdbsupport/fileio.{h,cc}.

Rename it fileio_error_to_host, for symmetry with host_to_fileio_error.

Change-Id: Ib9b8807683de2f809c94a5303e708acc2251a0df

gdbsupport: convert FILEIO_* macros to an enum

Converting from free-form macros to an enum gives a bit of type-safety.
This caught places where we would assign host error numbers to what
should contain a target fileio error number, for instance in
target_fileio_pread.

I added the FILEIO_SUCCESS enumerator, because
remote.c:remote_hostio_parse_result initializes the remote_errno output
variable to 0.  It seems better to have an explicit enumerator than to
assign a value for which there is no enumerator.  I considered
initializing this variable to FILEIO_EUNKNOWN instead, such that if the
remote side replies with an error and omits the errno value, we'll get
an errno that represents an error instead of 0 (which reprensents no
error).  But it's not clear what the consequences of that change would
be, so I prefer to err on the side of caution and just keep the existing
behavior (there is no intended change in behavior with this patch).

Note that remote_hostio_parse_resul still reads blindly what the remote
side sends as a target errno into this variable, so we can still end up
with a nonsensical value here.  It's not good, but out of the scope of
this patch.

Convert host_to_fileio_error and fileio_errno_to_host to return / accept
a fileio_error instead of an int, and cascade the change in the whole
chain that uses that.

Change-Id: I454b0e3fcf0732447bc872252fa8e57d138b0e03