[gdb/tdep] Fix gdb.base/msym-bp-shl.exp for ppc64le

With test-case gdb.base/msym-bp-shl.exp on powerpc64le-linux, I run into:
...
(gdb) PASS: gdb.base/msym-bp-shl.exp: debug=0: before run: break foo
info breakpoint^M
Num     Type           Disp Enb Address            What^M
1       breakpoint     keep y   <MULTIPLE>         ^M
1.1                         y   0x00000000000008d4 <foo+12>^M
1.2                         y   0x0000000000000a34 crti.S:88^M
(gdb) FAIL: gdb.base/msym-bp-shl.exp: debug=0: before run: info breakpoint
...

The problem is that the prologue skipper walks from foo@plt at 0xa28 to 0xa34:
...
0000000000000a28 <foo@plt>:
 a28:   c0 ff ff 4b     b       9e8 <__glink_PLTresolve>

Disassembly of section .fini:

0000000000000a2c <_fini>:
 a2c:   02 00 4c 3c     addis   r2,r12,2
 a30:   d4 74 42 38     addi    r2,r2,29908
 a34:   a6 02 08 7c     mflr    r0
...

This is caused by ppc_elfv2_elf_make_msymbol_special which marks foo@plt as
having a local entry point, due to incorrectly accessing an asymbol struct
using a (larger) elf_symbol_type.

Fix this by simply ignoring artificial symbols in
ppc_elfv2_elf_make_msymbol_special.

Tested on powerpc64le.

Approved-By: Ulrich Weigand <uweigand@de.ibm.com>
Reviewed-By: Carl Love <cel@us.ibm.com>
Tested-By: Carl Love <cel@us.ibm.com>
PR tdep/29814
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29814

PR10368, ISO 8859 mentioned as 7bit encoding in strings documentation

PR 10368
* doc/binutils.texi (strings): Delete example of 7-bit encoding.

Use bfd_rename_section in msp430.em

* emultempl/msp430.em (add_region_prefix <REGION_EITHER>): Use
bfd_rename_section.
* testsuite/ld-msp430-elf/msp430-tiny-rom.ld: Handle varian data
and bss input sections.

asan: pef: buffer overflow

* pef.c (bfd_pef_parse_traceback_table): Correct size moved when
stripping leading dot.

regen gas/Makefile.in

RISC-V: Allow merging 'H' extension

Because riscv_merge_std_ext function did not merge the 'H' extension, linked
executables lacked 'H' extension when multiple objects are merged.

This issue is found while building OpenSBI with 'H' extension (resulting
ELF files did not contain "h1p0" in "Tag_RISCV_arch" even if *all* linked
object files contained it).

This commit adds 'h' to standard_exts variable to merge 'H' extension.

bfd/ChangeLog:

* elfnn-riscv.c (riscv_merge_std_ext): Add 'H' extension merging.

RISC-V: Better support for long instructions (tests)

This commit tests both (assembler and disassembler) fixes of "Better support
for long instructions".

gas/ChangeLog:

* testsuite/gas/riscv/insn.s: Add testcases such that big number
handling is required and should be disassembled as long ".byte"
sequence with correct instruction bits.
* testsuite/gas/riscv/insn.d: Likewise.
* testsuite/gas/riscv/insn-na.d: Likewise.
* testsuite/gas/riscv/insn-dwarf.d: Likewise.

RISC-V: Better support for long instructions (assembler)

Commit bb996692bd96 ("RISC-V/gas: allow generating up to 176-bit
instructions with .insn") tried to start supporting long instructions but
it was insufficient.

1.  It heavily depended on the bignum internals (radix of 2^16),
2.  It generates "value conflicts with instruction length" even if a big
    number instruction encoding does not exceed its expected length and
3.  Because long opcode was handled separately (from struct riscv_cl_insn),
    some information like DWARF line number correspondence was missing.

To resolve these problems, this commit:

1.  Handles bignum (and its encodings) precisely and
2.  Incorporates long opcode handling into regular instruction handling.

This commit will be tested on the separate commit.

gas/ChangeLog:

* config/tc-riscv.c (struct riscv_cl_insn): Add long opcode field.
(create_insn) Clear long opcode marker.
(install_insn) Install longer opcode as well.
(s_riscv_insn) Likewise.
(riscv_ip_hardcode): Make big number handling stricter. Length and
the value conflicts only if the bignum size exceeds the expected
maximum length.

RISC-V: Better support for long instructions (disassembler)

Commit bb996692bd96 ("RISC-V/gas: allow generating up to 176-bit
instructions with .insn") tried to start supporting long instructions but
it was insufficient.

On the disassembler, correct ".byte" output was limited to the first 64-bits
of an instruction.  After that, zeroes are incorrectly printed.

Note that, it only happens on ".byte" output (instruction part) and not on
hexdump (data) part.  For example, before this commit, hexdump and ".byte"
produces different values:

Assembly:
  .insn 22, 0xfedcba98765432100123456789abcdef55aa33cc607f
objdump output example (before the fix):
  10:   607f 33cc 55aa cdef     .byte   0x7f, 0x60, 0xcc, 0x33, 0xaa, 0x55, 0xef, 0xcd, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
  18:   89ab 4567 0123 3210
  20:   7654 ba98 fedc

Note that, after 0xcd (after first 64-bits of the target instruction), all
".byte" values are incorrectly printed as zero while hexdump prints correct
instruction bits.

To resolve this, this commit adds "packet" argument to support dumping
instructions longer than 64-bits (to print correct instruction bits on
".byte").  This commit will be tested on the separate commit.

Assembly:
  .insn 22, 0xfedcba98765432100123456789abcdef55aa33cc607f
objdump output example (after the fix):
  10:   607f 33cc 55aa cdef     .byte   0x7f, 0x60, 0xcc, 0x33, 0xaa, 0x55, 0xef, 0xcd, 0xab, 0x89, 0x67, 0x45, 0x23, 0x01, 0x10, 0x32, 0x54, 0x76, 0x98, 0xba, 0xdc, 0xfe
  18:   89ab 4567 0123 3210
  20:   7654 ba98 fedc

opcodes/ChangeLog:

* riscv-dis.c (riscv_disassemble_insn): Print unknown instruction
using the new argument packet.
(riscv_disassemble_data): Add unused argument packet.
(print_insn_riscv): Pass packet to the disassemble function.

Automatic date update in version.in

Fix leak in the dwarf reader

Valgrind reports a leak in the dwarf reader (see details below).
The function dw2_get_file_names_reader is interning in the per_objfile
all the file names it finds, except the name of 'fnd file name and directory'.
Instead, it was xstrdup-ing the name.
Fix the leaks by also interning the name.

This was validated running the tests natively, and under valgrind.
Leaks have decreased as mentionned below.
Valgrind detected no error such as double free or use after free.

Stack trace of the leak:
==4113266== 490,735 bytes in 17,500 blocks are definitely lost in loss record 7,061 of 7,074
==4113266==    at 0x483979B: malloc (vg_replace_malloc.c:393)
==4113266==    by 0x25A454: xmalloc (alloc.c:57)
==4113266==    by 0x7D1E1E: xstrdup (xstrdup.c:34)
==4113266==    by 0x39D141: dw2_get_file_names_reader (read.c:2825)
==4113266==    by 0x39D141: dw2_get_file_names(dwarf2_per_cu_data*, dwarf2_per_objfile*) (read.c:2851)
==4113266==    by 0x39DD6C: dw_expand_symtabs_matching_file_matcher(dwarf2_per_objfile*, gdb::function_view<bool (char const*, bool)>) (read.c:4149)
==4113266==    by 0x3BC8B5: cooked_index_functions::expand_symtabs_matching(objfile*, gdb::function_view<bool (char const*, bool)>, lookup_name_info const*, gdb::function_view<bool (char const*)>, gdb::function_view<bool (compunit_symtab*)>, enum_flags<block_search_flag_values>, domain_enum, search_domain) (read.c:18688)
==4113266==    by 0x5DD1EA: objfile::map_symtabs_matching_filename(char const*, char const*, gdb::function_view<bool (symtab*)>) (symfile-debug.c:207)
==4113266==    by 0x5F04CC: iterate_over_symtabs(char const*, gdb::function_view<bool (symtab*)>) (symtab.c:633)
==4113266==    by 0x477EE3: collect_symtabs_from_filename(char const*, program_space*) (linespec.c:3712)
==4113266==    by 0x477FC1: symtabs_from_filename(char const*, program_space*) (linespec.c:3726)
==4113266==    by 0x47A9B8: convert_explicit_location_spec_to_linespec(linespec_state*, linespec*, char const*, char const*, symbol_name_match_type, char const*, line_offset) (linespec.c:2329)
==4113266==    by 0x47E86E: convert_explicit_location_spec_to_sals (linespec.c:2388)
==4113266==    by 0x47E86E: location_spec_to_sals(linespec_parser*, location_spec const*) (linespec.c:3104)
==4113266==    by 0x47EDAC: decode_line_full(location_spec*, int, program_space*, symtab*, int, linespec_result*, char const*, char const*) (linespec.c:3149)
...

Without the fix, the top 10 leaks are:
./gdb/testsuite/outputs/gdb.base/condbreak-bad/gdb.log:345:==3213924==    definitely lost: 130,937 bytes in 5,409 blocks
./gdb/testsuite/outputs/gdb.base/hbreak2/gdb.log:619:==3758919==    definitely lost: 173,323 bytes in 7,204 blocks
./gdb/testsuite/outputs/gdb.mi/mi-var-cp/gdb.log:1320:==4152873==    definitely lost: 172,826 bytes in 7,207 blocks
./gdb/testsuite/outputs/gdb.base/advance-until-multiple-locations/gdb.log:398:==2992643==    definitely lost: 172,965 bytes in 7,211 blocks
./gdb/testsuite/outputs/gdb.mi/mi-var-cmd/gdb.log:2302:==4159476==    definitely lost: 173,129 bytes in 7,211 blocks
./gdb/testsuite/outputs/gdb.cp/gdb2384/gdb.log:222:==3811851==    definitely lost: 218,106 bytes in 7,761 blocks
./gdb/testsuite/outputs/gdb.cp/mb-templates/gdb.log:310:==3787344==    definitely lost: 290,311 bytes in 10,340 blocks
./gdb/testsuite/outputs/gdb.mi/mi-var-rtti/gdb.log:2568:==4158350==    definitely lost: 435,427 bytes in 15,507 blocks
./gdb/testsuite/outputs/gdb.mi/mi-catch-cpp-exceptions/gdb.log:1704:==4119722==    definitely lost: 435,405 bytes in 15,510 blocks
./gdb/testsuite/outputs/gdb.mi/mi-vla-fortran/gdb.log:768:==4113266==    definitely lost: 508,585 bytes in 18,109 blocks

With the fix:
./gdb/testsuite/outputs/gdb.base/fork-running-state/gdb.log:1536:==2924193==    indirectly lost: 13,848 bytes in 98 blocks
./gdb/testsuite/outputs/gdb.base/fork-running-state/gdb.log:1675:==2928777==    indirectly lost: 13,848 bytes in 98 blocks
./gdb/testsuite/outputs/gdb.python/py-inferior-leak/gdb.log:4729:==3353335==    definitely lost: 3,360 bytes in 140 blocks
./gdb/testsuite/outputs/gdb.base/kill-detach-inferiors-cmd/gdb.log:210:==2746927==    indirectly lost: 13,246 bytes in 154 blocks
./gdb/testsuite/outputs/gdb.base/inferior-clone/gdb.log:179:==3034984==    indirectly lost: 12,921 bytes in 161 blocks
./gdb/testsuite/outputs/gdb.base/interrupt-daemon/gdb.log:209:==3006248==    indirectly lost: 20,683 bytes in 174 blocks
./gdb/testsuite/outputs/gdb.threads/watchpoint-fork/gdb.log:714:==3512403==    indirectly lost: 20,707 bytes in 175 blocks
./gdb/testsuite/outputs/gdb.threads/watchpoint-fork/gdb.log:962:==3514498==    indirectly lost: 20,851 bytes in 178 blocks
./gdb/testsuite/outputs/gdb.base/multi-forks/gdb.log:336:==2585839==    indirectly lost: 53,630 bytes in 386 blocks
./gdb/testsuite/outputs/gdb.base/multi-forks/gdb.log:1338:==2592417==    indirectly lost: 100,008 bytes in 1,154 blocks

Approved-By: Simon Marchi <simon.marchi@efficios.com>

fix leak in gdb_environ

valgrind reports a leak when assigning a gdb_environ to another gdb_environ.
The memory allocated for the target gdb_environ env variables is not released.
The gdb_environ selftest reproduces the leak (see below).
Fix the leak by clearing the target gdb_environ before std::move-ing the
members.

Tested natively and re-running all tests under valgrind.

==3261873== 4,842 bytes in 69 blocks are definitely lost in loss record 6,772 of 6,839
==3261873==    at 0x483979B: malloc (vg_replace_malloc.c:393)
==3261873==    by 0x25A454: xmalloc (alloc.c:57)
==3261873==    by 0x7D1E4E: xstrdup (xstrdup.c:34)
==3261873==    by 0x7E2A51: gdb_environ::from_host_environ() (environ.cc:56)
==3261873==    by 0x66F1C8: test_reinit_from_host_environ (environ-selftests.c:78)
==3261873==    by 0x66F1C8: selftests::gdb_environ_tests::run_tests() (environ-selftests.c:285)
==3261873==    by 0x7EFC43: operator() (std_function.h:622)
=

Approved-By: Simon Marchi <simon.marchi@efficios.com>

Use false/true for some inferior class members instead of 0/1

Some class members were changed to bool, but there was
still some assignments or comparisons using 0/1.

Approved-By: Simon Marchi <simon.marchi@efficios.com>

[gdb/server] Emit warning for SIGINT failure

Consider the executable from test-case gdb.base/interrupt-daemon.exp.

When starting it using gdbserver:
...
$ ./build/gdbserver/gdbserver localhost:2345 \
  ./outputs/gdb.base/interrupt-daemon/interrupt-daemon
...
and connecting to it using gdb:
...
$ gdb -q -ex "target remote localhost:2345" \
    -ex "set follow-fork-mode child" \
    -ex "break daemon_main" -ex cont
...
we are setup to do the same as in the test-case: interrupt a running inferior
using ^C.

So let's try:
...
(gdb) continue
Continuing.
^C
...
After pressing ^C, nothing happens.  This a known problem, filed as
PR remote/18772.

The problem is that in linux_process_target::request_interrupt, a kill is used
to send a SIGINT, but it fails.  And it fails silently.

Make the failure verbose by adding a warning, such that the gdbserver output
becomes more helpful:
...
Process interrupt-daemon created; pid = 15068
Listening on port 2345
Remote debugging from host ::1, port 35148
Detaching from process 15068
Detaching from process 15085
gdbserver: Sending SIGINT to process group of pid 15068 failed: \
  No such process
...

Note that the failure can easily be reproduced using the test-case and target
board native-gdbserver:
...
(gdb) continue^M
Continuing.^M
PASS: gdb.base/interrupt-daemon.exp: fg: continue
^CFAIL: gdb.base/interrupt-daemon.exp: fg: ctrl-c stops process (timeout)
...
as reported in PR server/23382.

Tested on x86_64-linux.
Approved-By: Simon Marchi <simon.marchi@efficios.com>

Automatic date update in version.in

[gdb/testsuite] Don't generate core in gdb.base/bt-on-fatal-signal.exp

When running test-case gdb.base/bt-on-fatal-signal.exp on powerpc64le-linux I
noticed:
...
FAIL: gdb.base/bt-on-fatal-signal.exp: SEGV: scan for backtrace (timeout)
...

The timeout is 10 seconds, but generating the core file takes more than a
minute, probably due to slow NFS.

I managed to reproduce this behaviour independently of gdb, by compiling
"int main (void) { __builtin_abort (); }" and running it, which took 1.5
seconds for a core file 50 times smaller than the one for gdb.

Fix this by preventing the core file from being generated, using a wrapper
around gdb that does "ulimit -c 0".

Tested on x86_64-linux.

[gdb/symtab] Handle failure to open .gnu_debugaltlink file

If we instrument cc-with-tweaks.sh to remove the .gnu_debugaltlink file after
dwz has created it, with test-case
gdb.threads/access-mem-running-thread-exit.exp and target board cc-with-dwz-m
we run into:
...
(gdb) file access-mem-running-thread-exit^M
Reading symbols from access-mem-running-thread-exit...^M
could not find '.gnu_debugaltlink' file for access-mem-running-thread-exit^M
...
followed a bit later by:
...
(gdb) file access-mem-running-thread-exit^M
Reading symbols from access-mem-running-thread-exit...^M
gdb/dwarf2/read.c:7284: internal-error: create_all_units: \
  Assertion `per_objfile->per_bfd->all_units.empty ()' failed.^M
...

The problem is that create_units does not catch the error thrown by
dwarf2_get_dwz_file.

Fix this by catching the error and performing the necessary cleanup, getting
the same result for the first and second file command.

PR symtab/29805
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29805

Fix jump on uninit producer_is_clang bit of cu.h dwarf2_cu struct.

Valgrind reports a "jump on unitialised bit error" when running
    e.g. gdb.base/macro-source-path.exp (see details below).

    Fix this by initializing producer_is_clang member variable of dwarf2_cu.

    Tested on amd64/debian11 and re-running gdb.base/macro-source-path.exp
    under valgrind.

    ==2140965== Conditional jump or move depends on uninitialised value(s)
    ==2140965==    at 0x5211F7: dwarf_decode_macro_bytes(dwarf2_per_objfile*, buildsym_compunit*, bfd*, unsigned char const*, unsigned char const*, macro_source_file*, line_header const*, dwarf2_section_info const*, int, int, unsigned int, dwarf2_section_info*, dwarf2_section_info*, gdb::optional<unsigned long>, htab*, dwarf2_cu*) (macro.c:676)
    ==2140965==    by 0x52158A: dwarf_decode_macros(dwarf2_per_objfile*, buildsym_compunit*, dwarf2_section_info const*, line_header const*, unsigned int, unsigned int, dwarf2_section_info*, dwarf2_section_info*, gdb::optional<unsigned long>, int, dwarf2_cu*) (macro.c:967)
    ==2140965==    by 0x523BC4: dwarf_decode_macros(dwarf2_cu*, unsigned int, int) (read.c:23379)
    ==2140965==    by 0x552AB5: read_file_scope(die_info*, dwarf2_cu*) (read.c:9687)
    ==2140965==    by 0x54F7B2: process_die(die_info*, dwarf2_cu*) (read.c:8660)
    ==2140965==    by 0x5569C7: process_full_comp_unit (read.c:8429)
    ==2140965==    by 0x5569C7: process_queue (read.c:7675)
    ==2140965==    by 0x5569C7: dw2_do_instantiate_symtab (read.c:2063)
    ==2140965==    by 0x5569C7: dw2_instantiate_symtab(dwarf2_per_cu_data*, dwarf2_per_objfile*, bool) (read.c:2085)
    ==2140965==    by 0x55700B: dw2_expand_symtabs_matching_one(dwarf2_per_cu_data*, dwarf2_per_objfile*, gdb::function_view<bool (char const*, bool)>, gdb::function_view<bool (compunit_symtab*)>) (read.c:3984)
    ==2140965==    by 0x557EA3: cooked_index_functions::expand_symtabs_matching(objfile*, gdb::function_view<bool (char const*, bool)>, lookup_name_info const*, gdb::function_view<bool (char const*)>, gdb::function_view<bool (compunit_symtab*)>, enum_flags<block_search_flag_values>, domain_enum, search_domain) (read.c:18781)
    ==2140965==    by 0x778977: objfile::lookup_symbol(block_enum, char const*, domain_enum) (symfile-debug.c:276)
    ....
    ==2140965==  Uninitialised value was created by a heap allocation
    ==2140965==    at 0x4839F01: operator new(unsigned long) (vg_replace_malloc.c:434)
    ==2140965==    by 0x533A64: cutu_reader::cutu_reader(dwarf2_per_cu_data*, dwarf2_per_objfile*, abbrev_table*, dwarf2_cu*, bool, abbrev_cache*) (read.c:6264)
    ==2140965==    by 0x5340C2: load_full_comp_unit(dwarf2_per_cu_data*, dwarf2_per_objfile*, dwarf2_cu*, bool, language) (read.c:7729)
    ==2140965==    by 0x548338: load_cu(dwarf2_per_cu_data*, dwarf2_per_objfile*, bool) (read.c:2021)
    ==2140965==    by 0x55634C: dw2_do_instantiate_symtab (read.c:2048)
    ==2140965==    by 0x55634C: dw2_instantiate_symtab(dwarf2_per_cu_data*, dwarf2_per_objfile*, bool) (read.c:2085)
    ==2140965==    by 0x55700B: dw2_expand_symtabs_matching_one(dwarf2_per_cu_data*, dwarf2_per_objfile*, gdb::function_view<bool (char const*, bool)>, gdb::function_view<bool (compunit_symtab*)>) (read.c:3984)
    ==2140965==    by 0x557EA3: cooked_index_functions::expand_symtabs_matching(objfile*, gdb::function_view<bool (char const*, bool)>, lookup_name_info const*, gdb::function_view<bool (char const*)>, gdb::function_view<bool (compunit_symtab*)>, enum_flags<block_search_flag_values>, domain_enum, search_domain) (read.c:18781)
    ==2140965==    by 0x778977: objfile::lookup_symbol(block_enum, char const*, domain_enum) (symfile-debug.c:276)
    ....

remove the declared but undefined/unused method find_partial_die

The method
       struct partial_die_info *find_partial_die (sect_offset sect_off);
in cu.h is defined, but is used nowhere and not implemented.

Automatic date update in version.in

Revert "readelf: Do not require EI_OSABI for IFUNC."

This reverts commit ffbbab0b3a1000f862b6d4ce3d9a76ed14f08801.

riscv: Add AIA extension support (Smaia, Ssaia)

This commit adds the AIA extensions (Smaia and Ssaia) CSRs.

bfd/ChangeLog:

* elfxx-riscv.c: Add 'smaia' and 'ssaia' to the list
of known standard extensions.

gas/ChangeLog:

* config/tc-riscv.c (enum riscv_csr_class):
(riscv_csr_address): Add CSR classes for Smaia/Ssaia.
* testsuite/gas/riscv/csr-dw-regnums.d: Add new CSRs.
* testsuite/gas/riscv/csr-dw-regnums.s: Likewise.
* testsuite/gas/riscv/csr-version-1p10.d: Likewise.
* testsuite/gas/riscv/csr-version-1p10.l: Likewise.
* testsuite/gas/riscv/csr-version-1p11.d: Likewise.
* testsuite/gas/riscv/csr-version-1p11.l: Likewise.
* testsuite/gas/riscv/csr-version-1p12.d: Likewise.
* testsuite/gas/riscv/csr-version-1p12.l: Likewise.
* testsuite/gas/riscv/csr-version-1p9p1.d: Likewise.
* testsuite/gas/riscv/csr-version-1p9p1.l: Likewise.
* testsuite/gas/riscv/csr.s: Likewise.

include/ChangeLog:

* opcode/riscv-opc.h (CSR_MISELECT): New CSR macro.
(CSR_MIREG): Likewise.
(CSR_MTOPEI): Likewise.
(CSR_MTOPI): Likewise.
(CSR_MVIEN): Likewise.
(CSR_MVIP): Likewise.
(CSR_MIDELEGH): Likewise.
(CSR_MIEH): Likewise.
(CSR_MVIENH): Likewise.
(CSR_MVIPH): Likewise.
(CSR_MIPH): Likewise.
(CSR_SISELECT): Likewise.
(CSR_SIREG): Likewise.
(CSR_STOPEI): Likewise.
(CSR_STOPI): Likewise.
(CSR_SIEH): Likewise.
(CSR_SIPH): Likewise.
(CSR_HVIEN): Likewise.
(CSR_HVICTL): Likewise.
(CSR_HVIPRIO1): Likewise.
(CSR_HVIPRIO2): Likewise.
(CSR_VSISELECT): Likewise.
(CSR_VSIREG): Likewise.
(CSR_VSTOPEI): Likewise.
(CSR_VSTOPI): Likewise.
(CSR_HIDELEGH): Likewise.
(CSR_HVIENH): Likewise.
(CSR_HVIPH): Likewise.
(CSR_HVIPRIO1H): Likewise.
(CSR_HVIPRIO2H): Likewise.
(CSR_VSIEH): Likewise.
(CSR_VSIPH): Likewise.
(DECLARE_CSR): Add CSRs for Smaia and Ssaia.

Changes for v3:
- Imply ssaia for smaia
- Imply zicsr for ssaia (and transitively smaia)
- Move hypervisor CSRs to Ssaia+H
- Rebase on upstream/master

Changes for v2:
- Add hypervisor and VS CSRs
- Fix whitespace issue

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

Automatic date update in version.in

sframe/doc: remove usage of xrefautomaticsectiontitle

xrefautomaticsectiontitle appears to be available from texinfo 5.0 or
greater.  As such, it is not worthwhile to add requirement for a minimum
necessary makeinfo version.  So remove the usage of it.

Also align node name with section title where possible.

ChangeLog:

* libsframe/doc/sframe-spec.texi: Remove usage of
xrefautomaticsectiontitle.

gdb: fix typo in debug output message

Spotted a minor type, a missing ')', in a debug message.

gdb/testsuite/gdb.base/break.exp: split test_break

Move all the remaining tests to a single test_break proc.  It's a bit
big, but all of these are kind of tied together.  The procs starts by
setting breakpoints, checks that we can see them in "info breakpoints",
and tries stopping on them.

Move all the "set bp_locationX" calls together at the top.

Change-Id: Id05f98957e1a3462532d2dbd577cd0a7c7263900
Approved-By: Kevin Buettner <kevinb@redhat.com>

gdb/testsuite/gdb.base/break.exp: split test_tbreak

Leave setting bp_location11 in the global scope, so that it's accessible
to other procs.

Change-Id: I8928f01640d3a1e993649b2168b9eda0724ee1d9
Approved-By: Kevin Buettner <kevinb@redhat.com>

gdb/testsuite/gdb.base/break.exp: split test_no_break_on_catchpoint

Change-Id: Ifa7070943f1de22c2839fedf5f346d6591bb5a76
Approved-By: Kevin Buettner <kevinb@redhat.com>

gdb/testsuite/gdb.base/break.exp: split test_break_nonexistent_line

Change-Id: I4390dd5da23bae83ccc513ad0de0169ddff7df12
Approved-By: Kevin Buettner <kevinb@redhat.com>

gdb/testsuite/gdb.base/break.exp: split test_break_default

One special thing here is that the part just above this one, that sets
catchpoints and verifies they are not hit, requires that we resume
execution to verify that the catchpoints are indeed not hit.   I guess
it was previously achieved by the until command, but it doesn't happen
now that the until is moved into test_break_default.  Add a
gdb_continue_to_end after setting the catchpoints.  If any catchpoint
were to be hit, it would catch the problem.

Change-Id: I5d4b43da91886b1beda9f6e56b05aa04331a9c05
Approved-By: Kevin Buettner <kevinb@redhat.com>

gdb/testsuite/gdb.base/break.exp: split test_break_silent_and_more

This one is a bit tricky.  The clear tests seem to depend on the various
breakpoints that have been set before, starting with the "silent"
breakpoints.  So, move all this in a single chunk, it can always be
split later if needed.

Change-Id: I7ba61a5b130ade63eda0c4790534840339f8a72f
Approved-By: Kevin Buettner <kevinb@redhat.com>

gdb/testsuite/gdb.base/break.exp: split test_break_line_convenience_var

Change-Id: I593002373da971a0a4d6b5355d3fe321873479ab
Approved-By: Kevin Buettner <kevinb@redhat.com>

gdb/testsuite/gdb.base/break.exp: split test_break_user_call

Change-Id: I9151ce9db9435722b758f41c6606b461bf15f320
Approved-By: Kevin Buettner <kevinb@redhat.com>

gdb/testsuite/gdb.base/break.exp: split test_finish_arguments

Change-Id: Id84babed1eeb3ce7d14b94ff332795964e8ead51
Approved-By: Kevin Buettner <kevinb@redhat.com>

gdb/testsuite/gdb.base/break.exp: use proc_with_prefix for test_next_with_recursion

This one is already in a proc, just make the proc use proc_with_prefix,
for consistency.

Change-Id: I313ecf5097ff04526c29396529baeba84e37df5a
Approved-By: Kevin Buettner <kevinb@redhat.com>

gdb/testsuite/gdb.base/break.exp: split test_break_optimized_prologue

Change-Id: Ibf17033c8ce72aa5cfe1b739be2902e84a5e945d
Approved-By: Kevin Buettner <kevinb@redhat.com>

gdb/testsuite/gdb.base/break.exp: split test_rbreak_shlib

Change-Id: I130e8914c2713095aab03e84aba1481b4c7af978
Approved-By: Kevin Buettner <kevinb@redhat.com>

gdb/testsuite/gdb.base/break.exp: split test_break_file_line_convenience_var

Change-Id: I0c31b037669b2917e062bf431372fb6531f8f53c
Approved-By: Kevin Buettner <kevinb@redhat.com>

gdb/testsuite/gdb.base/break.exp: split test_break_commands_clear

Change-Id: Ia58f90117d52fc419fc494836d9b4ed5d902fe9b
Approved-By: Kevin Buettner <kevinb@redhat.com>

Impport libiberty commit: 885b6660c17f from gcc mainline.  Fix gas's acinclude.m4 to stop a potwntial configure time warning message.

readelf: Do not require EI_OSABI for IFUNC.

PR 29718

binutils/ChangeLog:

* readelf.c (get_symbol_type): Consider STT_GNU_IFUNC as
reserved name.

x86: widen applicability and use of CheckRegSize

First of all make operand_type_register_match() apply to all sized
operands, i.e. in Intel Syntax also to respective memory ones. This
addresses gas wrongly accepting certain SIMD insns where register and
memory operand sizes should match but don't. This apparently has
affected all templates with one memory-only operand and one or more
register ones, both permitting at least two sizes, due to CheckRegSize
not taking effect.

Then also add CheckRegSize to a couple of non-SIMD templates matching
that same pattern of memory-only vs register operands. This replaces
bogus (for Intel Syntax) diagnostics referring to a wrong suffix (when
none was used at all) by "type mismatch" ones, just like already emitted
for insns where the template allows a register operand alongside a
memory one at any particular position.

This also is a prereq to limiting (ideally eliminating in the long run)
suffix "derivation" in Intel Syntax mode.

While making the code adjustment also flip order of checks to do the
cheaper one first in both cases.

x86: add missing CheckRegSize

To properly and predictably determine operand size encoding (operand
size or REX.W prefixes), consistent operand sizes need to be specified.
Add CheckRegSize where this was previously missing.

x86: correct handling of LAR and LSL

Both uniformly only ever take 16-bit memory operands while at the same
time requiring matching (in size) register operands, which then also
should disassemble that way. This in particular requires splitting each
of the templates for the assembler and separating decode of the
register and memory forms in the disassembler.

Tidy objdump printing of section size

* objdump.c (load_specific_debug_section): Use PRIx64 format.

Constify nm format array

* nm.c (formats, format): Make const.

PR16995, m68k coldfire emac immediate to macsr incorrect disassembly

Mode/reg bits for these insns are 000 Dy, 001 Ay, and 111 100 for the
move immediate.

* m68k-opc.c (m68k_opcodes): Only accept 000 and 001 as mode
for move reg to macsr/mask insns.

gas: Disable --gcodeview on PE targets with no O_secrel

Automatic date update in version.in

gdb/arm: Include FType bit in EXC_RETURN pattern on v8m

For v8m, the EXC_RETURN pattern, without security extension, consists of
FType, Mode and SPSEL.  These are the same bits that are used in v7m.
This patch extends the list of patterns to include also the FType bit
and not just Mode and SPSEL bits for v8m targets without security
extension.

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

regen POTFILES.in

PR22509 - Null pointer dereference on coff_slurp_reloc_table

This extends the commit 4581a1c7d304 fix to more targets, which
hardens BFD a little.  I think the real underlying problem was the
bfd_canonicalize_reloc call in load_specific_debug_section which
passed a NULL for "symbols".  Fix that too.

PR 22509
bfd/
* aoutx.h (swap_ext_reloc_out): Gracefully handle NULL symbols.
* i386lynx.c (swap_ext_reloc_out): Likewise.
* pdp11.c (pdp11_aout_swap_reloc_out): Likewise.
* coff-tic30.c (reloc_processing): Likewise.
* coff-tic4x.c (tic4x_reloc_processing): Likewise.
* coff-tic54x.c (tic54x_reloc_processing): Likewise.
* coff-z80.c (reloc_processing): Likewise.
* coff-z8k.c (reloc_processing): Likewise.
* ecoff.c (ecoff_slurp_reloc_table): Likewise.
* som.c (som_set_reloc_info): Likewise.
binutils/
* objdump.c (load_specific_debug_section): Pass syms to
bfd_canonicalize_reloc.

asan: NULL deref in filter_symbols

If tdata->symbols is NULL, make tdata->symcount zero too.  This makes
wasm_get_symtab_upper_bound return the proper result and stops
cascading errors.

* wasm-module.c (wasm_scan_name_function_section): Clear
tdata->symcount on error.

Document the memory_tagged argument for memory region callbacks

There were no comments in some instances (gdb/defs.h, gdb/core.c and
gdb/linux-tdep.c), so address that by adding comments where those are missing.

Fix gdb.cp/gdb2495.exp on powerpc64le

On powerpc64le-linux I ran into this FAIL:
...
(gdb) p exceptions.throw_function()^M
terminate called after throwing an instance of 'int'^M
^M
Program received signal SIGABRT, Aborted.^M
0x00007ffff7979838 in raise () from /lib64/libc.so.6^M
The program being debugged was signaled while in a function called from GDB.^M
GDB remains in the frame where the signal was received.^M
To change this behavior use "set unwindonsignal on".^M
Evaluation of the expression containing the function^M
(SimpleException::throw_function()) will be abandoned.^M
When the function is done executing, GDB will silently stop.^M
(gdb) FAIL: gdb.cp/gdb2495.exp: call a function that raises an exception \
  without a handler.
...

The following happens:
- we start an inferior call
- an internal breakpoint is set on the global entry point of std::terminate
- the inferior call uses the local entry point
- the breakpoint is not triggered
- we run into std::terminate

We can fix this by simply adding the missing gdbarch_skip_entrypoint call in
create_std_terminate_master_breakpoint, but we try to do this a bit more
generic, by:
- adding a variant of function create_internal_breakpoint which takes a
  minimal symbol instead of an address as argument
- in the new function:
  - using both gdbarch_convert_from_func_ptr_addr and gdbarch_skip_entrypoint
  - documenting why we don't need to use gdbarch_addr_bits_remove
  - adding a note about possibly
    needing gdbarch_deprecated_function_start_offset.
- using the new function in:
  - create_std_terminate_master_breakpoint
  - create_exception_master_breakpoint_hook, which currently uses only
    gdbarch_convert_from_func_ptr_addr.

Note: we could use the new function in more locations in breakpoint.c, but
as we're not aware of any related failures, we declare this out of scope for
this patch.

Tested on x86_64-linux, powerpc64le-linux.

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

RISC-V: Make R_RISCV_SUB6 conforms to riscv ABI standard

According to the riscv psabi, R_RISCV_SUB6 only allows 6 least significant
bits are valid, but since binutils implementation, we usually get 8 bits
field for it.  That means, the high 2 bits could be other field and have
different purpose.  Therefore, we should filter the 8 bits to 6 bits before
calculate, and then only encode the valid 6 bits back.  By the way, we also
need the out-of-range check for R_RISCV_SUB6, and the overflow checks for
all R_RISCV_ADD/SUB/SET relocations, but we can add them in the future patches.

Passing riscv-gnu-toolchain regressions.

bfd/ChangeLog:

        * elfnn-riscv.c (riscv_elf_relocate_section): Take the R_RISCV_SUB6
lower 6 bits as the significant bit.
        * elfxx-riscv.c (riscv_elf_add_sub_reloc): Likewise.

gas: Add --gcodeview option

ld: Add section contributions substream to PDB files

Automatic date update in version.in

aarch64-fbsd: Use a static regset for the TLS register set.

This uses custom collect/supply regset handlers which pass the TLS
register number from the gdbarch_tdep as the base register number.

Approved-By: Simon Marchi <simon.marchi@efficios.com>

arm-fbsd: Use a static regset for the TLS register set.

This uses custom collect/supply regset handlers which pass the TLS
register number from the gdbarch_tdep as the base register number.

Approved-By: Simon Marchi <simon.marchi@efficios.com>

fbsd-nat: Pass an optional register base to the register set helpers.

This is needed to permit using the helpers for register sets with a
variable base.  In particular regnum needs to be converted into a
relative register number before passed to regcache_map_supplies.

Approved-By: Simon Marchi <simon.marchi@efficios.com>

fbsd-nat: Use regset supply/collect methods.

fbsd-nat includes various helper routines for fetching and storing
register sets via ptrace where the register set is described by a
regset.  These helper routines directly invoke the
supply/collect_regset regcache methods which doesn't permit a regset
to provide custom logic when fetching or storing a register set.
Instead, just use the function pointers from the struct regset
directly.

Approved-By: Simon Marchi <simon.marchi@efficios.com>

regcache: Add collect/supply_regset variants that accept a register base.

Some register sets described by an array of regcache_map_entry
structures do not have fixed register numbers in their associated
architecture but do describe a block of registers whose numbers are at
fixed offsets relative to some base register value.  An example of
this are the TLS register sets for the ARM and AArch64 architectures.

Currently OS-specific architectures create register maps and register
sets dynamically using the register base number.  However, this
requires duplicating the code to create the register map and register
set.  To reduce duplication, add variants of the collect_regset and
supply_regset regcache methods which accept a base register number.
For valid register map entries (i.e. not REGCACHE_MAP_SKIP), add this
base register number to the value from the map entry to determine the
final register number.

Approved-By: Simon Marchi <simon.marchi@efficios.com>

x86: Don't define _TLS_MODULE_BASE_ for ld -r

bfd/

PR ld/29820
* elfxx-x86.c (_bfd_x86_elf_always_size_sections): Don't define
 _TLS_MODULE_BASE_ for ld -r.

ld/

PR ld/29820
* testsuite/ld-x86-64/pr29820.d: New file.
* testsuite/ld-x86-64/pr29820.s: Likewise.
* testsuite/ld-x86-64/x86-64.ex: Run pr29820.

Don't use "long" in readelf for file offsets

The aim here is to improve readelf handling of large 64-bit object
files on LLP64 hosts (Windows) where long is only 32 bits.  The patch
changes more than just file offsets.  Addresses and sizes are also
changed to avoid "long".  Most places get to use uint64_t even where
size_t may be more appropriate, because that allows some overflow
checks to be implemented easily (*alloc changes).

* dwarf.c (cmalloc, xcmalloc, xcrealloc, xcalloc2): Make nmemb
parameter uint64_t.
* dwarf.h: Update prototypes.
(struct dwarf_section): Make num_relocs uint64_t.
* elfcomm.c (setup_archive): Update error format.
* elfcomm.h (struct archive_info): Make sym_size, longnames_size,
nested_member_origin, next_arhdr_offset uint64_t.
* readelf.c (struct filedata): Make archive_file_offset,
archive_file_size, string_table_length, dynamic_addr,
dynamic_nent, dynamic_strings_length, num_dynamic_syms,
dynamic_syminfo_offset uint64_t.
(many functions): Replace uses of "unsigned long" with
"uint64_t" or "size_t".

Re: readelf: use fseeko64 or fseeko if possible

Replace the macros with a small wrapper function that verifies the fseek
offset arg isn't overlarge.

* readelf.c (FSEEK_FUNC): Delete, replace uses with..
(fseek64): ..this new function.
(process_program_headers): Don't cast p_offset to long.

gdb/arm: Fix obvious typo in b0b23e06c3a

As part of the rebase of the patch, I managed to loose the local
changes I had for the comments from Tomas in
https://sourceware.org/pipermail/gdb-patches/2022-November/193413.html
This patch corrects the obvious two typos.

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

binutils/configure.ac: integrate last change

Integrate back checks for fseeko{,64} into configure.ac, so
that regeneration works.

binutils/
* configure.ac: Add fseeko, fseeko64 checks.
* configure: Regenerate.

opcodes: Correct address for ARC's "isa_config" aux reg

This patch changes the address for "isa_config" auxiliary register
from 0xC2 to the correct value 0xC1.  Moreover, it only exists in
arc700+ and not all ARCs.

opcodes/ChangeLog:

* arc-regs.h: Change isa_config address to 0xc1.
isa_config exists for ARC700 and ARCV2 and not ARCALL.

gdb/testsuite: remove gcc restriction from gdb.dwarf2/clang-cli-macro.exp

With the recent changes to the dwarf assembler, there is no longer a
need to test for gcc in gdb.dwarf2/clang-cli-macro.exp and mark it as
untested. This commit removes that logic.

gas/sframe: avoid "shadowing" of glibc function name

Once again: Old enough glibc has an (unguarded) declaration of index()
in string.h, which triggers a "shadows a global declaration" warning
with our choice of wanring level and with at least some gcc versions.

Automatic date update in version.in

readelf: use fseeko64 or fseeko if possible

Changes readelf to make use first of fseeko64 and then fseeko,
depending on which of those is available. If neither is available,
reverts to the previous behavior of using fseek.

This is necessary when building readelf for LLP64 systems, where a
long will only be 32 bits wide. If the elf file in question is >= 2 GiB,
that is greater than the max long value and therefore fseek will fail
indicating that the offset is negative. On such systems, making use of
fseeko64 or fseeko will result in the ability so seek past the 2 GiB
max long boundary.

Note that large archive handling in readelf remains to be fixed.

PR29807, SIGSEGV when linking fuzzed PE object

PR 29807
* cofflink.c (_bfd_coff_generic_relocate_section): Skip relocs
against symbols with a NULL section.

Re: ld: Always output local symbol for relocatable link

Remove this code dating back to commit 98790d3a95fc entirely, what it
was trying to do is done elsewhere.

PR ld/29761
* elflink.c (elf_link_output_symstrtab): Don't handle symbols
in SEC_EXCLUDE sections here.

When getting the locno of a bpstat, handle the case of bp with null locations.

The test py-objfile.exp unloads the current file while debugging the process.
This results in bpstat bs->b->loc to become nullptr.
Handle this case in breakpoint.c:bpstat_locno.

Note: GDB crashes on this problem with an internal error,
but the end of gdb summary shows:
  ...
                  === gdb Summary ===

  # of expected passes 36

The output also does not contain a 'FAIL:'.
After the fix, the nr of expected passes increased.

In the gdb.log output, one can see:
  ...
  Fatal signal: Segmentation fault
  ----- Backtrace -----
  0x55698905c5b9 gdb_internal_backtrace_1
          ../../binutils-gdb/gdb/bt-utils.c:122
  0x55698905c5b9 _Z22gdb_internal_backtracev
  ...

  ERROR: Couldn't send python print(objfile.filename) to GDB.
  ERROR: : spawn id exp9 not open
      while executing
  "expect {
  -i exp9 -timeout 10
          -re ".*A problem internal to GDB has been detected" {
              fail "$message (GDB internal error)"
              gdb_internal_error..."
      ("uplevel" body line 1)
      invoked from within
  ....

Wondering if it might be possible to improve gdb_test to have
  gdb_test "python print(objfile.filename)" "None" \
      "objfile.filename after objfile is unloaded"
reporting a failed result instead of just producing the internal error.

Fix use after free introduced by $_hit_bpnum/$_hit_locno variables.

If the commands of the bpstat bs contain commands such as step or next or
continue, the BS and its commands are freed by execute_control_command.

So, we cannot remember the BS that was printed. Instead, remember
the bpnum and locno.

Regtested on debian/amd64 and re-run a few tests under valgrind.

Fix step-over-syscall.exp matching regexp for $bpnum.$locno matching

step-over-syscall.exp has some specific tests for gdbserver.
The regexp matching breakpoint hit must take the added locno into account.

Test re-run in 3 modes (normal, native-gdbserver and native-extended-gdbserver).

Fix ARM and AArch64 assembler tests to work in a multi-arch environment.

PR 29764
gas * testsuite/gas/arm/cpu-cortex-a76ae.d: Add arm prefix to the -m
option passed to objdump.
* testsuite/gas/arm/cpu-cortex-a77.d: Likewise.
* testsuite/gas/aarch64/cpu-cortex-a76ae.d: Add aarch64 prefix to
the -m option passed to objdump.
* testsuite/gas/aarch64/cpu-cortex-a77.d: Likewise.

bfd * cpu-arm.c (scan): Accept machine names prefixed with "arm:".
* cpu-aarch64.c (scan): Accept machine names prefixed with "aarch64:".

bin * doc/binutils.texi (objdump): Note that the -m option supports
the <architecture>:<machine> syntax.

gdb/arm: Ensure that stack pointers are in sync

For targets with secext, msp and psp can be seen as an alias for one
of msp_s, msp_ns, psp_s or psp_ns.
Without this patch, sp might be secure, but msp or psp is non-secure
(this state can not happen in the hardware).

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

gdb/arm: Update active msp/psp when switching stack

For targets with secext, msp and psp can be seen as an alias for one
of msp_s, msp_ns, psp_s or psp_ns. When switching active sp, the
corresponding msp/psp needs to be switched too.

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

gdb/csky just return type from csky_vector_type() for vector resgisters

Some gdb stubs may not describe the type for vector registers in the
tdesc-xml and only send bitsize="128", gdb can't deal with a reg
with default type int with bitsize==128. So Just return csky_vector_type()
for vector resgisters.

gdb/csky return type int32 for float and vector pseudo regs

When reg_nr is one of the float and vector pseudo registers,
return builtin_type (gdbarch)->builtin_int32 for it.

Automatic date update in version.in

[PR build/29791] gnulib: Disable _GL_ATTRIBUTE_DEALLOC on Solaris

gdbsupport compilation badly fails with GCC 12 on Solaris, with errors
like

../gnulib/config.h:1693:72: error: ‘malloc’ attribute argument 1 is ambiguous
 1693 | # define _GL_ATTRIBUTE_DEALLOC(f, i) __attribute__ ((__malloc__ (f, i)))
      |                                                                        ^
../gnulib/config.h:1693:72: note: use a cast to the expected type to disambiguate

We've not yet been able to determine where the ambiguity actually lies,
so this patch works around the issue by disabling _GL_ATTRIBUTE_DEALLOC
on Solaris, at least as a workaround for GDB 13.

As Tom suggested in the PR, this is done using our infrastructure for
local gnulib patches.

Tested on sparcv9-sun-solaris2.11, amd64-pc-solaris2.11, and
x86_64-pc-linux-gnu.

Approved-By: Simon Marchi <simon.marchi@efficios.com>

Fix sol-thread.c compilation on 32-bit Solaris

sol-thread.c fails to compile on 32-bit Solaris: there are several
instances of

In file included from /vol/src/gnu/gdb/hg/master/local/gdb/../gdbsupport/common-defs.h:203,
                 from /vol/src/gnu/gdb/hg/master/local/gdb/defs.h:28,
                 from /vol/src/gnu/gdb/hg/master/local/gdb/sol-thread.c:51:
/vol/src/gnu/gdb/hg/master/local/gdb/sol-thread.c: In member function ‘virtual void sol_thread_target::resume(ptid_t, int, gdb_signal)’:
/vol/src/gnu/gdb/hg/master/local/gdb/sol-thread.c:416:20: error: format ‘%ld’ expects argument of type ‘long int’, but argument 2 has type ‘ULONGEST’ {aka ‘long long unsigned int’} [-Werror=format=]
  416 |         warning (_("Specified thread %ld seems to have terminated"),
      |                    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/vol/src/gnu/gdb/hg/master/local/gdb/../gdbsupport/gdb_locale.h:28:29:
note: in definition of macro ‘_’
   28 | # define _(String) gettext (String)
      |                             ^~~~~~
/vol/src/gnu/gdb/hg/master/local/gdb/sol-thread.c:416:40: note: format
string is defined here
  416 |         warning (_("Specified thread %ld seems to have terminated"),
      |                                      ~~^
      |                                        |
      |                                        long int
      |                                      %lld

Fixed by using pulongest () instead.

Tested on i386-pc-solaris2.11, amd64-pc-solaris2.11,
sparc-sun-solaris2.11, and sparcv9-sun-solaris2.11 (together with
Simon's patch for PR build/29798).

Automatic date update in version.in

Add missing gdb_prompt in ctxobj.exp to avoid random failure, fix typo.

ctxobj.exp fails randomly when computer is loaded.
With the addition of $gdb_prompt in the regexp testing for breakpoint hit,
I could not make it fail anymore.

Also fixed a typo in a comment.

Show locno for 'multi location' breakpoint hit msg+conv var $_hit_bbnum $_hit_locno PR breakpoints/12464

This implements the request given in PR breakpoints/12464.

Before this patch, when a breakpoint that has multiple locations is reached,
GDB printed:
  Thread 1 "zeoes" hit Breakpoint 1, some_func () at somefunc1.c:5

This patch changes the message so that bkpt_print_id prints the precise
encountered breakpoint:
  Thread 1 "zeoes" hit Breakpoint 1.2, some_func () at somefunc1.c:5

In mi mode, bkpt_print_id also (optionally) prints a new table field "locno":
  locno is printed when the breakpoint hit has more than one location.
Note that according to the GDB user manual node 'GDB/MI Development and Front
Ends', it is ok to add new fields without changing the MI version.

Also, when a breakpoint is reached, the convenience variables
$_hit_bpnum and $_hit_locno are set to the encountered breakpoint number
and location number.

$_hit_bpnum and $_hit_locno can a.o. be used in the command list of a
breakpoint, to disable the specific encountered breakpoint, e.g.
   disable $_hit_bpnum.$_hit_locno

In case the breakpoint has only one location, $_hit_locno is set to
the value 1, so as to allow a command such as:
  disable $_hit_bpnum.$_hit_locno
to disable the breakpoint even when the breakpoint has only one location.

This also fixes a strange behaviour: when a breakpoint X has only
one location,
  enable|disable X.1
is accepted but transforms the breakpoint in a multiple locations
breakpoint having only one location.

The changes in RFA v4 handle the comments of Tom Tromey:
 - Changed convenience var names from $bkptno/$locno to
   $_hit_bpnum/$_hit_locno.
 - updated the tests and user manual accordingly.
   User manual also explictly describes that $_hit_locno is set to 1
   for a breakpoint with a single location.
 - The variable values are now set in bpstat_do_actions_1 so that
   they are set for silent breakpoints, and when several breakpoints
   are hit at the same time, that the variables are set to the printed
   breakpoint.

The changes in RFA v3 handle the additional comments of Eli:
 GDB/NEW:
  - Use max 80-column
  - Use 'code location' instead of 'location'.
  - Fix typo $bkpno
  - Ensure that disable $bkptno and disable $bkptno.$locno have
    each their explanation inthe example
  - Reworded the 'breakpoint-hit' paragraph.
 gdb.texinfo:
  - Use 'code location' instead of 'location'.
  - Add a note to clarify the distinction between $bkptno and $bpnum.
  - Use @kbd instead of examples with only one command.

Compared to RFA v1, the changes in v2 handle the comments given by
Keith Seitz and Eli Zaretskii:
  - Use %s for the result of paddress
  - Use bkptno_numopt_re instead of 2 different -re cases
  - use C@t{++}
  - Add index entries for $bkptno and $locno
  - Added an example for "locno" in the mi interface
  - Added examples in the Break command manual.

RISC-V: Add 'Ssstateen' extension and its CSRs

This commit adds 'Ssstateen' extension, which is a supervisor-visible view
of the 'Smstateen' extension.  It means, this extension implements sstateen*
and hstateen* CSRs of the 'Smstateen' extension.

Note that 'Smstateen' extension itself is unchanged but due to
implementation simplicity, it is implemented so that 'Smstateen' implies
'Ssstateen' (just like 'M' implies 'Zmmul').

This is based on the latest version of RISC-V Profiles
(version 0.9-draft, Frozen):
<https://github.com/riscv/riscv-profiles/commit/226b7f643067b29abc6723fac60d5f6d3f9eb901>

bfd/ChangeLog:

* elfxx-riscv.c (riscv_implicit_subsets): Update implication rules.
(riscv_supported_std_s_ext) Add 'Ssstateen' extension.

gas/ChangeLog:

* config/tc-riscv.c (enum riscv_csr_class): Rename
CSR_CLASS_SMSTATEEN_AND_H{,_32} to CSR_CLASS_SSSTATEEN_...
Add CSR_CLASS_SSSTATEEN.
(riscv_csr_address): Support new/renamed CSR classes.
* testsuite/gas/riscv/csr.s: Add 'Ssstateen' extension to comment.
* testsuite/gas/riscv/csr-version-1p9p1.l: Reflect changes to
error messages.
* testsuite/gas/riscv/csr-version-1p10.l: Likewise.
* testsuite/gas/riscv/csr-version-1p11.l: Likewise.
* testsuite/gas/riscv/csr-version-1p12.l: Likewise.
* testsuite/gas/riscv/ssstateen-csr.s: Test for 'Ssstateen' CSRs.
* testsuite/gas/riscv/ssstateen-csr.d: Likewise.
* testsuite/gas/riscv/smstateen-csr-s.d: Test to make sure that
supervisor/hypervisor part of 'Smstateen' CSRs are accessible from
'RV32IH_Smstateen', not just from 'RV32IH_Ssstateen' that is tested
in ssstateen-csr.d.

include/ChangeLog:

* opcode/riscv-opc.h: Update DECLARE_CSR declarations with
new CSR classes.

Automatic date update in version.in

gdbserver/linux-x86: move lwp declaration out of __x86_64__ region

Commit 4855cbdc3d8f ("gdbserver/linux-x86: make is_64bit_tdesc accept
thread as a parameter") caused this when building in 32 bits / i386
mode:

      CXX    linux-x86-low.o
    In file included from /home/smarchi/src/binutils-gdb/gdbserver/linux-x86-low.cc:24:
    /home/smarchi/src/binutils-gdb/gdbserver/linux-x86-low.cc: In member function ‘virtual int x86_target::low_get_thread_area(int, CORE_ADDR*)’:
    /home/smarchi/src/binutils-gdb/gdbserver/linux-x86-low.cc:357:47: error: ‘lwp’ was not declared in this scope
      357 |     struct thread_info *thr = get_lwp_thread (lwp);
          |                                               ^~~
    /home/smarchi/src/binutils-gdb/gdbserver/linux-low.h:709:31: note: in definition of macro ‘get_lwp_thread’
      709 | #define get_lwp_thread(lwp) ((lwp)->thread)
          |                               ^~~

This is because it moved the lwp variable declaration inside the
__x86_64__ guard, making it unavailable when building in 32 bits mode.
Move the lwp variable outside of the __x86_64__ region.

Change-Id: I7fa3938c6b44b345c27a52c8b8d3ea12aba53e05

gdbserver: use current_process in ps_getpid

The following patch ("gdbserver: switch to right process in
find_one_thread") makes it so find_one_thread calls into libthread_db
with a current process but no current thread.  This tripped on ps_getpid
using current_thread in order to get the process' pid.  Get the pid from
`current_process ()` instead, which removes the need to have a current
thread.  Eventually, it would be good to get it from the
gdb_ps_prochandle_t structure, to avoid the need for a current process
as well.

Reviewed-By: Andrew Burgess <aburgess@redhat.com>
Change-Id: I9d2fae266419199a2fbc2fde0a5104c6e0dbd2d5

gdbserver/linux-x86: make is_64bit_tdesc accept thread as a parameter

ps_get_thread_area receives as a parameter the lwpid it must work on.
It then calls is_64bit_tdesc, which uses the current_thread as the
thread to work on.  However, it is not said that both are the same.

This became a problem when working in a following patch that makes
find_one_thread switch to a process but to no thread (current_thread ==
nullptr).  When libthread_db needed to get the thread area,
is_64bit_tdesc would try to get the regcache of a nullptr thread.

Fix that by making is_64bit_tdesc accept the thread to work on as a
parameter.  Find the right thread from the context, when possible (when
we know the lwpid to work on).  Otherwise, pass "current_thread", to
retain the existing behavior.

Reviewed-By: Andrew Burgess <aburgess@redhat.com>
Change-Id: I44394d6be92392fa28de71982fd04517ce8a3007

gdbserver/linux: take condition out of callback in find_lwp_pid

Just a small optimization, it's not necessary to recompute lwp at each
iteration.

While at it, change the variable type to long, as ptid_t::lwp returns a
long.

Reviewed-By: Andrew Burgess <aburgess@redhat.com>
Change-Id: I181670ce1f90b59cb09ea4899367750be2ad9105

Fix deletion of FinishBreakpoints

Currently, FinishBreakpoints are set at the return address of a frame based on
the `finish' command, and are meant to be temporary breakpoints. However, they
are not being cleaned up after use, as reported in PR python/18655. This was
happening because the disposition of the breakpoint was not being set
correctly.

This commit fixes this issue by correctly setting the disposition in the
post-stop hook of the breakpoint. It also adds a test to ensure this feature
isn't regressed in the future.

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

gdb: fix symtab.c build on 32 bit targets

When building on Ubuntu 22.04, gcc 12, x86-64 with -m32 and -O2, I get:

      CXX    symtab.o
    /home/smarchi/src/binutils-gdb/gdb/symtab.c: In member function â€˜std::vector<symbol_search> global_symbol_searcher::search() const’:
    /home/smarchi/src/binutils-gdb/gdb/symtab.c:4961:44: error: â€˜__builtin___sprintf_chk’ may write a terminating nul past the end of the destination [-Werror=format-overflow=]
     4961 |               sprintf (tmp, "operator%.*s%s", fix, " ", opname);
          |                                            ^
    In file included from /usr/include/stdio.h:894,
                     from ../gnulib/import/stdio.h:43,
                     from /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/common-defs.h:86,
                     from /home/smarchi/src/binutils-gdb/gdb/defs.h:28,
                     from /home/smarchi/src/binutils-gdb/gdb/symtab.c:20:
    In function â€˜int sprintf(char*, const char*, ...)’,
        inlined from â€˜std::vector<symbol_search> global_symbol_searcher::search() const’ at /home/smarchi/src/binutils-gdb/gdb/symtab.c:4961:16:
    /usr/include/i386-linux-gnu/bits/stdio2.h:38:34: note: â€˜__builtin___sprintf_chk’ output between 9 and 2147483648 bytes into a destination of size 2147483647
       38 |   return __builtin___sprintf_chk (__s, __USE_FORTIFY_LEVEL - 1,
          |          ~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
       39 |                                   __glibc_objsize (__s), __fmt,
          |                                   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
       40 |                                   __va_arg_pack ());
          |                                   ~~~~~~~~~~~~~~~~~

PR build/29798 shows a similar error message but on Solaris.

Work around that by using string_printf.  It is a good thing to get rid
of the alloca anyway.

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

gdb/testsuite: rewrite gdb.cp/call-method-register.exp with dwarf assembler

Convert the gdb.cp/call-method-register.exp test to make use of the
DWARF assembler.

The existing gdb.cp/call-method-register.exp test relies on a GCC
extension - forcing a local variable into a particular named register.

This means that the test will only work with Clang, and, as we have to
name the register into which the variable will be placed, will only
work for those targets where we've selected a suitable register,
currently this is x86-64, i386, and ppc64.

By switching to the DWARF assembler, the test will work with gcc and
clang, and should work on most, if not all, architectures.

The test creates a small structure, something that can fit within a
register, and then tries to call a method on the structure from within
GDB.  This should fail because GDB can't take the address of the in
register structure (for the `this` pointer).

As the test is for a failure case, then we don't really care _which_
register the structure is in, and I take advantage of this for the
DWARF assembler test, I just declare that the variable is in
DW_OP_reg0, whatever that might be.  I've tested the new test on
x86-64, ppc, aarch64, and risc-v, and the test runs, and passes on all
these architectures, which is already more than we used to cover.

Additionally, on x86-64, I've tested with Clang and gcc, and the test
runs and passed with both compilers.

Reviewed-By: Lancelot SIX <lancelot.six@amd.com>

gdb/testsuite: fix gdb.debuginfod/fetch_src_and_symbols.exp with Clang

The gdb.debuginfod/fetch_src_and_symbols.exp test is showing a single
failure when run with some older versions of Clang, e.g. 9.0.1.

The problem appears to be with Clang's generated line table.  The test
source looks like this:

  int
  main()
  {
    asm ("main_label: .globl main_label");
    return 0;
  }

In GDB, when we 'start', we expect to stop at the 'return 0;' line.
This is the behaviour when the compiler is gcc, or later versions of
Clang.

However, with Clang 9.0.2, I see GDB stop on the 'asm' line.

In this commit I'll fix this issue by placing a breakpoint on the
return line, and then using gdb_continue_to_breakpoint to ensure we
have stopped in the correct place.

Of course, using gdb_continue_to_breakpoint will only work if we are
not already stopped at the breakpoint location, so I've added some
filler work before the 'return 0;' line.  With this done we can use
gdb_continue_to_breakpoint in all cases.

As a result of adding the new filler work, one of the later tests,
that used the 'list' command, no longer see the correct expected
output (the top line of the source file is no longer included in the
output).  I've fixed this by listing a known specific line, the test
is checking that GDB managed to find the source file, it doesn't
matter which source line we list, as long as we can list something.