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

gdbsupport: move include/gdb/fileio.h contents to fileio.h

I don't see why include/gdb/fileio.h is placed there.  It's not
installed by "make install", and it's not included by anything outside
of gdb/gdbserver/gdbsupport.

Move its content back to gdbsupport/fileio.h.  I have omitted the bits
inside an `#if 0`, since it's obviously not used, as well as the
"limits" constants, which are also unused.

Change-Id: I6fbc2ea10fbe4cfcf15f9f76006b31b99c20e5a9

gdbsupport: change path_join parameter to array_view<const char *>

When a GDB built with -D_GLIBCXX_DEBUG=1 reads a binary with a single
character name, we hit this assertion failure:

    $ ./gdb -q --data-directory=data-directory -nx ./x
    /usr/include/c++/12.1.0/string_view:239: constexpr const std::basic_string_view<_CharT, _Traits>::value_type& std::basic_string_view<_CharT, _Traits>::operator[](size_type) const [with _CharT = char; _Traits = std::char_traits<char>; const_reference = const char&; size_type = long unsigned int]: Assertion '__pos < this->_M_len' failed.

The backtrace:

    #3  0x00007ffff6c0f002 in std::__glibcxx_assert_fail (file=<optimized out>, line=<optimized out>, function=<optimized out>, condition=<optimized out>) at /usr/src/debug/gcc/libstdc++-v3/src/c++11/debug.cc:60
    #4  0x000055555da8a864 in std::basic_string_view<char, std::char_traits<char> >::operator[] (this=0x7fffffffcc30, __pos=1) at /usr/include/c++/12.1.0/string_view:239
    #5  0x00005555609dcb88 in path_join[abi:cxx11](gdb::array_view<std::basic_string_view<char, std::char_traits<char> > const>) (paths=...) at /home/simark/src/binutils-gdb/gdbsupport/pathstuff.cc:203
    #6  0x000055555e0443f4 in path_join<char const*, char const*> () at /home/simark/src/binutils-gdb/gdb/../gdbsupport/pathstuff.h:84
    #7  0x00005555609dc336 in gdb_realpath_keepfile[abi:cxx11](char const*) (filename=0x6060000a8d40 "/home/simark/build/binutils-gdb-one-target/gdb/./x") at /home/simark/src/binutils-gdb/gdbsupport/pathstuff.cc:122
    #8  0x000055555ebd2794 in exec_file_attach (filename=0x7fffffffe0f9 "./x", from_tty=1) at /home/simark/src/binutils-gdb/gdb/exec.c:471
    #9  0x000055555f2b3fb0 in catch_command_errors (command=0x55555ebd1ab6 <exec_file_attach(char const*, int)>, arg=0x7fffffffe0f9 "./x", from_tty=1, do_bp_actions=false) at /home/simark/src/binutils-gdb/gdb/main.c:513
    #10 0x000055555f2b7e11 in captured_main_1 (context=0x7fffffffdb60) at /home/simark/src/binutils-gdb/gdb/main.c:1209
    #11 0x000055555f2b9144 in captured_main (data=0x7fffffffdb60) at /home/simark/src/binutils-gdb/gdb/main.c:1319
    #12 0x000055555f2b9226 in gdb_main (args=0x7fffffffdb60) at /home/simark/src/binutils-gdb/gdb/main.c:1344
    #13 0x000055555d938c5e in main (argc=5, argv=0x7fffffffdcf8) at /home/simark/src/binutils-gdb/gdb/gdb.c:32

The problem is this line in path_join:

    gdb_assert (strlen (path) == 0 || !IS_ABSOLUTE_PATH (path));

... where `path` is "x".  IS_ABSOLUTE_PATH eventually calls
HAS_DRIVE_SPEC_1:

    #define HAS_DRIVE_SPEC_1(dos_based, f)                  \
      ((f)[0] && ((f)[1] == ':') && (dos_based))

This macro accesses indices 0 and 1 of the input string.  However, `f`
is a string_view of length 1, so it's incorrect to try to access index
1.  We know that the string_view's underlying object is a null-terminated
string, so in practice there's no harm.  But as far as the string_view
is concerned, index 1 is considered out of bounds.

This patch makes the easy fix, that is to change the path_join parameter
from a vector of to a vector of `const char *`.  Another solution would
be to introduce a non-standard gdb::cstring_view class, which would be a
view over a null-terminated string.  With that class, it would be
correct to access index 1, it would yield the NUL character.  If there
is interest in having this class (it has been mentioned a few times in
the past) I can do it and use it here.

This was found by running tests such as gdb.ada/arrayidx.exp, which
produce 1-char long filenames, so adding a new test is not necessary.

Change-Id: Ia41a16c7243614636b18754fd98a41860756f7af

gdb: remove TYPE_LENGTH

Remove the macro, replace all uses with calls to type::length.

Change-Id: Ib9bdc954576860b21190886534c99103d6a47afb

gdb: add type::length / type::set_length

Add the `length` and `set_length` methods on `struct type`, in order to remove
the `TYPE_LENGTH` macro.  In this patch, the macro is changed to use the
getter, so all the call sites of the macro that are used as a setter are
changed to use the setter method directly.  The next patch will remove the
macro completely.

Change-Id: Id1090244f15c9856969b9be5006aefe8d8897ca4

gdb: remove TYPE_TARGET_TYPE

Remove the macro, replace all uses by calls to type::target_type.

Change-Id: Ie51d3e1e22f94130176d6abd723255282bb6d1ed

gdb: add type::target_type / type::set_target_type

Add the `target_type` and `set_target_type` methods on `struct type`, in order
to remove the `TYPE_TARGET_TYPE` macro.  In this patch, the macro is changed to
use the getter, so all the call sites of the macro that are used as a setter
are changed to use the setter method directly.  The next patch will remove the
macro completely.

Change-Id: I85ce24d847763badd34fdee3e14b8c8c14cb3161

RISC-V: Fix riscv_set_tso declaration

To avoid -Werror=strict-prototypes, this commit changes () to (void).
This is because "()" possibly means a function prototype with indeterminate
arguments on old C standards.

gas/ChangeLog:

* config/tc-riscv.c (riscv_set_tso): Fix declaration.

PR29566, objdump -p considers an empty .gnu.version_r invalid

Allow and ignore an empty section.

PR 29566
* elf.c (bfd_section_from_shdr): Don't set elf_dynverdef or
elf_dynverref for empty sections.
(_bfd_elf_slurp_version_tables): Remove now redundant tests.

RISC-V: Set EF_RISCV_TSO also on .option arch

This is a minor fix to commit 96462b012988d35ebb1137a2ad9fd0a96547d79a
("RISC-V: Implement Ztso extension").  Currently, it sets EF_RISCV_TSO ELF
flag when initial ISA string contains the 'Ztso' extension.  However, GAS
has a way to update the ISA string: ".option arch".

When the architecture is updated by ".option arch", EF_RISCV_RVC ELF flag
is set when the 'C' extension is detected.  Analogously, this commit sets
the EF_RISCV_TSO when the 'Ztso' extension is detected.

gas/ChangeLog:

* config/tc-riscv.c (s_riscv_option): Set TSO ELF flag if the
'Ztso' extension is specified via ".option arch" directive.

PR29573, addr2line doesn't display file/line for local symbols

The DWARF standard is clear that DW_AT_linkage_name is optional.
Compilers may not provide the attribute on functions and variables,
even though the language mangles names.  g++ does not for local
variables and functions.  Without DW_AT_linkage_name, mangled object
file symbols can't be directly matched against the source-level
DW_AT_name in DWARF info.  One possibility is demangling the object
file symbols, but that comes with its own set of problems:
1) A demangler might not be available for the compiler/language.
2) Demangling doesn't give the source function name as stored in
   DW_AT_name.  Class and template parameters must be stripped at
   least.

So this patch takes a simpler approach.  A symbol matches DWARF info
if the DWARF address matches the symbol address, and if the symbol
name contains the DWARF name as a sub-string.  Very likely the name
matching is entirely superfluous.

PR 29573
* dwarf.c (lookup_symbol_in_function_table): Match a symbol
containing the DWARF source name as a substring.
(lookup_symbol_in_variable_table): Likewise.
(_bfd_dwarf2_find_nearest_line_with_alt): If stash_find_line_fast
returns false, fall back to comp_unit_find_line.

dwarf2.c: simplify best_fit_len tests

* dwarf2.c (lookup_address_in_function_table): Simplify
best_fit_len test.
(info_hash_lookup_funcinfo): Likewise.
(lookup_symbol_in_function_table): Likewise, also reorder tests
and check "file" is set.
(lookup_symbol_in_variable_table): Reorder tests.

dwarf2.c: mangle_style

non_mangled incorrectly returned "true" for Ada.  Correct that, and
add a few more non-mangled entries.  Return a value suitable for
passing to cplus_demangle to control demangling.

* dwarf2.c: Include demangle.h.
(mangle_style): Rename from non_mangled.  Return DMGL_* value
to suit lang.  Adjust all callers.

dwarf2.c remove varinfo and funcinfo sec field

The "sec" field in these structures is only set and used in lookup
functions.  It always starts off as NULL.  So the only possible effect
of the field is to modify the return of the lookup, which was its
purpose back in 2005 when HJ fixed PR990.  Since then we solved the
problem of relocatable object files with the fix for PR2338, so this
field is now redundant.

* dwarf.c (struct funcinfo, struct varinfo): Remove "sec" field.
(lookup_symbol_in_function_table): Don't set or test "sec".
(lookup_symbol_in_variable_table): Likewise.
(info_hash_lookup_funcinfo, info_hash_lookup_varinfo): Likewise.

configure: Pass CPPFLAGS_FOR_BUILD to subdirs

Because CPPFLAGS_FOR_BUILD is used in some subdirectories (through
bfd/warning.m4), not AC_SUBSTing the variable causes minor issues.

Fortunately, it didn't cause severe errors but error messages related to
@CPPFLAGS_FOR_BUILD@ (not AC_SUBSTed CPPFLAGS_FOR_BUILD variable passed
to subdirectories through Makefile) remain in config.log.

To avoid invalid invocation of preprocessor for build environment, we
need to set proper CPPFLAGS_FOR_BUILD (may be empty) and pass it to
subdirectories that need it.  This is what this commit does.

ChangeLog:

* configure.ac: Pass CPPFLAGS_FOR_BUILD to subdirectories.
* configure: Regenerate.

RISC-V: Implement Ztso extension

This patch support ZTSO extension. It will turn on the tso flag for elf_flags
once we have enabled Ztso extension.  This is intended to implement v0.1 of
the proposed specification which can be found in Chapter 25 of,
https://github.com/riscv/riscv-isa-manual/releases/download/draft-20220723-10eea63/riscv-spec.pdf.

bfd\ChangeLog:

        * elfnn-riscv.c (_bfd_riscv_elf_merge_private_bfd_data): Set TSO flag.
        * elfxx-riscv.c: Add Ztso's arch.

binutils\ChangeLog:

        * readelf.c (get_machine_flags): Set TSO flag.

gas\ChangeLog:

        * config/tc-riscv.c (riscv_set_tso): Ditto.
        (riscv_set_arch): Ditto.
        * testsuite/gas/riscv/ztso.d: New test.

include\ChangeLog:

        * elf/riscv.h (EF_RISCV_TSO): Ditto.

RISC-V: Always generate R_RISCV_CALL_PLT reloc for call in assembler.

Since we have the same behaviors of CALL and CALL_PLT relocs in linker for now,
https://github.com/bminor/binutils-gdb/commit/3b1450b38c644f99aa2e211747b428b9f8d15cca

And the psabi already deprecate the CALL reloc,
https://github.com/riscv-non-isa/riscv-elf-psabi-doc/commit/a0dced85018d7a0ec17023c9389cbd70b1dbc1b0

Therefore, we should always generate R_RISCV_CALL_PLT reloc for call, even if
it has @plt postfix.  I believe LLVM (https://reviews.llvm.org/D132530) already
support this, so GNU as should do the same thing.

gas/
* config/tc-riscv.c (riscv_ip): Always generate CALL_PLT reloc for
call, even if it has @plt postfix.
* testsuite/gas/riscv/no-relax-reloc.d: Updated CALL to CALL_PLT.
* testsuite/gas/riscv/relax-reloc.d: Likewise.
ld/
* testsuite/ld-riscv-elf/variant_cc-r.d: Updated CALL to CALL_PLT.

Automatic date update in version.in

Re: PowerPC64 pcrel got relocs against local symbols

The last patch wasn't all that shiny.  There are rather a lot more
relocations that can hit the assertion in md_apply_fix if the symbol
is local or absolute.  Fix them all.

* config/tc-ppc.c (ppc_force_relocation): Add all relocs that
expect a symbol in md_apply_fix.  Remove tls pcrel relocs
already covered in general tls match range.

looping in alpha_vms_slurp_relocs

The direct cause for the looping was failing to test for error return
from _bfd_vms_get_object_record inside a while(1) loop.  Fix that.
Also record status of first alpha_vms_slurp_relocs call and return
that for all subsequent calls.  (The object format has one set of
relocation records for all sections.)  If the first call fails, all
others should too.

* vms-alpha.c (struct vms_private_data_struct): Make reloc_done
a tri-state int.
(alpha_vms_slurp_relocs): Set reloc_done to 1 on success, -1 on
failure.  Return that status on subsequent calls.  Check
_bfd_vms_get_object_record return status.
(alpha_vms_get_reloc_upper_bound): Return status from
alpha_vms_slurp_relocs.
(alpha_vms_write_exec): Exclude sections with contents NULL due
to previous errors from layout, and don't try to write them.

ppc/svp64: test setvl ms operand

Make stdin_event_handler static

I noticed that stdin_event_handler is only used in event-top.c, so
this patch changes it to be 'static'.

Constify some target_so_ops instances

This changes some target_so_ops instances to be const.  This makes
their use a little more obvious (they can't be mutated) and also
allows for the removal of some initialization code.

Move solib_ops into gdbarch

This changs solib_ops to be an ordinary gdbarch value and updates all
the uses.  This removes a longstanding FIXME and makes the code
somewhat cleaner as well.

Remove current_target_so_ops

current_target_so_ops is only set in a single place.  It seems better
to simply remove it.

gdb/testsuite: add a debuginfod-support.exp helper library

We currently have a single test for GDB's debuginfod support, this is
gdb.debuginfod/fetch_src_and_symbols.exp, this script does all the
setup, starts debuginfod, and then does the testing.

This commit tries to split the existing script in two, there is a new
library lib/debuginfod-support.exp, which contains a helper functions
related to running debuginfod tests.  All the code in the new library
is basically copied from the existing test case (which is why I
retained the copyright date range on the new library), with some minor
adjustments to try and make the code a little more generic.

One change I made, for example, is the library offers functions to
shut down debuginfod, previously we just relied on expect shutting
down debuginfod when dejagnu completed.

The existing test script is updated to make use of the new library
code, and this test is still passing for me.  The only change in the
test results is a single test where I changed the name to remove the
port number from the test name - the port number can change from run
to run, so could make it hard to compare test results.

I have also done a little light house keeping on the original test
script, updating and adding new comments, and making use of
proc_with_prefix in a couple of places.

LoongArch: Set macro SUB_SEGMENT_ALIGN to 0.

Stop strip from complaining about empty note sections when stripping a binary for a second time.

* objcopy.c (copy_object): Do not issue a warning message when
encountering empty .gnu.build.attribute sections.

New Serbian translations for various binutils sub-directories.

Bug 29580 - typo in warning message: .note.gnu.build-id data size is too bug

LoongArch: Fix R_LARCH_IRELATIVE insertion after elf_link_sort_relocs

loongarch_elf_finish_dynamic_symbol is called after elf_link_sort_relocs
if -z combreloc.  elf_link_sort_relocs redistributes the contents of
.rela.* sections those would be merged into .rela.dyn, so the slot for
R_LARCH_IRELATIVE may be out of relplt->contents now.

To make things worse, the boundary check

    dyn < dyn + relplt->size / sizeof (*dyn)

is obviously wrong ("x + 10 < x"? :), causing the issue undetected
during the linking process and the resulted executable suddenly crashes
at runtime.

The issue was found during an attempt to add static-pie support to the
toolchain.

Fix it by iterating through the inputs of .rela.dyn to find the slot.

LoongArch: Don't write into GOT for local ifunc

Local ifuncs are always resolved at runtime via R_LARCH_IRELATIVE, so
there is no need to write anything into GOT.  And when we write the GOT
we actually trigger a heap-buffer-overflow: If a and b are different
sections, we cannot access something in b with "a->contents + (offset
from a)" because "a->contents" and "b->contents" are heap buffers
allocated separately, not slices of a large buffer.

So stop writing into GOT for local ifunc now.

Automatic date update in version.in

gprofng: build documentation only if BUILD_MAN is true

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

PR gprofng/29476
* gprofng/Makefile.am: Build documentation only if BUILD_MAN is true
* gprofng/Makefile.in: Rebuild.
* gprofng/configure: Rebuild.

gdb: add ATTRIBUTE_PRINTF to gdb_bfd_error_handler

I see this error when building with clang,

  CXX    gdb_bfd.o
gdb_bfd.c:1180:43: error: format string is not a string literal [-Werror,-Wformat-nonliteral]
  const std::string str = string_vprintf (fmt, ap_copy);
                                          ^~~
1 error generated.

This patch adds missing ATTRIBUTE_PRINTF to fix the error.

Tested on x86_64-linux with gcc 12 and clang 14.

Automatic date update in version.in

Automatic date update in version.in

[gdb/symtab] Fix "file index out of range" complaint

With the test-case included in this commit, we run into this FAIL:
...
(gdb) p var^M
During symbol reading: file index out of range^M
$1 = 0^M
(gdb) FAIL: gdb.dwarf2/dw2-no-code-cu.exp: p var with no complaints
...

This is a regression since commit 6d263fe46e0 ("Avoid bad breakpoints with
--gc-sections"), which contains this change in read_file_scope:
...
-  handle_DW_AT_stmt_list (die, cu, fnd, lowpc);
+  if (lowpc != highpc)
+    handle_DW_AT_stmt_list (die, cu, fnd, lowpc);
...

The change intends to avoid a problem with a check in
lnp_state_machine::check_line_address, but also prevents the file and dir
tables from being read, which causes the complaint.

Fix the FAIL by reducing the scope of the "lowpc != highpc" condition to the
call to dwarf_decode_lines in handle_DW_AT_stmt_list.

Tested on x86_64-linux.

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

Automatic date update in version.in

BFD error message suppression test case

This commit adds a GDB test case which tests GDB's BFD error handler
hook for suppressing output of all but the first identical messages.

See the comment at the beginning of bfd-errors.exp for details about
this new test.

I've tested this test for both 32- and 64-bit ELF files and also
on both little endian and big endian machines.  It also works for
both native and remote targets.  The only major restriction is that
it only works for ELF targets.

Suppress printing of superfluous BFD error messages

This commit adds a hook to the BFD error handler for suppressing
identical messages which have been output once already.

It's motivated by this Fedora bug...

https://bugzilla.redhat.com/show_bug.cgi?id=2083315

...in which over 900,000 BFD error messages are output when attaching
to firefox.  From the bug report, the messages all say:

BFD: /usr/lib/debug/usr/lib64/firefox/libxul.so-100.0-2.fc35.x86_64.debug: attempt to load strings from a non-string section (number 38)

Since there's no (additional) context which might assist the user in
determining what's wrong, there's really no point in outputting more
than one message.  Of course, if BFD should output some
other/different message, it should be output too, but all future
messages identical to those already output should be suppressed.

For the firefox problem, it turned out that there were only 37
sections, but something was referring to section #38.  I haven't
investigated further to find out how this came to be.

Despite this problem, useful debugging might still be done, especially
if the user doesn't care about debugging the problematic library.

If it turns out that knowing the quantity of messages might be useful,
I've implemented the suppression mechanism by keeping a count of each
identical message.  A new GDB command, perhaps a 'maintenance'
command, could be added to print out each message along with the
count.  I haven't implemented this though because I'm not convinced of
its utility.  Also, the BFD message printer has support for BFD-
specific format specifiers.  The BFD message strings that GDB stores
in its map are sufficient for distinguishing messages from each
other, but are not identical to those output by BFD's default error
handler.  So, that problem would need to be solved too.

[gdb/symtab] Handle named DW_TAG_unspecified_type DIE

With the test-case included in the patch, we run into:
...
(gdb) info types -q std::nullptr_t^M
During symbol reading: unsupported tag: 'DW_TAG_unspecified_type'^M
^M
File /usr/include/c++/7/x86_64-suse-linux/bits/c++config.h:^M
2198:   typedef decltype(nullptr) std::nullptr_t;^M
(gdb) FAIL: gdb.dwarf2/nullptr_t.exp: info types -q std::nullptr_t \
  without complaint
...

Fix the complaint by handling DW_TAG_unspecified_type in new_symbol, and verify
in the test-case using "maint print symbols" that the symbol exists.

Tested on x86_64-linux, with gcc 7.5.0 and clang 13.0.

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

[gdb/tdep] Fix PowerPC IEEE 128-bit format arg passing

On a powerpc system with gcc 12 built to default to 128-bit IEEE long double,
I run into:
...
(gdb) print find_max_long_double_real(4, ldc1, ldc2, ldc3, ldc4)^M
$8 = 0 + 0i^M
(gdb) FAIL: gdb.base/varargs.exp: print \
  find_max_long_double_real(4, ldc1, ldc2, ldc3, ldc4)
...

This is due to incorrect handling of the argument in ppc64_sysv_abi_push_param.

Fix this and similar cases, and expand the test-case to test handling of
homogeneous aggregates.

Tested on ppc64le-linux, power 10.

Co-Authored-By: Ulrich Weigand <uweigand@de.ibm.com>
Tested-by: Carl Love <cel@us.ibm.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29543

[gdb/testsuite] Fix gdb.dwarf2/dw2-dir-file-name.exp for aarch64

[ Another attempt at fixing the problem described in commit cd919f5533c
("[gdb/testsuite] Fix gdb.dwarf2/dw2-dir-file-name.exp"). ]

When running the test-case gdb.dwarf2/dw2-dir-file-name.exp with
aarch64-linux, we run into:
...
(gdb) continue^M
Continuing.^M
^M
Breakpoint 2, compdir_missing__ldir_missing__file_basename () at \
  tmp-dw2-dir-file-name.c:999^M
(gdb) FAIL: gdb.dwarf2/dw2-dir-file-name.exp: \
  compdir_missing__ldir_missing__file_basename: continue to breakpoint: \
  compdir_missing__ldir_missing__file_basename
...

The breakpoint set at compdir_missing__ldir_missing__file_basename_label,
address 0x400608 starts at a line entry:
...
CU: tmp-dw2-dir-file-name.c:
File name                    Line number    Starting address    View    Stmt
tmp-dw2-dir-file-name.c              999            0x400608               x
tmp-dw2-dir-file-name.c             1000            0x40062c               x
tmp-dw2-dir-file-name.c                -            0x40062c
...
and therefore the breakpoint is printed without instruction address.

In contrast, for x86_64-linux, we have the breakpoint printed with instruction
address:
...
(gdb) continue^M
Continuing.^M
^M
Breakpoint 2, 0x004004c1 in compdir_missing__ldir_missing__file_basename () \
  at tmp-dw2-dir-file-name.c:999^M
(gdb) PASS: gdb.dwarf2/dw2-dir-file-name.exp: \
  compdir_missing__ldir_missing__file_basename: continue to breakpoint: \
  compdir_missing__ldir_missing__file_basename
...

The breakpoint set at compdir_missing__ldir_missing__file_basename_label,
address 0x004004c1 doesn't start at a line entry:
...
CU: tmp-dw2-dir-file-name.c:
File name                    Line number    Starting address    View    Stmt
tmp-dw2-dir-file-name.c              999            0x4004bd               x
tmp-dw2-dir-file-name.c             1000            0x4004d3               x
tmp-dw2-dir-file-name.c                -            0x4004d3
...

Fix this by:
- unifying behaviour between the archs by adding an explicit line number entry
  for the address compdir_missing__ldir_missing__file_basename_label, making
  the FAIL reproducible on x86_64-linux.
- expecting the breakpoint to be printed without instruction address.

Tested on x86_64-linux and aarch64-linux.

[gdb] Handle pending ^C after rl_callback_read_char

In completion tests in various test-cases, we've been running into these
"clearing input line" timeouts:
...
(gdb) $cmd^GPASS: gdb.gdb/unittest.exp: tab complete "$cmd"
FAIL: gdb.gdb/unittest.exp: tab complete "$cmd" (clearing input line) (timeout)
...
where $cmd == "maintenance selftest name_that_does_not_exist".

AFAIU, the following scenario happens:
- expect sends "$cmd\t"
- gdb detects the stdin event, and calls rl_callback_read_char until it
  comes to handle \t
- readline interprets the \t as completion, tries to complete, fails to do so,
  outputs a bell (^G)
- expect sees the bell, and proceeds to send ^C
- readline is still in the call to rl_callback_read_char, and stores the
  signal in _rl_caught_signal
- readline returns from the call to rl_callback_read_char, without having
  handled _rl_caught_signal
- gdb goes to wait for the next event
- expect times out waiting for "Quit", the expected reaction for ^C

Fix this by handling pending signals after each call to rl_callback_read_char.

The fix is only available for readline 8.x, if --with-system-readline provides
an older version, then the fix is disabled due to missing function
rl_check_signals.

Tested on x86_64-linux.

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

PowerPC64 pcrel got relocs against local symbols

Not that anyone would want to indirect via the GOT when an address can
be loaded directly with pla, the following:

 pld 3,x@got@pcrel
x:

leads to "Internal error in md_apply_fix", because the generic parts
of assembler fixup handling convert the fx_pcrel fixup to one without
a symbol.  Stop that happening.

* config/tc-ppc.c (ppc_force_relocation): Add PLT_PCREL34 and
assorted GOT_PCREL34 relocs.

pdb sanity check block_size

* pdb.c (pdb_get_elt_at_index): Only allow block_size to be
512, 1024, 2048, or 4096.