Suppress some "undefined" warnings from flake8

flake8 warns about some identifiers in __init__.py, because it does
not realize these come from the star-imported _gdb module.  This patch
suppresses these warnings.

Specify ImportError in styling.py

styling.py has a long try/except surrounding most of the body.  flake8
warns about the final bare "except".  However, this except is really
only there to catch the situation where the host doesn't have Pygments
installed.  This patch changes this to only catch ImportError.

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

Suppress star import errors

flake8 warns about the "from _gdb.disassembler import *" line in
disassembler.py, and a similar line from __init__.py.  These line are
needed to re-export names from the corresponding C++ module, so this
patch applies the appropriate "noqa" flags.

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

Remove bare "except" from disassembler.py

flake8 complains about a bare "except" in disassembler.py.  In this
case, the code purports to guard against some kind of user error
involving data structure corruption.  I think it's better here to just
let the error occur -- py-disasm.c will show a stack trace in this
case.

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

Remove unused import from gdb/__init__.py

flake8 points out that the import of _gdb in gdb/__init__.py is
unused.  Remove it.

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

Ignore unsed import in dap/__init__.py

flake8 warns about dap/__init__.py because it has a number of unused
imports.  Most of these are intentional: the import is done to ensure
that the a DAP request is registered with the server object.

This patch applies a "noqa" comment to these imports, and also removes
one import that is truly unnecessary.

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

Fix flake8 errors in dap/server.py

Commit 032d23a6 ("Fix stray KeyboardInterrupt after cancel")
introduced some errors into dap/server.py.  A function is called but
not imported, and the wrong variable name is used.  This patch
corrects both errors.

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

Remove .flake8

I re-ran flake8 today and was puzzled to see W503 warnings.
Eventually I found out that the setup.cfg config overrides .flake8.
This patch merges the two and removes .flake8, to avoid future
confusion.

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

[gdb/testsuite] Add missing include in gdb.base/ctf-ptype.c

On fedora rawhide, when running test-case gdb.base/ctf-ptype.exp, I get:
...
gdb compile failed, ctf-ptype.c: In function 'main':
ctf-ptype.c:242:29: error: implicit declaration of function 'malloc' \
  [-Wimplicit-function-declaration]
  242 |   v_char_pointer = (char *) malloc (1);
      |                             ^~~~~~
ctf-ptype.c:1:1: note: include '<stdlib.h>' or provide a declaration of 'malloc'
  +++ |+#include <stdlib.h>
    1 | /* This test program is part of GDB, the GNU debugger.
...

Fix this by adding the missing include.

Tested on aarch64-linux.

[gdb/testsuite] Fix gdb.ada/verylong.exp on 32-bit target

In an aarch32-linux chroot on an aarch64-linux system, I run into:
...
(gdb) print x^M
$1 = 9223372036854775807^M
(gdb) FAIL: gdb.ada/verylong.exp: print x
...

A passing version on aarch64-linux looks like:
...
(gdb) print x^M
$1 = 170141183460469231731687303715884105727^M
(gdb) PASS: gdb.ada/verylong.exp: print x
...

The difference is caused by the size of the type Long_Long_Long_Integer, which
is:
- a 128-bit signed on 64-bit targets, and
- a 64-bit signed on 32-bit target.

Fix this by detecting the size of the Long_Long_Long_Integer type, and
handling it.

Tested on aarch64-linux and aarch32-linux.

Approved-By: Tom Tromey <tom@tromey.com>
PR testsuite/31574
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31574

[1] https://gcc.gnu.org/onlinedocs/gnat_rm/Implementation-Defined-Characteristics.html

Update objcopy's --section-alignment option so that it sets the alignment flag on PE sections.   Add a check for aligned sections not matching their VMAs.

[gdb/tui] Fix centering and highlighting of current line

After starting TUI like this with a hello world a.out:
...
$ gdb -q a.out -ex start -ex "tui enable"
...
we get:
...
┌─hello.c──────────────────────────────┐
│        5 {                           │
│        6   printf ("hello\n");       │
│        7                             │
│        8   return 0;                 │
│        9 }                           │
│                                      │
└──────────────────────────────────────┘
...

This is a regression since commit ee1e9bbb513 ("[gdb/tui] Fix displaying main
after resizing"), before which we had instead:
...
┌─hello.c──────────────────────────────┐
│        4 main (void)                 │
│        5 {                           │
│  >     6 \e[7m  printf ("hello\n");\e[0m       │
│        7                             │
│        8   return 0;                 │
│        9 }                           │
└──────────────────────────────────────┘
...

In other words, the problems are:
- the active line (source line 6) is no longer highlighted, and
- the active line is not vertically centered (screen line 2 out 6 instead of
  screen line 3 out of 6).

Fix these problems respectively by:
- in tui_enable, instead of "tui_show_frame_info (0)" using
  'tui_show_frame_info (deprecated_safe_get_selected_frame ())", and
- in tui_source_window_base::rerender, adding centering functionality.

Tested on aarch64-linux.

Co-Authored-By: Tom Tromey <tom@tromey.com>
Approved-By: Tom Tromey <tom@tromey.com>
PR tui/31522
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31522

PR31458, FAIL: MIPS eh-frame 3 with --no-keep-memory

PR 31458
bfd/
* elf-bfd.h (_bfd_elf_link_read_relocs),
(_bfd_elf_link_info_read_relocs): Constify section.
* elflink.c: Likewise.
* elfxx-mips.c (_bfd_mips_elf_eh_frame_address_size): Read
relocs again in case --no-keep-memory.
ld/
* testsuite/ld-mips-elf/mips-elf.exp: Run --no-keep-memory
version of eh-frame3 test.

PR 30569, delete _bfd_mips_elf_early_size_sections

PR30569 was triggered by a patch of mine 6540edd52cc0 moving the call
to always_size_sections in bfd_elf_size_dynamic_sections earlier, made
to support the x86 DT_RELR implementation.  This broke mips16 code
handling stubs when --export-dynamic is passed to the linker, because
numerous symbols then became dynamic after always_size_sections.  The
mips backend fiddles with symbols in its always_size_sections.  Maciej
in 902e9fc76a0e had moved the call to always_size_sections to after
the export-dynamic code.  Prior to that, Nathan in 04c3a75556c0 moved
it before the exec stack code, back to the start of
bfd_elf_size_dynamic_sections which was where Ian put it originally
in ff12f303355b.  So the call has moved around a little.  I'm leaving
it where it is, and instead calling mips_elf_check_symbols from
late_size_sections (the old size_dynamic_sections) which is now always
called.  In fact, the whole of _bfd_mips_elf_early_size_sections can
be merged into _bfd_mips_elf_late_size_sections.

PR 30569, always call elf_backend_size_dynamic_sections

This largely mechanical patch is preparation for a followup patch.

For quite some time I've thought that it would be useful to call
elf_backend_size_dynamic_sections even when no dynamic objects are
seen by the linker.  That's what this patch does, with some renaming.
There are no functional changes to the linker, just a move of the
dynobj test in bfd_elf_size_dynamic_sections to target backend
functions, replacing the asserts/aborts already there.  No doubt some
of the current always_size_sections functions could be moved to
size_dynamic_sections but I haven't made that change.

Because both hooks are now always called, I have renamed
always_size_sections to early_size_sections and size_dynamic_sections
to late_size_sections.  I condisdered calling late_size_sections plain
size_sections, since this is the usual target dynamic section sizing
hook, but decided that searching the sources for "size_sections" would
then hit early_size_sections and other functions.

objdump --disassemble=sym peculiarities

Given this testcase:
 .text
 mov $x1,%eax
f1:
 mov $f1,%eax
 .type f1,@function
 .size f1,.-f1

 mov $x2,%eax
f2:
 mov $f2,%eax
 .type f2,@function
 .size f2,.-f2+0x1000 #bad size

objdump --reloc --disassemble=f1 prints
00000000 <f1-0x5>:
   0: b8 00 00 00 00        mov    $0x0,%eax

and objdump --reloc --disassemble=f2 prints
0000000f <f2>:
   f: b8 0f 00 00 00        mov    $0xf,%eax
10: R_386_32 .text

It seems for f1 we get the insn before f1 and no reloc whereas, post
159daa36fa, f2 is disassembled correctly.  Some analysis says that
find_symbol_for_address may return a symbol past the current address,
and reloc skipping is broken.  Fix both of these problems.

* objdump.c (disassemble_jumps, disassemble_bytes): Replace
        relppp with relpp, ie. don't update caller's rel_pp.  Adjust
        calls.
(disassemble_section): Skip over relocs inside loop rather
        than before loop.  Revert 7e538762c2c1.  If given a symbol,
don't start disassembling until its address is reached.
Correct end of function calculation.

Automatic date update in version.in

hppa: Implement PA 2.0 symbolic relocations for long displacements

The PA 2.0 architecture introduced several new load and store
instructions with long displacements.  These include floating
point loads and stores for word mode, and integer and floating
point loads and stores for double words.  Currently, ld does
not correctly support symbolic relocations for these instructions.

If these are used, ld applies the standard R_PARISC_DPREL14R
relocation and corrupts the instruction.  This change uses
bfd_hppa_insn2fmt to determine the correct relocation format.

We need to check the computed displacement as the immediate
value used in these instruction must be a multiple of 4 or 8
depending on whether the access is for a word or double word.

A misaligned offset can potentially occur if the symbol is not
properly aligned or if $global$ (the global pointer) is not
double word aligned.  $global$ is provided as a .data section
start symbol.  The patch adjusts elf.sc and hppalinux.sh to
align .data to a 8-byte boundary in non-shared and non-pie
links.

2024-04-01  John David Anglin  <danglin@gcc.gnu.org>

PR ld/31503

bfd/ChangeLog:

* elf32-hppa.c (final_link_relocate): Output

ld/ChangeLog:

* emulparams/hppalinux.sh (DATA_SECTION_ALIGNMENT): Define.
* scripttempl/elf.sc: Align .data section to DATA_SECTION_ALIGNMENT
when relocating.

asan: heap-buffer-overflow objdump.c:3299 in disassemble_bytes

Fix yet another crash, this one with a fuzzed function symbol size.
The patch also corrects objdump behaviour when both --disassemble=sym
and --stop-address=value are given.  Previously --disassemble=sym
overrode --stop-address, now we take the lower of the stop-address
value and the end of function.

* objdump.c (disassemble_section): Sanity check ELF st_size.

LoongArch: Fix the issue of excessive relocation generated by GD and IE

Currently, whether GD and IE generate dynamic relocation is
determined by SYMBOL_REFERENCES_LOCAL and bfd_link_executable.
This results in dynamic relocations still being generated in some
situations where dynamic relocations are not necessary (such as
the undefined weak symbol in static links).

We use RLARCH_TLS_GD_IE_NEED_DYN_RELOC macros to determine whether
GD/IE needs dynamic relocation. If GD/IE requires dynamic relocation,
set need_reloc to true and indx to be a dynamic index.

At the same time, some test cases were modified to use regular
expression matching instead of complete disassembly matching.

LoongArch: gas: Ignore .align if it is at the start of a section

Ignore .align if it is at the start of a section and the alignment
can be divided by the section alignment, the section alignment
can ensure this .align has a correct alignment.

Automatic date update in version.in

gdb: build dprintf commands just once in code_breakpoint constructor

I noticed in code_breakpoint::code_breakpoint that we are calling
update_dprintf_command_list once for each breakpoint location, when we
really only need to call this once per breakpoint -- the data updated
by this function, the breakpoint command list -- is per breakpoint,
not per breakpoint location.  Calling update_dprintf_command_list
multiple times is just wasted effort, there's no per location error
checking, we don't even pass the current location to the function.

This commit moves the update_dprintf_command_list call outside of the
per-location loop.

There should be no user visible changes after this commit.

gdb: the extra_string in a dprintf breakpoint is never nullptr

Given the changes in the previous couple of commits, this commit
cleans up some of the asserts and 'if' checks related to the
extra_string within a dprintf breakpoint.

This commit:

  1. Adds some asserts to update_dprintf_command_list about the
  breakpoint type, and that the extra_string is not nullptr,

  2. Given that we know extra_string is not nullptr (this is enforced
  when the breakpoint is created), we can simplify
  code_breakpoint::code_breakpoint -- it no longer needs to check for
  the extra_string is nullptr case,

  3. In dprintf_breakpoint::re_set we can remove the assert (this will
  be checked within update_dprintf_command_list, we can also remove
  the redundant 'if' check.

There should be no user visible changes after this commit.

gdb: change 'if' to gdb_assert in update_dprintf_command_list

I noticed in update_dprintf_command_list that we handle the case where
the bp_dprintf style breakpoint doesn't have a format and args string.

However, I don't believe such a situation is possible.  The obvious
approach certainly already catches this case:

  (gdb) dprintf main
  Format string required

If it is possible to create a dprintf breakpoint without a format and
args string then I think we should be catching this case and handling
it at creation time, rather than having GDB just ignore the situation
later on.

And so, I propose that we change the 'if' that ignores the case where
the format/args string is empty, and instead assert that we do always
have a format/args string.  The original code, that handled an empty
format/args string has existed since commit e7e0cddfb0d4, which is
when dprintf support was added to GDB.

If I'm correct and this situation can't ever happen then there should
be no user visible changes after this commit.

gdb: create_breakpoint: asserts relating to extra_string/parse_extra

The goal of this commit is to better define the API for
create_breakpoint especially around the use of extra_string and
parse_extra.  This will be useful in the next commit when I plan to
make some changes to create_breakpoint.

This commit makes one possibly breaking change: until this commit it
was possible to create thread-specific dprintf breakpoint like this:

  (gdb) dprintf call_me, thread 1 "%s", "hello"
  Dprintf 2 at 0x401152: file /tmp/hello.c, line 8.
  (gdb) info breakpoints
  Num     Type           Disp Enb Address            What
  2       dprintf        keep y   0x0000000000401152 in call_me at /tmp/hello.c:8 thread 1
          stop only in thread 1
          printf "%s", "hello"
  (gdb)

This feature of dprintf was not documented, was not tested, and is
slightly different in syntax to how we create thread specific
breakpoints and/or watchpoints -- the thread condition appears after
the first ','.

I believe that this worked at all was simply by luck.  We happen to
pass the parse_extra flag as true from dprintf_command to
create_breakpoint.

So in this commit I made the choice to change this.  We now pass
parse_extra as false from dprintf_command to create_breakpoint.  With
this done it is assumed that the only thing in the extra_string is the
dprintf format and arguments.

Beyond this change I've updated the comment on create_breakpoint in
breakpoint.h, and I've then added some asserts into
create_breakpoint as well as moving around some of the error
handling.

 - We now assert on the incoming argument values,

 - I've moved an error check to sit after the call to
   find_condition_and_thread_for_sals, this ensures the extra_string
   was parsed correctly,

In dprintf_command:

 - We now throw an error if there is no format string after the
   dprintf location.  This error was already being thrown, but was
   being caught later in the process.  With this change we catch the
   missing string earlier,

 - And, as mentioned earlier, we pass parse_extra as false when
   calling create_breakpoint,

In create_tracepoint_from_upload:

 - We now throw an error if the parsed location doesn't completely
   consume the addr_str variable.  This error has now effectively
   moved out of create_breakpoint.

gdb: create_breakpoint: add asserts and additional comments

This commit extends the asserts on create_breakpoint (in the header
file), and adds some additional assertions into the definition.

The new assert confirms that when the thread and inferior information
is going to be parsed from the extra_string, then the thread and
inferior arguments should be -1.  That is, the caller of
create_breakpoint should not try to create a thread/inferior specific
breakpoint by *both* specifying thread/inferior *and* asking to parse
the extra_string, it's one or the other.

There should be no user visible changes after this commit.

BFD: Fix the bug of R_LARCH_AGLIN caused by discard section

To represent the first and third expression of .align, R_LARCH_ALIGN need to
associate with a symbol. We define a local symbol for R_LARCH_AGLIN.
But if the section of the local symbol is discarded, it may result in
a undefined symbol error.

Instead, we use the section name symbols, and this does not need to
add extra symbols.

During partial linking (ld -r), if the symbol associated with a relocation is
STT_SECTION type, the addend of relocation needs to add the section output
offset. We prevent it for R_LARCH_ALIGN.

The elf_backend_data.rela_normal only can set all relocations of a target to
rela_normal. Add a new function is_rela_normal to elf_backend_data, it can
set part of relocations to rela_normal.

Automatic date update in version.in

Lower variable definitions in tui_redisplay_readline

I noticed a redundant assignment to 'prev_col' in
tui_redisplay_readline, and then went ahead and lowered most of the
variable definitions in that function to their initialization point.

Automatic date update in version.in

gdb/testsuite: don't include port numbers in test names

The gdb.python/py-cmd-prompt.exp script includes a test that has a
gdbserver port number within a test name.  As port numbers can change
from one test run to the next (depending on what else is running on
the machine at the time), this can make it hard to compare test
results between runs.

Give the test a specific name to avoid including the port number.

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

gdb/testsuite: avoid $pc/$sp values in test names

Provide an explicit name for a test in gdb.base/pc-not-saved.exp to
avoid printing $pc and $sp values in the test name -- these values
might change between different test runs, which makes it harder to
compare test results.

There is no change in what is actually being tested with this commit.

[gdb/testsuite] Add missing includes in gdb.trace/collection.c

On fedora rawhide, with test-case gdb.trace/collection.exp, I get:
...
gdb compile failed, collection.c: In function 'strings_test_func':
collection.c:227:13: error: implicit declaration of function 'malloc' \
  [-Wimplicit-function-declaration]
  227 |   longloc = malloc(500);
      |             ^~~~~~
collection.c:1:1: note: \
  include '<stdlib.h>' or provide a declaration of 'malloc'
  +++ |+#include <stdlib.h>
    1 | /* This testcase is part of GDB, the GNU debugger.

collection.c:228:3: error: implicit declaration of function 'strcpy' \
  [-Wimplicit-function-declaration]
  228 |   strcpy(longloc, ... );
      |   ^~~~~~
collection.c:1:1: note: include '<string.h>' or provide a declaration of \
  'strcpy'
  +++ |+#include <string.h>
    1 | /* This testcase is part of GDB, the GNU debugger.
collection.c:230:8: error: implicit declaration of function 'strlen' \
  [-Wimplicit-function-declaration]
  230 |   i += strlen (locstr);
      |        ^~~~~~
collection.c:230:8: note: include '<string.h>' or provide a declaration of \
  'strlen'
...

Fix this by adding the missing includes.

Tested on aarch64-linux.

Approved-By: John Baldwin <jhb@FreeBSD.org>

[gdb/testsuite] Fix missing return type in gdb.linespec/break-asm-file.c

On fedora rawhide, when running test-case gdb.linespec/break-asm-file.exp, I
get:
...
gdb compile failed, break-asm-file.c:21:8: error: \
  return type defaults to 'int' [-Wimplicit-int]
   21 | static func()
      |        ^~~~
...

Fix this by adding the missing return type.

Tested on aarch64-linux.

Approved-By: John Baldwin <jhb@FreeBSD.org>

Automatic date update in version.in

Make pascal_language::print_type handle varstring==nullptr

PR gdb/31524 points out a crash when pascal_language::print_type is
called with varstring==nullptr.  This crash is a regression arising
from the printf/pager rewrite -- that indirectly removed a NULL check
from gdb's "puts".

This patch instead fixes the problem by adding a check to print_type.
Passing nullptr here seems to be expected in other places (e.g., there
is a call to type_print like this in expprint.c), and other
implementations of this method (or related helpers) explicitly check
for NULL.

I didn't write a test case for this because it seemed like overkill
for a Pascal bug that only occurs with -i=mi.  However, if you want
one, let me know and I will do it.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31524
Approved-By: John Baldwin <jhb@FreeBSD.org>

gas: gcfg: fix handling of non-local direct jmps in gcfg

The ginsn infrastructure in GAS includes the ability to create a GCFG
(ginsn CFG).  A GCFG is currently used for SCFI passes.

This patch fixes the following invalid assumptions / code blocks:
 - The function ginsn_direct_local_jump_p () was erroneously _not_
   checking whether the symbol is locally defined (i.e., within the
   scope of the code block for which GCFG is desired).  Fix the code
   to do so.
 - Similarly, the GCFG creation code, in gcfg_build () itself had an
   assumption that a GINSN_TYPE_JUMP to a non-local symbol will not be
   seen.  The latter can indeed be seen, and in fact, needs to be treated
   the same way as an exit from the function in terms of control-flow.

gas/
        * ginsn.c (ginsn_direct_local_jump_p): Check if the symbol
is local to the code block or function being assembled.
        (add_bb_at_ginsn): Remove buggy assumption.
        (frch_ginsn_data_append): Direct jmps do not disqualify a stream
of ginsns from GCFG creation.

gas/testsuite/
* gas/scfi/x86_64/scfi-cfg-3.d: New test.
* gas/scfi/x86_64/scfi-cfg-3.l: New test.
* gas/scfi/x86_64/scfi-cfg-3.s: New test.
* gas/scfi/x86_64/scfi-x86-64.exp: Add new test.

x86/SSE2AVX: move checking

It has always been looking a little odd to me that this was done deep
in cpu_flags_match(). Move it to match_template() itself - there's no
need to do anything complex when encountering such a template while it
cannot possibly be used.

x86/SSE2AVX: respect prefixes

1) Without -msse2avx we unconditionally honor REX.W. Hence we ought to
   also do so with -msse2avx, converting to VEX.W.

2) {rex} doesn't prevent conversion to VEX encodings. Thus {rex2}
   shouldn't either.

gas: drop integer_constant()'s maxdig

Once properly set, it's only ever holding the same value as "radix".
Even if there was some plan with it, that plan hasn't made it anywhere
in over 20 years.

gas: drop dead check for double quote

FB and dollar label definitions can't be enclosed in double quotes. In
fact at that point nul_char is the same as next_char, which we know is a
digit.

gas: sanitize FB- and dollar-label uses

I don't view it as sensible to be more lax when it comes to references
to (uses of) such labels compared to their definition: The latter has
been limited to decimal numerics, while the former permitted any radix.
Beyond that leading zeroes on such labels aren't helpful either. Imo
labels and their use sites would better match literally, to avoid
confusion.

As it turns out, one z80 testcase actually had such an odd use of labels
where definition and use don't match in spelling. That testcase is being
adjusted accordingly.

While there also adjust a comment on a local variable in
integer_constant().

x86: templatize RAO-INT insns

It's only four of them, but still better to reduce redundancy.

x86: templatize ADX insns

It's only two of them, but still better to reduce redundancy.

x86: templatize shift-double insns

With the multitude of new APX templates, it finally becomes desirable to
further remove redundancy by also templatizing basic arithmetic insns.
Continue with the shift-double ones.

While there also drop the APX form with ShiftCount omitted. Other shift
and rotate insns were deliberately left without this form as well. Note
that there's also no testsuite adjustment needed for this, indicating
that the form wasn't tested either.

x86: templatize shift/rotate insns

With the multitude of new APX templates, it finally becomes desirable to
further remove redundancy by also templatizing basic arithmetic insns.
Continue with the "ordinary" shift and rotate ones.

While there also drop the APX form of RCL/RCR with Imm1 omitted. Other
shift insns as well as ROR/ROL were deliberately left without this form
as well. Note that there's also no testsuite adjustment needed for this,
indicating that the form wasn't tested either.

Furthermore since RCL/RCR already had non-NDD APX forms, those end up
being added for the other 6 mnemonics, too.

x86: templatize binary ALU insns

With the multitude of new APX templates, it finally becomes desirable to
further remove redundancy by also templatizing basic arithmetic insns.
Continue with a the more complex binary (two source) cases.

Note how this adds a missing CheckOperandSize to one of the APX sub
forms.

Furthermore since SBB already had a non-NDD APX form, one ends up
being added for the other 6 mnemonics, too.

x86: templatize unary ALU insns

With the multitude of new APX templates, it finally becomes desirable to
further remove redundancy by also templatizing basic arithmetic insns.
Continue with a few simple unary (single source) cases.

x86: templatize INC/DEC

With the multitude of new APX templates, it finally becomes desirable to
further remove redundancy by also templatizing basic arithmetic insns.
Start with the simplest case, accompanied by a necessary adjustment to
i386-gen (such that template uses can also be at the start of a line).

While there also drop a bogus (meaningless / unreachable) "break" as
well as a unused variable (which I'm surprised compilers didn't warn
about).

[gdb/testsuite] Fix gdb.base/ending-run.exp on manjaro linux

On aarch64-linux, using the manjaro linux distro, I run into:
...
(gdb) next^M
32      }^M
(gdb) next^M
0x0000fffff7d67b80 in ?? () from /usr/lib/libc.so.6^M
(gdb) FAIL: gdb.base/ending-run.exp: step out of main
...

What happens here is described in detail in this clause:
...
    -re "0x.*\\?\\? \\(\\) from /lib/powerpc.*$gdb_prompt $" {
# This case occurs on Powerpc when gdb steps out of main and the
# needed debug info files are not loaded on the system, preventing
# GDB to determine which function it reached (__libc_start_call_main).
# Ideally, the target system would have the necessary debugging
# information, but in its absence, GDB's behavior is as expected.
...
    }
...
but the clause only matches for powerpc.

Fix this by:
- making the regexp generic enough to also match /usr/lib/libc.so.6, and
- updating the comment to not mention powerpc.

Tested on aarch64-linux.

PR testsuite/31450
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31450

[gdb/testsuite] Fix test-case gdb.threads/attach-stopped.exp on manjaro linux

When running test-case gdb.threads/attach-stopped.exp on aarch64-linux, using
the manjaro linux distro, I get:
...
 (gdb) thread apply all bt^M
 ^M
 Thread 2 (Thread 0xffff8d8af120 (LWP 278116) "attach-stopped"):^M
 #0  0x0000ffff8d964864 in clock_nanosleep () from /usr/lib/libc.so.6^M
 #1  0x0000ffff8d969cac in nanosleep () from /usr/lib/libc.so.6^M
 #2  0x0000ffff8d969b68 in sleep () from /usr/lib/libc.so.6^M
 #3  0x0000aaaade370828 in func (arg=0x0) at attach-stopped.c:29^M
 #4  0x0000ffff8d930aec in ?? () from /usr/lib/libc.so.6^M
 #5  0x0000ffff8d99a5dc in ?? () from /usr/lib/libc.so.6^M
 ^M
 Thread 1 (Thread 0xffff8db62020 (LWP 278111) "attach-stopped"):^M
 #0  0x0000ffff8d92d2d8 in ?? () from /usr/lib/libc.so.6^M
 #1  0x0000ffff8d9324b8 in ?? () from /usr/lib/libc.so.6^M
 #2  0x0000aaaade37086c in main () at attach-stopped.c:45^M
 (gdb) FAIL: gdb.threads/attach-stopped.exp: threaded: attach2 to stopped bt
...

The problem is that the test-case expects to see start_thread:
...
gdb_test "thread apply all bt" ".*sleep.*start_thread.*" \
    "$threadtype: attach2 to stopped bt"
...
but lack of symbols makes that impossible.

Fix this by allowing " in ?? () from " as well.

Tested on aarch64-linux.

PR testsuite/31451
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31451

[gdb/testsuite] Add missing include in gdb.base/rtld-step.exp

On fedora rawhide, with test-case gdb.base/rtld-step.exp I get:
...
static-pie-static-libc.c: In function '_start':^M
static-pie-static-libc.c:1:22: error: \
  implicit declaration of function '_exit' [-Wimplicit-function-declaration]^M
    1 | void _start (void) { _exit (0); }^M
      |                      ^~~~~^M
compiler exited with status 1
  ...
UNTESTED: gdb.base/rtld-step.exp: failed to compile \
  (-static-pie not supported or static libc missing)
...

Fix this by adding the missing include.

Tested on aarch64-linux.

Approved-by: Kevin Buettner <kevinb@redhat.com>

RISC-V: Removed privileged spec 1.9.1 support in assembler.

Removed since it's may have lots of conflicts with the newer extensions, but
still keep linker recognizes it in case of linking old objects.

gas/
* NEWS: Updated.
* config/tc-riscv.c (riscv_set_default_priv_spec): Regard 1.9.1 as
an unknown version.
(md_show_usage): Removed privileged spec 1.9.1 information.
* testsuite/gas/riscv/attribute-05.s: Updated since privileged spec
1.9.1 is unsupported.
* testsuite/gas/riscv/attribute-05.d: Likewise.
* testsuite/gas/riscv/attribute-12.d: Likewise.
* testsuite/gas/riscv/attribute-13.d: Likewise.
* testsuite/gas/riscv/csr-dw-regnums.d: Likewise.
* testsuite/gas/riscv/csr-dw-regnums.s: Likewise.
* testsuite/gas/riscv/csr.s: Likewise.
* testsuite/gas/riscv/csr-version-1p10.d: Likewise.
* testsuite/gas/riscv/csr-version-1p10.l: Likewise.
* testsuite/gas/riscv/csr-version-1p11.d: Likewise.
* testsuite/gas/riscv/csr-version-1p11.l: Likewise.
* testsuite/gas/riscv/csr-version-1p12.d: Likewise.
* testsuite/gas/riscv/csr-version-1p12.l: Likewise.
* testsuite/gas/riscv/csr-version-1p9p1.d: Removed.
* testsuite/gas/riscv/csr-version-1p9p1.l: Removed.
include/
* opcode/riscv-opc.h: Updated since privileged spec 1.9.1 is
unsupported.
ld/
* testsuite/ld-riscv-elf/attr-merge-priv-spec-01.d: Updated since
privileged spec 1.9.1 is unsupported.
* testsuite/ld-riscv-elf/attr-merge-priv-spec-02.d: Likewise.
* testsuite/ld-riscv-elf/attr-merge-priv-spec-03.d: Likewise.
* testsuite/ld-riscv-elf/attr-merge-priv-spec-a.s: Likewise.
* testsuite/ld-riscv-elf/attr-merge-priv-spec-b.s: Likewise.
* testsuite/ld-riscv-elf/attr-merge-priv-spec-failed-01.d: Likewise.
* testsuite/ld-riscv-elf/attr-merge-priv-spec-failed-02.d: Likewise.
* testsuite/ld-riscv-elf/attr-merge-priv-spec-failed-03.d: Likewise.
* testsuite/ld-riscv-elf/attr-merge-priv-spec-failed-04.d: Likewise.
* testsuite/ld-riscv-elf/attr-merge-priv-spec-failed-05.d: Likewise.
* testsuite/ld-riscv-elf/attr-merge-priv-spec-failed-06.d: Likewise.

Automatic date update in version.in

Fix clang build

Simon pointed out that commit 818ef5f4 ("Capture warnings when writing
to the index cache") broke the build with clang.  This patch fixes the
breakage.

gdb, gdbserver, gdbsupport: remove includes of early headers

Now that defs.h, server.h and common-defs.h are included via the
`-include` option, it is no longer necessary for source files to include
them.  Remove all the inclusions of these files I could find.  Update
the generation scripts where relevant.

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

gdb, gdbserver, gdbsupport: include early header files with `-include`

The motivation for this change is for analysis tools and IDEs to be
better at analyzing header files on their own.

There are some definitions and includes we want to occur at the very
beginning of all translation units.  The way we currently do that is by
requiring all source files (.c and .cc files) to include one of defs.h
(for gdb), server.h (for gdbserver) of common-defs.h (for gdbsupport and
shared source files).  These special header files define and include
everything that needs to be included at the very beginning.  Other
header files are written in a way that assume that these special
"prologue" header files have already been included.

My problem with that is that my editor (clangd-based) provides a very
bad experience when editing header files.  Since clangd doesn't know
that one of defs.h/server.h/common-defs.h was included already, a lot of
things are flagged as errors.  For instance, CORE_ADDR is not known.
It's possible to edit the files in this state, but a lot of the power of
the editor is unavailable.

My proposal to help with this is to include those things we always want
to be there using the compilers' `-include` option.  Tom Tromey said
that the current approach might exist because not all compilers used to
have an option like this.  But I believe that it's safe to assume they
do today.

With this change, clangd picks up the -include option from the compile
command, and is able to analyze the header file correctly, as it sees
all that stuff included or defined by that -include option.  That works
because when editing a header file, clangd tries to get the compilation
flags from a source file that includes said header file.

This change is a bit self-serving, because it addresses one of my
frustrations when editing header files, but it might help others too.
I'd be curious to know if others encounter the same kinds of problems
when editing header files.  Also, even if the change is not necessary by
any means, I think the solution of using -include for stuff we always
want to be there is more elegant than the current solution.

Even with this -include flag, many header files currently don't include
what they use, but rather depend on files included before them.  This
will still cause errors when editing them, but it should be easily
fixable by adding the appropriate include.  There's no rush to do so, as
long as the code still compiles, it's just a convenience thing.

The changes are:

 - Add the appropriate `-include` option to the various Makefiles.

 - There is one particularity for gdbserver's Makefile: we do not want
   to include server.h when building `gdbreplay.o`, as `gdbreplay.cc`
   doesn't include it.  So we can't simply put the `-include` in
   `INTERNAL_CFLAGS`.  Add the `-include server.h` option to the
   `COMPILE` and `IPAGENT_COMPILE` variables, and added a special rule
   to compile `gdbreplay.o` with `-include gdbsupport/common-defs.h`.

 - Remove the `-include` option from the `check-headers` rule in
   gdb/Makefile.in, since it is already included in `INTERNAL_CFLAGS`.

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

{gdb,gdbserver}/Makefile.in: remove unnecessary intermediary variables

Remove `INTERNAL_CFLAGS_BASE` and `INTERNAL_WARN_CFLAGS`, inline their
contents in `INTERNAL_CFLAGS`.  Not functional changes expected.

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

gdb, gdbserver, gdbsupport: reformat some Makefile variables, one entry per line

Reformat some variables definitions.  I think it makes them easier to
read, and it also makes diffs clearer.

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

gdb: make gdbarch_types.py non-executable

I noticed that gdbarch_types.py is executable.  It's not needed, since
it's only imported from gdbarch.py.

Change-Id: I481170714af66fc3fc3a48c55a7268e0789cf83e

Automatic date update in version.in

Revert "gdbserver: convert have_ptrace_getregset to a tribool"

This reverts commit 5920765d7513aaae9241a1850d62d73e0477f81c.

Revert "gdb/x86: move reading of cs and ds state into gdb/nat directory"

This reverts commit 01ed1674d4435aa4e194fd9373b7705e425ef354.

Revert "gdbserver/x86: move no-xml code earlier in x86_linux_read_description"

This reverts commit 0a7bb97ad2f2fe2d18a442dad265051e34eab13e.

Revert "gdb/gdbserver: share I386_LINUX_XSAVE_XCR0_OFFSET definition"

This reverts commit 7816b81e9b36ea0f57662bfd7446b573bf0c9e54.

Revert "gdb/gdbserver: share some code relating to target description creation"

This reverts commit cd9b374ffe372dcaf7e4c15548cf53a301d8dcdd.

Revert "gdb/arch: assert that X86_XSTATE_MPX is not set for x32"

This reverts commit efba976d9713a92b4507ccfef2257e4589da2798.

Revert "gdbserver: update target description creation for x86/linux"

This reverts commit 61bb321605fc74703adc994fd7a78e9d2495ca7a.

Revert "gdb/gdbserver: share x86/linux tdesc caching"

This reverts commit 198ff6ff819c240545f9fc68b39636fd376d4ba9.

Revert "gdbserver/Makefile.in: add missing `-x c++`"

This reverts commit c7c9820071f8b81a64221f5cfafb3cbfeafe7916.

Revert "gdb: fix possible uninitialised variable use"

This reverts commit 24df37a10f8773ad5db07dc000f694d6405e3a36.

Revert "gdb/gdbserver: fix some defined but unused function warnings"

This reverts commit f4c19f89ef43dbce8065532c808e1aeb05d08994.

Remove redundant check from parse_number.exp

A user on irc pointed out that parse_number.exp has a redundant check.
This patch removes the duplicate.

[gdb/testsuite] Fix valgrind tests on debian

On debian 12, I run into:
...
(gdb) target remote | vgdb --wait=2 --max-invoke-ms=2500 --pid=618591^M
Remote debugging using | vgdb --wait=2 --max-invoke-ms=2500 --pid=618591^M
relaying data between gdb and process 618591^M
warning: remote target does not support file transfer, \
  attempting to access files from local filesystem.^M
Reading symbols from /lib/ld-linux-aarch64.so.1...^M
(No debugging symbols found in /lib/ld-linux-aarch64.so.1)^M
0x000000000401a980 in ?? () from /lib/ld-linux-aarch64.so.1^M
(gdb) FAIL: gdb.base/valgrind-infcall.exp: target remote for vgdb
...

The problem is that we're expecting to match either of these regexps:
...
set start_re1 " in \\.?_start "
        set start_re2 "\\.?_start \\(\\) at "
...
but there are no dwarf or elf symbols present.

Fix this by also allowing:
...
       set start_re3 "$::hex in \\?\\? \\(\\) from "
...

Tested on aarch64-linux.

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

Capture warnings when writing to the index cache

PR symtab/30837 points out a race that can occur when writing to the
index cache: a call to ada_encode can cause a warning, which is
forbidden on a worker thread.

This patch fixes the problem by arranging to capture any such
warnings.

This is v2 of the patch.  It is rebased on top of some other changes
in the same area.  v1 was here:

    https://sourceware.org/pipermail/gdb-patches/2024-February/206595.html

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

Don't claim a fat IR object if no IR object should be claimed

When the linker sees an input object containing nothing but IR during
rescan, it should ignore it (LTO phase is over).  But if the input object
is a fat IR object, which has non-IR code as well, it should be used to
resolve references as if it did not contain any IR at all.  This patch
adds lto_type to bfd and linker avoids claiming a fat IR object if no IR
object should be claimed.

bfd/

PR ld/23935
* archive.c (_bfd_compute_and_write_armap): Check bfd_get_lto_type
instead of lto_slim_object.
* elflink.c (elf_link_add_object_symbols): Likewise.
* bfd.c (bfd_lto_object_type): New.
(bfd): Remove lto_slim_object and add lto_type.
(bfd_get_lto_type): New function.
* elf.c (lto_section): Removed.
(_bfd_elf_make_section_from_shdr): Don't set lto_slim_object.
* format.c: (lto_section): New.
(bfd_set_lto_type): New function.
(bfd_check_format_matches): Call bfd_set_lto_type.
* bfd-in2.h: Regenerated.

binutils/

PR ld/23935
* nm.c (display_rel_file): Check bfd_get_lto_type instead of
lto_slim_object.

ld/

PR ld/23935
* ldmain.c (add_archive_element): Don't claim a fat IR object if
no IR object should be claimed.
* testsuite/ld-plugin/lto.exp (pr20103): Adjust fat IR test.
Add PR ld/23935 test.
* testsuite/ld-plugin/pr23935a.c: New file.
* testsuite/ld-plugin/pr23935b.c: Likewise.

gdb/gdbserver: fix some defined but unused function warnings

This commit:

  commit 198ff6ff819c240545f9fc68b39636fd376d4ba9
  Date:   Tue Jan 30 15:37:23 2024 +0000

      gdb/gdbserver: share x86/linux tdesc caching

added some functions which are always defined, but their use is
guarded within various #ifdef blocks.  As a result we were seeing
errors about defined, but unused, functions.

I've fixed this problem in this commit by wrapping the function
definitions within #ifdef blocks.

I'm a little worried that there might be too many #ifdef blocks within
this file, however, I'm going to commit this fix for now as this will
fix the build, then I'll think about if there's a better way to split
this file so we might avoid some of these #ifdef blocks.

gdb: fix possible uninitialised variable use

After this commit:

  commit 198ff6ff819c240545f9fc68b39636fd376d4ba9
  Date:   Tue Jan 30 15:37:23 2024 +0000

      gdb/gdbserver: share x86/linux tdesc caching

a possible use of an uninitialised variable was introduced, the
'tdesc' variable in i386_linux_core_read_description might be read
without being written too if 'xcr0' was 0.

This is fixed in this commit.  I've updated the function to follow the
same pattern as amd64_linux_core_read_description, if xcr0 is 0 then
we select a default xcr0 value and use that to select a tdesc.

gdbserver/Makefile.in: add missing `-x c++`

When building with Clang, I get:

      CXX    nat/x86-linux-tdesc-ipa.o
    clang++: error: treating 'c' input as 'c++' when in C++ mode, this behavior is deprecated [-Werror,-Wdeprecated]

Fix that by adding the missing `-x c++` in the rule building
`gdb/nat/*.c` files for the in-process agent.

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

gdb: mark addrmap classes `final`

When building GDB with clang, I see:

    /usr/lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/unique_ptr.h:95:2: error: delete called on non-final 'addrmap_mutable' that has virtual functions but non-virtual destructor [-Werror,-Wdelete-non
    -abstract-non-virtual-dtor]
       95 |         delete __ptr;
          |         ^
    /usr/lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/unique_ptr.h:396:4: note: in instantiation of member function 'std::default_delete<addrmap_mutable>::operator()' requested here
      396 |           get_deleter()(std::move(__ptr));
          |           ^
    /home/smarchi/src/binutils-gdb/gdb/addrmap.c:422:14: note: in instantiation of member function 'std::unique_ptr<addrmap_mutable>::~unique_ptr' requested here
      422 |   auto map = std::make_unique<struct addrmap_mutable> ();
          |              ^

Fix that by making `addrmap_mutable` final, and `addrmap_fixed` too
while at it.

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

Automatic date update in version.in

gprofng: fix infinite recursion on calloc with multi-threaded applications

libcollector uses pthread_getspecific() and pthread_setspecific() to access
thread local memory. libcollector uses this memory to check that
interposed functions (like malloc, calloc or free) don't have recursion.
The first time we call calloc(), we call pthread_setspecific() to create
a thread-specific value.
On Ubuntu machine, pthread_setspecific() calls calloc(), and we cannot intercept
such recursion.
gcc supports thread-local storage. For example,
  static __thread int reentrance = 0;
I rewrote code using this instead of pthread_setspecific().

gprofng/ChangeLog
2024-03-23  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

PR gprofng/31460
* libcollector/heaptrace.c: Use the __thread variable to check for
* reentry. Clean up code.

gdb/testsuite: Fix set_unbuffered_mode.o handling in parallel mode

Cygwin/MinGW testing links in a set_unbuffered_mode.o object to all
test programs.  When running the testsuite in parallel mode, on
Cygwin, I noticed errors like:

  ERROR: remote_download to host of ..../build/set_unbuffered_mode.o to ..../build/set_unbuffered_mode_saved.o: cp: cannot open '..../build/set_unbuffered_mode.o' for reading: No such file or directory
...
  ERROR: remote_download to host of ..../build/set_unbuffered_mode.o to ..../build/set_unbuffered_mode_saved.o: cp: cannot stat '..../build/set_unbuffered_mode.o': No such file or directory
...
  ERROR: remote_download to host of ..../build/set_unbuffered_mode.o to ..../build/set_unbuffered_mode_saved.o: cp: skipping file '..../build/set_unbuffered_mode.o', as it was replaced while being copied

(Absolute paths elided above.)

The problem is that gdb_compile's unbuffered_mode_obj cache isn't
parallel safe.  This is fixed in this commit.

Reviewed-by: Kevin Buettner <kevinb@redhat.com>
Change-Id: I67a289473c14ce0603d4b0beb755b124588f18d2

Fix windows_nat_target::fake_create_process ptid

While working on Windows non-stop mode, I managed to introduce a bug
that led to fake_create_process being called.  That then resulted in
GDB crashes later on, because fake_create_process added a thread with
an incorrect ptid for this target.  It is putting dwThreadId in the
tid field of the ptid instead of on the lwp field.  This is fixed by
this patch.

Change-Id: Iaee5d2deaa57c501f7e6909f8ac242af9b183215

bfd: make _bfd_section_size_insane part of the public API

If a BFD user is making use of a function like
bfd_get_section_contents to read a section into a pre-allocated
buffer, then that BFD user might also want to make use of
_bfd_section_size_insane prior to allocating the buffer they intend to
use in order to validate that the buffer size that plan to allocate is
sane.

This commit makes _bfd_section_size_insane public, by renaming it to
bfd_section_size_insane.

I've updated the existing uses within bfd/, I don't believe this
function is used outside of bfd/ currently.

One place that I plan to make use of this function is in
gdb/gdb_bfd.c, in the function gdb_bfd_get_full_section_contents.
This change isn't included in this commit, but will come later if/when
this has been merged into bfd.

There should be no change in behaviour after this commit.

bfd/

* bfd-in2.h (bfd_section_size_insane): Add declaration.
* compress.c (bfd_get_full_section_contents): Update for new name
of _bfd_section_size_insane.
(bfd_init_section_compress_status): Likewise.
* dwarf2.c (read_section): Likewise.
(_bfd_dwarf2_slurp_debug_info): Likewise.
* libbfd.h (_bfd_section_size_insane): Remove declaration.
* section.c (_bfd_section_size_insane): Rename to ...
(bfd_section_size_insane): ... this.

binutils/

* readelf.c (uncompress_section_contents): Update comment to
account for new name of _bfd_section_size_insane.

gdb: move more completion setup into completer.c

Move more setup of the readline global state relating to tab
completion into completer.c out of top.c.

Lots of the readline setup is done in init_main (top.c).  This commit
moves those bits of initialisation that relate to completion, and
which are only set the one time, into completer.c.  This does mean
that readline initialisation is now done in multiple locations, some
in init_main (top.c) and some in completer.c, but I think this is OK.
The work done in init_main is the general readline setup.

I think making static what can be made static, and having it all in
one file, makes things easier to reason about.  So I'm OK with having
this split initialisation.

The only completion related thing which is still setup in top.c is
rl_completion_display_matches_hook.  I've left this where it is for
now as rl_completion_display_matches_hook is also updated in the tui
code, and the display hook functions are not in completer.c anyway, so
moving this initialisation to completer.c would not allow anything
else to be made static.

There should be no user visible changes after this commit.

gdb/completion: make completion_find_completion_word static

I noticed that completion_find_completion_word is only used within
completer.c, so lets make it static.

There should be no user visible changes after this commit.

gdb: remove special case completion word handling for filenames

This commit removes some code which is special casing the filename
completion logic.  The code in question relates to finding the
beginning of the completion word and was first introduced, or modified
into its existing form in commit 7830cf6fb9571c3357b1a0 (from 2001).

The code being removed moved the start of the completion word backward
until a character in gdb_completer_file_name_break_characters was
found, or until we reached the end of the actual command.

However, I doubt that this is needed any more.  The filename completer
has a corresponding filename_completer_handle_brkchars function which
provides gdb_completer_file_name_break_characters as the word break
characters to readline, and also sets rl_completer_quote_characters.
As such, I would expect readline to be able to correctly find the
start of the completion word.

There is one change which I've needed to make as a consequence of
removing the above code, and I think this is a bug fix.

In complete_line_internal_normal_command we initialised temporary
variable P to the CMD_ARGS; this is the complete text after the
command name.  Meanwhile, complete_line_internal_normal_command also
accepts an argument WORD, which is the completion word that readline
found for us.

In the code I removed P was updated, it was first set to WORD, and
then moved backwards to the "new" start of the completion word.

But notice, the default for P is the complete command argument text,
and only if we are performing filename completion do we modify P to be
the completion word.

We then passed P through to the actual commands completion function.

If we are doing anything other than filename completion then the value
of P passed is the complete argument text.

If we are doing filename completion then the value of P passed is the
completion word.

In filename_completer we get two arguments TEXT and WORD, the TEXT
argument is the value of P which is the "new" completion word, while
WORD is the completion word that readline calculated.

After simplifying complete_line_internal_normal_command, and the
temporary P is removed, we always pass the complete argument text into
TEXT, while WORD remains the completion word that readline found.

Previously in filename_completer we actually tried to generate
completions based on TEXT, which worked fine as TEXT actually
contained the completion word that we found in
complete_line_internal_normal_command.  But I believe that we should
be fine to use the completion word that readline found, so I have
updated filename_completer to generate completions based on WORD.

If I'm correct, then I don't expect to see any user visible changes
after this commit.

gdb: remove some dead code from completer.c

In completer.c there is some code that is surrounded with '#if 0',
this code:

  #if 0
    /* There is no way to do this just long enough to affect quote
       inserting without also affecting the next completion.  This
       should be fixed in readline.  FIXME.  */
    /* Ensure that readline does the right thing
       with respect to inserting quotes.  */
    rl_completer_word_break_characters = "";
  #endif

This code, in some form, and always defined out, has been around since
the original import of GDB.  Though the comment hints at what the
problem might be, it's not really clear what the issue is.  And
completion within GDB has moved on a long way since this code was
written ... but not used.

I'm proposing that we just remove this code.

If/when a problem comes up then we can look at how to solve it.  Maybe
this code would be the answer ... but also, I suspect, given all the
changes ... maybe not.  I'm not sure carrying around this code for
another 20+ years adds much value.

There should be no user visible changes after this commit.

gdb: allow double quotes for quoting filenames

Currently GDB only supports using single quotes for quoting things,
the reason for this, as explained in completer.c (next to the variable
gdb_completer_expression_quote_characters) is that double quoted
strings need to be treated differently by the C expression parser.

But for filenames I don't believe this restriction holds.  The file
names as passed to things like the 'file' command are not passing
through the C expression parser, so it seems like we should be fine to
allow double quotes for quoting in this case.

And so, this commit extends GDB to allow double quotes for quoting
filenames.  Maybe in future we might be able to allow double quote
quoting in additional places, but this seems enough for now.

The testing has been extended to cover double quotes in addition to
the existing single quote testing.

This change does a number of things:

 1. Set rl_completer_quote_characters in filename_completer and
 filename_completer_handle_brkchars, this overrides the default which
 is set in complete_line_internal_1,

 2. In advance_to_completion_word we now take a set of quote
 characters as a parameter, the two callers
 advance_to_expression_complete_word_point and
 advance_to_filename_complete_word_point now pass in the required set
 of quote characters,

 3. In completion_find_completion_word we now use the currently active
 set of quote characters, this means we'll use
 gdb_completer_expression_quote_characters or
 gdb_completer_file_name_quote_characters depending on what type of
 things we are completing.

gdb: fix bug where quote characters would become nullptr

In gdb_completion_word_break_characters_throw, after calling
complete_line_internal, if the completion function chose to use a
custom word point then we set rl_completer_quote_characters to NULL.

However, nowhere do we set rl_completer_quote_characters back to its
default value, which is setup in init_main (top.c).

An example of something that uses a custom word point for its
completion is 'thread apply all ...'.

An example of something that relies on rl_completer_quote_characters
would be completion of a quoted filename that contains white space.

Consider this shell and GDB session.  The <TAB> markers indicate where
I've used tab to trigger completion:

  $ mkdir /tmp/aaa\ bbb
  $ touch /tmp/aaa\ bbb/xx\ 11
  $ touch /tmp/aaa\ bbb/xx\ 22
  $ gdb -q
  (gdb) file '/tmp/aaa bbb/xx<TAB><TAB>
  xx 11  xx 22
  (gdb) thread apply all hel<TAB>
  (gdb) thread apply all help
  (gdb) file '/tmp/aaa bbb/xx<TAB><TAB>

First I create a directory structure which uses white space within
file and directory names.  Then within GDB I use the 'file' command
and use a single quote to quote the filename.  When I tab complete GDB
correctly offers the two files within the directory '/tmp/aaa bbb/'.

This works because rl_completer_quote_characters contains the single
quote, and so readline knows that it is trying to complete the string
that starts after the single quote: /tmp/aaa bbb/xx

Next I invoke the completer for the 'thread apply all' command, to do
this I type 'thread apply all hel' and hit tab, this expands to the
one completion 'thread apply all help'.  We can run this command or
not, it doesn't matter (there are no threads, so we'll get no output).

Now I repeat the original 'file' completion.  This time though I don't
get offered any completions.

The reason is that the 'thread apply all' completer set
rl_completer_quote_characters to nullptr.  Now, when readline tries to
figure out the word to complete it doesn't see the single quote as the
start of a quoted word, so instead readline falls back to the word
break characters, and in this case spots the white space.  As a result
readline tries to complete the string 'bbb/xx' which obviously doesn't
have any completions.

By setting rl_completer_quote_characters each time completion is
invoked this problem is resolved and the second 'file' command
completes as expected.

I've extended gdb.base/filename-completion.exp to also test with
quoted filenames, and added a 'thread apply all' completion at the
start to expose this bug.

As setting of rl_completer_quote_characters is now all done in the
completer.c file the function get_gdb_completer_quote_characters()
could be made static.  However, as this function is only used one time
to initialise rl_completer_quote_characters, I've instead just deleted
get_gdb_completer_quote_characters() and used
gdb_completer_quote_characters directly.

gdb: remove skip_quoted and skip_quoted_chars

The function skip_quoted_chars (completer.c) is only used by
skip_quoted (also completer.c), so could be made static.  The function
skip_quoted just calls directly to skip_quoted_chars but fills in some
default arguments.

The function skip_quoted is only used by the Pascal expression parser,
and is only used in one place.

The skip_quoted_chars function skips a single string; it either looks
for a string between matching quotes, or for a string up to a word
break character.

However, given how the Pascal expression parser calls this function,
we know that the first character will always be a single quote, in
which case skip_quoted_chars will looks for a string between matching
single quotes.

The skip_quoted_chars doesn't do any escaped character handling, it
will just stop at the next single quote character.

In this commit I propose to remove skip_quoted and skip_quoted_chars,
and replace these with a smaller function pascal_skip_string  which
I've placed in p-exp.y.  This new function only skips a string between
matching single quotes, which is exactly the use case that we need.

The benefit of this change is to remove (some) code duplication.  It
feels like skip_quoted is similar in some ways to
extract_string_maybe_quoted, however, there are some differences;
skip_quoted uses the quotes and word break characters from the
completion engine which extract_string_maybe_quoted does not.

However, I'm currently working on improving filename completion, one
part of this is that I'm looking at allowing filenames to be quoted
with single or double quotes, while the default string quoting in
GDB (for expressions) can only use single quotes.  If I do end up
allowing single and double quotes in some cases, but we retain the
single quotes only for expressions then skip_quoted starts to become a
problem, should it accept both quote types, or only one?

But given how skip_quoted is used, I can avoid worrying about this by
simply removing skip_quoted.

The Pascal tests do still pass.  The code that called skip_quoted is
called at least once in the Pascal tests (adding an abort() call
causes gdb.pascal/types.exp to fail), but I doubt the testing is
extensive.  Not sure how widely used GDB for Pascal actually is
though.

gdb: rename unwindonsignal to unwind-on-signal

We now have unwind-on-timeout and unwind-on-terminating-exception, and
then the odd one out unwindonsignal.

I'm not a great fan of these squashed together command names, so in
this commit I propose renaming this to unwind-on-signal.

Obviously I've added the hidden alias unwindonsignal so any existing
GDB scripts will keep working.

There's one test that I've extended to test the alias works, but in
most of the other test scripts I've changed over to use the new name.

The docs are updated to reference the new name.

Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Tested-By: Luis Machado <luis.machado@arm.com>
Tested-By: Keith Seitz <keiths@redhat.com>

gdb: introduce unwind-on-timeout setting

Now that inferior function calls can timeout (see the recent
introduction of direct-call-timeout and indirect-call-timeout), this
commit adds a new setting unwind-on-timeout.

This new setting is just like the existing unwindonsignal and
unwind-on-terminating-exception, but the new setting will cause GDB to
unwind the stack if an inferior function call times out.

The existing inferior function call timeout tests have been updated to
cover the new setting.

Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Tested-By: Luis Machado <luis.machado@arm.com>
Tested-By: Keith Seitz <keiths@redhat.com>

gdb: add timeouts for inferior function calls

In the previous commits I have been working on improving inferior
function call support.  One thing that worries me about using inferior
function calls from a conditional breakpoint is: what happens if the
inferior function call fails?

If the failure is obvious, e.g. the thread performing the call
crashes, or hits a breakpoint, then this case is already well handled,
and the error is reported to the user.

But what if the thread performing the inferior call just deadlocks?
If the user made the call from a 'print' or 'call' command, then the
user might have some expectation of when the function call should
complete, and, when this time limit is exceeded, the user
will (hopefully) interrupt GDB and regain control of the debug
session.

But, when the inferior function call is from a breakpoint condition it
is much harder to understand that GDB is deadlocked within an inferior
call.  Maybe the breakpoint hasn't been hit yet?  Or maybe the
condition was always false?  Or maybe GDB is deadlocked in an inferior
call?  The only way to know for sure is for the user to periodically
interrupt the inferior, check on the state of all the threads, and
then continue.

Additionally, the focus of the previous commit was inferior function
calls, from a conditional breakpoint, in a multi-threaded inferior.
This opens up a whole new set of potential failure conditions.  For
example, what if the function called relies on interaction with some
other thread, and the other thread crashes?  Or hits a breakpoint?
Given how inferior function calls work (in a synchronous manner), a
stop event in some other thread is going to be ignored while the
inferior function call is being executed as part of a breakpoint
condition, and this means that GDB could get stuck waiting for the
original condition thread, which will now never complete.

In this commit I propose a solution to this problem.  A timeout.  For
targets that support async-mode we can install an event-loop timer
before starting the inferior function call.  When the timer expires we
will stop the thread performing the inferior function call.  With this
mechanism in place a user can be sure that any inferior call they make
will either complete, or timeout eventually.

Adding a timer like this is obviously a change in behaviour for the
more common 'call' and 'print' uses of inferior function calls, so, in
this patch, I propose having two different timers.  One I call the
'direct-call-timeout', which is used for 'call' and 'print' commands.
This timeout is by default set to unlimited, which, not surprisingly,
means there is no timeout in place.

A second timer, which I've called 'indirect-call-timeout', is used for
inferior function calls from breakpoint conditions.  This timeout has
a default value of 30 seconds.  This is a reasonably long time to
wait, and hopefully should be enough in most cases to allow the
inferior call to complete.  An inferior call that takes more than 30
seconds, which is installed on a breakpoint condition is really going
to slow down the debug session, so hopefully this is not a common use
case.

The user is, of course, free to reduce, or increase the timeout value,
and can always use Ctrl-c to interrupt an inferior function call, but
this timeout will ensure that GDB will stop at some point.

The new commands added by this commit are:

  set direct-call-timeout SECONDS
  show direct-call-timeout
  set indirect-call-timeout SECONDS
  show indirect-call-timeout

These new timeouts do depend on async-mode, so, if async-mode is
disabled (maint set target-async off), or not supported (e.g. target
sim), then the timeout is treated as unlimited (that is, no timeout is
set).

For targets that "fake" non-async mode, e.g. Linux native, where
non-async mode is really just async mode, but then we park the target
in a sissuspend, we could easily fix things so that the timeouts still
work, however, for targets that really are not async aware, like the
simulator, fixing things so that timeouts work correctly would be a
much bigger task - that effort would be better spent just making the
target async-aware.  And so, I'm happy for now that this feature will
only work on async targets.

The two new show commands will display slightly different text if the
current target is a non-async target, which should allow users to
understand what's going on.

There's a somewhat random test adjustment needed in gdb.base/help.exp,
the test uses a regexp with the apropos command, and expects to find a
single result.  Turns out the new settings I added also matched the
regexp, which broke the test.  I've updated the regexp a little to
exclude my new settings.

Reviewed-By: Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Tested-By: Luis Machado <luis.machado@arm.com>
Tested-By: Keith Seitz <keiths@redhat.com>

gdb: fix b/p conditions with infcalls in multi-threaded inferiors

This commit fixes bug PR 28942, that is, creating a conditional
breakpoint in a multi-threaded inferior, where the breakpoint
condition includes an inferior function call.

Currently, when a user tries to create such a breakpoint, then GDB
will fail with:

  (gdb) break infcall-from-bp-cond-single.c:61 if (return_true ())
  Breakpoint 2 at 0x4011fa: file /tmp/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.threads/infcall-from-bp-cond-single.c, line 61.
  (gdb) continue
  Continuing.
  [New Thread 0x7ffff7c5d700 (LWP 2460150)]
  [New Thread 0x7ffff745c700 (LWP 2460151)]
  [New Thread 0x7ffff6c5b700 (LWP 2460152)]
  [New Thread 0x7ffff645a700 (LWP 2460153)]
  [New Thread 0x7ffff5c59700 (LWP 2460154)]
  Error in testing breakpoint condition:
  Couldn't get registers: No such process.
  An error occurred while in a function called from GDB.
  Evaluation of the expression containing the function
  (return_true) will be abandoned.
  When the function is done executing, GDB will silently stop.
  Selected thread is running.
  (gdb)

Or, in some cases, like this:

  (gdb) break infcall-from-bp-cond-simple.c:56 if (is_matching_tid (arg, 1))
  Breakpoint 2 at 0x401194: file /tmp/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.threads/infcall-from-bp-cond-simple.c, line 56.
  (gdb) continue
  Continuing.
  [New Thread 0x7ffff7c5d700 (LWP 2461106)]
  [New Thread 0x7ffff745c700 (LWP 2461107)]
  ../../src.release/gdb/nat/x86-linux-dregs.c:146: internal-error: x86_linux_update_debug_registers: Assertion `lwp_is_stopped (lwp)' failed.
  A problem internal to GDB has been detected,
  further debugging may prove unreliable.

The precise error depends on the exact thread state; so there's race
conditions depending on which threads have fully started, and which
have not.  But the underlying problem is always the same; when GDB
tries to execute the inferior function call from within the breakpoint
condition, GDB will, incorrectly, try to resume threads that are
already running - GDB doesn't realise that some threads might already
be running.

The solution proposed in this patch requires an additional member
variable thread_info::in_cond_eval.  This flag is set to true (in
breakpoint.c) when GDB is evaluating a breakpoint condition.

In user_visible_resume_ptid (infrun.c), when the in_cond_eval flag is
true, then GDB will only try to resume the current thread, that is,
the thread for which the breakpoint condition is being evaluated.
This solves the problem of GDB trying to resume threads that are
already running.

The next problem is that inferior function calls are assumed to be
synchronous, that is, GDB doesn't expect to start an inferior function
call in thread #1, then receive a stop from thread #2 for some other,
unrelated reason.  To prevent GDB responding to an event from another
thread, we update fetch_inferior_event and do_target_wait in infrun.c,
so that, when an inferior function call (on behalf of a breakpoint
condition) is in progress, we only wait for events from the current
thread (the one evaluating the condition).

In do_target_wait I had to change the inferior_matches lambda
function, which is used to select which inferior to wait on.
Previously the logic was this:

   auto inferior_matches = [&wait_ptid] (inferior *inf)
     {
       return (inf->process_target () != nullptr
               && ptid_t (inf->pid).matches (wait_ptid));
     };

This compares the pid of the inferior against the complete ptid we
want to wait on.  Before this commit wait_ptid was only ever
minus_one_ptid (which is special, and means any process), and so every
inferior would match.

After this commit though wait_ptid might represent a specific thread
in a specific inferior.  If we compare the pid of the inferior to a
specific ptid then these will not match.  The fix is to compare
against the pid extracted from the wait_ptid, not against the complete
wait_ptid itself.

In fetch_inferior_event, after receiving the event, we only want to
stop all the other threads, and call inferior_event_handler with
INF_EXEC_COMPLETE, if we are not evaluating a conditional breakpoint.
If we are, then all the other threads should be left doing whatever
they were before.  The inferior_event_handler call will be performed
once the breakpoint condition has finished being evaluated, and GDB
decides to stop or not.

The final problem that needs solving relates to GDB's commit-resume
mechanism, which allows GDB to collect resume requests into a single
packet in order to reduce traffic to a remote target.

The problem is that the commit-resume mechanism will not send any
resume requests for an inferior if there are already events pending on
the GDB side.

Imagine an inferior with two threads.  Both threads hit a breakpoint,
maybe the same conditional breakpoint.  At this point there are two
pending events, one for each thread.

GDB selects one of the events and spots that this is a conditional
breakpoint, GDB evaluates the condition.

The condition includes an inferior function call, so GDB sets up for
the call and resumes the one thread, the resume request is added to
the commit-resume queue.

When the commit-resume queue is committed GDB sees that there is a
pending event from another thread, and so doesn't send any resume
requests to the actual target, GDB is assuming that when we wait we
will select the event from the other thread.

However, as this is an inferior function call for a condition
evaluation, we will not select the event from the other thread, we
only care about events from the thread that is evaluating the
condition - and the resume for this thread was never sent to the
target.

And so, GDB hangs, waiting for an event from a thread that was never
fully resumed.

To fix this issue I have added the concept of "forcing" the
commit-resume queue.  When enabling commit resume, if the force flag
is true, then any resumes will be committed to the target, even if
there are other threads with pending events.

A note on authorship: this patch was based on some work done by
Natalia Saiapova and Tankut Baris Aktemur from Intel[1].  I have made
some changes to their work in this version.

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

[1] https://sourceware.org/pipermail/gdb-patches/2020-October/172454.html

Co-authored-by: Natalia Saiapova <natalia.saiapova@intel.com>
Co-authored-by: Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
Reviewed-By: Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
Tested-By: Luis Machado <luis.machado@arm.com>
Tested-By: Keith Seitz <keiths@redhat.com>

Revert "gdb: remove unnecessary parameter wait_ptid from do_target_wait"

This reverts commit ac0d67ed1dcf470bad6a3bc4800c2ddc9bedecca.

There was nothing wrong with the commit which I'm reverting here, but
it removed some functionality that will be needed for a later commit;
that is, the ability for GDB to ask for events from a specific ptid_t
via the do_target_wait function.

In a follow up commit, this functionality will be used to implement
inferior function calls in multi-threaded inferiors.

This is not a straight revert of the above commit.  Reverting the
above commit replaces a 'nullptr' with 'NULL', I've gone in and
changed that, preserving the 'nullptr'.

Reviewed-By: Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
Tested-By: Luis Machado <luis.machado@arm.com>
Tested-By: Keith Seitz <keiths@redhat.com>

gdb/gdbserver: share x86/linux tdesc caching

This commit builds on the previous series of commits to share the
target description caching code between GDB and gdbserver for
x86/Linux targets.

The objective of this commit is to move the four functions (2 each of)
i386_linux_read_description and amd64_linux_read_description into
gdb/nat/x86-linux-tdesc.c and combine them so we have just a single
copy of each.  Then both GDB and gdbserver will link against these
shared functions.

It is worth reading the description of the previous commit to see why
this merging is not as simple as it seems: on the gdbserver side we
actually have two users of these functions, gdbserver itself, and the
in process agent (IPA).

However, the previous commit streamlined the gdbserver code, and so
now it is simple to move the two functions along with all their
support functions from the gdbserver directory into the gdb/nat/
directory, and then GDB is fine to call these functions.

One small curiosity with this patch is the function
x86_linux_post_init_tdesc.  On the gdbserver side the two functions
amd64_linux_read_description and i386_linux_read_description have some
functionality that is not present on the GDB side, that is some
additional configuration that is performed as each target description
is created to setup the expedited registers.

To support this I've added the function x86_linux_post_init_tdesc.
This function is called from the two *_linux_read_description
functions, but is implemented separately for GDB and gdbserver.

This does mean adding back some non-shared code when this whole series
has been about sharing code, but now the only non-shared bit is the
single line that is actually different between GDB and gdbserver, all
the rest, which is identical, is now shared.

I did need to add a new rule to the gdbserver Makefile, this is to
allow the nat/x86-linux-tdesc.c file to be compiled for the IPA.

Approved-By: John Baldwin <jhb@FreeBSD.org>

gdbserver: update target description creation for x86/linux

This commit is part of a series which aims to share more of the target
description creation between GDB and gdbserver for x86/Linux.

After some refactoring, the previous commit actually started to share
some code, we added the shared x86_linux_tdesc_for_tid function into
nat/x86-linux-tdesc.c.  However, this function still relies on
amd64_linux_read_description and i386_linux_read_description which are
implemented separately for both gdbserver and GDB.  Given that at
their core, all these functions to is:

  1. take an xcr0 value as input,
  2. mask out some feature bits,
  3. look for a cached pre-generated target description and return it
     if found,
  4. if no cached target description is found then call either
     amd64_create_target_description or
     i386_create_target_description to create a new target
     description, which is then added to the cache.  Return the newly
     created target description.

The inner functions amd64_create_target_description and
i386_create_target_description are already shared between GDB and
gdbserver (in the gdb/arch/ directory), so the only thing that
the *_read_description functions really do is add the caching layer,
and it feels like this really could be shared.

However, we have a small problem.

On the GDB side we create target descriptions using a different set of
cpu features than on the gdbserver side!  This means that for the
exact same target, we might get a different target description when
using native GDB vs using gdbserver.  This surely feels like a
mistake, I would expect to get the same target description on each.

The table below shows the number of possible different target
descriptions that we can create on the GDB side vs on the gdbserver
side for each target type:

        | GDB | gdbserver
  ------|-----|----------
  i386  | 64  | 7
  amd64 | 32  | 7
  x32   | 16  | 7

So in theory, all I want to do is move the GDB version
of *_read_description into the nat/ directory and have gdbserver use
that, then both GDB and gdbserver would be able to create any of the
possible target descriptions.

Unfortunately it's a little more complex than that due to the in
process agent (IPA).

When the IPA is in use, gdbserver sends a target description index to
the IPA, and the IPA uses this to find the correct target description
to use.

** START OF AN ASIDE **

Back in the day I suspect this approach made perfect sense.  However
since this commit:

  commit a8806230241d201f808d856eaae4d44088117b0c
  Date:   Thu Dec 7 17:07:01 2017 +0000

      Initialize target description early in IPA

I think passing the index is now more trouble than its worth.

We used to pass the index, and then use that index to lookup which
target description to instantiate and use.  However, the above commit
fixed an issue where we can't call malloc() within (certain parts of)
the IPA (apparently), so instead we now pre-compute _every_ possible
target description within the IPA.  The index is now only used to
lookup which of the (many) pre-computed target descriptions to use.

It would (I think) have been easier all around if the IPA just
self-inspected, figured out its own xcr0 value, and used that to
create the one target description that is required.  So long as the
xcr0 to target description code is shared (at compile time) with
gdbserver, then we can be sure that the IPA will derive the same
target description as gdbserver, and we would avoid all this index
passing business, which has made this commit so very, very painful.

** END OF AN ASIDE **

Currently then for x86/linux, gdbserver sends a number between 0 and 7
to the IPA, and the IPA uses this to create a target description.

However, I am proposing that gdbserver should now create one of (up
to) 64 different target descriptions for i386, so this 0 to 7 index
isn't going to be good enough any more (amd64 and x32 have slightly
fewer possible target descriptions, but still more than 8, so the
problem is the same).

For a while I wondered if I was going to have to try and find some
backward compatible solution for this mess.  But after seeing how
lightly the IPA is actually documented, I wonder if it is not the case
that there is a tight coupling between a version of gdbserver and a
version of the IPA?  At least I'm hoping so.

In this commit I have thrown out the old IPA target description index
numbering scheme, and switched to a completely new numbering scheme.
Instead of the index that is passed being arbitrary, the index is
instead calculated from the set of cpu features that are present on
the target.  Within the IPA we can then reverse this logic to recreate
the xcr0 value based on the index, and from the xcr0 value we can
create the correct target description.

With the gdbserver to IPA numbering scheme issue resolved I have then
update the gdbserver versions of amd64_linux_read_description and
i386_linux_read_description so that they create target descriptions
using the same set of cpu features as GDB itself.

After this gdbserver should now always come up with the same target
description as GDB does on any x86/Linux target.

This commit does not introduce any new code sharing between GDB and
gdbserver as previous commits in this series does.  Instead this
commit is all about bringing GDB and gdbserver into alignment
functionally so that the next commit can merge the GDB and gdbserver
versions of these functions.

Approved-By: John Baldwin <jhb@FreeBSD.org>