Remove bfd_boolean definition from bfd

It has been almost 5 years since I started retiring bfd_boolean.
Remove it entirely.

Remove bfd_boolean from sim

Replace a few vestiges of bfd_boolean in sim with bool, and FALSE/TRUE
with false/true where the type is clearly bool.

Remove bfd_boolean from gdb

Replace a few vestiges of bfd_boolean in gdb with bool.  I haven't
tried to replace FALSE/TRUE in gdb except when the type was clearly
bool.  There may well be other occurrences of FALSE or TRUE that ought
to be tidied.  Source that uses BOOL or a typedef enum boolean in
particular isn't changed.

[pre-commit] Bump black to 26.3.0

Ran "pre-commit autoupdate".  No changes in formatting.

gas/doc: clarify internal symbol vs local symbol terminology

In ELF, "local symbols" refer to symbols of STB_LOCAL binding. The
doc is inconsistent: while it uses "local symbol" in places like .local,
"local symbols" are also used for .L-prefixed symbols (as determined by
bfd_is_local_label).

Rename "Local Symbol Names" to "Internal Symbol Names" for .L-prefixed
symbols, and rename "Local Labels" to "Numeric Local Labels" for
N:/Nb/Nf numeric labels.  This avoids confusion with ELF STB_LOCAL
"local symbols".

The term "internal symbol" is chosen over alternatives like "temporary
symbol" because it describes the purpose of these symbols: they are for
internal use by compilers and assemblers, not meant to be visible
externally (albeit they can become visible in certain situations).
While ELF defines STV_INTERNAL as a symbol visibility, it is rarely used
in practice and unlikely to cause confusion (only used by SGI for their
link-time interprocedural optimization; useless on other OSes).

Remove bfd_boolean from gas and gprofng

A few uses have crept back in, replace with bool.  Also replace FALSE/TRUE
with false/true.

ppc-opc.c non-ascii string

Fix a gettext complaint.

* ppc-opc.c (insert_sr): Don't use non-ascii dash.

Automatic date update in version.in

Fix debug_names function visibility

A few test cases that emit custom DWARF with debug_names had a
discrepancy between the debug info and the debug names.  In particular
a function would be marked private in the info:

    subprogram {
DW_AT_name _start
DW_AT_low_pc $_start_start DW_FORM_addr
DW_AT_high_pc $_start_end DW_FORM_addr
    }

(Note there's no DW_AT_external)

... but be marked public in the names:

    debug_names {} {
...
name _start subprogram CU-1 0xEDDB6232

(Note there's no DW_IDX_GNU_internal)

I believe these test cases worked by accident; that is, taking an
unusual path through the code to still get the right output.

This patch fixes these tests to be self-consistent.

gas: pru: Add TSEN and MVI instructions

Add support for TSEN and MVI instructions to GAS and libopcodes.
TSEN is available in newer PRU core revisions, and can be used to
implement multitasking.  MVI allows indirectly addressing CPU registers
using a pointer in R1 register.

References:
 - https://www.ti.com/lit/ug/spruij2/spruij2.pdf
   Chapter "Move Register File Indirect (MVIx)"
 - https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1426480/am2431-pru-assembly-instruction-user-guide

Signed-off-by: Dimitar Dimitrov <dimitar@dinux.eu>

ld: clarify comments on /DISCARD/ output section behavior

The previous comments made it difficult to understand how the /DISCARD/
output section interacts with non-contiguous regions.

In summary, the general rule is that the first (top-most) clause takes
precedence over subsequent ones:
- If /DISCARD/ appears first, the section is dropped. There is no need
  to warn about potential behavior changes with non-contiguous regions
  when the section is already discarded.
- If /DISCARD/ follows clauses that assign the input section to an output
  section, /DISCARD/ is ignored. If the input section can't be assigned
  to the output section for a later reason, an error will be raised.
  Otherwise the input section will be assigned as intended to an output
  section specified by one of the matching clauses previous to /DISCARD/.

aarch64: add tests for non-contiguous memory regions

This patch adds AArch64 test cases for all non-contiguous memory scenarios.
Those tests were copy-pasted from AArch32, and adapted for AArch64.
It also adds a new test case inspired from a real case where several sections
containing interrupt vector tables, declared in different compilation units,
and all aligned on 2KB, are supposed to be merged into one output section
fitting on 2KB memory.

ld: fix segfault on discarded input sections not fitting in memory regions

In the case of non-contiguous memory regions, if an input section did not
fit in any of the designated memory regions, the linker marked it as
discarded, and warn_non_contiguous_discards() would only issue warning on
it, relying on later unresolved symbol errors to terminate the process
before a crash occur. This approach was insufficient, and crashes did occur
on AArch64.

This patch renames warn_non_contiguous_discards () to a name that does not
contain "discard" as it created some confusion with the /DISCARD/ output
section. It also promotes the warnings to errors, and ensures that the
link process terminates cleanly if any input section is not allocated to
an output section.

It also updates an AArch32 test's expectations to match the corrected
behavior. Tests for the crash cases are added in a subsequent patch.

Finally, it adds some patterns to /DISCARD/ in ld-elf/non-contiguous.ld.
Before this patch, a section which was not assigned to an output section
because no pattern matched, did not raise any error.

Approved-By: Jan Beulich <jbeulich@suse.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31412

explicitly state code assumptions on output section in AArch64 ld handlers

When support for non-contiguous memory was added, some corner cases when
sections were removed from the output object, did not emit fatal error and
reached code paths that correctly assumed every input section had a valid
output section, and this led to crashes due to segfault.

This patch adds BFD_ASSERTs in the previously segfaulting code, to
explicitly state code assumptions.

ld: fix segfault caused by untagged stub sections

In the case of non-contiguous memory regions, a far-call stub section
must be assigned to the memory of the section it was originally emitted
for. If the stub section does not fit, the section is marked as dropped,
and removed later. To emit a useful message to the user, however, a stub
section needs to be discernible from sections originating from input
objects.

Previously [1], this distinction was made using the SEC_LINKER_CREATED
flag only in the AArch32 backend handler <arch>_add_stub_section. Other
backends that didn't set this flag on their stub sections skipped required
checks in ld/ldlang.c:size_input_section(). On AArch64, this caused the
linker to proceed into code paths that assumed output sections were set,
instead of reporting fatal errors, and ultimately led to a segmentation
fault.

However, the SEC_LINKER_CREATED flag does not solely indicate that a
section was created by the linker. Its original meaning also meant that
the section should not be handled by the generic relocation code. Reusing
this flag to identify stub sections, while it appeared to fix the issue,
introduced unintended side effects. On PowerPC, for instance, it skipped
relocations present in the stubs and interpreted them as absolute
addresses.

This patch proposes a new attribute 'veneer', indicating that a section
contains branch veneers. The attribute is set on AArch32, AArch64 and
PowerPC immediately after the creation of the stub section. Others
architectures are left unchanged, as they do not appear to support
non-contiguous memory regions (no tests were found to verify the fix).
Additionally, the diagnostic message was improved when a stub cannot be
placed in the same memory region as its referencing code.

Approved-By: Jan Beulich <jbeulich@suse.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31412

[1]: abf874a, Add support for non-contiguous memory regions.

[pre-commit] Bump codespell to 2.4.2

Ran "pre-commit autoupdate".

Doing "pre-commit run --all-files codespell" still passes.

Now that ignore-multiline-regex is fixed, enable ignoring blocks of code using
codespell:ignore-begin/codespell:ignore-end.

Automatic date update in version.in

gdb: rename blockvec to rangevec in dwarf2_record_block_ranges

This commit just renames local variable blockvec to rangevec. It seems
to me that rangevec is better name since it holds on struct blockrange.

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

[gdb/symtab] Replace per-BFD lock with global BFD lock

Our current BFD locking scheme is as follows [1]:
...
There is one global mutex, gdb_bfd_mutex, which BFD can lock and unlock via
the callbacks we pass it.  This appears to lock the internal global data
structures of BFD (like its global cache or some global counter), but not data
in individual `bfd *`instances.  If the user of BFD wishes to call functions
on a given `bfd *` from multiple threads, it must provide the synchronization
itself.  For this, we have gdb_bfd_data::per_bfd_mutex.
...

PR33811 reports the following data race:
...
  Read of size 1 at 0x72440010c608 by thread T5 (mutexes: write M0):
    #0 bfd_get_section_limit_octets bfd.h:2433
    #1 bfd_get_section_contents bfd/section.c:1612
    #2 bfd_is_section_compressed_info bfd/compress.c:901
    #3 bfd_is_section_compressed bfd/compress.c:959
    #4 gdb_bfd_map_section(bfd_section*, unsigned long*) gdb/gdb_bfd.c:779
...
vs:
...
  Previous write of size 4 at 0x72440010c608 by main thread (mutexes: write M1):
    #0 bfd_cache_delete bfd/cache.c:180
    #1 _bfd_cache_close_unlocked bfd/cache.c:607
    #2 bfd_cache_close_all bfd/cache.c:664
    #3 notify_before_prompt gdb/event-top.c:524
...

In more detail, this read in bfd_get_section_limit_octets in bfd/bfd-in2.h:
...
  if (abfd->direction != write_direction && sec->rawsize != 0)
...
vs. this write in bfd_cache_delete in bfd/cache.c:
...
  abfd->last_io = bfd_io_force;
...

There is already locking used for both the read and write.

In gdb_bfd_map_section, we use the per-BFD lock:
...
  gdb_bfd_data *gdata = (gdb_bfd_data *) bfd_usrdata (abfd);
  gdb::lock_guard<gdb::mutex> guard (gdata->per_bfd_mutex);
...

And in bfd_cache_close_all, we use the global BFD lock:
...
bool
bfd_cache_close_all (void)
{
  ...
  if (!bfd_lock ())
    return false;
  ...
  if (!bfd_unlock ())
    return false;
  return ret;
}
...

The problem is that the locking is not sufficient.  Since bfd_cache_close_all
accesses individual BFDs, it needs to lock the corresponding per-BFD locks as
well.

A naive way to implement this using the existing scheme of wrappers, would be to
add a gdb_bfd_cache_close_all that locks all per-BFD locks, calls
bfd_cache_close_all, and unlocks all per-BFD locks, like this:
...
bool
gdb_bfd_cache_close_all ()
{
  bool res;
  for (auto abfd : all_bfds)
    {
      auto gdata = static_cast<gdb_bfd_data *> (bfd_usrdata (abfd));
      gdata->per_bfd_mutex.lock ();
    }
  res = bfd_cache_close_all ();
  for (auto abfd : all_bfds)
    {
      auto gdata = static_cast<gdb_bfd_data *> (bfd_usrdata (abfd));
      gdata->per_bfd_mutex.unlock ();
    }
  return res;
}
...

Apart from the fact that trying to hold all those locks at the same time
increases the changes of deadlock, it also accesses all_bfds without locking
the required global BFD lock (reported by TSAN).

It's easy enough to fix that by adding:
...
 gdb_bfd_cache_close_all ()
 {
+  gdb::lock_guard<gdb::recursive_mutex> guard (gdb_bfd_mutex);
...
but that brings us to the problem of lock-order-inversion (also reported by
TSAN), and indeed timeouts do occur.

I came up with a complicated scheme [2] that:
- doesn't try to lock all the per-BFD locks at the same time, and
- addresses the lock-order-inversion problem by releasing the global BFD lock
  before acquiring the per-BFD lock and then re-acquiring the global BFD lock

However, this approach was seen as too convoluted.

So instead, revert to a simple locking scheme with only the global BFD lock,
dropping the per-BFD lock.

This changes the per-BFD locking in gdb_bfd_map_section to global BFD locking,
which means that the read in bfd_get_section_limit_octets is now guarded by
the global BFD lock, which is the same lock guarding the write in
bfd_cache_delete.  So, the race is fixed.

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

[1] https://sourceware.org/pipermail/gdb-patches/2026-January/224291.html
[2] https://sourceware.org/pipermail/gdb-patches/2026-January/224426.html

[gdb/testsuite] Fix gdb.opt/inline-entry.exp with clang

I ran test-case gdb.opt/inline-entry.exp with clang, more specifically:
...
get_compiler_info: clang-17-0-6
...
and ran into:
...
(gdb) continue^M
Continuing.^M
^M
Breakpoint 2.1, bar (val=<optimized out>) at inline-entry.c:29^M
29        if (global == val)^M
(gdb) PASS: gdb.opt/inline-entry.exp: continue to bar
continue^M
Continuing.^M
^M
Breakpoint 2.3, bar (val=2) at inline-entry.c:29^M
29        if (global == val)^M
(gdb) FAIL: gdb.opt/inline-entry.exp: continue to foo
continue^M
Continuing.^M
^M
Breakpoint 3, foo (arg=arg@entry=1) at inline-entry.c:23^M
23        global += arg;^M
(gdb) FAIL: gdb.opt/inline-entry.exp: continue until exit
...

The problem is that the test-case expects two breakpoint locations for
function bar, and to hit one of them, but there are three and it hits two of
them.

This is due to the debug info, which for function bar:
...
 <1><25d>: Abbrev Number: 7 (DW_TAG_subprogram)
    <25e>   DW_AT_name        : bar
    <25f>   DW_AT_decl_file   : 1
    <260>   DW_AT_decl_line   : 27
    <261>   DW_AT_prototyped  : 1
    <261>   DW_AT_type        : <0x243>
    <265>   DW_AT_external    : 1
    <265>   DW_AT_inline      : 1       (inlined)
 <2><265>: Abbrev Number: 8 (DW_TAG_formal_parameter)
    <266>   DW_AT_name        : val
    <267>   DW_AT_decl_file   : 1
    <268>   DW_AT_decl_line   : 27
    <269>   DW_AT_type        : <0x243>
...
has three corresponding DW_TAG_inlined_subroutine DIEs:
...
 <2><27d>: Abbrev Number: 10 (DW_TAG_inlined_subroutine)
    <27e>   DW_AT_abstract_origin: <0x25d>
    <282>   DW_AT_ranges      : 0x31
    <283>   DW_AT_call_file   : 1
    <284>   DW_AT_call_line   : 38
 <2><285>: Abbrev Number: 11 (DW_TAG_inlined_subroutine)
    <286>   DW_AT_abstract_origin: <0x25d>
    <28a>   DW_AT_low_pc      : 0x114f
    <28b>   DW_AT_high_pc     : 0x5
    <28f>   DW_AT_call_file   : 1
    <290>   DW_AT_call_line   : 38
    <291>   DW_AT_call_column : 18
 <3><292>: Abbrev Number: 12 (DW_TAG_formal_parameter)
    <293>   DW_AT_const_value : 1
    <294>   DW_AT_abstract_origin: <0x265>
 <2><299>: Abbrev Number: 11 (DW_TAG_inlined_subroutine)
    <29a>   DW_AT_abstract_origin: <0x25d>
    <29e>   DW_AT_low_pc      : 0x1166
    <29f>   DW_AT_high_pc     : 0x7
    <2a3>   DW_AT_call_file   : 1
    <2a4>   DW_AT_call_line   : 38
    <2a5>   DW_AT_call_column : 30
 <3><2a6>: Abbrev Number: 12 (DW_TAG_formal_parameter)
    <2a7>   DW_AT_const_value : 2
    <2a8>   DW_AT_abstract_origin: <0x265>
...
while the source contains just two calls:
...
    35 int
    36 main (void)
    37 {
    38   if ((global && bar (1)) || bar (2))
    39     return 0;
    40   return 1;
    41 }
...

This is a bug in the debug info.

I don't see a way to work around this in gdb, so work around this in the
test-case by bailing out if there are more or less than two breakpoint
locations for function bar.

Tested on x86_64-linux.

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

gdb/python: fix gdb.FinishBreakpoint returning to a tail call frame

I noticed that gdb.FinishBreakpoint doesn't work if the parent
function is a tail call function.  In bpfinishpy_init we use
get_frame_pc to find the address at which the finish breakpoint should
be placed within the previous frame.

However, if the previous frame is a tail call frame, then get_frame_pc
will return an address outside of the tail call function, an address
which will not be reached on the return path.

Unlike other recent tail call fixes I've made, we cannot switch to
using something like get_frame_address_in_block here as in the tail
call case this will return an address within the function, but not an
address that will be executed when we return.

What we need to do in the tail call case is create the finish
breakpoint in the frame that called the tail call function.  Or if
that frame is itself a tail call, then we should walk back up the call
stack until we find a non-tail call function.

This can be achieved by adding a call to skip_tailcall_frames into
bpfinishpy_init after our existing call to get_prev_frame.

I've extended the existing test case to cover this additional
situation.

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

gdb/python: don't allow FinishBreakpoints for inline frames

Creating a Python gdb.FinishBreakpoint for an inline frame doesn't
work.

If we look at the 'finish' command, in the finish_command
function (infcmd.c) then we see that GDB handles inline frames very
different to non-inline frames.

For non-inline frames GDB creates a temporary breakpoint and then
resumes the inferior until the breakpoint is hit.

But for inline frames, GDB steps forward until we have left the inline
frame.

When it comes to gdb.FinishBreakpoint we only have the "create a
temporary breakpoint" mechanism; that is, after all, what the
FinishBreakpoint is, it's a temporary breakpoint placed at the
return address in the caller.

Currently, when a FinishBreakpoint is created within an inline frame,
GDB ends up creating the breakpoint at the current $pc.  As a result
the breakpoint will not be hit before the current function
exits (unless there's a loop going on, but that's not the point).

We could imagine what a solution to this problem would look like, GDB
would need to figure out the set of addresses for all possible exit
points from the inline function, and place a breakpoint at each of
these locations.  I don't propose doing that in this commit.

Instead, I plan to update the docs to note that creating a
FinishBreakpoint within an inline frame is not allowed, and I will
catch this case within bpfinishpy_init (python/py-finishbreakpoint.c)
and throw an error.

Though the error is new, all I'm doing is raising an error for a case
that never worked.

There's a new test to cover this case.

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

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

gdb/python: fix FinishBreakpoint.return_value for tail call functions

The FinishBreakpoint.return_value attribute will not be populated
correctly for tail call functions.

In bpfinishpy_init (python/py-finishbreakpoint.c) we use the function
get_frame_pc_if_available to return an address, and then use this
address to lookup a function symbol.

The problem is that, for tail call functions, the address returned by
get_frame_pc_if_available can be outside the bounds of the function,
as a result GDB might find no function symbol at all, or might find
the wrong function symbol, if the tail call function is immediately
adjacent to the next function.

Fix this by using get_frame_address_in_block_if_available instead.
For tail call functions this will return an address within the bounds
of the function, which means that GDB should find the correct function
symbol, and from this the correct return type.

I've extended the existing FinishBreakpoint with tail call test case
to include printing the return value, this test fails without this
patch, but now works.

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

gdb: fix frame_unwind_caller_WHAT functions for inline and tail calls

The 3 frame_unwind_caller_WHAT functions:

  + frame_unwind_caller_id
  + frame_unwind_caller_pc
  + frame_unwind_caller_arch

Are, I believe, currently all broken with respect to inline and tail
call functions.

The Python FinishBreakpoint type creates a breakpoint in the caller
function which, when triggered, indicates that the FinishBreakpoint
has gone out of scope.

I was writing a test for the FinishBreakpoint type which included a
tail call function, and the FinishBreakpoint was being created for the
tail call function frame.  What I observed is that the out of scope
breakpoint was never being hit.

The call stack in my new test looked like this:

  main -> tailcall_function -> normal_function

I would stop in normal_function, and then create a FinishBreakpoint
for the parent (tailcall_function) frame.  The FinishBreakpoint's out
of scope breakpoint was being correctly placed in the 'main' function,
but would never trigger.

The problem is that the breakpoint placed in 'main' holds a frame-id.
This frame-id is the frame in which the breakpoint should trigger.
This frame-id exists to prevent premature stops due to recursion.  But
in this case, when the breakpoint in 'main' was hit, despite no
recursion having occurred, the frame-id didn't match, and so the
breakpoint was ignored.

The problem is that in bpfinishpy_init we call frame_unwind_caller_id
to compute the frame-id of the frame in which we should stop, and
frame_unwind_caller_id was returning the wrong frame-id.  As far as I
can tell frame_unwind_caller_id has been broken since it was updated
for inline functions in commit edb3359dff90ef8a.

The frame_unwind_caller_id function, and all the
frame_unwind_caller_WHAT functions, are intended to return the
previous frame, but should skip over any inline, or tail call frames.
Let's look at an example call stack:

  #0 A // A normal function.
  #1 B // An inline function.
  #2 C // An inline function.
  #3 D // A normal function.
  #4 E // A normal function.

Starting from #0, a normal function, frame_unwind_caller_id, should
return the frame-id for #3, and this is what happens.

But if we start in #1 and call frame_unwind_caller_id, then we should
still return the frame-id for #3, but this is not what happens.
Instead we return the frame-id for #4, skipping a frame.

The problem is that frame_unwind_caller_id starts by calling
skip_artificial_frames, which calls get_prev_frame_always until we
reach a non-inline (or non-tail call) frame, this moves us from #1 to

Then, back in frame_unwind_caller_id we call get_prev_frame_always,
which moves us to #4.

Then frame_unwind_caller_id finishes with a call to
skip_artificial_frames, this could potentially result in additional
frames being skipped, but in my example above this isn't the case.

The problem here is that if skip_artificial_frames skips anything,
then we have already unwound to the caller frame, and the
get_prev_frame_always call in frame_unwind_caller_id is unnecessary.

I propose to add a new helper function frame_unwind_caller_frame,
which should do the correct thing; it unwinds one frame and then calls
skip_artificial_frames.  This should do exactly what is needed.

Then all the frame_unwind_caller_WHAT functions will be updated to use
this helper function, and just extract the required property from the
resulting frame.

With this fix in place I could then write the FinishBreakpoint test,
which now works.

I took a look for other places where frame_unwind_caller_id is used
and spotted that the 'until' command does much the same thing, placing
a breakpoint in the caller frame.  As predicted, the 'until' command
is also broken when used within a tail call frame.  This patch fixes
that issue too.  There's also a test for the until command.

The bug PR gdb/28683 seems to describe this exact problem with a
specific AArch64 case given.  I haven't actually setup the environment
needed to test this bug, but I'm reasonably sure that this patch will
fix the bug.  Even if it doesn't then it's certainly related and worth
linking into the bug report.

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

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

[gdb/testsuite] Fix flake8 error in gdb.python/py-selected-context.py

We currently are running into a flake8 error:
...
$ pre-commit run --all-files flake8
flake8..................................................................Failed
- hook id: flake8
- exit code: 1

gdb/testsuite/gdb.python/py-selected-context.py:24:5: \
  F824 `global event_throws_error` is unused: name is never assigned in scope
...

Fix this by dropping the unnecessary "global event_throws_error".

Tested on x86_64-linux.

[gdb/testsuite] Fix gdb.python/py-selected-context.exp with glibc debuginfo

With test-case gdb.python/py-selected-context.exp, I run into:
...
(gdb) thread 1
[Switching to thread 1.1 (Thread 0x7ffff7cc0080 (LWP 1793477))]
57          return INTERNAL_SYSCALL_CANCEL (...
Python Exception <class 'gdb.GdbError'>: error from gdb_selected_context_handler
(gdb) FAIL: $exp: switch thread, handler raises an error
...

The regexp doesn't expect the source line, which indeed is not printed if I
de-install glibc debuginfo.

Fix this by updating the regexp.

Tested on x86_64-linux.

gdb: remove last_examine_address

Remove the global variable `last_examine_address`.  It can be obtained
from another global variable, `last_examine_value`.

Reviewed-By: Keith Seitz <keiths@redhat.com>
Approved-By: Tom Tromey <tom@tromey.com>

gdb: use builtin_func_ptr for `$_` set by "x/i"

The 'x' command with the 'i' format specifier is for displaying
instructions.  The "last address examined" convenience var, that is
'$_', is set to a single byte pointer by "x/i":

  (gdb) p $pc
  $1 = (void (*)()) 0x5555555551d4 <main+15>
  (gdb) x/i $pc
  => 0x5555555551d4 <main+15>:    movl   $0x2a,-0x4(%rbp)
  (gdb) p $_
  $2 = (int8_t *) 0x5555555551d4 <main+15>
  (gdb)

However, because "x/i" is for displaying instructions, it makes more
sense to give '$_' a code pointer type, which is done by this patch:

  (gdb) p $pc
  $1 = (void (*)()) 0x5555555551d4 <main+15>
  (gdb) x/i $pc
  => 0x5555555551d4 <main+15>:    movl   $0x2a,-0x4(%rbp)
  (gdb) p $_
  $2 = (void (*)()) 0x5555555551d4 <main+15>
  (gdb)

This is a minor user experience improvement and should not change
functionality.

Reviewed-By: Keith Seitz <keiths@redhat.com>
Approved-By: Tom Tromey <tom@tromey.com>

gdb: use builtin_func_ptr for `$_` set by "info breakpoints" and "info line"

The `$_` convenience var, as set by the "info breakpoints" and
"info line" commands, has the type builtin_data_ptr (i.e. `void *`).
However, both of the aforementioned commands deal with code addresses.
Hence, it makes more sense to use builtin_func_ptr (i.e.
`void (*)()`).

With this change:

    (gdb) b main
    Breakpoint 2 at 0x402547: file test.cpp, line 20.
    (gdb) info breakpoints
    Num     Type           Disp Enb Address            What
    2       breakpoint     keep y   0x0000000000402547 in main(int, char**) at test.cpp:20
    (gdb) p $_
    $2 = (void (*)(void)) 0x402547 <main(int, char**)+39>
    (gdb) ptype $_
    type = void (*)(void)
    (gdb) ptype &main
    type = int (*)(int, char **)
    (gdb) info line 22
    Line 22 of "test.cpp" starts at address 0x40256d <main(int, char**)+77> and ends at 0x4025bd <main(int, char**)+157>.
    (gdb) p $_
    $3 = (void (*)(void)) 0x40256d <main(int, char**)+77>
    (gdb) ptype $_
    type = void (*)(void)
    (gdb)

This also matches the type of PC:

    (gdb) ptype $pc
    type = void (*)(void)

Also add test cases to check that "info breakpoints" and "info line"
set the `$_` var.

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

gdb: update doc for the $_ variable and search commands

I noticed that forward-search and reverse-search commands set the $_
convenience variable.  This is mentioned in the help menu (see below)
but is not stated in the documentation.  Add related text to the doc.

  (gdb) help search
  forward-search, fo, search
  Search for regular expression (see regex(3)) from last line listed.
  The matching line number is also stored as the value of "$_".
  (gdb) help rev
  reverse-search, rev
  Search backward for regular expression (see regex(3)) from last line listed.
  The matching line number is also stored as the value of "$_".
  (gdb)

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

gdbserver: require_running_or_break for the 'z' and 'vCont' packets

Similar to several other packages that access/modify process state,
the 'z'/'Z' and 'vCont' packets need to access the process.  Hence,
add a `require_running_or_break` as a pre-check.

Also add a test to check that gdbserver does not crash when certain
packets are received while there does not exist a process.

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

gdb/python: introduce gdb.Symtab.source_lines method

This commit adds a new method gdb.Symtab.source_lines.  This method
can be used to read the lines from a symtab's source file.  This is
similar to GDB's internal source_cache::get_source_lines function.

Currently using the Python API, if a user wants to display source
lines then they need to use Symtab.fullname() to get the source file
name, then open this file and parse out the lines themselves.

This isn't too much effort, but the problem is that these lines will
not be styled.  The user could style the source content themselves,
but will this be styled exactly as GDB would style it?

The new Symtab.source_lines() method returns source lines with styling
included (as ANSI terminal escape sequences), assuming of course, that
styling is currently enabled.

Of course, in some cases, a user of the Python API might want source
code without styling.  That's supported too, the new method has an
'unstyled' argument.  If this is True then the output is forced to be
unstyled.  The argument is named 'unstyled' rather than 'styled'
because the API call cannot force styling on.  If 'set style enabled
off' is in effect then making the API call will never return styled
source lines.

The new API call allows for a range of lines to be requested if
desired.

As part of this commit I've updated the host_string_to_python_string
utility function to take a std::string_view.

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

gdb: return optional from last_symtab_line, and use this more

I noticed that last_symtab_line is defined as returning an int, but if
the file associated with the symtab cannot be read then the function
returns false!

This commit updates last_symtab_line to return std::optional<int> and
replaces 'return false' with 'return {}'.

I then realised that last_symtab_line isn't actually used very often,
but we do use source_cache::get_line_charpos to perform the same job.
So I went through all uses of ::get_line_charpos and replaced them
with last_symtab_line where appropriate.  I think this makes it
clearer what we're actually trying to do.

There should be no user visible changes after this commit.

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

gdb/python: new selected_context event

This commit introduces a new Python event, selected_context.  This
event is attached to the user_selected_context_changed observer, which
triggers when the user changes the currently selected inferior,
thread, or frame.

Adding this event allows a Python extension to update in response to
user driven changes without having to poll the state from a
before_prompt hook, which is what I currently do to achieve the same
results.

I did consider splitting the user_selected_context_changed observer
into 3 separate Python events, inferior_changed, thread_changed, and
frame_changed, but I couldn't see any significant advantage to doing
this, so in the end I went with just a single event, and the event
object contains the inferior, thread, and frame.

Additionally, the user isn't informed about which aspect of the
context changed.  That is, every event carries the inferior, thread,
and frame, so an event triggered when switching frames will looks
identical to an event triggered when switching inferiors.  If the user
wants to know what changed then they will have to track the current
state themselves, and then compare the event state to the stored
current state.  In many cases though I suspect that just being told
something changed, and then updating everything will be sufficient,
which is why I've not bothered trying to inform the user what changed.

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

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

PowerPC: Fix dmxxshake128pad test case for big-endian targets

The encoding pattern for dmxxshake128pad in future.d was incorrect for
big-endian targets, causing the gas testsuite to fail with a regexp_diff
mismatch.  The expected byte order did not match the objdump output on
big-endian systems.

Update the expected encoding to match the correct byte order.

gas/
* gas/testsuite/gas/ppc/future.d: Fix Encoding

Automatic date update in version.in

Don't lose actual error in _bfd_generic_read_minisymbols

Setting bfd_error_no_symbols in the error return loses the underlying
reason why the function failed.  Also fix a few places where functions
called by _bfd_generic_read_minisymbols didn't set bfd_error on failure.

* syms.c (_bfd_generic_read_minisymbols): Don't bfd_set_error
here.
* aoutx.h (aout_get_external_symbols): Call bfd_set_error on
error return.
* pdp11.c (aout_get_external_symbols): Likewise.
* ecoff.c (_bfd_ecoff_slurp_symbolic_info): Likewise.

gas: only free on exit when --enable-leak-check

Adds a new --enable-leak-check option, controlling whether memory is
freed before exit in order to find memory leaks.  The default is to
free memory if BFD_ASAN is non-zero.

* configure.ac: Add new --enable-leak-check..
(ENABLE_LEAK_CHECK): ..defining this.
* as.c (gas_early_init): free_notes on exit only if ENABLE_LEAK_CHECK.
* expr.c (expr_end): Nothing to do when !ENABLE_LEAK_CHECK.
* macro.c (macro_end): Likewise.
* output-file.c (output_file_close): Don't stash frchain obstacks
when !ENABLE_LEAK_CHECK.
* read.c (read_end): Nothing to do when !ENABLE_LEAK_CHECK.
(poend): Likewise.
* stabs.c (stabs_end): Likewise.
* subsegs.c (subsegs_end): Likewise.
* symbols.c (symbol_end): Likewise.
* config/obj-elf-attr.c (oav1_attr_info_exit): Likewise.
* config/obj-elf.c (elf_end): Likewise.
* config/tc-arc.c (arc_md_end): Likewise.
* config/tc-i386.c (i386_md_end): Likewise.
* config/tc-loongarch.c (loongarch_md_end): Likewise.
* config/tc-ppc.c (ppc_md_end): Likewise.
* config/tc-pru.c (pru_md_end): Likewise.
* config/tc-riscv.c (riscv_md_end): Likewise.
* config/tc-tic54x.c (tic54x_md_end): Likewise.
* configure: Regenerate.
* config.in: Regenerate.

Delete rx and rl78 md_end

There isn't much point in having functions that do nothing

* config/tc-rl78.c (rl78_md_end): Delete.
* config/tc-rl78.h (md_end): Don't define.
* config/tc-rx.c (rx_md_end): Delete.
* config/tc-rx.h (md_end): Don't define.

Use ref_ptr upcasts in Python code

In some spots the Python code will do an explicit upcast of gdbpy_ref,
like:

    return gdbpy_ref<> ((PyObject *) color_obj.release ());

Now that ref_ptr allows upcasts, and because gdb's Python objects
derive from PyObject, these reshufflings can be expressed more simply.

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

Allow upcasts in gdb::ref_ptr

This patch changes gdb::ref_ptr to allow upcasts.  I.e., after this
patch, ref_ptr<Derived> can be cast to ref_ptr<Base>.

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

Don't use template for gdbpy_ref_policy

Now that gdb's Python types derive from PyObject, there's no need to
use a template for gdbpy_ref_policy.  This simplifies the code a tiny
bit.

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

gdb: switch bytes object helpers to Python limited API equivalents

* PyBytes_AS_STRING -> PyBytes_AsString
* PyBytes_GET_SIZE -> PyBytes_Size

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

gdb: switch tuple object helpers to Python limited API equivalents

* PyTuple_GET_ITEM -> PyTuple_GetItem
* PyTuple_SET_ITEM -> PyTuple_SetItem
* PyTuple_GET_SIZE -> PyTuple_Size

Unlike PyTuple_SET_ITEM(), PyTuple_SetItem() returns an integer: 0 on
success and -1 on error (e.g. IndexError). The existing code must therefore
be updated to handle this new behaviour.

Since processing now stops when PyTuple_SetItem() returns an error, some
resources (such as newly allocated tuples) must be properly deallocated in
error paths. To address this, this patch replaces the use of raw 'PyObject *'
pointers with gdbpy_ref<>, a reference-counted wrapper around 'PyObject *',
which automatically decrements the reference count on early exit.

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

PowerPC: Support for SHA2 and SHA3 Compute Instructions (RFC02654)

opcodes/
* ppc-opc.c: (insert_sr, extract_sr, insert_bl, extract_bl):
New functions.
(DMRATp, PADE, HASHT, HASHSR, PADID, PADBL, XSHAHASH, XSHA3HASH,
XSHA2HASH, XX2PAD, XX2PADE, XSHAHASH_MASK, XSHA2HASH_MASK,
XSHA3SR_MASK, XSHA3HASH_MASK, XX2PAD_MASK, XX2PADE_MASK): New defines.
(OBF, PMSK8, L, RRWn, UIM): Update for new macros.
(powerpc_opcodes): Add dmsha256hash, dmsha512hash, dmsha2hash,
dmsha3dw, dmcryshash, dmsha3hash, dmxxsha3512pad, dmxxsha3384pad,
dmxxsha3256pad, dmxxsha3224pad, dmxxshake256pad, dmxxshake128pad,
dmxxsha384512pad, dmxxsha224256pad, dmxxshapad.

gas/
* testsuite/gas/ppc/future.s: New test.
* testsuite/gas/ppc/future.d: Likewise.

Automatic date update in version.in

Revert "[gdb/testsuite] Fix gdb.base/inline-frame-cycle-unwind.exp for s390x"

This reverts commit ac9d893e3c44af942588fd1a5c694a8b8b351fb3.

(A better option for solving this problem has already been pushed.)

gdb/testsuite: Skip gdb.base/watchpoint-adjacent.exp on s390x

The watchpoint-adjacent.exp test requires both read and write hardware
watchpoints.  s390x only supports write watchpoints, causing 108 test
failures when rwatch commands fail with "Target does not support this
type of hardware watchpoint."

Add a require for allow_hw_watchpoint_access_tests to skip this test on
architectures without read watchpoint support.

Approved-By: Tom de Vries <tdevries@suse.de>

[gdb/testsuite] Fix gdb.base/inline-frame-cycle-unwind.exp for s390x

This commit fixes six failures for s390x due to a fundamental
difference in unwinding behavior between s390x and other
architectures:

FAIL: gdb.base/inline-frame-cycle-unwind.exp: bt: cycle at level 5:
  backtrace when the unwind is broken at frame 5
FAIL: gdb.base/inline-frame-cycle-unwind.exp: bt: cycle at level 3:
  backtrace when the unwind is broken at frame 3
FAIL: gdb.base/inline-frame-cycle-unwind.exp: bt: cycle at level 1:
  backtrace when the unwind is broken at frame 1
FAIL: gdb.base/inline-frame-cycle-unwind.exp: bt -no-filters: cycle at level 5:
  backtrace when the unwind is broken at frame 5
FAIL: gdb.base/inline-frame-cycle-unwind.exp: bt -no-filters: cycle at level 3:
  backtrace when the unwind is broken at frame 3
FAIL: gdb.base/inline-frame-cycle-unwind.exp: bt -no-filters: cycle at level 1:
  backtrace when the unwind is broken at frame 1

The core issue is that on s390x, the Canonical Frame Address (CFA) for
a function points *into the caller's stack frame*, whereas on x86_64
or aarch64 the CFA points *within the current function's frame*.  This
architectural difference causes cycle detection to occur later on
s390x.

The patch resolves this by:
- Making expected backtrace output architecture-specific.
- For non-s390x targets: expecting the full set of frames up to the
  specified level.
- For s390x: expecting fewer frames before detecting the cycle
  (e.g., level 5 shows 3 frames instead of 5).
- Skipping the cycle at level 1 test entirely on s390x since it cannot
  be detected at that frame.

Tested using recent Fedora releases on s390x, x86_64, and aarch64.

Return bool from some Ada type predicates

This changs some Ada type predicates to return bool.  The main user of
these, possible_user_operator_p, is also converted.

Return bool from ada-lang.c:return_match

Change ada-lang.c:return_match to return bool.

Return bool from ada_args_match

Change ada_args_match to return bool.

Return bool from ada_is_constrained_packed_array_type

Change ada_is_constrained_packed_array_type to return bool, and fix a
few small related issues along the way.

Return bool from ada_is_unconstrained_packed_array_type

Change ada_is_unconstrained_packed_array_type to return bool.

Use gdb_bfd_openr in corelow.c

corelow.c has a couple of calls to bfd_openr, each followed by a call
to new_reference.  It's cleaner to use the provided gdb_bfd_openr
wrapper.

Reviewed-By: Keith Seitz <keiths@redhat.com>

gdb/testsuite: fix printf regexp for ppc64le with glibc ieee128 fix

On ppc64le, when the compiler selects IEEE-128 long double ABI
(-mabi=ieeelongdouble), calls to printf are redirected to
___ieee128_printf.  This causes 'break printf' in GDB to never stop
at printf:
...
(gdb) break printf
Breakpoint 3 at 0x7ffff7a6b880
(gdb) continue
Continuing.
value is 7

[Inferior 1 (process 403664) exited normally]
(gdb) FAIL: gdb.base/annota1.exp: continue to printf
...

glibc fixed this by adding local symbol aliases in the ieee128
compatibility files so that the original symbol names are present in
the symbol table again (glibc commit f05ab7c4a99b).  After the glibc
fix, GDB stops at printf but the breakpoint is reported as
'Breakpoint 3.2, ___ieee128_printf' since printf now resolves to two
locations.  The current GDB test regexps do not match this output.

...
(gdb) break printf
Breakpoint 3 at 0x7ffff7a6b278: printf. (2 locations)
(gdb) continue
Continuing.

Breakpoint 3.2, ___ieee128_printf (format=0x10000970 \"value is %d\n\")
    at ../sysdeps/ieee754/ldbl-128ibm-compat/ieee128-printf.c:28
(gdb) FAIL: gdb.base/annota1.exp: continue to printf
...

This causes failures in gdb.base/annota1.exp and gdb.base/annota3.exp
because the pattern 'Breakpoint 3, ' does not match 'Breakpoint 3.2, '.
Fix this by changing 'Breakpoint 3, ' to 'Breakpoint 3.*, '.

In gdb.server/sysroot.exp the pattern '(__)?printf' does not match
'___ieee128_printf'.
Fix this by changing '(__)?printf' to '.*printf' to match any printf
variant including printf, __printf, and ___ieee128_printf,
following the same approach as previous fixes for __printf on x86_64
(commit f870f78fb2d) and printf@@GLIBC_2.17 on ppc64le (commit
29004660c94).

Tested on ppc64le, x86_64-linux.

Approved-By: Tom de Vries <tdevries@suse.de>

[gdb/record] Fix syscall recording some more

I ran into the same gdb.reverse/sigall-reverse.exp failure on ppc64le-linux,
as fixed in commits:
- commit 3686645cec9 ("[gdb/record] Fix return value for svc in
  aarch64_record_branch_except_sys"), and
- commit 4ef576bdb7f ("[gdb/record] Fix return value for syscall in
  loongarch_record_syscall_insn").

The difference with those commits is that the problem is not due to confusion
about a port-local enums (aarch64_record_result, loongarch_record_result).

Instead, the port just treats return values 1 and -1 the same:
...
  if (tdep->ppc_syscall_record (regcache) != 0)
    return -1;
...

Fix this by passing through the return value 1 instead.

Likewise on s390x-linux.

Tested on ppc64le-linux and s390x-linux.

Reviewed-by: Abhay Kandpal <abhay@linux.ibm.com>

Re: Define BFD_ASAN to detect asan

Avoid a complaint from older preprocessors about a "missing binary
operator" between an undefined __has_feature macro and its parameter.

aarch64 gas: use bool return type for sub-option parsing

The signature of the functions used to decode sub-options mirrors that
of md_parse_option(). They currently return an integer, but the return
value is always set to 0 on failure and 1 on success, which exactly
matches boolean semantics.
These functions likely predate C99 as the minimum supported C standard
in binutils. Today, there is no good reason to keep this legacy interface
instead of using a proper boolean type.

This patch updates the sub-option parsing functions to return a boolean
and adjusts the corresponding code accordingly.

Automatic date update in version.in

Define BFD_ASAN to detect asan

Remove obsolete comment from solib_bfd_fopen

I noticed an out-of-date comment in solib_bfd_fopen.

gdb/infrun: do not restart a stepped thread if not running

Suppose we have two inferiors on an all-stop target with schedule-multi
set on:

  $ gdb -q
  (gdb) target extended-remote | gdbserver --multi -
  Remote debugging using | gdbserver --multi -
  Remote debugging using stdio
  (gdb) file /temp/test
  Reading symbols from /temp/test...
  (gdb) set remote exec-file /temp/test
  (gdb) start
  Temporary breakpoint 1 at 0x115c: file test.c, line 8.
  Starting program: /temp/test
  stdin/stdout redirected
  Process /temp/test created; pid = 864027
  ...

  Temporary breakpoint 1, main (argc=1, argv=0x7fffffffd218) at test.c:8
  8         foo();
  (gdb) add-inferior
  [New inferior 2]
  Added inferior 2 on connection 1 (extended-remote | gdbserver --multi -)
  (gdb) inferior 2
  [Switching to inferior 2 [<null>] (<noexec>)]
  (gdb) file /temp/test
  Reading symbols from /temp/test...
  (gdb) set remote exec-file /temp/test
  (gdb) tbreak 2
  Temporary breakpoint 2 at 0x555555555131: /temp/test.c:2. (2 locations)
  (gdb) run
  Starting program: /temp/test
  stdin/stdout redirected
  Process /temp/test created; pid = 864430
  ...

  Thread 2.1 "test" hit Temporary breakpoint 2, foo () at test.c:2
  2         int a = 42;
  (gdb) set schedule-multi on
  (gdb)

At this point, detaching the first inferior works fine:

  (gdb) detach inferiors 1
  Detaching from program: /temp/test, process 858904
  Detaching from process 858904
  [Inferior 1 (process 858904) detached]
  (gdb) info inferiors
    Num  Description       Connection                                Executable
    1    <null>            1 (extended-remote | gdbserver --multi -) /temp/test
  * 2    process 858925    1 (extended-remote | gdbserver --multi -) /temp/test
  (gdb)

Let us now repeat exactly the same scenario, but before detaching, we
make the current thread single-step an instruction:

  ...
  Thread 2.1 "test" hit Temporary breakpoint 2, foo () at test.c:2
  2         int a = 42;
  (gdb) stepi
  3         int b = 43;
  (gdb) detach inferiors 1
  Detaching from program: /temp/test, process 876580
  Detaching from process 876580
  gdbserver: Couldn't reap LWP 876580 while detaching: No child processes
  [Inferior 1 (process 876580) detached]
  (gdb) [Switching to Thread 877351.877351]
  3   int b = 43;

There is a mysterious line info output.  Running the scenario with
infrun debug logs reveals more information.

  ...
  Thread 2.1 "test" hit Temporary breakpoint 2, foo () at test.c:2
  2         int a = 42;
  (gdb) stepi
  3         int b = 43;
  (gdb) set debug infrun on
  (gdb) detach inferiors 1
  [infrun] scoped_disable_commit_resumed: reason=detaching
  [infrun] scoped_disable_commit_resumed: reason=detaching
  Detaching from program: /temp/test, process 3537498
  Detaching from process 3537498
  gdbserver: Couldn't reap LWP 3537498 while detaching: No child processes
  [Inferior 1 (process 3537498) detached]
  [infrun] reset: reason=detaching
  [infrun] start_step_over: enter
    [infrun] start_step_over: stealing global queue of threads to step, length = 0
    [infrun] operator(): step-over queue now empty
  [infrun] start_step_over: exit
  [infrun] restart_stepped_thread: switching back to stepped thread (stepping)
  [infrun] keep_going_stepped_thread: resuming previously stepped thread
  [infrun] keep_going_stepped_thread: expected thread advanced also (0x555555555131 -> 0x555555555138)
  [infrun] clear_step_over_info: clearing step over info
  [infrun] do_target_resume: resume_ptid=-1.0.0, step=0, sig=GDB_SIGNAL_0
  [infrun] infrun_async: enable=1
  [infrun] reset: reason=detaching
  [infrun] maybe_set_commit_resumed_all_targets: enabling commit-resumed for target extended-remote
  [infrun] maybe_call_commit_resumed_all_targets: calling commit_resumed for target extended-remote
  (gdb) [infrun] fetch_inferior_event: enter
    [infrun] scoped_disable_commit_resumed: reason=handling event
    [infrun] do_target_wait: Found 2 inferiors, starting at #0
    [infrun] random_pending_event_thread: None found.
    [infrun] print_target_wait_results: target_wait (-1.0.0 [process -1], status) =
    [infrun] print_target_wait_results:   3537875.3537875.0 [Thread 3537875.3537875],
    [infrun] print_target_wait_results:   status->kind = STOPPED, sig = GDB_SIGNAL_TRAP
    [infrun] handle_inferior_event: status->kind = STOPPED, sig = GDB_SIGNAL_TRAP
    [infrun] context_switch: Switching context from 0.0.0 to 3537875.3537875.0
    [infrun] handle_signal_stop: stop_pc=0x555555555138
    [infrun] handle_signal_stop: [3537875.3537875.0] hit its single-step breakpoint
    [infrun] handle_signal_stop: delayed software breakpoint trap, ignoring
    [infrun] process_event_stop_test: stepi/nexti
    [infrun] stop_waiting: stop_waiting
  [Switching to Thread 3537875.3537875]
  3       }
    [infrun] infrun_async: enable=0
    [infrun] reset: reason=handling event
    [infrun] maybe_set_commit_resumed_all_targets: not requesting commit-resumed for target extended-remote, no resumed threads
  [infrun] fetch_inferior_event: exit

GDB attempted to do a step-over for the current thread.  This takes us
to the commit that introduced restarting step-overs:

  commit 408f66864a1a823591b26420410c982174c239a2
  Author: Pedro Alves <pedro@palves.net>
  Date:   Mon Jan 11 20:01:58 2021 +0000

    detach in all-stop with threads running

    A following patch will add a testcase that has a number of threads
    constantly stepping over a breakpoint, and then has GDB detach the
    process, while threads are running.  If we have more than one inferior
    running, and we detach from just one of the inferiors, we expect that
    the remaining inferior continues running.  However, in all-stop, if
    GDB needs to pause the target for the detach, nothing is re-resuming
    the other inferiors after the detach.  "info threads" shows the
    threads as running, but they really aren't.  This fixes it.

However, the thread that was resumed for step-over in our scenario did
not have an interrupted step-over; it had completed its stepi already.
More debugging reveals that the thread is resumed because of the
following two conditions in `restart_stepped_thread`:

      if (tp->control.trap_expected)
        {
          infrun_debug_printf ("switching back to stepped thread (step-over)");

          if (keep_going_stepped_thread (tp))
            return true;
        }

and

      if (tp->control.step_range_end)
        {
          infrun_debug_printf ("switching back to stepped thread (stepping)");

          if (keep_going_stepped_thread (tp))
            return true;
        }

The root cause of the problem is, `restart_stepped_thread` checks for
the thread state as

    if (tp->state == THREAD_EXITED)
      continue;

but the thread's state is THREAD_STOPPED.  To fix, we change the state
check to

    if (tp->state != THREAD_RUNNING)

Additionally, the 'trap_expected' and the 'step_range_end' fields of
the thread's control remain set even after the "stepi" command
completes, creating a half-baked internal state that can be misleading
when debugging.  We address this problem by clearing the control
fields when stepping completes.  We also add a regression test.

Regression-tested on X86_64 Linux using the default, native-gdbserver,
and native-extended-gdbserver board files.

Tested-By: Guinevere Larsen <guinevere@redhat.com>
Approved-by: Kevin Buettner <kevinb@redhat.com>

gdb/linux-tdep: pass string by reference

Sonarqube in me IDE pointed out this "const string" parameter that
should be a reference.  I then looked at the callers, and saw that one
would pass `.c_str()`, causing an unnecessary copy, and the other using
std::move unnecessarily.

Change-Id: I29a84a9d2fad79ac68a66a95553a30173fa3544c

Automatic date update in version.in

[pre-commit] Bump isort to 8.0.1

Ran "pre-commit autoupdate".  No changes in formatting.

Automatic date update in version.in

xcofflink buffer overflows

This fixes two fuzzed object file out-of-bounds accesses.

* xcofflink.c (xcoff_link_add_symbols): Properly bounds check
XTY_LD x_scnlen index.  Sanity check r_symndx before using it
to index sym hashes.

Automatic date update in version.in

Use bool for "warn_if_slow"

A few places still used int for the type of the 'warn_if_slow' flag.
This fixes all these spots.

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

Use enum types for remote fileio flags

This changes gdbsupport/fileio.h to use enums with underlying types
for the various constants -- open flags, modes, and lseek flags.
These types replace #defines that were previously used.

Then, this fixes all the users of these flags.  This found a few bugs.
Some of these were pedantic (using the constant 0700 where perhaps
FILEIO_S_IRWXU would be more precise), but sparc64-tdep.c confused
host and remote flags.

Also, I believe solib-rocm.c had a couple of arguments in the wrong
order.

I also found that gdb/remote-fileio.c had essentially duplicated some
code from gdbsupport.  This patch removes the duplicates.

New in v2:
- The lseek enum is anonymous, the type itself isn't used, just
  the constants

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

Use a newtype for remote file descriptor

I was digging through the remote fd code and got a little confused at
some point about what kind of fd was used where.

It seemed better to me to avoid any confusion by making the remote
file descriptor a newtype, i.e., incompatible with 'int'.

I limited the change to the "public" API.  That is, I let the file
descriptor as used by the actual target implementation methods remain
"int".

This found one bug, namely that sparc64-tdep.c assumed that 0 was an
invalid value for a target fd.

New in v2:
- solib-rocm.c compiles now
- Renamed to target_fd (including scoped_target_fd)

New in v3:
- Renamed scoped_target_fd back in remote.c

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

Avoid minimal language when DW_LANG_HIP is used.

AMD clang is going to start using DW_LANG_HIP instead of
DW_LANG_C_plus_plus_14 (see PR at
https://github.com/llvm/llvm-project/pull/181738). Rather than
falling back to the minimal language, this commit ensures that
GDB will still treat it like a C++ app. The commit also adds
a test to an existing one.

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

Use the "O!" format more in the Python code

I noticed a few spots in the Python code that were decoding method
arguments and then immediately type-checking an argument.  This can be
done more concisely using the "O!" format.

Reviewed-By: Tom de Vries <tdevries@suse.de>

gdb: Add myself to gdb/MAINTAINERS

Compute register name once in default_print_one_register_info

PR gdb/9884 points out that default_print_one_register_info could call
gdbarch_register_name a single time.  The current code seems harmless
but OTOH the proposed change is also harmless and perhaps slightly
faster, so why not.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=9884
Approved-By: Tom de Vries <tdevries@suse.de>

libctf: remove CTF_F_ARRNELEMS flag

This patch removes the constraint that a CTF_F_ARRNELEMS flag has to be
present in order to reverse the elements of an array when dumping. The
flag was never added to GCC, and having this requirement causes more
problems than it solves. A quick recap of the issue:

Given an array int foo[1][2][3], the expected graph is:
int foo[1][2][3] -> int foo[2][3] -> int foo[3] -> int foo

Prior to GCC PR114186, the emitted graph would be:
int foo[1][2][3] -> int foo[1][2] -> int foo[1] -> int foo

Following GCC PR114186, before the libctf fix, the output was:
int foo[3][2][1] -> int foo[3][2] -> int foo[3] -> int foo
So the underlying type graph was correct, but the ordering of elements
was incorrect.

With this fix, we emit correct ordering of the type graph, with no
requirements for the compiler to signal that it has GCC PR114186.

include/
* ctf.h (CTF_F_ARRNELEMS): Delete.
(CTF_F_MAX): Adjust.

libctf/
* ctf-decl.c (ctf_decl_push): Act as if CTF_F_ARRNELEMS is
always set.
* ctf-dump.c (ctf_dump_header): No longer dump its value.
* testsuite/libctf-lookup/multidim-array.c: No longer detect
compilers not emitting this flag (none do).

libctf: allow ctf_arc_bufpreamble to fail

The recent libctf fix for ctf_arc_bufpreamble missed a case:
what if the input is exactly sizeof (ctf_archive_t) in size (which can
happen if the archive has no members at all, so returning the preamble
from one of the members is in any case impossible?).  In this case
it'll return an off-the-end pointer, and its caller will overrun.
(This can also happen with fuzzed input which has a valid magic
number.)

Allow it to fail in this case, returning NULL, and adjust its sole
caller.  The caller's conclusions in this case will be wrong (it will
conclude that the archive is connected to .symtab), but the incorrect
conclusions are harmless because the lack of archive members will
immediately cause a failure in ctf_arc_bufopen(), and an error return.

Thanks to Alan Modra for the original fix this soups up.

libctf/
PR libctf/33548

* ctf-archive.c (ctf_arc_bufpreamble): Fail if the archive is
too short (or empty, with no dicts to contain preambles),
returning NULL.
* ctf-open-bfd.c (ctf_bfdopen_ctfsect): Handle a NULL return.

gdb: switch sequence protocol helpers to Python limited API equivalents

* PySequence_ITEM -> PySequence_GetItem

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

PR 33743 readelf abort during RELR relocation handling

Rather than aborting, use "unknown relative" as the reloc type should
display_elf_relocation_at want to print a relocation.  Also fix
another case where readelf doesn't understand the relocation and sets
all_relocations[i].r_name to NULL.

PR 33743
* readelf.c (dump_relr_relocations): Don't abort on unknown
e_machine.
(dump_relocations): Don't assume we can pass NULL to a %s
format.

[pre-commit] Bump isort to 8.0.0

Ran "pre-commit autoupdate".  No changes in formatting.

gas: use get_single_number() in get_linefile_number()

We don't really want to handle expressions there, we want plain numbers.

PPC: improve handling of improper "kind-of-register" operands

A unary % is expected to be followed by a register. While this is being
diagnosed as "bad expression", a 2nd error then follows ("syntax error;
found ..."). Consume the % in md_operand() (thus preventing it to be
treated as modulus with missing [i.e. implicitly 0] leading operand) and
mark the expression O_illegal (thus avoiding the "bad expression") when
the "register" is unrecognized.

Reviewed-by: Peter Bergner <bergner@tenstorrent.com>

PPC: ignore rest of line after earlier error

If the operand parsing loop exits prematurely (due to an error), don't
report a second error for the unparsed remainder.

Reviewed-by: Peter Bergner <bergner@tenstorrent.com>

Use check_typedef in two spots

I found a couple of spots that were manually unwrapping typedefs.
This won't work properly if a stub type is involved.

This patch changes these places to use check_typedef.  I have no way
to test these targets though.

Reviewed-By: Tom de Vries <tdevries@suse.de>

Automatic date update in version.in

sim: fix a few -Wdiscarded-qualifiers errors

Change-Id: I5caaf741a6d3835d593e62c3a567171c09d6241c

[gdb] Fix typo recordered -> recorded

Fix the typo recordered -> recorded, and add it to the local dictionary.

While we're at it, fix "must be equal <n> bytes" -> "must be equal to <n>
bytes".

[gdb/record] Fix return value for syscall in loongarch_record_syscall_insn

This is the loongarch version of commit 3686645cec9 ("[gdb/record] Fix return
value for svc in aarch64_record_branch_except_sys").

Approved-By: Tiezhu Yang <yangtiezhu@loongson.cn>
Tested-by: Tiezhu Yang <yangtiezhu@loongson.cn>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33924

Work around gcc-4.9 bug

Commit 893eb49c9b12 exposed a gcc-4.9 build error, with gcc-4.9
erroneously complaining that F_MIN_SUBSECTION_DATA_LEN has a
non-constant initialisation.

* readelf.c (F_MIN_SUBSECTION_DATA_LEN): Use #define to work
around gcc-4.9 bug.
(F_SUBSECTION_LEN, F_SUBSECTION_COMPREHENSION),
(F_SUBSECTION_ENCODING): Use #define here too.
(elf_parse_attrs_subsection_v2): Adjust format string.

same-inode.h: don't depend on _GL_WINDOWS_STAT_INODES

It looks like assuming _GL_WINDOWS_STAT_INODES is 1 is likely our best
option.  See gnulib/m4/windows-stat-inodes.m4.  Note that this doesn't
really make SAME_INODE usable on windows hosts as a number of the
likely filesystems (FAT, HPFS, or NTFS) don't support st_ino.

* same-inode.h (SAME_INODE <_WIN32>): Remove _GL_WINDOWS_STAT_INODES
test.  Assume it is true.

Automatic date update in version.in

gdb: limit updating the address spaces to the current target

For the `update_address_spaces` function, there is this comment:

   It is assumed that there are no bound inferiors yet, otherwise,
   they'd be left with stale referenced to released aspaces.

The function indeed iterates over all inferiors and resets their
address spaces.  The function has only one caller:
remote_target::start_remote_1.  This means, if we already have an
inferior and then start a remote target in a second inferior, we may
alter the address space of the first inferior.  It seems the current
code is a left-over from pre-multi-target days.  To prevent bad things
from happening, update the address spaces for a given target only.

A scenario where unwanted behavior occurs is as follows: Start a
multi-threaded program in non-stop mode.  Hit a breakpoint with a
thread.  Create a second inferior on a remote target.  Switch back to
inferior 1.  Continuing repeatedly hits the breakpoint.  See below.

  $ gdb /tmp/multi-thread
  Reading symbols from /tmp/multi-thread...
  (gdb) set non-stop on
  (gdb) break 30
  Breakpoint 1 at 0x151e: file multi-thread.cpp, line 30.
  (gdb) run
  Starting program: /tmp/multi-thread
  [Thread debugging using libthread_db enabled]
  Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
  [New Thread 0x7ffff7a4f640 (LWP 3413070)]
  [New Thread 0x7ffff724e640 (LWP 3413071)]
  [New Thread 0x7ffff6a4d640 (LWP 3413072)]
  [New Thread 0x7ffff624c640 (LWP 3413073)]

  Thread 1 "multi-thread" hit Breakpoint 1, main (argc=1, argv=0x7fffffffdec8) at multi-thread.cpp:30
  30        int x = 42;
  (gdb) add-inferior -no-connection
  [New inferior 2]
  Added inferior 2
  (gdb) inferior 2
  [Switching to inferior 2 [<null>] (<noexec>)]
  (gdb) target extended-remote | gdbserver --multi -
  Remote debugging using | gdbserver --multi -
  Remote debugging using stdio
  (gdb) inferior 1
  [Switching to inferior 1 [process 3413067] (/tmp/multi-thread)]
  [Switching to thread 1.1 (Thread 0x7ffff7a50740 (LWP 3413067))]
  #0  main (argc=1, argv=0x7fffffffdec8) at multi-thread.cpp:30
  30        int x = 42;
  (gdb) continue
  Continuing.

  Thread 1.1 "multi-thread" hit Breakpoint 1, main (argc=1, argv=0x7fffffffdec8) at multi-thread.cpp:30
  30        int x = 42;
  (gdb) continue
  Continuing.

  Thread 1.1 "multi-thread" hit Breakpoint 1, main (argc=1, argv=0x7fffffffdec8) at multi-thread.cpp:30
  30        int x = 42;
  (gdb) continue
  Continuing.

  Thread 1.1 "multi-thread" hit Breakpoint 1, main (argc=1, argv=0x7fffffffdec8) at multi-thread.cpp:30
  30        int x = 42;
  (gdb)
  ...

It was not possible to simplify the bug reproducer.  For some reason,
simplifications make observable problems go away.  Adding the case
above as a testcase.

Regression-tested in Linux x86-64 with the default, native-gdbserver,
and native-extended-gdbserver board files.

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

Fix even more -Wdiscarded-qualifers issues

Fedora Rawhide is failing to build due to new glibc header changes
enforcing const-correctness in functions like strchr and memchr.
For example:

../../opcodes/aarch64-dis.c: In function ‘remove_dot_suffix’:
../../opcodes/aarch64-dis.c:4027:7: error: assignment discards ‘const’ qualifier from po
inter target type [-Werror=discarded-qualifiers]
 4027 |   ptr = strchr (inst->opcode->name, '.');
      |       ^
cc1: all warnings being treated as errors

This patch addresses all the discovered issues with --enable-targets=all
and regenerates a few cgen files along the way.

gdb: convert 'debug skip' to the new(ish) debug scheme

Convert 'set debug skip' to use the newer debug scheme.

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

gdb: more styling for skip command output

Add function and file styling to output of the 'skip', 'skip file',
and 'skip function' commands.

I did worry a little about this case:

  (gdb) skip -gfile *.c
  File(s) *.c will be skipped when stepping.

After this change the '*.c' will be given file_name_style, even though
it's not an actual filename, but a filename glob.

However, if you do this:

  (gdb) info skip
  Num   Enb Glob File                 RE Function
  1     y      y *.c                   n <none>

Then the '*.c' is already (even before this patch) given
file_name_style, so if nothing else, my change makes things
consistent.  And personally, I think it's OK to style the '*.c'.

There's a similar issue with 'skip -rfunction PATTERN' where the
PATTERN will be styled in the output with function_name_style even
though it's not an actual function name.  As with the filename case
PATTERN is already styled in the 'info skip' table, so I think the
change in this commit is consistent if nothing else.

There should be no functional change after this commit; just improved
styling.

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

gdb: option completion for the 'skip' command

This commit adds proper option completion for the 'skip' command, the
skip_command function (skip.c) has been rewritten as a consequence.
All the existing functionality should have been retained, though some
of the error messages have changed as we now get the errors generated
by the option parsing code rather than the ones from skip_command.

I've added more skip tests to cover error cases that were not
previously tested.  And I've added a test for 'skip FUNCTION_NAME'
which was previously untested.

Consider the -gfile option for the skip command.  Previously the skip
command was hard coded to accept -gfile or -gfi, these were aliases.
But you couldn't pass -gfil.  Now we've switched to the general option
handling routine the only option is -gfile, but our option handling
code will accept any partial option name that uniquely identifies an
option, so -g, -gf, -gfi, -gfil, and -gfile are all valid, and all
aliases of each other.  The same is true for all the options that skip
accepts.

Because of this I've gone through and removed all references to the
short form option names that I can find.  Now that tab-completion
works, there's no need to advertise specific short form names, and as
discussed above, all unique short forms are still valid.

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

gdb: aliases for some skip related commands

Skips are created using 'skip', 'skip file', or 'skip function', then
managed with 'skip enable', 'skip disable', and 'skip delete'.

This is slightly different to other things, for example breakpoint,
where we have a command to create the thing, e.g. 'break', but then we
have 'enable breakpoints', 'disable breakpoints', and 'delete
breakpoints' to manage the thing.

If you tab-complete on any of the 'enable', 'disable', or 'delete'
prefix commands you'll find these are used to manage a whole bunch of
different types of thing.

When I started playing with skips, my instinct, given the existing
patterns in GDB, was to try 'enable skip', 'disable skip', and 'delete
skip', and it surprised me that these didn't work.

But notice we do have 'info skip' rather than 'skip info'.  So the
"normal" pattern does apply in some cases.

In this commit I propose that we create aliases 'enable skip',
'disable skip', and 'delete skip' which just alias back to the
existing commands.  We cannot delete the existing commands for fear of
breaking existing user scripts.

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

gdb: implement "info proc environ"

Add a new "environ" subcommand to "info proc" to print the initial
environment variables of a given process.  The environment variables
are printed line-by-line and are indented by two spaces, so that they
can be distinguished from the rest of the output in "info proc all".

Note that the information printed by this new command is not
necessarily the same as `show environment`, which lists the
environment variables that will be given to the program next time it
is started under GDB.  The two information may differ in particular
when GDB attached to a running program that was started in an
environment different than GDB's.

Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Andrew Burgess <aburgess@redhat.com>

gdb: remove 'num' field from 'struct address_space'

The getter method `num ()` in `struct address_space` is never used.
Remove it.  This leads to two more simplifications: (1) the
address_space constructor can be defaulted in the header, (2)
`highest_address_space_num` global counter is no longer needed and can
be removed.

Tested by re-building.

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