This commit adds Zfhmin and Zhinxmin extensions (subsets of Zfh and
Zhinx extensions, respectively).  In the process supporting Zfhmin and
Zhinxmin extension, this commit also changes how instructions are
categorized considering Zfhmin, Zhinx and Zhinxmin extensions.

bfd/ChangeLog:

	* elfxx-riscv.c (riscv_implicit_subsets): Change implicit
	subsets.  Zfh->Zicsr is not needed and Zfh->F is replaced with
	Zfh->Zfhmin and Zfhmin->F.  Zhinx->Zicsr is not needed and
	Zhinx->Zfinx is replaced with Zhinx->Zhinxmin and
	Zhinxmin->Zfinx.
	(riscv_supported_std_z_ext): Add 'Zfhmin' and 'Zhinxmin'
	extensions.  Reorder them for canonical ordering.
	(riscv_multi_subset_supports): Rewrite handling for new
	instruction classes.
	(riscv_multi_subset_supports_ext): Add diagnostics.
	(riscv_parse_check_conflicts): Change error message to include
	'Zfh' and 'Zfhmin' extensions.

gas/ChangeLog:

	* testsuite/gas/riscv/zfhmin-d-insn-class-fail.s: New complex
	error handling test.
	* testsuite/gas/riscv/zfhmin-d-insn-class-fail-1.d: Likewise.
	* testsuite/gas/riscv/zfhmin-d-insn-class-fail-1.l: Likewise.
	* testsuite/gas/riscv/zfhmin-d-insn-class-fail-2.d: Likewise.
	* testsuite/gas/riscv/zfhmin-d-insn-class-fail-2.l: Likewise.
	* testsuite/gas/riscv/zfhmin-d-insn-class-fail-3.d: Likewise.
	* testsuite/gas/riscv/zfhmin-d-insn-class-fail-3.l: Likewise.
	* testsuite/gas/riscv/zfhmin-d-insn-class-fail-4.d: Likewise.
	* testsuite/gas/riscv/zfhmin-d-insn-class-fail-4.l: Likewise.
	* testsuite/gas/riscv/zfhmin-d-insn-class-fail-5.d: Likewise.
	* testsuite/gas/riscv/zfhmin-d-insn-class-fail-5.l: Likewise.
	* testsuite/gas/riscv/zhinx.d: Renamed from fp-zhinx-insns.d
	and refactored.
	* testsuite/gas/riscv/zhinx.s: Likewise.

include/ChangeLog:

	* opcode/riscv.h (enum riscv_insn_class): Renew instruction
	classes INSN_CLASS_ZFH_OR_ZHINX, INSN_CLASS_ZFHMIN,
	INSN_CLASS_ZFHMIN_OR_ZHINXMIN, INSN_CLASS_ZFHMIN_AND_D and
	INSN_CLASS_ZFHMIN_AND_Q.
	Remove INSN_CLASS_ZFH, INSN_CLASS_D_AND_ZFH and
	INSN_CLASS_Q_AND_ZFH.

opcodes/ChangeLog:

	* riscv-opc.c (riscv_opcodes): Change instruction classes for
	Zfh and Zfhmin instructions.  Fix `fcvt.h.lu' instruction
	(two operand variant) mask.

Adding support for location and range lists for split-dwarf and dwarf-5.
Following issues are taken care.
1. Display of the index values for DW_FORM_loclistx and DW_FORM_rnglistx.
2. Display of .debug_loclists.dwo and .debug_rnglists.dwo sections.

        * dwarf.c(read_and_display_attr_value): Handle DW_FORM_loclistx
        and DW_FORM_rnglistx for .dwo files.
        (process_debug_info): Load .debug_loclists.dwo and
        .debug_rnglists.dwo if exists.
        (load_separate_debug_files): Load .debug_loclists and
        .debug_rnglists if exists.
        Include 2 entries in debug_displays table.
        * dwarf.h (enum dwarf_section_display_enum): Include 2 entries.

This is in preparation of dropping the leading . from the strings.

While there also move PROCESSOR_GENERIC{32,64} from the middle of AMD
entries to near the top.

Putting individual elements behind macros, besides (imo) improving
readability, will make subsequent (and likely also future) changes less
intrusive.

Utilize this right away to pack the table a little more tightly, by
converting "skip" to bool and putting it earlier in a group of bitfields
together with "len".

Introduce a helper function to replace 4 instances of similar code. Use
reconcat() to cover the previously explicit free().

Lots of memory used in gas should go on this obstack.  The patch also
frees all the gas obstacks on exit, which isn't a completely trivial
task.

	* subsegs.c (alloc_seginfo): New function.
	(subseg_change, subseg_get): Use it.
	(subsegs_end): New function.
	* as.h (subsegs_end): Declare.
	* output-file.c: Include subsegs.h
	(stash_frchain_obs): New function.
	(output_file_close): Save obstacks attached to output bfd before
	closing.  Call subsegs_end with the array of obstacks.

This fixes an inconsequential objcopy memory leak.  I'd normally
ignore reports of leaks like this one, that are merely one block or
fewer per section processed, since objcopy soon exits and frees all
memory.  However I thought it worth providing support for allocating
memory on a bfd objalloc in objcopy and other utils.

	PR 29233
	* bucomm.c (bfd_xalloc): New function.
	* bucomm.h (bfd_xalloc): Declare.
	* objcopy.c (copy_relocations_in_section): Use it to allocate
	array of reloc pointers.  Rewrite code stripping relocs to do
	without extra memory allocation.

        * dwarf.c(process_debug_info): Include DW_TAG_skeleton_unit.
        (display_debug_str_offsets): While dumping .debug_str_offsets.dwo,
        pass proper str_offsets_base to fetch_indexed_string().
        (load_separate_debug_files): Skip DWO ID dump for dwarf-5.

	* disassemble.c: (disassemble_init_for_target): Set
	created_styled_output for AVR based targets.
	* avr-dis.c: (print_insn_avr): Use fprintf_styled_ftype
	instead of fprintf_ftype throughout.
	(avr_operand): Pass in and fill disassembler_style when
	parsing operands.

The dwarf2_per_cu_data fields lang and unit_type both have a dont-know
initial value (respectively language_unknown and (dwarf_unit_type)0), which
allows us to add certain checks, f.i. checking that that a field is not read
before written.

Add get/set member functions for the two fields as a convenient location to
add such checks, make the fields private to enforce using the member
functions, and add the m_ prefix.

Tested on x86_64-linux.

Use the (wider) predicate rather than a triplet. This eliminates the sole
i386-msdos failure in the testsuite.

The only case where 64-bit code uses non-sign-extended (can also be
considered zero-extended) displacements is when an address size override
is in place for a memory operand (i.e. particularly excluding
displacements of direct branches, which - if at all - are controlled by
operand size, and then are still sign-extended, just from 16 bits).
Hence the distinction in templates is unnecessary, allowing code to be
simplified in a number of places. The only place where logic becomes
more complicated is when signed-ness of relocations is determined in
output_disp().

The other caveat is that Disp64 cannot be specified anymore in an insn
template at the same time as Disp32. Unlike for non-64-bit mode,
templates don't specify displacements for both possible addressing
modes; the necessary adjustment to the expected ones has already been
done in match_template() anyway (but of course the logic there needs
tweaking now). Hence the single template so far doing so is split.

Commit 7d5e4556 rendered the check near the end of what is now
i386_finalize_displacement() entirely dead for AT&T mode, since for
operands involving a displacement .unspecified will always be set. But
the logic there is bogus anyway - Intel syntax operand size specifiers
are of no interest there either. The only thing which matters in the
"displacement only" determination is .baseindex.

Of course when masking displacement kinds we should not at the same time
also mask off other attributes.

Furthermore the type mask returned by lex_got() also needs to be
adjusted: The only case where we want Disp32 (rather than Disp32S) is
when dealing with 32-bit addressing mode in 64-bit code.

There are two related problems here: The use of "addr32" on a direct
branch would, besides causing a warning, result in operands to be
permitted which mistakenly are refused without "addr32". Plus at some
point not too long ago I'm afraid it may have been me who regressed the
relocation addends emitted for such branches. Correct both problems,
adding a testcase to guard against regressing this again.

Because ratified Zihintpause extension has a version number of 2.0
(not 1.0), we should update the number.

bfd/ChangeLog:

	* elfxx-riscv.c (riscv_supported_std_z_ext): Update version
	number of Zihintpause extension.

When building gdb with -fsanitize=thread and gcc 12, and running test-case
gdb.dwarf2/dwz.exp, we run into a data race between thread T2 and the main
thread in the same write:
...
Write of size 1 at 0x7b200000300c:^M
    #0 cutu_reader::cutu_reader(dwarf2_per_cu_data*, dwarf2_per_objfile*, \
    abbrev_table*, dwarf2_cu*, bool, abbrev_cache*) gdb/dwarf2/read.c:6252 \
    (gdb+0x82f3b3)^M
...
which is here:
...
         this_cu->dwarf_version = cu->header.version;
...

Both writes are called from the parallel for in dwarf2_build_psymtabs_hard,
this one directly:
...
    #1 process_psymtab_comp_unit gdb/dwarf2/read.c:6774 (gdb+0x8304d7)^M
    #2 operator() gdb/dwarf2/read.c:7098 (gdb+0x8317be)^M
    #3 operator() gdbsupport/parallel-for.h:163 (gdb+0x872380)^M
...
and this via the PU import:
...
    #1 cooked_indexer::ensure_cu_exists(cutu_reader*, dwarf2_per_objfile*, \
    sect_offset, bool,  bool) gdb/dwarf2/read.c:17964 (gdb+0x85c43b)^M
    #2 cooked_indexer::index_imported_unit(cutu_reader*, unsigned char const*, \
    abbrev_info const*) gdb/dwarf2/read.c:18248 (gdb+0x85d8ff)^M
    #3 cooked_indexer::index_dies(cutu_reader*, unsigned char const*, \
    cooked_index_entry const*, bool) gdb/dwarf2/read.c:18302 (gdb+0x85dcdb)^M
    #4 cooked_indexer::make_index(cutu_reader*) gdb/dwarf2/read.c:18443 \
    (gdb+0x85e68a)^M
    #5 process_psymtab_comp_unit gdb/dwarf2/read.c:6812 (gdb+0x830879)^M
    #6 operator() gdb/dwarf2/read.c:7098 (gdb+0x8317be)^M
    #7 operator() gdbsupport/parallel-for.h:171 (gdb+0x8723e2)^M
...

Fix this by setting the field earlier, in read_comp_units_from_section.

The write in cutu_reader::cutu_reader() is still needed, in case
read_comp_units_from_section is not used (run the test-case with say, target
board cc-with-gdb-index).

Make the write conditional, such that it doesn't trigger if the field is
already set by read_comp_units_from_section.  Instead, verify that the
field already has the value that we're trying to set it to.

Move this logic into into a member function set_version (in analogy to the
already present member function version) to make sure it's used consistenly,
and make the field private in order to enforce access through the member
functions, and rename it to m_dwarf_version.

While we're at it, make sure that the version is set before read, to avoid
say returning true for "per_cu.version () < 5" if "per_cu.version () == 0".

Tested on x86_64-linux.

When building gdb with -fsanitize=thread, I run into:
...
FAIL: gdb.base/early-init-file.exp: check startup version string has style \
  version
...
due to this:
...
warning: Found custom handler for signal 7 (Bus error) preinstalled.^M
warning: Found custom handler for signal 8 (Floating point exception) \
  preinstalled.^M
warning: Found custom handler for signal 11 (Segmentation fault) \
  preinstalled.^M
Some signal dispositions inherited from the environment (SIG_DFL/SIG_IGN)^M
won't be propagated to spawned programs.^M
...
appearing before the "GNU gdb (GDB) $version" line.

This is similar to the problem fixed by commit f0bbba78
("gdb.debuginfod/fetch_src_and_symbols.exp: fix when GDB is built with
AddressSanitizer").

In that commit, the problem was fixed by starting gdb with -quiet, but using
that would mean the "GNU gdb (GDB) $version" line that we're trying to check
would disappear.

Fix this instead by updating the regexp to allow the message.

Tested on x86_64-linux.

Remove indentation from the text of the manual after the example here:

"  Completion will in some cases guide you with a suggestion of what
kind of argument an option expects.  For example:

     (gdb) print -elements <TAB><TAB>
     NUMBER     unlimited

   Here, the option expects a number (e.g., '100'), not literal
'NUMBER'.  Such metasyntactical arguments are always presented in
uppercase."

as this is a continuation of the same paragraph.

Completion results are usually different when the operation is applied
to a word that is or is not followed by a space.  In some cases they are
equivalent, however a space would not be produced if completion was used
earlier on in the word processed.

However in the manual we have completion examples given using a space
that actually prevents the example from working.  E.g.:

(gdb) info bre <TAB>

(nothing) and:

(gdb) info bre <TAB><TAB>
Display all 200 possibilities? (y or n)

as it now goes on to propose the entire symbol table, while:

(gdb) info bre<TAB>
(gdb) info breakpoints

does the right thing, but is not what is shown in the manual.

In other cases an extraneous space is used that does not correspond to
the actual completion pattern shown, which gives an impression of
sloppiness.

Remove extraneous spaces then from completion examples as appropriate.

Fix a completion consistency issue with `set' commands accepting integer
values and the special `unlimited' keyword:

(gdb) complete print -elements
print -elements NUMBER
print -elements unlimited
(gdb)

vs:

(gdb) complete set print elements
set print elements unlimited
(gdb)

(there is a space entered at the end of both commands, not shown here)
which also means if you strike <Tab> with `set print elements ' input,
it will, annoyingly, complete to `set print elements unlimited' right
away rather than showing a choice between `NUMBER' and `unlimited'.

Add `NUMBER' then as an available completion for such `set' commands:

(gdb) complete set print elements
set print elements NUMBER
set print elements unlimited
(gdb)

Adjust the testsuite accordingly.  Also document the feature in the
Completion section of the manual in addition to the Command Options
section already there.

When testing GDB's ability to stop in constructors, gdb.cp/mb-ctor.exp
only tested objects allocated on the stack. This commit adds a couple of
dynamic allocations and tests if GDB can stop in it as well.

	* dwarf.c (dwarf_select_sections_by_name): If the entry's value is
	zero then clear the corresponding variable.
	(dwarf_select_sections_by_letters): Likewise.
	* testsuite/binutils-all/debuginfo.exp: Expect -WE and -wE
	debuginfod tests to fail.

With gdb build with gcc-12 and -fsanitize=thread, and test-case
gdb.base/gdb-sigterm.exp, I run into:
...
WARNING: ThreadSanitizer: data race (pid=9722)^M
  Write of size 4 at 0x00000325bc68 by thread T1:^M
  #0 handle_sigterm(int) src/gdb/event-top.c:1211 (gdb+0x8ec01f)^M
  ...
  Previous read of size 4 at 0x00000325bc68 by main thread:^M
    [failed to restore the stack]^M
^M
  Location is global 'sync_quit_force_run' of size 4 at \
  0x00000325bc68 (gdb+0x325bc68)^M
  ...
SUMMARY: ThreadSanitizer: data race gdb/event-top.c:1211 in \
  handle_sigterm(int)^M
...
and 3 more data races involving handle_sigterm and locations:
- active_ext_lang
- quit_flag
- heap block of size 40
  (XNEW (async_signal_handler) in create_async_signal_handler)

This was reported in PR29297.

The testcase executes a "kill -TERM $gdb_pid", which generates a
process-directed signal.

A process-directed signal can be delivered to any thread, and what we see
here is the fallout of the signal being delivered to a worker thread rather
than the main thread.

Fix this by blocking SIGTERM in the worker threads.

[ I have not been able to reproduce this after it occurred for the first time,
so unfortunately I cannot confirm that the patch fixes the problem. ]

Tested on x86_64-linux, with and without -fsanitize=thread.

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

In passing I noticed that the column headings for the table of MI
compatibility and breaking changes, were overlapping, at least when
the PDF is generated on my machine.

I propose giving slightly more space to the two version number
columns, this prevents the headers overlapping for me.

Simon reported that the recent change to make GDB and GDBserver avoid
reading shell registers caused a GDBserver regression, caught with
ASan while running gdb.server/non-existing-program.exp:

 $ /home/smarchi/build/binutils-gdb/gdb/testsuite/../../gdb/../gdbserver/gdbserver stdio non-existing-program
 =================================================================
 ==127719==ERROR: AddressSanitizer: heap-use-after-free on address 0x60f0000000e9 at pc 0x55bcbfa301f4 bp 0x7ffd238a7320 sp 0x7ffd238a7310
 WRITE of size 1 at 0x60f0000000e9 thread T0
     #0 0x55bcbfa301f3 in scoped_restore_tmpl<bool>::~scoped_restore_tmpl() /home/smarchi/src/binutils-gdb/gdbserver/../gdbsupport/scoped_restore.h:86
     #1 0x55bcbfa2ffe9 in post_fork_inferior(int, char const*) /home/smarchi/src/binutils-gdb/gdbserver/fork-child.cc:120
     #2 0x55bcbf9c9199 in linux_process_target::create_inferior(char const*, std::__debug::vector<char*, std::allocator<char*> > const&) /home/smarchi/src/binutils-gdb/gdbserver/linux-low.cc:991
     #3 0x55bcbf954549 in captured_main /home/smarchi/src/binutils-gdb/gdbserver/server.cc:3941
     #4 0x55bcbf9552f0 in main /home/smarchi/src/binutils-gdb/gdbserver/server.cc:4084
     #5 0x7ff9d663b0b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x240b2)
     #6 0x55bcbf8ef2bd in _start (/home/smarchi/build/binutils-gdb/gdbserver/gdbserver+0x1352bd)

 0x60f0000000e9 is located 169 bytes inside of 176-byte region [0x60f000000040,0x60f0000000f0)
 freed by thread T0 here:
     #0 0x7ff9d6c6f0c7 in operator delete(void*) ../../../../src/libsanitizer/asan/asan_new_delete.cpp:160
     #1 0x55bcbf910d00 in remove_process(process_info*) /home/smarchi/src/binutils-gdb/gdbserver/inferiors.cc:164
     #2 0x55bcbf9c4ac7 in linux_process_target::remove_linux_process(process_info*) /home/smarchi/src/binutils-gdb/gdbserver/linux-low.cc:454
     #3 0x55bcbf9cdaa6 in linux_process_target::mourn(process_info*) /home/smarchi/src/binutils-gdb/gdbserver/linux-low.cc:1599
     #4 0x55bcbf988dc4 in target_mourn_inferior(ptid_t) /home/smarchi/src/binutils-gdb/gdbserver/target.cc:205
     #5 0x55bcbfa32020 in startup_inferior(process_stratum_target*, int, int, target_waitstatus*, ptid_t*) /home/smarchi/src/binutils-gdb/gdbserver/../gdb/nat/fork-inferior.c:515
     #6 0x55bcbfa2fdeb in post_fork_inferior(int, char const*) /home/smarchi/src/binutils-gdb/gdbserver/fork-child.cc:111
     #7 0x55bcbf9c9199 in linux_process_target::create_inferior(char const*, std::__debug::vector<char*, std::allocator<char*> > const&) /home/smarchi/src/binutils-gdb/gdbserver/linux-low.cc:991
     #8 0x55bcbf954549 in captured_main /home/smarchi/src/binutils-gdb/gdbserver/server.cc:3941
     #9 0x55bcbf9552f0 in main /home/smarchi/src/binutils-gdb/gdbserver/server.cc:4084
     #10 0x7ff9d663b0b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x240b2)

 previously allocated by thread T0 here:
     #0 0x7ff9d6c6e5a7 in operator new(unsigned long) ../../../../src/libsanitizer/asan/asan_new_delete.cpp:99
     #1 0x55bcbf910ad0 in add_process(int, int) /home/smarchi/src/binutils-gdb/gdbserver/inferiors.cc:144
     #2 0x55bcbf9c477d in linux_process_target::add_linux_process_no_mem_file(int, int) /home/smarchi/src/binutils-gdb/gdbserver/linux-low.cc:425
     #3 0x55bcbf9c8f4c in linux_process_target::create_inferior(char const*, std::__debug::vector<char*, std::allocator<char*> > const&) /home/smarchi/src/binutils-gdb/gdbserver/linux-low.cc:985
     #4 0x55bcbf954549 in captured_main /home/smarchi/src/binutils-gdb/gdbserver/server.cc:3941
     #5 0x55bcbf9552f0 in main /home/smarchi/src/binutils-gdb/gdbserver/server.cc:4084
     #6 0x7ff9d663b0b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x240b2)

Above we see that in the non-existing-program case, the process gets
deleted before the starting_up flag gets restored to false.

This happens because startup_inferior calls target_mourn_inferior
before throwing an error, and in GDBserver, unlike in GDB, mourning
deletes the process.

Fix this by not using a scoped_restore to manage the starting_up flag,
since we should only clear it when startup_inferior doesn't throw.

Change-Id: I67325d6f81c64de4e89e20e4ec4556f57eac7f6c

Match the whole error message expected to be given rather than omitting
the part about the "unlimited" keyword.  There's no point in omitting
the missing part first, and second with an upcoming change the part in
parentheses will no longer be a fixed string, so doing a full match will
ensure the algorithm correctly builds the message expected here.  Also
avoid any wildcard matches.

With errors given for bad commands such as `set annotate' or `set width'
we produce an extraneous full stop within parentheses:

(gdb) set annotate
Argument required (integer to set it to.).
(gdb) set width
Argument required (integer to set it to, or "unlimited".).
(gdb)

This is grammatically incorrect, so remove the full stop and adjust the
testsuite accordingly.

Extend the description of the MI command --data-disassemble.
Specifically, expand the description of the 'opcodes' field to explain
how the bytes are formatted.

The FPCCR.TS bit is used to identify if FPU registers are considered
non-secure or secure.  If they are secure, then callee saved registers
(S16 to S31) are stacked on exception entry or otherwise skipped.

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

The function aarch64_print_operand (aarch64-opc.c) is responsible for
converting an instruction operand into the textual representation of
that operand.

In some cases, a comment is included in the operand representation,
though this (currently) only happens for the last operand of the
instruction.

In a future commit I would like to enable the new libopcodes styling
for AArch64, this will allow objdump and GDB[1] to syntax highlight
the disassembler output, however, having operands and comments
combined in a single string like this makes such styling harder.

In this commit, I propose to extend aarch64_print_operand to take a
second buffer.  Any comments for the instruction are written into this
extra buffer.  The two callers of aarch64_print_operand are then
updated to pass an extra buffer, and print any resulting comment.

In this commit no styling is added, that will come later.  However, I
have adjusted the output slightly.  Before this commit some comments
would be separated from the instruction operands with a tab character,
while in other cases the comment was separated with two single spaces.

After this commit I use a single tab character in all cases.  This
means a few test cases needed updated.  If people would prefer me to
move everyone to use the two spaces, then just let me know.  Or maybe
there was a good reason why we used a mix of styles, I could probably
figure out a way to maintain the old output exactly if that is
critical.

Other than that, there should be no user visible changes after this
commit.

[1] GDB patches have not been merged yet, but have been posted to the
GDB mailing list:
https://sourceware.org/pipermail/gdb-patches/2022-June/190142.html

When running the gdb.base/break-idempotent.exp test on ppc, I was
seeing some test failures (or rather errors), that looked like this:

  (gdb) watch local
  Hardware watchpoint 2: local

  has_hw_wp_support: Hardware watchpoint detected
  ERROR: no fileid for gcc2-power8
  ERROR: Couldn't send delete breakpoints to GDB.
  ERROR OCCURED: can't read "gdb_spawn_id": no such variable
      while executing
  "expect {
  -i 1000 -timeout 100
          -re ".*A problem internal to GDB has been detected" {
              fail "$message (GDB internal error)"
              gdb_internal_erro..."
      ("uplevel" body line 1)
      invoked from within

What happens is that in break-idempotent.exp we basically do this:

    if {[prepare_for_testing "failed to prepare" $binfile $srcfile $opts]} {
        continue
    }

    # ....

    if {![skip_hw_watchpoint_tests]} {
        test_break $always_inserted "watch"
    }

The problem with this is that skip_hw_watchpoint_tests, includes this:

    if { [istarget "i?86-*-*"]
	 || [istarget "x86_64-*-*"]
	 || [istarget "ia64-*-*"]
	 || [istarget "arm*-*-*"]
	 || [istarget "aarch64*-*-*"]
	 || ([istarget "powerpc*-*-linux*"] && [has_hw_wp_support])
	 || [istarget "s390*-*-*"] } {
	return 0
    }

For powerpc only we call has_hw_wp_support.  This is a caching proc
that runs a test within GDB to detect if we have hardware watchpoint
support or not.

Unfortunately, to run this test we restart GDB, and when the test has
completed, we exit GDB.  This means that in break-idempotent.exp, when
we call skip_hw_watchpoint_tests for the first time on powerpc, GDB
will unexpectedly be exited.  When we later call delete_breakpoints we
see the errors I reported above.

The fix is to call skip_hw_watchpoint_tests early, before we start GDB
as part of the break-idempotent.exp script, and store the result in a
variable, we can then check this variable in the script as needed.

After this change break-idempotent.exp runs fine on powerpc.

Co-authored-by: Andrew Burgess <aburgess@redhat.com>