Automatic date update in version.in

Automatic date update in version.in

gdb/testsuite: accept script argument for mi_make_breakpoint_pending

This commit changes mi_make_breakpoint_pending to accept the 'script'
and 'times' arguments.

I've then added a new test that makes use of 'scripts' in
gdb.mi/mi-pending.exp and gdb.mi/mi-dprintf-pending.exp.

There is already a test in gdb.mi/mi-pending.exp that uses the 'times'
argument -- previously this argument was being ignored, but is now
used.

Reviewed-By: Tom Tromey <tom@tromey.com>

gdb/testsuite: avoid {"} pattern in lib/mi-support.exp

Commit:

  commit c569a946f6925d3f210c3eaf74dcda56843350ef
  Date:   Fri Mar 24 10:45:37 2023 +0100

      [gdb/testsuite] Fix unbalanced quotes in mi_expect_stop argument

Introduced the use of {"} in mi-support.exp.  There is absolutely
nothing wrong with this in any way.  However, this is causing my
editor to get the syntax highlighting of this file wrong after this
point.

Maybe the real answer is to use a better editor, or fix my current
editor.... but I'm hoping I can instead take the lazy approach of just
changing {"} to "\"", which is handled fine, and means exactly the
same as far as I understand it.

There should be no change in what is tested after this commit.

Reviewed-By: Tom Tromey <tom@tromey.com>

pauth: Create new feature string for pauth to prevent crashing older gdb's

Older gdb's (9, 10, 11 and 12) have a bug that causes them to crash whenever
a target reports the pauth feature string in the target description and also
provide additional register outside of gdb's known and expected feature
strings.

This was fixed in gdb 13 onwards, but that means we're stuck with gdb's out
there that will crash on connection to the above targets.

QEMU has postponed inclusion of the pauth feature string in version 8, and
instead we agreed to use a new feature name to prevent crashing those older
gdb's.

Initially there was a plan to backport a trivial fix all the way to gdb 9, but
given QEMU's choice, this is no longer needed.

This new feature string is org.gnu.gdb.aarch64.pauth_v2, and should be used
by all targets going forward, except native linux gdb and gdbserver, for
backwards compatibility with older gdb's/gdbserver's.

gdb/gdbserver will still emit the old feature string for Linux since it doesn't
report additional system registers and thus doesn't cause a crash of older
gdb's. We can revisit this in the future once the problematic gdb's are likely
no longer in use.

I've added some documentation to explain the situation.

debug registers: Add missing debug version entry for FEAT_Debugv8p8

The Arm Architecture Reference Manual defines debug version 0b1010 for
FEAT_Debugv8p8. This is used to identify valid hardware debug registers.

gdb currently only knows about versions up to FEAT_Debugv8p4. This patch
teaches gdb about this new version.

No visible changes should happen as consequence of this patch, but in the
future gdb will be able to identify debug registers in newer hardware.

Regression-tested on aarch64-linux Ubuntu 20.04/22.04.

gdb/testsuite: Skip dump ihex for 64-bit address in gdb.base/dump.exp

(1) Description of problem

In the current code, when execute the following test on LoongArch:

$make check-gdb TESTS="gdb.base/dump.exp"
```
FAIL: gdb.base/dump.exp: dump array as value, intel hex
FAIL: gdb.base/dump.exp: dump struct as value, intel hex
FAIL: gdb.base/dump.exp: dump array as memory, ihex
FAIL: gdb.base/dump.exp: dump struct as memory, ihex

```
These tests passed on the X86_64,

(2) Root cause

On LoongArch, variable intarray address 0x120008068 out of range for IHEX,
so dump ihex test failed.

gdb.base/dump.exp has the following code to check 64-bit address

```
 # Check the address of a variable.  If it is bigger than 32-bit,
 # assume our target has 64-bit addresses that are not supported by SREC,
 # IHEX and TEKHEX.  We skip those tests then.
 set max_32bit_address "0xffffffff"
 set data_address [get_hexadecimal_valueof "&intarray" 0x100000000]
 if {${data_address} > ${max_32bit_address}} {
    set is64bitonly "yes"
}
```

We check the "&intarray" on different target as follow:

```
$gdb gdb/testsuite/outputs/gdb.base/dump/dump
...
(gdb) start
...

On X86_64:
(gdb) print /x &intarray
$1 = 0x404060

On LoongArch:
(gdb) print /x &intarray
$1 = 0x120008068
```
The variable address difference here is due to the link script
of linker.

```
On X86_64:
$ld --verbose
...
PROVIDE (__executable_start = SEGMENT_START("text-segment", 0x400000));
. = SEGMENT_START("text-segment", 0x400000) + SIZEOF_HEADERS;

On LoongArch:
$ld --verbose
...
PROVIDE (__executable_start = SEGMENT_START("text-segment", 0x120000000));
. = SEGMENT_START("text-segment", 0x120000000) + SIZEOF_HEADERS;

```

(3) How to fix

Because 64-bit variable address out of range for IHEX, it's not an
functional problem for LoongArch. Refer to the handling of 64-bit
targets in this testsuite, use the "is64bitonly" flag to skip those
tests for the target has 64-bit addresses.

Signed-off-by: Hui Li <lihui@loongson.cn>
Approved-By: Tom Tromey <tom@tromey.com>
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>

[gdb/testsuite] Add regression test for PR30325

Add regression tests for PR30325, one for the asm window and one for the
source window.

Use maint set tui-left-margin verbose to make the extend of the left margin
clear.

Tested on x86_64-linux.

Approved-By: Andrew Burgess <aburgess@redhat.com>

Automatic date update in version.in

Avoid double-free with debuginfod

PR gdb/29257 points out a possible double free when debuginfod is in
use.  Aside from some ugly warts in the symbol code (an ongoing
issue), the underlying issue in this particular case is that elfread.c
seems to assume that symfile_bfd_open will return NULL on error,
whereas in reality it throws an exception.  As this code isn't
prepared for an exception, bad things result.

This patch fixes the problem by introducing a non-throwing variant of
symfile_bfd_open and using it in the affected places.

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

arc: Update ARC specific linker tests.

All the tests are designed for a little-endian ARC system. Thus,
update the arc predicate in arc.exp, improve the matching pattern for
linker relaxation test, and add linker scripts to nps-1x tests.

Signed-off-by: Claudiu Zissulescu <claziss@synopsys.com>

arc: Update ARC's CFI tests.

The double store/loads instructions (e.g. STD/LDD) are not baseline
ARC ISA.  The same holds for some short instructions.  Update the
tests to use base ARC ISA.

Signed-off-by: Claudiu Zissulescu <claziss@synopsys.com>

arc: Update GAS test

Signed-off-by: Claudiu Zissulescu <claziss@gmail.com>

Preserve a few more bfd fields in check_format_matches

AOUT and COFF targets set symcount and start_address in their object_p
functions.  If these are used anywhere then it would pay to save and
restore them so that a successful match gets the values expected
rather than that for a later unsuccessful target match.

* format.c (struct bfd_preserve): Move some fields.  Add
symcount, read_only and start_address.
(bfd_preserve_save): Save..
(bfd_preserve_restore): ..and restore..
(bfd_reinit): ..and zero new fields.

Re: pe_ILF_object_p and bfd_check_format_matches

The last patch wasn't quite correct.  bfd_preserve_restore also needs
to handle an in-memory to file backed transition, seen in a testcase
ILF object matching both pei-arm-little and pei-arm-wince-little.
There the first match is saved in preserve_match, and restored at the
end of the bfd_check_format_matches loop making the bfd in-memory.  On
finding more than one match the function wants to restore the bfd back
to its original state with another bfd_preserve_restore call before
exiting with a bfd_error_file_ambiguously_recognized error.

It is also not correct to restore abfd->iostream unless the iovec
changes.  abfd->iostream is a FILE* when using cache_iovec, and if
the file has been closed and reopened the iostream may have changed.

* format.c (io_reinit): New function.
(bfd_reinit, bfd_preserve_restore): Use it.

Automatic date update in version.in

[gdb/tui] Revert workaround in tui_source_window::show_line_number

The m_digits member of tui_source_window is documented as having semantics:
...
  /* How many digits to use when formatting the line number.  This
     includes the trailing space.  */
...

The commit 1b6d4bb2232 ("Redraw both spaces between line numbers and source
code") started printing two trailing spaces instead:
...
-  xsnprintf (text, sizeof (text), "%*d ", m_digits - 1, lineno);
+  xsnprintf (text, sizeof (text), "%*d  ", m_digits - 1, lineno);
...

Now that PR30325 is fixed, this no longer has any effect.

Fix this by reverting to the original behaviour: print one trailing space
char.

Tested on x86_64-linux.

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

[gdb/tui] Fix left margin in disassembly window

With a hello world a.out, and maint set tui-left-margin-verbose on, we have
this disassembly window:
...
┌───────────────────────────────────────────────────────────┐
│___ 0x555555555149 <main>           endbr64                │
│___ 0x55555555514d <main+4>         push   %rbp            │
│___ 0x55555555514e <main+5>         mov    %rsp,%rbp       │
│B+> 0x555555555151 <main+8>         lea    0xeac(%rip),%rax│
│___ 0x555555555158 <main+15>        mov    %rax,%rdi       │
...
Note the space between "B+>" and 0x555555555151.  The space shows that a bit
of the left margin is not written, which is a problem because that location is
showing a character previously written, which happens to be a space, but also
may be something else, for instance a '[' as reported in PR tui/30325.

The problem is caused by confusion about the meaning of:
...
 #define TUI_EXECINFO_SIZE 4
...

There's the meaning of defining the size of this zero-terminated char array:
...
      char element[TUI_EXECINFO_SIZE];
...
which is used to print the "B+>" bit, which is 3 chars wide.

And there's the meaning of defining part of the size of the left margin:
...
  int left_margin () const
  { return 1 + TUI_EXECINFO_SIZE + extra_margin (); }
...
where it represents 4 chars.

The discrepancy between the two causes the space between "B+>" and
"0x555555555151".

Fix this by redefining TUI_EXECINFO_SIZE to 3, and using:
...
      char element[TUI_EXECINFO_SIZE + 1];
...
such that we have:
...
|B+>0x555555555151 <main+8>         lea    0xeac(%rip),%rax │
...

This changes the layout of the disassembly window back to what it was before
commit 9e820dec13e ("Use a curses pad for source and disassembly windows"),
the commit that introduced the PR30325 regression.

This also changes the source window from:
...
│___000005__{                                               |
...
to:
...
│___000005_{                                                |
...

Tested on x86_64-linux.

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

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

[gdb/tui] Add maint set/show tui-left-margin-verbose

The TUI has two types of windows derived from tui_source_window_base:
- tui_source_window (the source window), and
- tui_disasm_window (the disassembly window).

The two windows share a common concept: the left margin.

With a hello world a.out, we can see the source window:
...
┌─/home/vries/hello.c───────────────────────────────────────┐
│        5  {                                               │
│B+>     6    printf ("hello\n");                           │
│        7    return 0;                                     │
│        8  }                                               │
│        9                                                  │
│
...
where the left margin is the part holding "B+>" and the line number, and the
disassembly window:
...
┌───────────────────────────────────────────────────────────┐
│    0x555555555149 <main>           endbr64                │
│    0x55555555514d <main+4>         push   %rbp            │
│    0x55555555514e <main+5>         mov    %rsp,%rbp       │
│B+> 0x555555555151 <main+8>         lea    0xeac(%rip),%rax│
│    0x555555555158 <main+15>        mov    %rax,%rdi       │
...
where the left margin is just the bit holding "B+>".

Because the left margin contains some spaces, it's not clear where it starts
and ends, making it harder to observe problems related to it.

Add a new maintenance command "maint set tui-left-margin-verbose", that when
set to on replaces the spaces in the left margin with either '_' or '0',
giving us this for the source window:
...
┌─/home/vries/hello.c───────────────────────────────────────┐
│___000005__{                                               │
│B+>000006__  printf ("hello\n");                           │
│___000007__  return 0;                                     │
│___000008__}                                               │
...
and this for the disassembly window:
...
┌───────────────────────────────────────────────────────────┐
│___ 0x555555555149 <main>           endbr64                │
│___ 0x55555555514d <main+4>         push   %rbp            │
│___ 0x55555555514e <main+5>         mov    %rsp,%rbp       │
│B+> 0x555555555151 <main+8>         lea    0xeac(%rip),%rax│
│___ 0x555555555158 <main+15>        mov    %rax,%rdi       │
...

Note the space between "B+>" and 0x555555555151.  The space shows that a bit
of the left margin is not written, a problem reported as PR tui/30325.

Specifically, PR tui/30325 is about the fact that the '[' character from the
string "[ No Assembly Available ]" ends up in that same spot:
...
│B+>[0x555555555151 <main+8>         lea    0xeac(%rip),%rax│
...
which only happens for certain window widths.

The new command allows us to spot the problem with any window width.

Likewise, when we revert the fix from commit 1b6d4bb2232 ("Redraw both spaces
between line numbers and source code"), we have:
...
┌─/home/vries/hello.c───────────────────────────────────────┐
│___000005_ {                                               │
│B+>000006_   printf ("hello\n");                           │
│___000007_   return 0;                                     │
│___000008_ }                                               │
...
showing a similar problem at the space between '_' and '{'.

Tested on x86_64-linux.

Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Tom Tromey <tom@tromey.com>

Use SELF_CHECK in all unit tests

I noticed a few unit tests are using gdb_assert.  I think this was an
older style, before SELF_CHECK was added.  This patch switches them
over.

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

arc: remove faulty instructions

Clean not implemented ARC instruction from ARC instruction table.

Use 'require' with gnatmake_version_at_least

I found a couple of tests that check gnatmake_version_at_least using
"if" where "require" would be a little cleaner.  This patch converts
these.

MIPS: make mipsisa32 and mipsisa64 link more systematic

Introduce `static const struct mips_mach_extension mips_mach_32_64[]`
and `mips_mach_extends_32_64 (unsigned long base, unsigned long extension)`,
to make mipsisa32 and mipsisa64 interlink more systemtic.

Normally, the ISA mipsisa64rN has two subset: mipsisa64r(N-1) and
mipsisa32rN. `mips_mach_extensions` can hold only mipsisa64r(N-1),
so we need to introduce a new instruction `mips_mach_32_64`, which holds the pair 32vs64.

Note: R6 is not compatible with pre-R6.

bfd/ChangeLog:

* elfxx-mips.c (mips_mach_extends_p): make mipsisa32 and
  mipsisa64 interlink more systematic.
  (mips_mach_32_64): new struct added.
  (mips_mach_extends_32_64): new function added.

Fix typos in the linker's documentation of the --enable-non-contiguous-regions option.

PR30326, uninitialised value in objdump compare_relocs

This is a fuzzing PR, with a testcase involving a SHF_ALLOC and
SHF_COMPRESSED SHT_RELA section, ie. a compressed dynamic reloc
section.  BFD doesn't handle compressed relocation sections, with most
of the code reading relocs using sh_size (often no bfd section is
created) but in the case of SHF_ALLOC dynamic relocs we had some code
using the bfd section size.  This led to a mismatch, sh_size is
compressed, size is uncompressed, and from that some uninitialised
memory.  Consistently using sh_size is enough to fix this PR, but I've
also added tests to exclude SHF_COMPRESSED reloc sections from
consideration.

PR 30362
* elf.c (bfd_section_from_shdr): Exclude reloc sections with
SHF_COMPRESSED flag from normal reloc processing.
(_bfd_elf_get_dynamic_reloc_upper_bound): Similarly exclude
SHF_COMPRESSED sections from consideration.  Use sh_size when
sizing to match slurp_relocs.
(_bfd_elf_canonicalize_dynamic_reloc): Likewise.
(_bfd_elf_get_synthetic_symtab): Use NUM_SHDR_ENTRIES to size
plt relocs.
* elf32-arm.c (elf32_arm_get_synthetic_symtab): Likewise.
* elf32-ppc.c (ppc_elf_get_synthetic_symtab): Likewise.
* elf64-ppc.c (ppc64_elf_get_synthetic_symtab): Likewise.
* elfxx-mips.c (_bfd_mips_elf_get_synthetic_symtab): Likewise.

ubsan: dwarf2.c:2232:7: runtime error: index 16 out of bounds

Except it isn't out of bounds because space for a larger array has
been allocated.

* dwarf2.c (struct trie_leaf): Make ranges a C99 flexible array.
(alloc_trie_leaf, insert_arange_in_trie): Adjust sizing.

Fail of x86_64 AMX-COMPLEX insns (Intel disassembly)

x86_64-w64-mingw32 pads sections.

* testsuite/gas/i386/x86-64-amx-complex-intel.d: Don't fail
due to nop padding.

pe_ILF_object_p and bfd_check_format_matches

If pe_ILF_object_p succeeds, pe_ILF_build_a_bfd will have changed the
bfd from being file backed to in-memory.  This can have unfortunate
results for targets checked by bfd_check_format_matches after that
point as they will be matching against the created in-memory image
rather than the file.  bfd_preserve_restore also has a problem if it
flips the BFD_IN_MEMORY flag, because the flag affects iostream
meaning and should be set if using _bfd_memory_iovec.  To fix these
problems, save and restore iostream and iovec along with flags, and
modify bfd_reinit to make the bfd file backed again.  Restoring the
iovec and iostream allows the hack in bfd_reinit keeping BFD_IN_MEMORY
(part of BFD_FLAGS_SAVED) to be removed.
One more detail: If restoring from file backed to in-memory then the
bfd needs to be forcibly removed from the cache lru list, since after
the bfd becomes in-memory a bfd_close will delete the bfd's memory
leaving the lru list pointing into freed memory.

* cache.c (bfd_cache_init): Clear BFD_CLOSED_BY_CACHE here..
(bfd_cache_lookup_worker): ..rather than here.
(bfd_cache_close): Comment.
* format.c (struct bfd_preserve): Add iovec and iostream fields.
(bfd_preserve_save): Save them..
(bfd_preserve_restore): ..and restore them, calling
bfd_cache_close if the iovec differs.
(bfd_reinit): Add preserve param.  If the bfd has been flipped
to in-memory, reopen the file.  Restore flags.
* peicode.h (pe_ILF_cleanup): New function.
(pe_ILF_object_p): Return it.
* bfd.c (BFD_FLAGS_SAVED): Delete.
* bfd-in2.h: Regenerate.

Comment typo fix

Automatic date update in version.in

bfd: optimize bfd_elf_hash

The bfd_elf_hash loop is taken straight from the sysV document, but it
is poorly optimized. This refactoring removes about 5 x86 insns from
the 15 insn loop.

1) The if (..) is meaningless -- we're xoring with that value, and of
course xor 0 is a nop. On x86 (at least) we actually compute the xor'd
value and then cmov.  Removing the if test removes the cmov.

2) The 'h ^ g' to clear the top 4 bits is not needed, as those 4 bits
will be shifted out in the next iteration.  All we need to do is sink
a mask of those 4 bits out of the loop.

3) anding with 0xf0 after shifting by 24 bits can allow betterin
encoding on RISC ISAs than masking with '0xf0 << 24' before shifting.
RISC ISAs often require materializing larger constants.

bfd/
* elf.c (bfd_elf_hash): Refactor to optimize loop.
(bfd_elf_gnu_hash): Refactor to use 32-bit type.

gdb, doc: correct argument description for info connections/inferiors

It said for 'info inferiors' and 'info connections' that the argument
could be 'a space separated list of inferior numbers' which is correct
but incomplete.  In fact the arguments can be any space separated
combination of numbers and (ascending) ranges.

The beginning of the section now describes the ID list as a new keyword.

Co-Authored-By: Christina Schimpe <christina.schimpe@intel.com>

Replace an assertion in the dwarf code with a warning message.

  PR 30327
  * dwarf.c (read_and_display_attr_value): Warn if the number of views is greater than the number of locations.

Fix an illegal memorty access when running gprof over corrupt data.

  PR 30324
  * symtab.c (symtab_finalize): Only change the end address if dst has been updated.

Fix an attempt to allocate an excessive amount of memory when parsing a corrupt DWARF file.

  PR 30313
  * dwarf.c (display_debug_lines_decoded): Check for an overlarge number of files or directories.

Fix a potential illegal memory access when displaying corrupt DWARF information.

  PR 30312
  * dwarf.c (prealloc_cu_tu_list): Always allocate at least one entry.

Fix an attempt to allocate an overlarge amount of memory when decoding a corrupt ELF format file.

  PR 30311
  * readelf.c (uncompress_section_contents): Check for a suspiciously large uncompressed size.

Fix illegal memory access when disassembling corrupt NFP binaries.

  PR 30310
  * nfp-dis.c (init_nfp6000_priv): Check that the output section exists.

gdb: fix indentation within print_one_breakpoint_location

Spotted some code in print_one_breakpoint_location that was not
indented correctly, this commit just changes the indentation.

There should be no user visible changes after this commit.

gdb/testsuite: fix typo gdb_name_name -> gdb_test_name

Spotted a small typo in gdb_breakpoint proc, we use $gdb_name_name
instead of $gdb_test_name in one place.  Fixed in this commit.

gdb: warn when converting h/w watchpoints to s/w

On amd64 (at least) if a user sets a watchpoint before the inferior
has started then GDB will assume that a hardware watchpoint can be
created.

When the inferior starts there is a chance that the watchpoint can't
actually be create as a hardware watchpoint, in which case (currently)
GDB will silently convert the watchpoint to a software watchpoint.
Here's an example session:

  (gdb) p sizeof var
  $1 = 4000
  (gdb) watch var
  Hardware watchpoint 1: var
  (gdb) info watchpoints
  Num     Type           Disp Enb Address    What
  1       hw watchpoint  keep y              var
  (gdb) starti
  Starting program: /home/andrew/tmp/watch

  Program stopped.
  0x00007ffff7fd3110 in _start () from /lib64/ld-linux-x86-64.so.2
  (gdb) info watchpoints
  Num     Type           Disp Enb Address            What
  1       watchpoint     keep y                      var
  (gdb)

Notice that before the `starti` command the watchpoint is showing as a
hardware watchpoint, but afterwards it is showing as a software
watchpoint.  Additionally, note that we clearly told the user we
created a hardware watchpoint:

  (gdb) watch var
  Hardware watchpoint 1: var

I think this is bad.  I used `starti`, but if the user did `start` or
even `run` then the inferior is going to be _very_ slow, which will be
unexpected -- after all, we clearly told the user that we created a
hardware watchpoint, and the manual clearly says that hardware
watchpoints are fast (at least compared to s/w watchpoints).

In this patch I propose adding a new warning which will be emitted
when GDB downgrades a h/w watchpoint to s/w.  The session now looks
like this:

  (gdb) p sizeof var
  $1 = 4000
  (gdb) watch var
  Hardware watchpoint 1: var
  (gdb) info watchpoints
  Num     Type           Disp Enb Address    What
  1       hw watchpoint  keep y              var
  (gdb) starti
  Starting program: /home/andrew/tmp/watch
  warning: watchpoint 1 downgraded to software watchpoint

  Program stopped.
  0x00007ffff7fd3110 in _start () from /lib64/ld-linux-x86-64.so.2
  (gdb) info watchpoints
  Num     Type           Disp Enb Address            What
  1       watchpoint     keep y                      var
  (gdb)

The important line is:

  warning: watchpoint 1 downgraded to software watchpoint

It's not much, but hopefully it will be enough to indicate to the user
that something unexpected has occurred, and hopefully, they will not
be surprised when the inferior runs much slower than they expected.

I've added an amd64 only test in gdb.arch/, I didn't want to try
adding this as a global test as other architectures might be able to
support the watchpoint request in h/w.

Also the test is skipped for extended-remote boards as there's a
different set of options for limiting hardware watchpoints on remote
targets, and this test isn't about them.

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

gdb/riscv: Support c.li in prologue unwinder

I was seeing some failures in gdb.threads/omp-par-scope.exp when run
on a riscv64 target.  It turns out the cause of the problem is that I
didn't have debug information installed for libgomp.so, which this
test makes use of.  The test requires GDB to backtrace through a
libgomp function, and the riscv prologue unwinder was failing to
unwind this particular stack frame.

The reason for the failure to unwind was that the function prologue
includes a c.li (compressed load immediate) instruction, and the riscv
prologue scanning unwinder doesn't know what to do with this
instruction, though the unwinder does understand c.lui (compressed
load unsigned immediate).

This commit adds support for c.li.  After this GDB is able to unwind
through libgomp, and I no longer see any unexpected failures in
gdb.threads/omp-par-scope.exp.

I've also included a new test in gdb.arch/ which specifically checks
for our c.li support.

Automatic date update in version.in

gdb/dwarf: Fix MinGW build

Unfortunately MinGW doesn't support std::future yet, so this causes the
build to fail.  Use GDB's version which provides a fallback for this case.

Tested for regressions on native aarch64-linux.

Approved-By: Tom Tromey <tromey@adacore.com>

Handle unwinding from SEGV on Windows

PR win32/30255 points out that a call to a NULL function pointer will
leave gdb unable to "bt" on Windows.

I tracked this down to the amd64 windows unwinder.  If we treat this
scenario as if it were a leaf function, unwinding works fine.

I'm not completely sure this patch is the best way.  I considered
having it check for 'pc==0' -- but then I figured this could affect
any inaccessible PC, not just the special 0 value.

No test case because I can't run dejagnu tests on Windows.  I tested
this by hand using the test case in the bug.

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

x86: Add inval tests for AMX instructions

gas/ChangeLog:

* testsuite/gas/i386/i386.exp: Run AMX-FP16 and AMX-COMPLEX
inval testcases.
* testsuite/gas/i386/x86-64-amx-inval.l: Add AMX-BF16 tests.
* testsuite/gas/i386/x86-64-amx-inval.s: Ditto.
* testsuite/gas/i386/x86-64-amx-complex-inval.l: New test.
* testsuite/gas/i386/x86-64-amx-complex-inval.s: Ditto.
* testsuite/gas/i386/x86-64-amx-fp16-inval.l: Ditto.
* testsuite/gas/i386/x86-64-amx-fp16-inval.s: Ditto.

Automatic date update in version.in

Automatic date update in version.in

Fix typos in previous commit of gdb.texinfo.

* gdb/doc/gdb.texinfo (Requirements): Fix typos.

libctf, link: fix CU-mapped links with CTF_LINK_EMPTY_CU_MAPPINGS

This is a bug in the intersection of two obscure options that cannot
even be invoked from ld with a feature added to stop ld of the
same input file repeatedly from crashing the linker.

The latter fix involved tracking input files (internally to libctf) not
just with their input CU name but with a version of their input CU name
that was augmented with a numeric prefix if their linker input file name
was changed, to prevent distinct CTF dicts with the same cuname from
overwriting each other. (We can't use just the linker input file name
because one linker input can contain many CU dicts, particularly under
ld -r).  If these inputs then produced conflicting types, those types
were emitted into similarly-named output dicts, so we needed similar
machinery to detect clashing output dicts and add a numeric prefix to
them as well.

This works fine, except that if you used the cu-mapping feature to force
double-linking of CTF (so that your CTF can be grouped into output dicts
larger than a single translation unit) and then also used
CTF_LINK_EMPTY_CU_MAPPINGS to force every possible output dict in the
mapping to be created (even if empty), we did the creation of empty dicts
first, and then all the actual content got considered to be a clash. So
you ended up with a pile of useless empty dicts and then all the content
was in full dicts with the same names suffixed with a #0.  This seems
likely to confuse consumers that use this facility.

Fixed by generating all the EMPTY_CU_MAPPINGS empty dicts after linking
is complete, not before it runs.

No impact on ld, which does not do cu-mapped links or pass
CTF_LINK_EMPTY_CU_MAPPINGS to ctf_link().

libctf/
* ctf-link.c (ctf_create_per_cu): Don't create new dicts iff one
        already exists and we are making one for no input in particular.
        (ctf_link): Emit empty CTF dicts corresponding to no input in
        particular only after linkiing is complete.

libctf: propagate errors from parents correctly

CTF dicts have per-dict errno values: as with other errno values these
are set on error and left unchanged on success.  This means that all
errors *must* set the CTF errno: if a call leaves it unchanged, the
caller is apt to find a previous, lingering error and misinterpret
it as the real error.

There are many places in libctf where we carry out operations on parent
dicts as a result of carrying out other user-requested operations on
child dicts (e.g. looking up information on a pointer to a type will
look up the type as well: the pointer might well be in a child and the
type it's a pointer to in the parent).  Those operations on the parent
might fail; if they do, the error must be correctly reflected on the
child that the user-visible operation was carried out on.  In many
places this was not happening.

So, audit and fix all those places.  Add tests for as many of those
cases as possible so they don't regress.

libctf/
* ctf-create.c (ctf_add_slice): Use the original dict.
* ctf-lookup.c (ctf_lookup_variable): Propagate errors.
(ctf_lookup_symbol_idx): Likewise.
* ctf-types.c (ctf_member_next): Likewise.
(ctf_type_resolve_unsliced): Likewise.
(ctf_type_aname): Likewise.
(ctf_member_info): Likewise.
(ctf_type_rvisit): Likewise.
(ctf_func_type_info): Set the error on the right dict.
(ctf_type_encoding): Use the original dict.
* testsuite/libctf-writable/error-propagation.*: New test.

libctf, tests: do not assume host and target have identical field offsets

The newly-introduced libctf-lookup unnamed-field-info test checks
C compiler-observed field offsets against libctf-computed ones
by #including the testcase in the lookup runner as well as
generating CTF for it.  This only works if the host, on which
the lookup runner is compiled and executed, is the same architecture as
the target, for which the CTF is generated: when crossing, the trick
may fail.

So pass down an indication of whether this is a cross into the
testsuite, and add a new no_cross flag to .lk files that is used to
suppress test execution when a cross-compiler is being tested.

libctf/
* Makefile.am (check_DEJAGNU): Pass down TEST_CROSS.
* Makefile.in: Regenerated.
* testsuite/lib/ctf-lib.exp (run_lookup_test): Use it to
implement the new no_cross option.
* testsuite/libctf-lookup/unnamed-field-info.lk: Mark as
no_cross.

Automatic date update in version.in

Rewrite Ada symbol cache

In an experiment I'm trying, I needed Ada symbol cache entries to be
allocated with 'new'.  This patch reimplements the symbol cache to use
the libiberty hash table and to use new and delete.  A couple of other
minor cleanups are done.

Add Ada test case for break using a label

I noticed there aren't any Ada test cases for setting a breakpoint
using a label.  This patch adds one, adapted from the AdaCore test
suite.

Use ui_out for "maint info frame-unwinders"

This changes "maint info frame-unwinders" to use ui-out.  This makes
the table slightly nicer.  In general I think it's better to use
ui-out for tables.

[gdb/testsuite] Add -q to INTERNAL_GDBFLAGS

Whenever we start gdb in the testsuite, we have the rather verbose:
...
$ gdb
GNU gdb (GDB) 14.0.50.20230405-git
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word".
(gdb)
...

This makes gdb.log longer than necessary and harder to read.

We do need to test that the output is produced, but that should be limited to
one or a few test-cases.

Fix this by adding -q to INTERNAL_GDBFLAGS, such that we simply have:
...
$ gdb -q
(gdb)
...

Tested on x86_64-linux.

[gdb/testsuite] Add missing .note.GNU-stack in gdb.arch/amd64-disp-step-self-call.exp

For test-case gdb.arch/amd64-disp-step-self-call.exp I get:
...
gdb compile failed, ld: warning: amd64-disp-step-self-call0.o: \
  missing .note.GNU-stack section implies executable stack
ld: NOTE: This behaviour is deprecated and will be removed in a future \
  version of the linker
...

Fix this by adding the missing .note.GNU-stack.

Likewise for gdb.arch/i386-disp-step-self-call.exp.

Tested on x86_64-linux.

Support Intel AMX-COMPLEX

gas/ChangeLog:

* NEWS: Support Intel AMX-COMPLEX.
* config/tc-i386.c: Add amx_complex.
* doc/c-i386.texi: Document .amx_complex.
* testsuite/gas/i386/i386.exp: Run AMX-COMPLEX tests.
* testsuite/gas/i386/amx-complex-inval.l: New test.
* testsuite/gas/i386/amx-complex-inval.s: Ditto.
* testsuite/gas/i386/x86-64-amx-complex-bad.d: Ditto.
* testsuite/gas/i386/x86-64-amx-complex-bad.s: Ditto.
* testsuite/gas/i386/x86-64-amx-complex-intel.d: Ditto.
* testsuite/gas/i386/x86-64-amx-complex.d: Ditto.
* testsuite/gas/i386/x86-64-amx-complex.s: Ditto.

opcodes/ChangeLog:

* i386-dis.c (MOD_VEX_0F386C_X86_64_W_0): New.
(PREFIX_VEX_0F386C_X86_64_W_0_M_1_L_0): Ditto.
(X86_64_VEX_0F386C): Ditto.
(VEX_LEN_0F386C_X86_64_W_0_M_1): Ditto.
(VEX_W_0F386C_X86_64): Ditto.
(mod_table): Add MOD_VEX_0F386C_X86_64_W_0.
(prefix_table): Add PREFIX_VEX_0F386C_X86_64_W_0_M_1_L_0.
(x86_64_table): Add X86_64_VEX_0F386C.
(vex_len_table): Add VEX_LEN_0F386C_X86_64_W_0_M_1.
(vex_w_table): Add VEX_W_0F386C_X86_64.
* i386-gen.c (cpu_flag_init): Add CPU_AMX_COMPLEX_FLAGS and
CPU_ANY_AMX_COMPLEX_FLAGS.
* i386-init.h: Regenerated.
* i386-mnem.h: Ditto.
* i386-opc.h (CpuAMX_COMPLEX): New.
(i386_cpu_flags): Add cpuamx_complex.
* i386-opc.tbl: Add AMX-COMPLEX instructions.
* i386-tbl.h: Regenerated.

gdb/testsuite: updates for gdb.arch/{amd64,i386}-disp-step-self-call.exp

This commit:

  commit cf141dd8ccd36efe833aae3ccdb060b517cc1112
  Date:   Wed Feb 22 12:15:34 2023 +0000

      gdb: fix reg corruption from displaced stepping on amd64

Added two test scripts gdb.arch/amd64-disp-step-self-call.exp and
gdb.arch/i386-disp-step-self-call.exp.  These scripts contained a test
that included a stack address in the test name, this makes it harder
to compare results between runs.

This commit gives the tests proper names that doesn't include an
address.

Also in gdb.arch/i386-disp-step-self-call.exp I noticed that we were
writing 8-bytes rather than 4 in order to clear the return address
entry on the stack.  This is also fixed in this commit.

Automatic date update in version.in

Use unique_xmalloc_ptr in apply_ext_lang_type_printers

This changes apply_ext_lang_type_printers to use unique_xmalloc_ptr,
removing some manual memory management.  Regression tested on x86-64
Fedora 36.

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

Fix gdb.base/align-*.exp and Clang + LTO and AIX GCC

Clang with LTO (clang -flto) garbage collects unused global variables,
Thus, gdb.base/align-c.exp and gdb.base/align-c++.exp fail with
hundreds of FAILs like so:

 $ make check \
    TESTS="gdb.*/align-*.exp" \
    RUNTESTFLAGS="CC_FOR_TARGET='clang -flto' CXX_FOR_TARGET='clang++ -flto'"
 ...
 FAIL: gdb.base/align-c.exp: get integer valueof "a_char"
 FAIL: gdb.base/align-c.exp: print _Alignof(char)
 FAIL: gdb.base/align-c.exp: get integer valueof "a_char_x_char"
 FAIL: gdb.base/align-c.exp: print _Alignof(struct align_pair_char_x_char)
 FAIL: gdb.base/align-c.exp: get integer valueof "a_char_x_unsigned_char"
 ...

AIX GCC has the same issue, and there the easier way of adding
__attribute__((used)) to globals does not help.

So add explicit uses of all globals to the generated code.

For the C++ test, that reveals that the static variable members of the
generated structs are not defined anywhere, leading to undefined
references.  Fixed by emitting initialization for all static members.

Lastly, I noticed that CXX_FOR_TARGET was being ignored -- that's
because the align-c++.exp testcase is compiling with the C compiler
driver.  Fixed by passing "c++" as option to prepare_for_testing.

Change-Id: I874b717afde7b6fb1e45e526912b518a20a12716

gdb: run black code formatter on gdbarch_components.py

The following commit changed gdbarch_components.py but failed to
format it with black:

  commit cf141dd8ccd36efe833aae3ccdb060b517cc1112
  Date:   Wed Feb 22 12:15:34 2023 +0000

      gdb: fix reg corruption from displaced stepping on amd64

This commit just runs black on the file and commits the result.

The change is just the addition of an extra "," -- there will be no
change to the generated source files after this commit.

There will be no user visible changes after this commit.

gdb/python: allow Frame.read_var to accept named arguments

This commit allows Frame.read_var to accept named arguments, and also
improves (I think) some of the error messages emitted when values of
the wrong type are passed to this function.

The read_var method takes two arguments, one a variable, which is
either a gdb.Symbol or a string, while the second, optional, argument
is always a gdb.Block.

I'm now using 'O!' as the format specifier for the second argument,
which allows the argument type to be checked early on.  Currently, if
the second argument is of the wrong type then we get this error:

  (gdb) python print(gdb.selected_frame().read_var("a1", "xxx"))
  Traceback (most recent call last):
    File "<string>", line 1, in <module>
  RuntimeError: Second argument must be block.
  Error while executing Python code.
  (gdb)

After this commit, we now get an error like this:

  (gdb) python print(gdb.selected_frame().read_var("a1", "xxx"))
  Traceback (most recent call last):
    File "<string>", line 1, in <module>
  TypeError: argument 2 must be gdb.Block, not str
  Error while executing Python code.
  (gdb)

Changes are:

  1. Exception type is TypeError not RuntimeError, this is unfortunate
  as user code _could_ be relying on this, but I think the improvement
  is worth the risk, user code relying on the exact exception type is
  likely to be pretty rare,

  2. New error message gives argument position and expected argument
  type, as well as the type that was passed.

If the first argument, the variable, has the wrong type then the
previous exception was already a TypeError, however, I've updated the
text of the exception to more closely match the "standard" error
message we see above.  If the first argument has the wrong type then
before this commit we saw this:

  (gdb) python print(gdb.selected_frame().read_var(123))
  Traceback (most recent call last):
    File "<string>", line 1, in <module>
  TypeError: Argument must be a symbol or string.
  Error while executing Python code.
  (gdb)

And after we see this:

  (gdb) python print(gdb.selected_frame().read_var(123))
  Traceback (most recent call last):
    File "<string>", line 1, in <module>
  TypeError: argument 1 must be gdb.Symbol or str, not int
  Error while executing Python code.
  (gdb)

For existing code that doesn't use named arguments and doesn't rely on
exceptions, there will be no changes after this commit.

Reviewed-By: Tom Tromey <tom@tromey.com>

gdb/python: convert Frame.read_register to take named arguments

Following on from the previous commit, this updates
Frame.read_register to accept named arguments.  As with the previous
commit there's no huge benefit for the users in accepting named
arguments here -- this function only takes a single argument after
all.

But I do think it is worth keeping Frame.read_register method in sync
with the PendingFrame.read_register method, this allows for the
possibility that the user has some code that can operate on either a
Frame or a Pending frame.

Minor update to allow for named arguments, and an extra test to check
the new functionality.

Reviewed-By: Tom Tromey <tom@tromey.com>

gdb/python: have PendingFrame methods accept keyword arguments

Update the two gdb.PendingFrame methods gdb.PendingFrame.read_register
and gdb.PendingFrame.create_unwind_info to accept keyword arguments.

There's no huge benefit for making this change, both of these methods
only take a single argument, so it is (maybe) less likely that a user
will take advantage of the keyword arguments in these cases, but I
think it's nice to be consistent, and I don't see any particular draw
backs to making this change.

For PendingFrame.read_register I've changed the argument name from
'reg' to 'register' in the documentation and used 'register' as the
argument name in GDB.  My preference for APIs is to use full words
where possible, and given we didn't support named arguments before
this change should not break any existing code.

There should be no user visible changes (for existing code) after this
commit.

Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Reviewed-By: Tom Tromey <tom@tromey.com>

gdb/python: have UnwindInfo.add_saved_register accept named args

Update gdb.UnwindInfo.add_saved_register to accept named keyword
arguments.

As part of this update we now use gdb_PyArg_ParseTupleAndKeywords
instead of PyArg_UnpackTuple to parse the function arguments.

By switching to gdb_PyArg_ParseTupleAndKeywords, we can now use 'O!'
as the argument format for the function's value argument.  This means
that we can check the argument type (is gdb.Value) as part of the
argument processing rather than manually performing the check later in
the function.  One result of this is that we now get a better error
message (at least, I think so).  Previously we would get something
like:

  ValueError: Bad register value

Now we get:

  TypeError: argument 2 must be gdb.Value, not XXXX

It's unfortunate that the exception type changed, but I think the new
exception type actually makes more sense.

My preference for argument names is to use full words where that's not
too excessive.  As such, I've updated the name of the argument from
'reg' to 'register' in the documentation, which is the argument name
I've made GDB look for here.

For existing unwinder code that doesn't throw any exceptions nothing
should change with this commit.  It is possible that a user has some
code that throws and catches the ValueError, and this code will break
after this commit, but I think this is going to be sufficiently rare
that we can take the risk here.

Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Reviewed-By: Tom Tromey <tom@tromey.com>

gdb: fix reg corruption from displaced stepping on amd64

This commit aims to address a problem that exists with the current
approach to displaced stepping, and was identified in PR gdb/22921.

Displaced stepping is currently supported on AArch64, ARM, amd64,
i386, rs6000 (ppc), and s390.  Of these, I believe there is a problem
with the current approach which will impact amd64 and ARM, and can
lead to random register corruption when the inferior makes use of
asynchronous signals and GDB is using displaced stepping.

The problem can be found in displaced_step_buffers::finish in
displaced-stepping.c, and is this; after GDB tries to perform a
displaced step, and the inferior stops, GDB classifies the stop into
one of two states, either the displaced step succeeded, or the
displaced step failed.

If the displaced step succeeded then gdbarch_displaced_step_fixup is
called, which has the job of fixing up the state of the current
inferior as if the step had not been performed in a displaced manner.
This all seems just fine.

However, if the displaced step is considered to have not completed
then GDB doesn't call gdbarch_displaced_step_fixup, instead GDB
remains in displaced_step_buffers::finish and just performs a minimal
fixup which involves adjusting the program counter back to its
original value.

The problem here is that for amd64 and ARM setting up for a displaced
step can involve changing the values in some temporary registers.  If
the displaced step succeeds then this is fine; after the step the
temporary registers are restored to their original values in the
architecture specific code.

But if the displaced step does not succeed then the temporary
registers are never restored, and they retain their modified values.

In this context a temporary register is simply any register that is
not otherwise used by the instruction being stepped that the
architecture specific code considers safe to borrow for the lifetime
of the instruction being stepped.

In the bug PR gdb/22921, the amd64 instruction being stepped is
an rip-relative instruction like this:

  jmp    *0x2fe2(%rip)

When we displaced step this instruction we borrow a register, and
modify the instruction to something like:

  jmp    *0x2fe2(%rcx)

with %rcx having its value adjusted to contain the original %rip
value.

Now if the displaced step does not succeed, then %rcx will be left
with a corrupted value.  Obviously corrupting any register is bad; in
the bug report this problem was spotted because %rcx is used as a
function argument register.

And finally, why might a displaced step not succeed?  Asynchronous
signals provides one reason.  GDB sets up for the displaced step and,
at that precise moment, the OS delivers a signal (SIGALRM in the bug
report), the signal stops the inferior at the address of the displaced
instruction.  GDB cancels the displaced instruction, handles the
signal, and then tries again with the displaced step.  But it is that
first cancellation of the displaced step that causes the problem; in
that case GDB (correctly) sees the displaced step as having not
completed, and so does not perform the architecture specific fixup,
leaving the register corrupted.

The reason why I think AArch64, rs600, i386, and s390 are not effected
by this problem is that I don't believe these architectures make use
of any temporary registers, so when a displaced step is not completed
successfully, the minimal fix up is sufficient.

On amd64 we use at most one temporary register.

On ARM, looking at arm_displaced_step_copy_insn_closure, we could
modify up to 16 temporary registers, and the instruction being
displaced stepped could be expanded to multiple replacement
instructions, which increases the chances of this bug triggering.

This commit only aims to address the issue on amd64 for now, though I
believe that the approach I'm proposing here might be applicable for
ARM too.

What I propose is that we always call gdbarch_displaced_step_fixup.

We will now pass an extra argument to gdbarch_displaced_step_fixup,
this a boolean that indicates whether GDB thinks the displaced step
completed successfully or not.

When this flag is false this indicates that the displaced step halted
for some "other" reason.  On ARM GDB can potentially read the
inferior's program counter in order figure out how far through the
sequence of replacement instructions we got, and from that GDB can
figure out what fixup needs to be performed.

On targets like amd64 the problem is slightly easier as displaced
stepping only uses a single replacement instruction.  If the displaced
step didn't complete the GDB knows that the single instruction didn't
execute.

The point is that by always calling gdbarch_displaced_step_fixup, each
architecture can now ensure that the inferior state is fixed up
correctly in all cases, not just the success case.

On amd64 this ensures that we always restore the temporary register
value, and so bug PR gdb/22921 is resolved.

In order to move all architectures to this new API, I have moved the
minimal roll-back version of the code inside the architecture specific
fixup functions for AArch64, rs600, s390, and ARM.  For all of these
except ARM I think this is good enough, as no temporaries are used all
that's needed is the program counter restore anyway.

For ARM the minimal code is no worse than what we had before, though I
do consider this architecture's displaced-stepping broken.

I've updated the gdb.arch/amd64-disp-step.exp test to cover the
'jmpq*' instruction that was causing problems in the original bug, and
also added support for testing the displaced step in the presence of
asynchronous signal delivery.

I've also added two new tests (for amd64 and i386) that check that GDB
can correctly handle displaced stepping over a single instruction that
branches to itself.  I added these tests after a first version of this
patch relied too much on checking the program-counter value in order
to see if the displaced instruction had executed.  This works fine in
almost all cases, but when an instruction branches to itself a pure
program counter check is not sufficient.  The new tests expose this
problem.

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

Approved-By: Pedro Alves <pedro@palves.net>

Re: objcopy write_debugging_info memory leaks

Oops, tried to free too much

* wrstabs.c (write_stabs_in_sections_debugging_info): Don't
free strings.

objdump print_debugging_info memory leaks

Fix memory leaks and do a general tidy of the code for printing coff
and stabs debug.

* prdbg.c: Delete unnneeded forward function declarations.
Delete unnecessary casts throughout.  Free all strings
returned from pop_type throughout file.
(struct pr_stack): Delete "num_parents".  Replace tests for
"num_parents" non-zero with tests of "parents" non-NULL
throughout.  Free "parents" before assigning, and set to NULL
after freeing.  Remove const from "method".  Always strdup
strings assigned to method, and free before assigning.
(print_debugging_info): Free info.stack and info.filename.

objdump -g on gcc COFF/PE files

objdump -g can't be used much.  Trying to dump PE files invariably
seems to run into "debug_name_type: no current file" or similar
errors, because parse_coff expects a C_FILE symbol to be the first
symbol.  Dumping -gstabs output works since the N_SO stab is present.
Pre-setting the file name won't hurt stabs dumping.

* rddbg.c (read_debugging_info): Call debug_set_filename.

gas/write.c use better types

A tiny tidy.

* write.c (frags_chained): Make it a bool.
(n_fixups): Make it unsigned.

objcopy write_debugging_info memory leaks

The old stabs code didn't bother too much about freeing memory.
This patch corrects that and avoids some dubious copying of strings.

* objcopy.c (write_debugging_info): Free both strings and
syms on failure to create sections.
* wrstabs.c: Delete unnecessary forward declarations and casts
throughout file.
(stab_write_symbol_and_free): New function.  Use it
throughout, simplifying return paths.
(stab_push_string): Don't strdup string.  Use it thoughout
for malloced strings.
(stab_push_string_dup): New function.  Use it throughout for
strings in auto buffers.
(write_stabs_in_sections_debugging_info): Free malloced memory.
(stab_enum_type): Increase buffer sizing for worst case.
(stab_range_type, stab_array_type): Reduce buffer size.
(stab_set_type): Likewise.
(stab_method_type): Free args on error return.  Correct
buffer size.
(stab_struct_field): Fix memory leaks.
(stab_class_static_member, stab_class_baseclass): Likewise.
(stab_start_class_type): Likewise.  Correct buffer size.
(stab_class_start_method): Correct buffer size.
(stab_class_method_var): Free memory on error return.
(stab_start_function): Fix "rettype" memory leak.

Automatic date update in version.in

gdb/testsuite: Default to assembler's preferred debug format in asm-source.exp

The stabs debug format is obsolete and there's no reason to think that
toolchains still have good support for it. Therefore, if a specific debug
format wasn't set in asm-source.exp then leave it to the assembler to
decide which one to use.

Reviewed-By: Tom Tromey <tom@tromey.com>

gdb: Fix reading of partial symtabs in dbxread.c

After commit 9675da25357c ("Use unrelocated_addr in minimal symbols"),
aarch64-linux started failing gdb.asm/asm-source.exp:

Running /home/thiago.bauermann/src/binutils-gdb/gdb/testsuite/gdb.asm/asm-source.exp ...
PASS: gdb.asm/asm-source.exp: f at main
PASS: gdb.asm/asm-source.exp: n at main
PASS: gdb.asm/asm-source.exp: next over macro
FAIL: gdb.asm/asm-source.exp: step into foo2
PASS: gdb.asm/asm-source.exp: info target
PASS: gdb.asm/asm-source.exp: info symbol
PASS: gdb.asm/asm-source.exp: list
PASS: gdb.asm/asm-source.exp: search
FAIL: gdb.asm/asm-source.exp: f in foo2
FAIL: gdb.asm/asm-source.exp: n in foo2 (the program exited)
FAIL: gdb.asm/asm-source.exp: bt ALL in foo2
FAIL: gdb.asm/asm-source.exp: bt 2 in foo2
PASS: gdb.asm/asm-source.exp: s 2
PASS: gdb.asm/asm-source.exp: n 2
FAIL: gdb.asm/asm-source.exp: bt 3 in foo3
PASS: gdb.asm/asm-source.exp: info source asmsrc1.s
FAIL: gdb.asm/asm-source.exp: finish from foo3 (the program is no longer running)
FAIL: gdb.asm/asm-source.exp: info source asmsrc2.s
PASS: gdb.asm/asm-source.exp: info sources
FAIL: gdb.asm/asm-source.exp: info line
FAIL: gdb.asm/asm-source.exp: next over foo3 (the program is no longer running)
FAIL: gdb.asm/asm-source.exp: return from foo2
PASS: gdb.asm/asm-source.exp: look at global variable
PASS: gdb.asm/asm-source.exp: x/i &globalvar
PASS: gdb.asm/asm-source.exp: disassem &globalvar, (int *) &globalvar+1
PASS: gdb.asm/asm-source.exp: look at static variable
PASS: gdb.asm/asm-source.exp: x/i &staticvar
PASS: gdb.asm/asm-source.exp: disassem &staticvar, (int *) &staticvar+1
PASS: gdb.asm/asm-source.exp: look at static function

The problem is simple: a pair of parentheses was removed from the
expression calculating text_end and thus text_size was only added if
lowest_text_address wasn't equal to -1.

This patch restores the previous behaviour and fixes the testcase.
Tested on native aarch64-linux.

Reviewed-By: Tom Tromey <tom@tromey.com>

Improve documentation of GDB build requirements and options

MPFR is now mandatory, so its previous description in Requirements
was inappropriate and out of place.  In addition, the description
of how to go about specifying 'configure' time options for
building with libraries was highly repetitive.  Some of the text
was also outdated and used wrong markup.

Original patch and suggestions from Philippe Blain
<levraiphilippeblain@gmail.com>.

ChangeLog:
2023-04-05  Eli Zaretskii  <eliz@gnu.org>

* gdb/doc/gdb.texinfo (Requirements, Configure Options): Update and
rearrange; improve and fix markup.

gdb, doc: add the missing '-gid' option to 'info threads'

The 'info threads' command does not show the '-gid' option
in the syntax.  Add the option.  The flag is already explained
in the command description and used in the examples.

Approved-By: Eli Zaretskii <eliz@gnu.org>

gdb: boolify 'should_print_thread'

Convert the return type of 'should_print_thread' from int to bool.

Reviewed-By: Tom Tromey <tom@tromey.com>

gdb: make find_thread_ptid a process_stratum_target method

Make find_thread_ptid (the overload that takes a process_stratum_target)
a method of process_stratum_target.

Change-Id: Ib190a925a83c6b93e9c585dc7c6ab65efbdd8629
Reviewed-By: Tom Tromey <tom@tromey.com>

gdb: make find_thread_ptid an inferior method

Make find_thread_ptid (the overload that takes an inferior) a method of
struct inferior.

Change-Id: Ie5b9fa623ff35aa7ddb45e2805254fc8e83c9cd4
Reviewed-By: Tom Tromey <tom@tromey.com>

Automatic date update in version.in

bfd+ld: when / whether to generate .c files

Having been irritated by seeing bfd/elf{32,64}-aarch64.c to be re-
generated in x86-only builds, I came across 769a27ade588 ("Re: bfd
BLD-POTFILES.in dependencies"). I think this went slightly too far, as
outside of maintainer mode dependencies will cause the subset of files
to be (re-)generated which are actually needed for the build.
Generating them all is only needed when wanting to update certain files
under bfd/po/, i.e. in maintainer mode.

In the course of looking around in an attempt to try to understand how
things are meant to work, I further noticed that ld has got things
slightly wrong too: BLD-POTFILES.in depending on $(BLD_POTFILES) isn't
quite right (the output doesn't change when any of the enumerated files
changes; it's the mere presence which matters); like in bfd it looks
like we would better extend BUILT_SOURCES accordingly.

Furthermore it became apparent that ld fails to enumerate the .c files
generated from the .l and .y ones. While in their absence it was benign
whether translatable strings in the source files were actually marked as
such, this now becomes relevant. Mark respective strings at the same
time, but skipping ones which look to be of interest for debugging
purposes only (e.g. such used by printf() enclosed in #ifdef TRACE).

Use bfd_alloc memory for read_debugging_info storage

Trying to free malloc'd memory used by the stabs and coff debug info
parsers is complicated, and traversing the trees generated requires a
lot of code.  It's better to bfd_alloc the memory which allows it all
to be freed without fuss when the bfd is closed.  In the process of
doing this I reverted most of commit a6336913332.

Some of the stabs handling code grows arrays of pointers with realloc,
to deal with arbitrary numbers of fields, function args, etc.  The
code still does that but copies over to bfd_alloc memory when
finished.  The alternative is to parse twice, once to size, then again
to populate the arrays.  I think that complication is unwarranted.

Note that there is a greater than zero chance this patch breaks
something, eg. that I missed an attempt to free obj_alloc memory.
Also it seems there are no tests in the binutils testsuite aimed at
exercising objdump --debugging.

* budbg.h (finish_stab, parse_stab): Update prototypes
* debug.c: Include bucomm.h.
(struct debug_handle): Add "abfd" field.
(debug_init): Add "abfd" param.  bfd_alloc handle.
(debug_xalloc, debug_xzalloc): New functions.  Use throughout
in place of xmalloc and memset.
(debug_start_source): Remove "name_used" param.
* debug.h (debug_init, debug_start_source): Update prototypes.
(debug_xalloc, debug_xzalloc): Declare.
* objcopy.c (copy_object): Don't free dhandle.
* objdump.c (dump_bfd): Likewise.
* rdcoff.c (coff_get_slot): Add dhandle arg.  debug_xzalloc
memory in place of xcalloc.  Update callers.
(parse_coff_struct_type): Don't leak on error return.  Copy
fields over to debug_xalloc memory.
(parse_coff_enum_type): Copy names and vals over the
debug_xalloc memory.
* rddbg.c (read_debugging_info): Adjust debug_init call.
Don't free dhandle.
(read_section_stabs_debugging_info): Don't free shandle.
Adjust parse_stab call.  Call finish_stab on error return.
(read_symbol_stabs_debugging_info): Similarly.
* stabs.c (savestring): Delete unnecessary forward declaration.
Add dhandle param.  debug_xalloc memory.  Update callers.
(start_stab): Delete unnecessary casts.
(finish_stab): Add "emit" param.  Free file_types, so_string,
and stabs handle.
(parse_stab): Delete string_used param.  Revert code dealing
with string_used.  Copy so_string passed to debug_set_filename
and stored as main_filename to debug_xalloc memory.  Similarly
for string passed to debug_start_source and push_bincl.  Copy
args to debug_xalloc memory.  Don't leak args.
(parse_stab_enum_type): Copy names and values to debug_xalloc
memory.  Don't free name.
(parse_stab_struct_type): Don't free fields.
(parse_stab_baseclasses): Delete unnecessary cast.
(parse_stab_struct_fields): Return debug_xalloc fields.
(parse_stab_cpp_abbrev): Use debug_xalloc for _vb$ type name.
(parse_stab_one_struct_field): Don't free name.
(parse_stab_members): Copy variants and methods to
debug_xalloc memory.  Don't free name or argtypes.
(parse_stab_argtypes): Use debug_xalloc memory for physname
and args.
(push_bincl): Add dhandle param.  Use debug_xalloc memory.
(stab_record_variable): Use debug_xalloc memory.
(stab_emit_pending_vars): Don't free var list.
(stab_find_slot): Add dhandle param.  Use debug_xzalloc
memory.  Update all callers.
(stab_find_tagged_type): Don't free name.  Use debug_xzalloc.
(stab_demangle_qualified): Don't free name.
(stab_demangle_template): Don't free s1.
(stab_demangle_args): Tidy pvarargs refs.  Copy *pargs on
success to debug_xalloc memory, free on failure.
(stab_demangle_fund_type): Don't free name.
(stab_demangle_v3_arglist): Copy args to debug_xalloc memory.
Don't free dt.

Automatic date update in version.in

Add readMemory and writeMemory requests to DAP

This adds the DAP readMemory and writeMemory requests.  A small change
to the evaluation code is needed in order to test this -- this is one
of the few ways for a client to actually acquire a memory reference.

gdb: cleanup around some set_momentary_breakpoint_at_pc calls

I noticed a couple of places in infrun.c where we call
set_momentary_breakpoint_at_pc, and then set the newly created
breakpoint's thread field, these are in:

  insert_exception_resume_breakpoint
  insert_exception_resume_from_probe

Function set_momentary_breakpoint_at_pc calls
set_momentary_breakpoint, which always creates the breakpoint as
thread-specific for the current inferior_thread().

The two insert_* functions mentioned above take an arbitrary
thread_info* as an argument and set the breakpoint::thread to hold the
thread number of that arbitrary thread.

However, the insert_* functions store the breakpoint pointer within
the current inferior_thread(), so we know that the thread being passed
in must be the currently selected thread.

What this means is that we can:

  1. Assert that the thread being passed in is the currently selected
  thread, and

  2. No longer adjust the breakpoint::thread field, this will already
  have been set correctly be calling set_momentary_breakpoint_at_pc.

There should be no user visible changes after this commit.

gdb: don't always print breakpoint location after failed condition check

Consider the following session:

  (gdb) list some_func
  1 int
  2 some_func ()
  3 {
  4   int *p = 0;
  5   return *p;
  6 }
  7
  8 void
  9 foo ()
  10 {
  (gdb) break foo if (some_func ())
  Breakpoint 1 at 0x40111e: file bpcond.c, line 11.
  (gdb) r
  Starting program: /tmp/bpcond

  Program received signal SIGSEGV, Segmentation fault.
  0x0000000000401116 in some_func () at bpcond.c:5
  5   return *p;
  Error in testing condition for breakpoint 1:
  The program being debugged stopped while in a function called from GDB.
  Evaluation of the expression containing the function
  (some_func) will be abandoned.
  When the function is done executing, GDB will silently stop.

  Breakpoint 1, 0x0000000000401116 in some_func () at bpcond.c:5
  5   return *p;
  (gdb)

What happens here is the breakpoint condition includes a call to an
inferior function, and the inferior function segfaults.  We can see
that GDB reports the segfault, and then gives an error message that
indicates that an inferior function call was interrupted.

After this GDB appears to report that it is stopped at Breakpoint 1,
inside some_func.

I find this second stop report a little confusing.  While it is true
that GDB stopped as a result of hitting breakpoint 1, I think the
message GDB currently prints might give the impression that GDB is
actually stopped at a location of breakpoint 1, which is not the case.

Also, I find the second stop message draws attention away from
the "Program received signal SIGSEGV, Segmentation fault" stop
message, and this second stop might be thought of as replacing in
someway the earlier message.

In short, I think things would be clearer if the second stop message
were not reported at all, so the output should, I think, look like
this:

  (gdb) list some_func
  1 int
  2 some_func ()
  3 {
  4   int *p = 0;
  5   return *p;
  6 }
  7
  8 void
  9 foo ()
  10 {
  (gdb) break foo if (some_func ())
  Breakpoint 1 at 0x40111e: file bpcond.c, line 11.
  (gdb) r
  Starting program: /tmp/bpcond

  Program received signal SIGSEGV, Segmentation fault.
  0x0000000000401116 in some_func () at bpcond.c:5
  5   return *p;
  Error in testing condition for breakpoint 1:
  The program being debugged stopped while in a function called from GDB.
  Evaluation of the expression containing the function
  (some_func) will be abandoned.
  When the function is done executing, GDB will silently stop.
  (gdb)

The user can still find the number of the breakpoint that triggered
the initial stop in this line:

  Error in testing condition for breakpoint 1:

But there's now only one stop reason reported, the SIGSEGV, which I
think is much clearer.

To achieve this change I set the bpstat::print field when:

  (a) a breakpoint condition evaluation failed, and

  (b) the $pc of the thread changed during condition evaluation.

I've updated the existing tests that checked the error message printed
when a breakpoint condition evaluation failed.

gdb: avoid repeated signal reporting during failed conditional breakpoint

Consider the following case:

  (gdb) list some_func
  1 int
  2 some_func ()
  3 {
  4   int *p = 0;
  5   return *p;
  6 }
  7
  8 void
  9 foo ()
  10 {
  (gdb) break foo if (some_func ())
  Breakpoint 1 at 0x40111e: file bpcond.c, line 11.
  (gdb) r
  Starting program: /tmp/bpcond

  Program received signal SIGSEGV, Segmentation fault.
  0x0000000000401116 in some_func () at bpcond.c:5
  5   return *p;
  Error in testing breakpoint condition:
  The program being debugged was signaled while in a function called from GDB.
  GDB remains in the frame where the signal was received.
  To change this behavior use "set unwindonsignal on".
  Evaluation of the expression containing the function
  (some_func) will be abandoned.
  When the function is done executing, GDB will silently stop.

  Program received signal SIGSEGV, Segmentation fault.

  Breakpoint 1, 0x0000000000401116 in some_func () at bpcond.c:5
  5   return *p;
  (gdb)

Notice that this line:

  Program received signal SIGSEGV, Segmentation fault.

Appears twice in the output.  The first time is followed by the
current location.  The second time is a little odd, why do we print
that?

Printing that line is controlled, in part, by a global variable,
stopped_by_random_signal.  This variable is reset to zero in
handle_signal_stop, and is set if/when GDB figures out that the
inferior stopped due to some random signal.

The problem is, in our case, GDB first stops at the breakpoint for
foo, and enters handle_signal_stop and the stopped_by_random_signal
global is reset to 0.

Later within handle_signal_stop GDB calls bpstat_stop_status, it is
within this function (via bpstat_check_breakpoint_conditions) that the
breakpoint condition is checked, and, we end up calling the inferior
function (some_func in our example above).

In our case above the thread performing the inferior function call
segfaults in some_func.  GDB catches the SIGSEGV and handles the stop,
this causes us to reenter handle_signal_stop.  The global variable
stopped_by_random_signal is updated, this time it is set to true
because the thread stopped due to SIGSEGV.  As a result of this we
print the first instance of the line (as seen above in the example).

Finally we unwind GDB's call stack, the inferior function call is
complete, and we return to the original handle_signal_stop.  However,
the stopped_by_random_signal global is still carrying the value as
computed for the inferior function call's stop, which is why we now
print a second instance of the line, as seen in the example.

To prevent this, I propose adding a scoped_restore before we start an
inferior function call.  This will save and restore the global
stopped_by_random_signal value.

With this done, the output from our example is now this:

 (gdb) list some_func
  1 int
  2 some_func ()
  3 {
  4   int *p = 0;
  5   return *p;
  6 }
  7
  8 void
  9 foo ()
  10 {
  (gdb) break foo if (some_func ())
  Breakpoint 1 at 0x40111e: file bpcond.c, line 11.
  (gdb) r
  Starting program: /tmp/bpcond

  Program received signal SIGSEGV, Segmentation fault.
  0x0000000000401116 in some_func () at bpcond.c:5
  5   return *p;
  Error in testing condition for breakpoint 1:
  The program being debugged stopped while in a function called from GDB.
  Evaluation of the expression containing the function
  (some_func) will be abandoned.
  When the function is done executing, GDB will silently stop.

  Breakpoint 1, 0x0000000000401116 in some_func () at bpcond.c:5
  5   return *p;
  (gdb)

We now only see the 'Program received signal SIGSEGV, ...' line once,
which I think makes more sense.

Finally, I'm aware that the last few lines, that report the stop as
being at 'Breakpoint 1', when this is not where the thread is actually
located anymore, is not great.  I'll address that in the next commit.

gdbserver: allow agent expressions to fail with invalid memory access

This commit extends gdbserver to take account of a failed memory
access from agent_mem_read, and to return a new eval_result_type
expr_eval_invalid_memory_access.

I have only updated the agent_mem_read calls related directly to
reading memory, I have not updated any of the calls related to
tracepoint data collection.  This is just because I'm not familiar
with that area of gdb/gdbserver, and I don't want to break anything,
so leaving the existing behaviour untouched seems like the safest
approach.

I've then updated gdb.base/bp-cond-failure.exp to test evaluating the
breakpoints on the target, and have also extended the test so that it
checks for different sizes of memory access.

gdbserver: allows agent_mem_read to return an error code

Currently the gdbserver function agent_mem_read ignores any errors
from calling read_inferior_memory.  This means that if there is an
attempt to access invalid memory then this will appear to succeed.

In this patch I update agent_mem_read so that if read_inferior_memory
fails, agent_mem_read will return an error code.

However, none of the callers of agent_mem_read actually check the
return value, so this commit will have no effect on anything.  In the
next commit I will update the users of agent_mem_read to check for the
error code.

I've also updated the header comments on agent_mem_read to better
reflect what the function does, and its possible return values.

gdb: include breakpoint number in testing condition error message

When GDB fails to test the condition of a conditional breakpoint, for
whatever reason, the error message looks like this:

  (gdb) break foo if (*(int *) 0) == 1
  Breakpoint 1 at 0x40111e: file bpcond.c, line 11.
  (gdb) r
  Starting program: /tmp/bpcond
  Error in testing breakpoint condition:
  Cannot access memory at address 0x0

  Breakpoint 1, foo () at bpcond.c:11
  11   int a = 32;
  (gdb)

The line I'm interested in for this commit is this one:

  Error in testing breakpoint condition:

In the case above we can figure out that the problematic breakpoint
was #1 because in the final line of the message GDB reports the stop
at breakpoint #1.

However, in the next few patches I plan to change this.  In some cases
I don't think it makes sense for GDB to report the stop as being at
breakpoint #1, consider this case:

  (gdb) list some_func
  1 int
  2 some_func ()
  3 {
  4   int *p = 0;
  5   return *p;
  6 }
  7
  8 void
  9 foo ()
  10 {
  (gdb) break foo if (some_func ())
  Breakpoint 1 at 0x40111e: file bpcond.c, line 11.
  (gdb) r
  Starting program: /tmp/bpcond

  Program received signal SIGSEGV, Segmentation fault.
  0x0000000000401116 in some_func () at bpcond.c:5
  5   return *p;
  Error in testing breakpoint condition:
  The program being debugged was signaled while in a function called from GDB.
  GDB remains in the frame where the signal was received.
  To change this behavior use "set unwindonsignal on".
  Evaluation of the expression containing the function
  (some_func) will be abandoned.
  When the function is done executing, GDB will silently stop.

  Program received signal SIGSEGV, Segmentation fault.

  Breakpoint 1, 0x0000000000401116 in some_func () at bpcond.c:5
  5   return *p;
  (gdb)

Notice that, the final lines of output reports the stop as being at
breakpoint #1, even though the inferior in not located within
some_func, and it's certainly not located at the breakpoint location.

I find this behaviour confusing, and propose that this should be
changed.  However, if I make that change then every reference to
breakpoint #1 will be lost from the error message.

So, in this commit, in preparation for the later commits, I propose to
change the 'Error in testing breakpoint condition:' line to this:

  Error in testing condition for breakpoint NUMBER:

where NUMBER will be filled in as appropriate.  Here's the first
example with the updated error:

  (gdb) break foo if (*(int *) 0) == 0
  Breakpoint 1 at 0x40111e: file bpcond.c, line 11.
  (gdb) r
  Starting program: /tmp/bpcond
  Error in testing condition for breakpoint 1:
  Cannot access memory at address 0x0

  Breakpoint 1, foo () at bpcond.c:11
  11   int a = 32;
  (gdb)

The breakpoint number does now appear twice in the output, but I don't
see that as a negative.

This commit just changes the one line of the error, and updates the
few tests that either included the old error in comments, or actually
checked for the error in the expected output.

As the only test that checked the line I modified is a Python test,
I've added a new test that doesn't rely on Python that checks the
error message in detail.

While working on the new test, I spotted that it would fail when run
with native-gdbserver and native-extended-gdbserver target boards.
This turns out to be due to a gdbserver bug.  To avoid cluttering this
commit I've added a work around to the new test script so that the
test passes for the remote boards, in the next few commits I will fix
gdbserver, and update the test script to remove the work around.

asan: csky floatformat_to_double uninitialised value

* csky-dis.c (csky_print_operand <OPRND_TYPE_FCONSTANT>): Don't
access ibytes after read_memory_func error.  Change type of
ibytes to avoid casts.

gdb/riscv: fix regressions in gdb.base/unwind-on-each-insn.exp

This commit builds on the previous one to fix all the remaining
failures in gdb.base/unwind-on-each-insn.exp for RISC-V.

The problem we have in gdb.base/unwind-on-each-insn.exp is that, when
we are in the function epilogue, the previous frame and stack pointer
values are being restored, and so, the values that we calculated
during the function prologue are no longer suitable.

Here's an example from the function 'bar' in the mentioned test.  This
was compiled for 64-bit RISC-V with compressed instruction support:

  Dump of assembler code for function bar:
     0x000000000001018a <+0>: add sp,sp,-32
     0x000000000001018c <+2>: sd ra,24(sp)
     0x000000000001018e <+4>: sd fp,16(sp)
     0x0000000000010190 <+6>: add fp,sp,32
     0x0000000000010192 <+8>: sd a0,-24(fp)
     0x0000000000010196 <+12>: ld a0,-24(fp)
     0x000000000001019a <+16>: jal 0x10178 <foo>
     0x000000000001019e <+20>: nop
     0x00000000000101a0 <+22>: ld ra,24(sp)
     0x00000000000101a2 <+24>: ld fp,16(sp)
     0x00000000000101a4 <+26>: add sp,sp,32
     0x00000000000101a6 <+28>: ret
  End of assembler dump.

When we are at address 0x101a4 the previous instruction has restored
the frame-pointer, as such GDB's (current) preference for using the
frame-pointer as the frame base address is clearly not going to work.
We need to switch to using the stack-pointer instead.

At address 0x101a6 the previous instruction has restored the
stack-pointer value.  Currently GDB will not understand this and so
will still assume the stack has been decreased by 32 bytes in this
function.

My proposed solution is to extend GDB such that GDB will scan the
instructions at the current $pc looking for this pattern:

  ld    fp,16(sp)
  add   sp,sp,32
  ret

Obviously the immediates can change, but the basic pattern indicates
that the function is in the process of restoring state before
returning.  If GDB sees this pattern then GDB can use the inferior's
position within this instruction sequence to help calculate the
correct frame-id.

With this implemented then gdb.base/unwind-on-each-insn.exp now fully
passes.

Obviously what I've implemented is just a heuristic.  It's not going
to work for every function.  If the compiler reorders the
instructions, or merges the epilogue back into the function body then
GDB is once again going to get the frame-id wrong.

I'm OK with that, we're no worse off that we are right now in that
situation (plus we can always improve the heuristic later).

Remember, this is for debugging code without debug information,
and (in our imagined situation) with more aggressive levels of
optimisation being used.  Obviously GDB is going to struggle in these
situations.

My thinking is, lets get something in place now.  Then, later, if
possible, we might be able to improve the logic to cover more
situations -- if there's an interest in doing so.  But I figure we
need something in place as a starting point.

After this commit gdb.base/unwind-on-each-insn.exp passes with no
failures on RV64.

gdb/riscv: support c.ldsp and c.lwsp in prologue scanner

Add support to the RISC-V prologue scanner for c.ldsp and c.lwsp
instructions.

This fixes some of the failures in gdb.base/unwind-on-each-insn.exp,
though there are further failures that are not fixed by this commit.

This change started as a wider fix that would address all the failures
in gdb.base/unwind-on-each-insn.exp, however, that wider fix needed
support for the two additional compressed instructions.

When I added support for those two compressed instructions I noticed
that some of the failures in gdb.base/unwind-on-each-insn.exp resolved
themselves!

Here's what's going on:

The reason for the failures is that GDB is trying to build the
frame-id during the last few instructions of the function.  These are
the instructions that restore the frame and stack pointers just prior
to the return instruction itself.

By the time we reach the function epilogue the stack offset that we
calculated during the prologue scan is no longer valid, and so we
calculate the wrong frame-id.

However, in the particular case of interest here, the test function
'foo', the function is so simple and short (the empty function) that
GDB's prologue scan could, in theory, scan every instruction of the
function.

I say "could, in theory," because currently GDB stops the prologue
scan early when it hits an unknown instruction.  The unknown
instruction happens to be one of the compressed instructions that I'm
adding support for in this commit.

Now that GDB understands the compressed instructions the prologue scan
really does go from the start of the function right up to the current
program counter.  As such, GDB sees that the stack frame has been
allocated, and then deallocated, and so builds the correct frame-id.

Of course, most real functions are not as simple as the test function
'foo'.  As such, we can't usually rely on scanning right up to the end
of the function -- there are some instructions we always need to stop
at because GDB can't reason about how they change the inferior
state (e.g. a function call).  The test function 'bar' is just such an
example.

After this commit, we can now build the frame-id correctly for every
instruction in 'foo', but there are some tests still failing in 'bar'.

gdb/riscv: convert riscv debug settings to new debug print scheme

Convert the RISC-V specific debug settings to use the new debug
printing scheme.  This updates the following settings:

  set/show debug riscv breakpoints
  set/show debug riscv gdbarch
  set/show debug riscv infcall
  set/show debug riscv unwinder

All of these settings now take a boolean rather than an integer, and
all print their output using the new debug scheme.

There should be no visible change for anyone not turning on debug.

opcodes/arm: adjust whitespace in cpsie instruction

While I was working on the disassembler styling for ARM I noticed that
the whitespace in the cpsie instruction was inconsistent with most of
the other ARM disassembly output, the disassembly for cpsie looks like
this:

  cpsie   if,#10

notice there's no space before the '#10' immediate, most other ARM
instructions have a space before each operand.

This commit updates the disassembler to add the missing space, and
updates the tests I found that tested this instruction.

gdb/testsuite: gdb.server/server-kill.exp 'info frame' before kill_server

This commit follows on from the following two commits:

  commit 80dc83fd0e70f4d522a534bc601df5e05b81d564
  Date:   Fri Jun 11 11:30:47 2021 +0100

      gdb/remote: handle target dying just before a stepi

And:

  commit 079f190d4cfc6aa9c934b00a9134bc0fcc172d53
  Date:   Thu Mar 9 10:45:03 2023 +0100

      [gdb/testsuite] Fix gdb.server/server-kill.exp for remote target

The first of these commits fixed an issue in GDB and tried to extend
the gdb.server/server-kill.exp test to cover the GDB fix.

Unfortunately, the changes to gdb.server/server-kill.exp were not
correct, and were causing problems when trying to run with the
remote-gdbserver-on-localhost board file.

The second commit reverts some of the gdb.server/server-kill.exp
changes introduced in the first commit so that the test will now work
correctly with the remote-gdbserver-on-localhost board file.

The second commit is just about GDB's testing infrastructure -- it's
not about the original fix to GDB from the first commit, the actual
GDB change was fine.

While reviewing the second commit I wanted to check that the problem
fixed in the first commit is still being tested by the
gdb.server/server-kill.exp script, so I reverted the change to
breakpoint.c that is the core of the first commit and ran the test
script ..... and saw no failures.

The first commit is about GDB discovering that gdbserver has died
while trying to insert a breakpoint.  As soon as GDB spots that
gdbserver is gone we mourn the remote inferior, which ends up deleting
all the breakpoints associated with the remote inferiors.  We then
throw an exception which is caught in the insert breakpoints code, and
we try to display an error that includes the breakpoint number
.... but the breakpoint has already been deleted ... and so GDB
crashes.

After digging a little, what I found is that today, when the test does
'stepi' the first thing we end up doing is calculating the frame-id as
part of the stepi logic, it is during this frame-id calculation that
we mourn the remote inferior, delete the breakpoints, and throw an
exception.  The exception is caught by the top level interpreter loop,
and so we never try to print the breakpoint number which is what
caused the original crash.

If I add an 'info frame' command to the test script, prior to killing
gdbserver, then now when we 'stepi' GDB already has the frame-id
calculated, and the first thing we do is try to insert the
breakpoints, this will trigger the original bug.

In order to reproduce this experiment you'll need to change a function
in breakpoint.c, like this:

  static void
  rethrow_on_target_close_error (const gdb_exception &e)
  {
    return;
  }

Then run gdb.server/server-kill.exp with and without this patch.  You
should find that without this patch there are zero test failures,
while with this patch there will be one failure like this:

  (gdb) PASS: gdb.server/server-kill.exp: test_stepi: info frame
  Executing on target: kill -9 4513    (timeout = 300)
  builtin_spawn -ignore SIGHUP kill -9 4513
  stepi
  ../../src/gdb/breakpoint.c:2863: internal-error: insert_bp_location: Assertion `bl->owner != nullptr' failed.
  A problem internal to GDB has been detected,
  further debugging may prove unreliable.
  ----- Backtrace -----
  ...

gdb/testsuite: fix failure in gdb.python/py-unwind.exp

A potential test failure was introduced with commit:

  commit 6bf5f25bb150c0fbcb125e3ee466ba8f9680310b
  Date:   Wed Mar 8 16:11:30 2023 +0000

      gdb/python: make the gdb.unwinder.Unwinder class more robust

In this commit a new test was added, however the expected output
pattern varies depending on which Python version GDB is linked
against.

Older versions of Python result in output like this:

    (gdb) python global_test_unwinder.name = "foo"
    Traceback (most recent call last):
      File "<string>", line 1, in <module>
    AttributeError: can't set attribute
    Error while executing Python code.
    (gdb)

While more recent versions of Python give a similar, but slightly more
verbose error message, like this:

    (gdb) python global_test_unwinder.name = "foo"
    Traceback (most recent call last):
      File "<string>", line 1, in <module>
    AttributeError: can't set attribute 'name'
    Error while executing Python code.
    (gdb)

The test was only accepting the first version of the output.  This
commit extends the test pattern so that either version will be
accepted.