Automatic date update in version.in

gdb/python: new events.corefile_changed event

Add a new Python event registry, events.corefile_changed.  This event
is emitted each time the corefile within an inferior changes.

The event object has a single 'inferior' attribute which is the
gdb.Inferior object for which the core file changed.  The user can
then inspect Inferior.corefile to see details about the new core file,
or this will be None if the core file was removed from the inferior.

I've updated the existing test to cover this new event.

The new test covers both the corefile_changed event, but also monitors
the exited event.  This ties into the work done in the previous
commit where we use whether the inferior has exited or not as a guard
for whether core_target::exit_core_file_inferior should be called.
Unloading a core file should result in a single corefile_changed event
and a single exited event.

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

gdb: refactor core_target ::close and ::detach functions

This patch refactors the core_target ::close, ::detach, and
::clear_core functions so that the m_core_bfd is not cleared before
the core_target is deleted.

My motivation for this change is the get_inferior_core_bfd function.
This function checks to see if an inferior has a core_target in its
target stack, if it does then there is an assert that the
core_target's m_core_bfd will not be NULL.

Currently, this assert is mostly correct, but during a call to
target_detach, the assert stops being true.  Calling target_detach
will call core_target::detach, which calls core_target::clear_core,
which sets m_core_bfd to NULL.  The core_target is not unpushed from
the inferior's target stack until GDB returns from ::clear_core back
to ::detach.  This means that, for a short period of time, from the
moment m_core_bfd is set to NULL in ::clear_core, until the unpush
back in ::detach, the assertion in get_inferior_core_bfd is no longer
valid.

Within this window we trigger the core_file_changed observer.  If any
of the observers call get_inferior_core_bfd then the assertion will
trigger.

Currently, no observer calls get_inferior_core_bfd, the observer just
clears some caches.  However, in the next commit I'd like to add a new
Python event API for when the core file is changed.  User code
attached to this event can call Inferior.corefile, which is
implemented by a call to get_inferior_core_bfd, and in this case the
assert will trigger.

I could just delete the assertion, but I'd prefer to not do that.  I
think by restructuring the code we can leave the assertion in place.

The first thing to understand is that a core_target is not shareable,
see process_stratum_target::is_shareable.  This means that a
core_target will only appear within a single inferior's target stack.

Next there are two ways that a core_target can be removed from an
inferior's target stack.  First is via target_detach, this is
triggered either by the 'detach' command, or by the 'core-file'
command without a core filename.  In both these cases target_detach is
called, which calls core_target::detach, this function unpushes the
core_target from the inferior's target stack.  As the core_target is
not shareable the reference count will return to zero, at which point
the core_target will be closed and deleted.

The second way that a core_target can be removed from an inferior's
target_stack is by direct replacement.  If a user loads a different
process_stratum_target, e.g. 'target remote ....' then this replaces
the core_target in the target_stack.  Doing this reduces the
core_target's reference count to zero, which causes the target to be
closed and deleted.

These two approaches differ in that the first calls
core_target::detach and then core_target::close, while the second
avoids calling ::detach, and immediately calls ::close.

My proposal is that we can defer calling the core_file_changed
observer until core_target::close.  By this point the core_target will
have been removed from the inferior's target_stack, and so the assert
in get_inferior_core_bfd will still hold.  We already call the
observer at this point for the process_stratum_target replacement
case (e.g. when a user does 'target remote ...' to replace a core file
target), this proposal would just mean that we always call the
observer at this point, rather than potentially calling it earlier in
the detach case.

This commit does this change by making a number of changes:

  * The code to reset m_core_bfd to NULL, and to trigger the
    core_file_changed observer, is removed from core_target::clear,
    this only leaves the code relating to exiting and cleaning up
    after the inferior that was created for inspecting the core file.

  * To reflect this change of focus, core_target::clear_core is
    renamed to core_target::exit_core_file_inferior.

  * In core_target::detach, nothing really needs to change other than
    calling ::exit_core_file_inferior.  I have added an assert that
    reflects the fact that ::detach cannot be called twice on the same
    core_target (after the first call the core_target will always be
    closed and deleted).

  * In core_target::close the call to ::exit_core_file_inferior needs
    to be conditional.  As discussed above, in the replacement case,
    ::close can be called without first calling ::detach.  But in the
    target_detach case, ::detach will have already been called, and as
    a result ::exit_core_file_inferior will have already been called.

  * Also in core_target::close, we now unconditionally trigger the
    core_target_changed observer.

This commit is a refactor, and there should be no user observable
changes.

gdb: delete some unnecessary code from core_target::detach

This commit removes some unnecessary code from core_target::detach.

When a core_target is created the core BFD (m_core_bfd) is set, and
will never be NULL.  The m_core_bfd remains set until either
core_target::detach or core_target::close is called.

The core_target::close function is only called when the refcount of a
core_target reaches zero, the core_target::close function deletes the
core_target, so we know that after calling core_target::close no other
core_target member functions will be called (as the core_target will
have been deleted).

The core_target::detach function is called as a result of calling
target_detach, which is called as a result of either the 'detach'
command, or the 'core-file' command (without passing a file name).

As a core_target is not shareable (see
process_stratum_target::is_shareable), once a core_target is detached,
its reference count will eventually reduce to zero (a reference is
temporarily held in target_detach), and then it will be closed and
deleted.

What this means is that there is absolutely no way that a core_target
can ever be detached twice, not that such a thing would make much
sense, but it cannot happen.

Understanding this we can know that when core_target::detach is called
m_core_bfd will never be NULL, I've added an assert for this case.

Given this assert, if we look at core_target::clear_core, which
core_target::detach calls, we can see that exit_inferior will always
be called.  If we look at exit_inferior (in inferior.c) we see that
the last two actions of that function are:

  /* Clear the register cache and the frame cache.  */
  registers_changed ();
  reinit_frame_cache ();

Which are also two of the last three actions of core_target::detach.
Clearly the calls in core_target::detach are redundant.

Just for good measure, if we look in target_detach, from where
core_target::detach will have been called, just before the function
returns we have:

  registers_changed_ptid (proc_target, save_pid_ptid);
  reinit_frame_cache ();

The registers_changed_ptid call is slightly more restrictive, only
clearing the register cache for the target being detached, but that
should be good enough -- I think exit_inferior could probably be
changed to call registers_changed_ptid for the inferior that exited,
but that's a problem for another day.

What this all tells me is that the registers_changed call and the
reinit_frame_cache call in core_target::detach are unnecessary, and
can be deleted, which is what this patch does.

Given I was making changes in core_target::detach, I've taken this
opportunity to update an out of date comment.  The comment talked
about 'this' possibly becoming dangling, however, this was never the
case as target_detach holds a reference to the target, preventing it
from being deleted until target_detach returns.

There should be no user visible changes after this commit.

Remove OBJSTAT and OBJSTATS macros

The OBJSTATS macro seems pretty pointless, so I removed it.  Then when
looking at the OBJSTAT macro as well, I decided to remove it and also
struct objstats.

After this patch, symbols are allocated using a template method that
automatically updates the n_syms member.  This cleans up the code a
little.

Also, nothing ever set objstats::sz_strtab, so this is removed.

Regression tested on x86-64 Fedora 43.

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

Rename context_stack and make it private

"context_stack" has been misnamed at least since the storage was
changed to a std::vector, and arguably even since the very beginning.

This patch renames it to "lexical_context", which is a bit closer to
what is is for.

This type is also no longer used outside of buildsym itself -- callers
can now push and pop contexts, but they don't act on the context
object itself.  So, the type is made private.

One benefit of this approach is that callers no longer need to be
quite as careful -- previously there was at least a possibility that a
context object pointer would be invalidated when pushing and popping
the stack.

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

Return void from buildsym_compunit::push_context

There is one caller that uses the result of
buildsym_compunit::push_context.  This patch changes this method to
return void and changes that spot to instead call a new methods on
buildsym_compunit.

This patch also removes the get_current_context_stack method in favor
of a new method that checks the exact condition needed by the one
caller.

This patch enables a subsequent cleanup; in particular now the
'context_stack' type isn't used outside of buildsym.

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

Change pop_context to return a block

This changes buildsym_compunit::pop_context to create and return the
block, if needed.  It also arranges to reset some fields in the
buildsym_compunit object to their saved values.

This also enables the removal of the set_local_using_directives
method.

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

Remove context_stack::depth

context_stack::depth is never used, and I think it's not really
useful, so this removes it.

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

Remove some dead code from buildsym.c

This patch removes some code from buildsym.c that, according to the
comment, was only used for some SCO or maybe COFF thing.  This code is
dead now, and it was a hack anyway and probably should never have been
allowed.

In v2 I've removed the entire block, since callers should be pairing
pushes and pops anyway.

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

Use scoped_restore for dwarf2_cu::list_in_scope

Some functions in the DWARF reader temporarily set
dwarf2_cu::list_in_scope and then reset it when returning.  This patch
changes these spots to use scoped_restore.

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

gdb, testsuite: fix regression in gdb.multi/multi-{exit, kill}.exp

Commit d19862435df418a2ec78d078048f54d115c67a66 ("gdbserver:
require_running_or_break for the 'z' and 'vCont' packets") introduced
regressions in gdb.multi/multi-exit.exp and gdb.multi/multi-kill.exp.

If the remote target has multiple inferiors and is resumed with
schedule-multi on, all processes may terminate, making the target have
no threads left.  The target reports termination events to GDB.  GDB
processes the first event and attempts to stop all processes.  For
this, it sends 'vCont;t' packets to the target.  But the patch mentioned
above required the target to be in a running state, which is not true
anymore.  Therefore, target responds with an error.

Fix the regression by reverting the 'require_running_or_return'
enforcement for vCont.

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

x86/Intel: make PC-relative expressions work (again?)

Associating fixups with too complex expressions will prevent the detection
and conversion of expressions which are actually PC-relative. Such a
situation can arise when converting O_index expressions: An extra O_add
(with a constant) or O_symbol is already "too complex", let alone an
O_multiply by zero.

x86/Intel: don't modify equates' expressions

Equates involving registers were mis-treated when parsing insn operand
expressions: When "pulling out" the register(s), they would have got
converted to O_constant. While other (local) parsing code was able to cope
with this, the generic part of the assembler was misled. A visible bad
effect would be that local absolute symbols would appear in the symbol
table, when really that should be register symbols (which wouldn't be put
in the symbol table at all).

Clone symbols / expressions as necessary before modifying them.

gas: don't lose addend in snapshot_symbol() when hitting a local symbol

Unlike the one in PR gas/20941, input doesn't need to be entirely bogus
for a local symbol to appear here: Local symbols can be created for
various reasons. If we find one, we have to take exp.X_add_number into
account. Plus, like for "normal" symbols, we should not add in the
symbol's value if the result (in resolve_expression()) is still going to
be O_symbol: The returned value then is relative to the returned symbol.

gas: don't fail due to local register symbols

The diagnostic text as well as its origin are pretty clear: This is about
global symbols. This is further supported by S_IS_LOCAL() returning true
for symbols in reg_section. Add the missing check, adjusting the testcase
that was introduced back at the time (where the sole diagnostic originally
issued was therefore wrong, while other diagnostics were missing, but got
added thanks to work done elsewhere). Further drop the bogus trailing .equ
in another testcase, which were apparently put there to avoid tripping
this or some other undue check (albeit no error surfaced there already
before the change here).

While there also fully eliminate the redundant "sname": There's "name"
already, getting set up a little earlier.

m32r hi/lo reloc offset sanity checks

This fixes another fuzzer attack.

* elf32-m32r.c (m32r_elf_hi16_reloc): Properly check reloc offset.
(m32r_elf_relocate_hi16): Add input_section param.  Return status.
Sanity check reloc offsets before accessing section contents.
Simplify sign extension.
(m32r_elf_lo16_reloc): Sanity check reloc offset.  Simplify
sign extension.  Remove unnecessary casts.
(m32r_elf_relocate_section): Adjust m32r_elf_relocate_hi16 calls.

gas: segfault in out_debug_str

Another fuzzer fix.  I don't care to emit diagnostics for silly input,
so haven't done so here.

* dwarf2dbg.c (out_debug_str): Don't segfault on NULL file name.

Don't create got in bfin_relocate_section

Commit 7a84e3daf81a created .got in relocate_section which according
to https://sourceware.org/pipermail/binutils/2008-February/055281.html
was to "fix a crash when linking incompatible object files (normal
vs. FD-PIC)".  I can see how that happens by inspecting the two
check_relocs functions, and note that Bernd's change to
merge_private_bfd_data will cause a linker error on trying to link
incompatible ABI objects before relocate_section is reached.  However
a user can silence the error with --no-warn-mismatch.  It is far too
late to be creating sections in relocate_sections.  They won't be
output.

* elf32-bfin.c (bfin_relocate_section): Do not create .got
here to avoid a segfault.  Instead report an unresolvable
relocation error if .got has not already been created.

tc-i386.c s_insn and input_line_pointer

A comment in check_Scc_OszcOperations says:
      /* No need to save/restore input_line_pointer; that's done in the
 caller already.  */
That isn't true always.  Fix a case where input_line_pointer is not
restored and ignore_rest_of_line() accesses a wild pointer.

* gas/config/tc-i386.c (s_insn <bad>): Restore input_line_pointer.

Automatic date update in version.in

gas: don't allow single quote to go past eol

Fuzzers have found a testcase where expr() runs off the end of a strdup
buffer created in tc-i386.c check_Scc_OszcOperations.
printf '\"\000.insn EVEX  {scc='\''\000' > test.s

This patch fixes the overrun, and another parsing error that has
existed since commit 219deb70ce2c.  gas/testsuite/gas/mri/float.s
doesn't exercise that mri mode code path.

* expr.c (operand): Don't increment input_line_pointer past
end of line/statement when single quote appears at the end of
a line.  Don't increment input_line_pointer before mri mode
':' hex float.

gdb/ser-unix: add POSIX cfsetispeed/cfsetospeed support for custom baud rates

glibc 2.42 and later, and GNU Hurd, accept arbitrary baud rates
directly via cfsetispeed and cfsetospeed.  This behaviour is expected
to be standardized in a future POSIX revision.

Introduce a configure-time test (HAVE_CFSETSPEED_ARBITRARY) that
detects this capability and add a new platform-agnostic helper
set_custom_baudrate_posix.  The main dispatcher now prefers the POSIX
path when it is available, falling back to the existing Linux (BOTHER)
or Darwin (IOSSIOSPEED) implementations otherwise.

The HAVE_CUSTOM_BAUDRATE_SUPPORT guard is extended to also cover the
new POSIX case.

Suggested-by: Kevin Buettner <kevinb@redhat.com>
Suggested-by: Maciej W. Rozycki <macro@orcam.me.uk>
Signed-off-by: Sunil Dora <sunilkumar.dora@windriver.com>
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-by: Kevin Buettner <kevinb@redhat.com>

gdb/ser-unix: fix musl build failure when setting custom baud rates

On musl-based systems, <asm/termbits.h> may expose BOTHER even though
struct termios does not define c_ispeed/c_ospeed.  This causes the
Linux-specific custom baud rate path to be compiled and fail to build.

Fix the problem at the macro level by requiring
HAVE_STRUCT_TERMIOS_C_OSPEED (obtained via AC_CHECK_MEMBERS) together
with BOTHER in the HAVE_CUSTOM_BAUDRATE_SUPPORT guard.  This prevents
the Linux-specific code from being compiled on musl while leaving
set_custom_baudrate_linux unchanged.

This is a pure build fix with no functional or behavioural change on
any existing platform.

Suggested-by: Maciej W. Rozycki <macro@orcam.me.uk>
Signed-off-by: Sunil Dora <sunilkumar.dora@windriver.com>
Approved-by: Kevin Buettner <kevinb@redhat.com>

Automatic date update in version.in

Remove "prefix" argument from cp_type_print_method_args

The "prefix" argument to cp_type_print_method_args is only ever the
empty string, so it can be removed.

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

[gdb/build] Fix Wunused-variable in selftests::test_enumerate

On openSUSE Leap 15.6, with gcc 7.5.0, I ran into:
...
enumerate-selftests.c: In function 'void selftests::test_enumerate()':
enumerate-selftests.c:85:22: error: \
  unused variable 'i' [-Werror=unused-variable]
     for (auto [i, val] : gdb::ranges::views::enumerate (vec))
                      ^
cc1plus: all warnings being treated as errors
...

Fix this by checking the value of i.

Tested on x86_64-linux.

gdbsupport: remove iteration_status_str

When building with g++ 8 (on Alma Linux 8), we get:

      CXX    ada-exp.o
    In file included from /binutils-gdb/gdb/../gdbsupport/array-view.h:24,
                     from /binutils-gdb/gdb/../gdbsupport/common-utils.h:27,
                     from /binutils-gdb/gdb/../gdbsupport/common-defs.h:214,
                     from /binutils-gdb/gdb/defs.h:26,
                     from <command-line>:
    /binutils-gdb/gdb/../gdbsupport/iteration-status.h: In function ‘constexpr const char* iteration_status_str(iteration_status)’:
    /binutils-gdb/gdb/../gdbsupport/gdb_assert.h:43:22: error: call to non-‘constexpr’ function ‘void internal_error_loc(const char*, int, const char*, ...)’
       internal_error_loc (__FILE__, __LINE__, _("%s: " message), __func__, \
       ~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
             ##__VA_ARGS__)
             ~~~~~~~~~~~~~~
    /binutils-gdb/gdb/../gdbsupport/iteration-status.h:45:3: note: in expansion of macro ‘gdb_assert_not_reached’
       gdb_assert_not_reached ("invalid iteration_status value");
       ^~~~~~~~~~~~~~~~~~~~~~

It turns out that iteration_status_str isn't used, it apparently was
only used transiently in my series.  Remove it to fix the build failure.

Change-Id: Icb43d4d719ad94a3eafa5fd55c81a56cbe0da91d

Automatic date update in version.in

gdb: don't use .text as default entry point section

We got a Fedora GDB bug report that a user tried to debug an Appimage,
and GDB would reliably crash like this:

  (gdb) run
  Starting program: /tmp/build/gdb/testsuite/outputs/gdb.base/solib-bad-entry-addr/solib-bad-entry-addr
  ../../src/gdb/symfile.c:843: internal-error: sect_index_text not initialized
  A problem internal to GDB has been detected,
  further debugging may prove unreliable.
  ----- Backtrace -----
  ... etc ...

The specific AppImage being debugged can be found here, I've modified
the URL with a warning marker.  I make no claims about whether it is
safe to download the image, and running it is definitely at your own
risk.  If you wish to, delete the warning marker to download:

  https://github.com/Murmele/Gittyup/<RUN AT YOUR OWN RISK>/releases/download/gittyup_v1.4.0/Gittyup-1.4.0-x86_64.AppImage

At the point of the above crash GDB's stack is:

  #9  0x000000000190c6ed in internal_error_loc (file=0x1e4a94e "../../src/gdb/symfile.c", line=838, fmt=0x1e4aa50 "sect_index_text not initialized") at ../../src/gdbsupport/errors.cc:57
  #10 0x0000000000f5f5ac in init_entry_point_info (objfile=0x5a98e80) at ../../src/gdb/symfile.c:838
  #11 0x0000000000f5f943 in syms_from_objfile (objfile=0x5a98e80, addrs=0x7ffd78728490, add_flags=...) at ../../src/gdb/symfile.c:962
  #12 0x0000000000f5fe6d in symbol_file_add_with_addrs (abfd=..., name=0x3e76e50 "/tmp/.mount_GittyujmIBkD/usr/bin/../../home/runner/work/Gittyup/Qt/5.15.2/gcc_64/lib/./libicudata.so.56", add_flags=..., addrs=0x7ffd78728490, flags=..., parent=0x0) at ../../src/gdb/symfile.c:1071
  #13 0x0000000000f601aa in symbol_file_add_from_bfd (abfd=..., name=0x3e76e50 "/tmp/.mount_GittyujmIBkD/usr/bin/../../home/runner/work/Gittyup/Qt/5.15.2/gcc_64/lib/./libicudata.so.56", add_flags=..., addrs=0x7ffd78728490, flags=..., parent=0x0) at ../../src/gdb/symfile.c:1145
  #14 0x0000000000f0f2ad in solib_read_symbols (so=..., flags=...) at ../../src/gdb/solib.c:627
  #15 0x0000000000f10263 in solib_add (pattern=0x0, from_tty=0, readsyms=1) at ../../src/gdb/solib.c:960

From this we can see GDB is trying to add the shared library:

  /tmp/.mount_GittyujmIBkD/usr/bin/../../home/runner/work/Gittyup/Qt/5.15.2/gcc_64/lib/./libicudata.so.56

The internal error is triggered from these lines in
init_entry_point_info:

  if (!found)
    ei->the_bfd_section_index = SECT_OFF_TEXT (objfile);

Where SECT_OFF_TEXT is:

  #define SECT_OFF_TEXT(objfile) \
     ((objfile->sect_index_text == -1) \
      ? (internal_error (_("sect_index_text not initialized")), -1) \
      : objfile->sect_index_text)

So we can see that objfile::sect_index_text is -1, which leads to the
internal error.

Looking at the 'readelf -Wa ...' output for the shared library in
question we see this:

  ELF Header:
    Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
    Class:                             ELF64
    Data:                              2's complement, little endian
    Version:                           1 (current)
    OS/ABI:                            UNIX - System V
    ABI Version:                       0
    Type:                              DYN (Shared object file)
    Machine:                           Advanced Micro Devices X86-64
    Version:                           0x1
    Entry point address:               0x2d7
    Start of program headers:          25051136 (bytes into file)
    Start of section headers:          25047552 (bytes into file)
    Flags:                             0x0
    Size of this header:               64 (bytes)
    Size of program headers:           56 (bytes)
    Number of program headers:         7
    Size of section headers:           64 (bytes)
    Number of section headers:         11
    Section header string table index: 7

  Section Headers:
    [Nr] Name              Type            Address          Off    Size   ES Flg Lk Inf Al
    [ 0]                   NULL            0000000000000000 000000 000000 00      0   0  0
    [ 1] .note.gnu.build-id NOTE            0000000000000190 000190 000024 00   A  0   0  4
    [ 2] .gnu.hash         GNU_HASH        00000000000001b8 0001b8 000034 00   A  3   0  8
    [ 3] .dynsym           DYNSYM          00000000000001f0 0001f0 000090 18   A 10   2  8
    [ 4] .rodata           PROGBITS        00000000000002e0 0002e0 17e27d0 00   A  0   0 16
    [ 5] .eh_frame         PROGBITS        00000000017e2ab0 17e2ab0 000000 00   A  0   0  8
    [ 6] .dynamic          DYNAMIC         00000000019e2f10 17e2f10 0000f0 10  WA 10   0  8
    [ 7] .shstrtab         STRTAB          0000000000000000 17e3000 000063 00      0   0  1
    [ 8] .symtab           SYMTAB          0000000000000000 17e3068 000150 18      9  10  8
    [ 9] .strtab           STRTAB          0000000000000000 17e31b8 000044 00      0   0  1
    [10] .dynstr           STRTAB          00000000019e3188 17e4188 000420 00   A  0   0  8
  Key to Flags:
    W (write), A (alloc), X (execute), M (merge), S (strings), I (info),
    L (link order), O (extra OS processing required), G (group), T (TLS),
    C (compressed), x (unknown), o (OS specific), E (exclude),
    D (mbind), l (large), p (processor specific)

  There are no section groups in this file.

  Program Headers:
    Type           Offset   VirtAddr           PhysAddr           FileSiz  MemSiz   Flg Align
    LOAD           0x000000 0x0000000000000000 0x0000000000000000 0x17e2ab0 0x17e2ab0 R   0x200000
    GNU_STACK      0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 RW  0x10
    NOTE           0x000190 0x0000000000000190 0x0000000000000190 0x000024 0x000024 R   0x4
    LOAD           0x17e2f10 0x00000000019e2f10 0x00000000019e2f10 0x0000f0 0x0000f0 RW  0x200000
    DYNAMIC        0x17e2f10 0x00000000019e2f10 0x00000000019e2f10 0x0000f0 0x0000f0 RW  0x8
    GNU_RELRO      0x17e2f10 0x00000000019e2f10 0x00000000019e2f10 0x0000f0 0x0000f0 R   0x1
    LOAD           0x17e4000 0x00000000019e3000 0x00000000019e3000 0x0005a8 0x0005a8 RW  0x1000

Things to note here are:

  1. There really is no .text section, or any executable sections,

  2. there are 3 LOAD segments.  This will be important later, and

  3. the "Entry point address" is outside all sections, and is
     non-zero.

Next we can investigate where objfile::sect_index_text is set to
something other than -1.  Starting in init_objfile_sect_indices, if
the objfile has a ".text" section then sect_index_text can be set.
This case clearly doesn't apply.

Next symfile_find_segment_sections is called.  This tries to match a
common case where we have either 1 or 2 LOAD segments, and assumes a
default distribution of sections to segments.  However, we have 3 LOAD
segments, so these lines:

  if (data->segments.size () != 1 && data->segments.size () != 2)
    return;

result in an early return from symfile_find_segment_sections without
sect_index_text being set.

Back in init_objfile_sect_indices, if no sections have an offset then
we set any currently unset sect_index_* values, including
sect_index_text, to point at section 0.  However, in our case the
objfile is a relocatable shared library, so the sections will have an
offset, and so this final fallback case doesn't apply.

The result is that init_objfile_sect_indices never sets
sect_index_text.  This worries me a little as
init_objfile_sect_indices contains this comment:

  /* This is where things get really weird...  We MUST have valid
     indices for the various sect_index_* members or gdb will abort.
     So if for example, there is no ".text" section, we have to
     accommodate that.  First, check for a file with the standard
     one or two segments.  */

Notice the emphasis on MUST in that comment, and indeed, we exit this
function without setting sect_index_text, and GDB does indeed abort.
The comment seems to imply that the following code is going to try to
figure out a suitable stand-in sect_index_text for when there is no
".text" section, but clearly I've run into a case that isn't covered.

All of this code relating to setting sect_index_text was introduced in
commit:

  commit 31d99776c73d6fca13163da59c852b0fa99f89b8
  Date:   Mon Jun 18 15:46:38 2007 +0000

Which unfortunately is from a time where we didn't write useful commit
messages, so to understand the commit you need to go read the mailing
list archive, but they don't offer much more insight:

  https://sourceware.org/pipermail/gdb-patches/2007-May/050527.html

Clearly the comment in init_objfile_sect_indices would suggest that
the fix here is to figure out some "fake" value for sect_index_text,
and that would certainly avoid the problem here.  But, at least for
this problem, I think there's maybe a better solution.

The original internal error is triggered by a use of SECT_OFF_TEXT in
init_entry_point_info.  We have an entry point address, we try to find
the section index for the section containing the entry point, and
failing that, we assume the entry point is in the text section.  This
fall-back assumption means that, if the text section has an offset
applied, then the entry point will also have that same offset
applied.  But it's not clear to me why picking the text section is
going to be any more valid than any other section, especially in a
case like this where we don't even have a text section, so the
sect_index_text might itself point to some other arbitrary section.

Earlier in init_entry_point_info we already have a fall-back case
where we set entry_info::entry_point_p to false to indicate that the
objfile has no entry point, so this is always a possibility.  So I
wondered about writing something like:

  if (!found)
    {
      if (objfile->sect_index_text != -1)
ei->the_bfd_section_index = SECT_OFF_TEXT (objfile);
      else
        ei->entry_point_p = false;
    }

If we have no text section index then we just claim the objfile has no
entry point.  But I didn't like this for two reasons, first, the
comment back in init_objfile_sect_indices saying that the index should
be set, this seems to indicate that we should not be making decisions
later within GDB based on whether the index is set or not.

And second, using the text section as a fall back, when the entry
address is outside every section, just seems off.  So I wondered, why
not just reject the entry point completely in this case?  Which is how
I ended up with:

  if (!found)
    ei->entry_point_p = false;

With this patch in place I was able to start debugging the AppImage
linked above.

I created a simple test case which reproduces this issue.  It's a
little contrived because it has to hit all the points required to
trigger this bug:

  1. No .text section,

  2. more than 2 LOAD segments, and

  3. entry address outside every section.

I have no idea what caused the original shared library to take on
these characteristics, it might even be a tool issue building the
original shared library.  I haven't investigated this, as I don't
think it really matters, GDB shouldn't be crashing just because the
incoming objects are a little weird.

I've attached a link to the Fedora bug in the 'Bug:' tag, but it's a
little confusing.  An automated system has merged together two bug
reports.  As such the overall bug report linked too is for a
completely different issue, only comments 21, 22, 23, and 24 relate to
the bug being fixed here.

Bug: https://bugzilla.redhat.com/show_bug.cgi?id=2366461#c21

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

gdb: int to bool in struct entry_info

Convert 'struct entry_info' to use bool for flag fields.  The places
where these flags are set are updated too.  I have also removed the
bit width specifier ": 1" from the flag field definitions.  There is
one entry_info struct per BFD in GDB, which is not a huge number, so
forcing the bool fields to 1-bit doesn't seen necessary.

There should be no user visible changes after this commit.

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

gdb: make iterate_over_symbols return void, rename to for_each_symbol

Nothing really uses the return value of iterate_over_symbols and
language::iterate_over_symbols.  Also, all provided callback always
return true, iterating on all matching symbols.  Simplify them to not
return a value and not have the "stop iterating" feature.

Rename to for_each_symbol, just to be consistent with previous patches.

Also rename symbol_found_callback_ftype to
for_each_symbol_callback_ftype for consistency.

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

gdb: make symbol_found_callback_ftype a function_view

All uses of symbol_found_callback_ftype use it within a function_view,
so factor out the function_view into the type alias.

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

gdb: change objfile::map_symtabs_matching_filename to find_symtab_matching_filename

The only user of objfile::map_symtabs_matching_filename uses that method
to find the first matching symtab.  It would therefore be more natural
for that method to be a "find" method, returning the first symtab
matching the predicate.

Change map_symtabs_matching_filename to be
find_symtab_matching_filename, and the internal
iterate_over_one_compunit_symtab to be find_symtab_in_compunit_symtab.

This makes function find_symtab simpler.

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

gdb: split iterate_over_symtabs into for_each_symtab and find_symtab

Same rationale as the previous patches.

For the moment, find_symtab is only needed internally in symtab.c, so
keep it static there.  Note that the interaction with
objfile.map_symtabs_matching_filename gets cleaner in a subsequent
patch.

for_each_symtab is implemented using find_symtab, because the iteration
behavior is not completely trivial.

find_symtab_callback_ftype is in the header file, because it is used
from another source file in the next patch.

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

gdb: split iterate_over_minimal_symbols into for_each_minimal_symbol and find_minimal_symbol

Based on the same rationale as the previous patches, split
iterate_over_minimal_symbols in two.

Implement for_each_minimal_symbol using find_minimal_symbol, since that
one is really not trivial.

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

gdb: split iterate_over_threads into for_each_thread and find_thread

Same rationale as the previous patch, I think the code would be clearer
and simpler with separate "for each" and "find" functions rather than
one that does both jobs.

No need for the callbacks of the "for each" function to return anything,
as none of them needs to interrupt the iteration.

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

gdb, gdbserver: split iterate_over_lwps into for_each_lwp and find_lwp

Even though it works, I have always been mildly annoyed by
iterate_over_lwps being used for both iterating over all lwps and
finding one lwp matching a criterion.  I think it would be clearer to
have two functions for the two use cases.  Then it would be 100% clear
at the call site what the intention is.  It would be clear that a
callback returning bool is meant to be a predicate for the find
function, while a callback returning void is meant to be a callback for
the "for each" function.

Therefore, split iterate_over_lwps in two:

 - find_lwp to find the first lwp matching a boolean predicate (and the
   given ptid filter)
 - for_each_lwp to apply a function on all lwps (optionally filtering by
   ptid or pid)

The callbacks given to for_each_lwp can now return void.

Introduce some overloads for for_each_lwp, for the various common use
cases:

 - filtering by ptid
 - filtering by pid
 - no ptid/pid filter

find_lwp and two overloads of for_each_lwp are actually only used in
gdb/linux-nat.c, so make them local to that file.  Only the pid variant
of for_each_lwp is used in shared code.

The pattern used in this patch serves as the basis for subsequent
patches that split other "iterate over" functions the same way.

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

gdb, gdbserver: make iterate_over_lwps_ftype a function_view

All users of iterate_over_lwps_ftype use it within a function_view
template.  Integrate function_view to the type alias.

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

gdb: introduce iteration_status enum, use it for search callbacks

There are a bunch of iteration functions that take a callback returning
true or false to indicate whether to continue or stop iterating.  These
functions then return the same value, indicate whether the iteration was
done until the end of interrupted.  I think this is confusing and
error-prone, as I never know which value means what.  It is especially
confusing when two opposite conventions collide, such as in
objfile::map_symtabs_matching_filename.

I propose to make that more obvious by introducing a new
iteration_status enum with self-documenting values.

I started to change the callback type
compunit_symtab_iteration_callback, taken by
quick_symbol_functions::search, and then followed that path to update a
bunch of other functions.

I chose the name to be kind of generic, so that it can be used for other
similar iteration patterns.  I also put it in gdbsupport, in case we
want to use it in gdbserver too.

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

gdb: rename search_symtabs_expansion_listener -> compunit_symtab_iteration_callback

I think that the name search_symtabs_expansion_listener function type
no longer makes sense for the following reasons:

 - Since we have both `symtab` and `compunit_symtab` structs, I like
   when we are specific about which one we're talking about.  In this
   case, the callback takes a `compunit_symtab`.

 - Following series "Search symbols via quick API" [1] last year (I
   believe commit f88f9f42db8 ("Have expand_symtabs_matching work for
   already-expanded CUs")), the callback gets called for all matching
   compunit_symtabs, not just those that get expanded.

I therefore propose to rename it to compunit_symtab_iteration_callback.
I chose "callback" over "listener", because I think that listener
implies that there is some event happening, that we listen for.  That
made sense before where we would listen for the "expansion" event.  But
now since it just gets called back for all matching CUs, I think that
"callback" makes more sense.

I renamed the parameters accordingly.

[1] https://inbox.sourceware.org/gdb-patches/20250909-search-in-psyms-v4-0-e7ef9e3b6479@tromey.com/

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

gdb/dwarf: remove unused file_match parameter from dwarf2_base_index_functions::search_one

The `file_matcher` parameter is unused.

The information from `file_matcher` is actually encoded in
`cus_to_skip`.  All callers to this:

    auto_bool_vector cus_to_skip;
    dw_search_file_matcher (per_objfile, cus_to_skip, file_matcher);

... which populates `cus_to_skip` with all the CUs that do not match
`file_matcher`.

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

Add --debug-dir option to readelf and objdumo.  Load separate debug info files when disassemblng.

gdb/testsuite: fix skip-tree.exp test for PowerPC

The gdb.base/skip-tree.exp test was added in commit:

  commit 5ed98c177f9a2381fe5c6ab873d05f1e5dcb8f7f
  Date:   Wed Feb 4 20:31:31 2026 +0000

      gdb: introduce '**' for skip globs

This test currently fails on PowerPC due to architectural differences
in function return handling.

On PowerPC64 ELFv2, calls to external functions are followed by a
`nop` instruction that serves as a placeholder for TOC pointer
restoration. Since this `nop` typically has no DWARF line entry,
`finish` reports the call line instead of the next line.

This issue was reported here:

  https://inbox.sourceware.org/gdb-patches/20260415055144.2729164-1-abhay@linux.ibm.com

The fix proposed there was to add a PowerPC specific check so that the
test would send a `next` command after using `finish` to advance to
the expected source line.

This commit actually takes a more general approach.  After calling
`finish` we check which line we ended up on.  If it was the caller
line then we send GDB a `next` to move to the expected line.  If we
arrive directly at the next line, then no `next` is needed.

I've tested this change on x86-64, where no `next` is needed, and
PowerPC, where `next` is now used as required to get the test
passing.

To simplify the pattern matching in the exp file, I tweaked the source
file slightly.  But adding a call to a dummy 'func5' it's now easy to
pattern match as we step through 'func1', 'func2', etc.

Co-Authored-By: Abhay Kandpal <abhay@linux.ibm.com>

x86/AT&T: properly reject effectively absent memory operands

A segment override or * followed by nothing is not a valid operand, yet
is regarded as one due to strchr() succeeding when passed nul as 2nd
argument.

x86: refine special casing of insns with MSR as immediate

PR gas/34028

i.op[].imms is legitimate to de-reference only when the operand actually
is an immediate. The pointer happens to be non-NULL for most other operand
kinds (i.e. a deref is UB, but would likely not fault), just not for
memory operands without displacement.

Leverage that the to-be-special-cased insns all only have just a single
immediate, and leverage further that after the immediately preceding
swapping of operands valid immediates will come first. Hence the
conditional can be adjusted to satisfy the criteria above, and no loop is
needed at all.

With the conditional changed, leverage the property also in optimize_imm()
itself, reducing the number of loop iterations.

make more use of elf_symtab_hdr

This is a mostly mechanical replacement of elf_tdata (abfd)->symtab_hdr
with elf_symtab_hdr (abfd).

Re: Add a "-O 0" option to the linker

Only put labels in first column of tests, for hppa64-hpux.

Automatic date update in version.in

gdb: use enumerate in gdbtypes.c

Use the new enumerate util to move to a range-based loop, while keeping
the counter.

Change-Id: If82eaec7afa4e78fa51e973fae4d0ecef728ea95

gdb/dwarf: use enumerate in index-write.c

Use the new enumerate util to get rid of some manual counters.

Change-Id: I0573f0890e9b775a5181d8c0d435bb7ba661cae4

gdbsupport: add gdb::ranges::views::enumerate util

Add a "enumerate" utility, that acts pretty much like Python's
enumerate().  It makes the code slightly nicer, for when you would
otherwise need to handle the counter by hand.

It can be used like this:

  std::vector<int> my_vector;
  for (auto [i, val] : gdb::ranges::views::enumerate (my_vector))
    ...

`i` will hold the 0-based index of the current iteration, and `val` will
be a reference to the value of the current iteration.

The name is chosen to match std::ranges::views::enumerate from C++23,
making it easy to switch to that eventually.

Change-Id: I1870ab50537bcf54bba44a30a0b01ab397be16e3

gdb: remove an unintended #undef

An #undef seems to have sneaked into gdbsupport/scoped_signal_handler.h.
This causes the HAVE_SIGACTION macro to be cleared unintentionally.
Remove the line.

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

[gdb/build] Reimplement Wstringop-overread workaround

While working on commit 391c4026573 ("[gdb] Simplify debuginfod_is_enabled") I
noticed this Wstringop-overread workaround:
...
      url_view = url_view.substr (off);
      /* g++ 11.2.1 on s390x, g++ 11.3.1 on ppc64le and g++ 11 on
 hppa seem convinced url_view might be of SIZE_MAX length.
 And so complains because the length of an array can only
 be PTRDIFF_MAX.  */
      DIAGNOSTIC_PUSH
      DIAGNOSTIC_IGNORE_STRINGOP_OVERREAD
      off = url_view.find_first_of (' ');
      DIAGNOSTIC_POP
...

I had difficulty understanding how the warning got triggered, and why it was
ok to ignore it, so I investigated this and ended up filing a gcc PR [1].

While doing so, I realized that this:
...
-      url_view = url_view.substr (off);
+      url_view = url_view.substr (off, PTRDIFF_MAX);
...
is a simpler workaround, that:
- is not specific to the warning and also
- states explicitly what the assumption is we're making.

I ended up using this instead to make the workaround part more minimal:
...
       url_view = url_view.substr (off);
+      url_view = url_view.substr (0, PTRDIFF_MAX);
       off = url_view.find_first_of (' ');
...

The gcc PR got closed because it's supposed to be fixed in 12.1, so the
workaround is enabled only for g++ < 12.1.

Tested on x86_64-linux.

Approved-By: Tom Tromey <tom@tromey.com>
[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124879

ld: Move "-O 0" option to binutils 2.47 section

Since "-O 0" option is added to binutils 2.47, move it to binutils 2.47
section.

* NEWS: Move "-O 0" option to binutils 2.47 section.

Signed-off-by: H.J. Lu <hjl.tools@gmail.com>

Automatic date update in version.in

Clean up comment in language.h

I noticed a comment in language.h that was partially obsolete.  This
patch removes the obsolete bits and makes a small change to the rest.

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

gdb/testsuite: fix dw2-entry-pc.exp with ASLR

Following Simon Marchi's fix for dw2-empty-inline-ranges.exp [1], this
test exhibits the same failure pattern when running in an environment
where GDB can't disable address space randomization (such as in a
container where that capability is removed) with a toolchain generating
position-independent executables.

The test does a first run to grab addresses of labels and function
boundaries (foo_middle, foo_start, foo_end, and range labels).  It then
crafts DWARF using these addresses across multiple test iterations.
When the executable is PIE and ASLR is active, the addresses in each
subsequent run don't match the addresses from the initial run.

The failure manifests in the 'maint info blocks' output comparisons,
where the expected addresses (from the first run) don't match the
actual addresses in the test runs.

The simplest fix, following Simon's approach, is to use "nopie" when
building the binaries.  This doesn't affect the effectiveness of the
test, which is exercising different ways DW_AT_entry_pc can be
expressed in DWARF.

Also, with a non-PIE executable, it is no longer necessary to run the
inferior before grabbing the addresses in the initial run, as they are
stable.  So remove that runto_main call.

[1] https://inbox.sourceware.org/gdb-patches/20260205204257.422150-1-simon.marchi@efficios.com/

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

Automatic date update in version.in

[gdb/symtab] Add find_symbol_for_pc_maybe_inline

We have function find_symbol_for_pc:
...
find_symbol_for_pc (CORE_ADDR pc)
{
  return find_symbol_for_pc_sect (pc, find_pc_mapped_section (pc));
}
...
which uses some standard way of getting the section for the given pc.

Add a similar function find_symbol_for_pc_maybe_inline that calls
find_symbol_for_pc_sect_maybe_inline, and use it in jump_command.

Tested on x86_64-linux.

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

gdb: use get_current_frame consistently in print_stop_location

In print_stop_location, in the PRINT_UNKNOWN case we currently use a
strange mix of get_current_frame and get_selected_frame.  This works
fine because at the point print_stop_location is called the selected
frame will always be the current frame, but calling these two
different functions is confusing, at least for me.

Since bpstat_print selects the frame to print (which usually is the current
frame, but not always), the correct frame to use is the selected frame after
the bpstat_print call.

Assign the selected frame to a variable print_frame, and use it throughout the
function.

There should be no user visible changes after this commit.

Co-Authored-By: Tom de Vries <tdevries@suse.de>
Approved-By: Andrew Burgess <aburgess@redhat.com>

gdb: fix missing print frame when stepping out of function

Consider test-case gdb.dwarf2/dw2-extend-inline-block.exp,
specifically the "contiguous block" prefix part, which can be stepped
through like this:

...
  $ gdb -q outputs/gdb.dwarf2/dw2-extend-inline-block/dw2-extend-inline-block-5
  Reading symbols from dw2-extend-inline-block-5...
  (gdb) start
  ... snip ...
  Temporary breakpoint 1, main () at dw2-extend-inline-block.c:35
  35   /* main:2 */
  (gdb) s
  36   /* main:3 */ foo (); /* foo call line */
  (gdb)
  foo () at dw2-extend-inline-block.c:26
  26   /* foo:1 */
  (gdb) s
  27   /* foo:2 */
  (gdb) s
  28   /* foo:3 */
  (gdb) s
  main () at dw2-extend-inline-block.c:37
  37   /* main:4 */
  (gdb)
...

If we slightly modify the line program:

...
DW_LNE_set_address main_4
+ DW_LNS_advance_line 1
DW_LNS_copy

DW_LNE_set_address main_5
- DW_LNS_advance_line 1
DW_LNS_negate_stmt
DW_LNS_copy
...

we change the 36/0x401165 entry into a 37/0x401165 entry:

...
  File name                     Line number    Starting address    View    Stmt
  dw2-extend-inline-block.c              34            0x401116               x
  dw2-extend-inline-block.c              35            0x401129               x
  dw2-extend-inline-block.c              26            0x401138               x
  dw2-extend-inline-block.c              27            0x401147               x
  dw2-extend-inline-block.c              28            0x401156               x
  dw2-extend-inline-block.c              36            0x401156
 -dw2-extend-inline-block.c              36            0x401165
 +dw2-extend-inline-block.c              37            0x401165
  dw2-extend-inline-block.c              37            0x401174               x
  dw2-extend-inline-block.c              38            0x401183               x
  dw2-extend-inline-block.c              39            0x401192               x
  dw2-extend-inline-block.c              40            0x4011a1               x
  dw2-extend-inline-block.c               -            0x4011b7
...

As it happens, the fix to extend truncated inlined function blocks
doesn't work in this case.  This is PR gdb/33930.

We can work around this by making sure that the inlined function block
isn't truncated in the first place:

...
- DW_AT_high_pc main_3 addr
+ DW_AT_high_pc main_4 addr
...

But then we still run into PR gdb/33981: the problem that gdb doesn't
notify us when stepping out of foo:

...
  (gdb) step^M
  28        /* foo:3 */^M
  (gdb) step^M
  37        /* main:4 */^M
  (gdb)
...

What happens is that the slightly different line program triggers a
different stepping path, which includes a case of "stepped to a
different frame, but it's not the start of a statement", which
refreshes the stepping info and consequently updates
tp->control.step_frame_id to the frame id of main.

So by the time we're stopped at line 37, and are trying to figure out
what to print in print_stop_location, this condition evaluates to
true:

...
      if (tp->control.stop_step
  && (tp->control.step_frame_id
      == get_frame_id (get_current_frame ()))
  && (tp->control.step_start_function
      == find_symbol_for_pc (tp->stop_pc ())))
...

and we get:

...
      /* Finished step in same frame and same file, just print source
 line.  */
      source_flag = SRC_LINE;
...

It's good to realize here that because foo is inlined into main,
tp->control.step_start_function is not foo but main, so consequently
the step_start_function check (which checks if we are still in the
same function) also passes, even though we actually stepped from foo
into main.

The problem is the use of find_symbol_for_pc, this function
deliberately skips over inline frames and returns the symbol for the
innermost non-inline frame.

It might be tempting to think that we should switch to use
find_symbol_for_pc_sect_maybe_inline, which will return the symbol for
an inline frame, but this also has problems, specifically, attempting
this caused a regression in gdb.opt/inline-cmds.exp.  The previous
version of this patch, which showed the regression can be found here:

  https://inbox.sourceware.org/gdb-patches/20260331132342.1050954-1-tdevries@suse.de

At a given $pc the inferior might be reported as being within an
inline frame, or it might be reported as being in the containing
non-inline frame.  When the user performs a 'step' the
step_start_function needs to be set based on the function symbol of
the frame the inferior is actually reported in.  And we have a
function that gives us this information, get_frame_function.  So
instead of looking up the step_start_function based on the $pc value,
set it based on the frame.

Test gdb.dwarf2/dw2-extend-inline-block.exp is extended with the
additional test case described above.

Tested on x86_64-linux.

Co-Authored-By: Andrew Burgess <aburgess@redhat.com>
Approved-By: Andrew Burgess <aburgess@redhat.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33930
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33981

[gdb] Add thread_control_state::step_start_function methods

Factor out all uses of thread_control_state::step_start_function into
methods, and make the field private.

Tested on x86_64-linux.

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

[gdb/testsuite] Extend gdb.opt/inline-cmds.exp

When using this tentative patch [1], GDB regresses like this in test-case
gdb.opt/inline-cmds.exp:
...
 Temporary breakpoint 1, main () at inline-cmds.c:64
 64   y = 8; /* set mi break here */
 (gdb) s
+main () at inline-cmds.c:66
 66   result = func1 ();
 (gdb) s
 func1 () at inline-cmds.c:35
 35   bar ();
 (gdb)
...
but the regression doesn't produce a FAIL.

The regression does produce a FAIL during the part of the test that runs in MI
mode.

Extend the test so the regression also produces a FAIL in CLI mode.

Approved-By: Andrew Burgess <aburgess@redhat.com>
[1] https://sourceware.org/pipermail/gdb-patches/2026-March/226272.html

[gdb/contrib] Skip generated aclocal.m4 with codespell

Skip these 3 generated files with codespell:
- gdb/aclocal.m4
- gdbserver/aclocal.m4
- gdbsupport/aclocal.m4

AFAICT, gdb/testsuite/aclocal.m4 is not generated.

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

PR 34052 kill: Terminate inferior with non-zero exit code on Windows

Don't terminate the inferior with exit code 0 (a 'success' exit
code). Rather, use the standard exit code 137 as with SIGKILL on
Linux.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=34052
Reviewed-By: Andrew Burgess <aburgess@redhat.com>
Approved-By: Tom Tromey <tom@tromey.com>

[gdb] Simplify debuginfod_is_enabled

Simplify debuginfod_is_enabled by adding an early-exit for the
debuginfod_enabled == debuginfod_on case.

Automatic date update in version.in

Add a "-O 0" option to the linker for a faster, but less effective link.

Automatic date update in version.in

Automatic date update in version.in

gdb: store gdbtk object files into their sources directory

Do not list gdbtk required object file names, but generates them from
source file names.

Use gdb object file list rather than static library for linking insight.

gdb: Improve indexing of 'dir' command and related commands

I had difficulty finding the 'dir' command in the manual (I forgot its
name, amazingly enough), so I've installed this to improve its indexing.

* gdb/doc/gdb.texinfo (Source Path): Improve indexing.

gdb/dwarf: fix internal error when FDEs do not describe the CFA

New in v2: change how undefined_retaddr is set, to avoid regressions on
AArch64 (among possibly others).

This patch fixes an internal error problem that happens when a frame
description entry does not define the Canonical Frame Address (CFA).
This problem was initially reported downstream as a ROCgdb issue (see
Bug trailer below), but I wrote a reproducer that uses the .debug_frame
functionality added to the DWARF assembler in the previous patch.

The error is:

    /home/smarchi/src/binutils-gdb/gdb/dwarf2/frame.c:1046: internal-error: Unknown CFA rule.

The original bug was encountered while debugging a GPU kernel written
with Triton [1].  From what I understand, the generated kernel does not
really use a stack, so the .debug_frame contents generated is quite
bare:

    $ readelf --debug-dump=frames k
    Contents of the .debug_frame section:

    00000000 000000000000000c ffffffff CIE
      Version:               4
      Augmentation:          ""
      Pointer Size:          8
      Segment Size:          0
      Code alignment factor: 4
      Data alignment factor: 4
      Return address column: 16

      DW_CFA_nop

    00000010 0000000000000014 00000000 FDE cie=00000000 pc=0000000000001600..0000000000001704

For those who don't speak fluent .debug_frame, what we see here is a
Frame Description Entry (FDE) that doesn't define any register rule,
referring to a Common Information Entry (CIE) that also doesn't define
any initial register rule.  This is equivalent to having no unwind
information at all.  One question is: why generate these at all?  I
suppose that this is an edge case, that the compiler is written in a way
that that presumes there will always be some unwind info.  That there is
no "if unwind info is empty, skip emitting the FDE" check.  Anyway, the
important thing for us is that these can be found in the wild, so GDB
shouldn't crash.

The fix consists of handling CFA_UNSET in the dwarf2_frame_cache switch.
CFA_UNSET is the initial state when we start interpreting a CFA program,
meaning that we don't know yet how the CFA is defined.  In our case, it
remains unset after interpreting the CFA program.

With just the fix above, we get:

    (gdb) bt
    #0  0x000055555555511d in main ()
    Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Which is good (better than crashing), but it would be good to avoid the
error.  To do so, set the undefined_retaddr flag to true.  This has
two effects:

 - dwarf2_frame_this_id won't try to build a frame id from the CFA
   (which is good, we don't have a CFA)
 - dwarf2_frame_unwind_stop_reason will return UNWIND_OUTERMOST, which
   is the most accurate thing we can return here (there is no outer
   frame)

The result is the expected:

    (gdb) bt
    #0  0x000055555555511d in main ()

My initial implementation changed this condition:

  if (fs.retaddr_column < fs.regs.reg.size ()
      && fs.regs.reg[fs.retaddr_column].how == DWARF2_FRAME_REG_UNDEFINED)
    cache->undefined_retaddr = true;

such that we would enter it if

    fs.retaddr_column <+ fs.regs.reg.size ()

However, this broke the unwinding on AArch64 (and possibly others).

Add a test case written using the DWARF assembler that reproduces the
issue.

[1] https://triton-lang.org/

Change-Id: I67c717ff03a41c0630a73ce9549d88ff363e8cea
Bug: https://github.com/ROCm/ROCgdb/issues/47
Approved-By: Tom Tromey <tom@tromey.com>

gdb/testsuite: add .debug_frame support in DWARF assembler

Add support to the DWARF assembler for generating .debug_frame sections.
My initial use case is to reproduce a crash happening when encountering
an empty FDE, but I suppose that other use cases will pop up in the
future.

 - Generate procs for the `DW_CFA_*` constants, similar to how the
   DW_OP_* constants are handled.  These `DW_CFA_*` procs are expected
   to be used in the CIE and FDE bodies, described below.

 - Add handlers for `DW_CFA_*` operations that take arguments.  I tried
   to cover everything that is in DWARF 5.

 - Add the `frame` proc, used to generate one .debug_frame section.

 - Add the `_frame_CIE` proc (available as `CIE` in the context of the
   frame proc), used to generate one Common Information Entry.

 - Add the `_frame_FDE` proc (available as `FDE` in the context of the
   frame proc), used to generate one Frame Description Entry.

Due to the nature of the .debug_frame contents (it describes how
specific machine registers get saved), I expect that most of
the tests written using this will be arch-specific.  But  I think it
will still be useful, as it will let us craft .debug_frame sections to
look exactly how we want.

I included a test (gdb.dwarf2/debug-frame.exp), which is more like a
proof that we can build something useful using this, and can serve as an
example for whoever wants to write a test case using this in the future.

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

Automatic date update in version.in

[gdb] Add selftest for tui_setup_io

Add a selftest for the problem described in commit b171f68e945 ("[gdb/tui]
Make tui_setup_io more robust").

Reviewed-By: Guinevere Larsen <guinevere@redhat.com>

[gdb] Add missing copyright notice in pyproject.toml

I noticed gdb/pyproject.toml is missing a copyright notice.

Add this.  Since it was added in 2021, use copyright years 2021-2026.

x86/AT&T: make GOT-relative expressions work

The expressions used in intel-got{32,64}.s should equally work (or not) in
AT&T mode. Changing the Intel syntax parser such that O_symbol wouldn't
happen to be wrapped around such expressions breaks it there, too. It
really isn't correct to limit this to just O_symbol. Permitting O_add and
O_subtract as well requires taking care of the other operand as well then.
(Strictly speaking non-zero offsets aren't very useful here, but then at
least with an equate of 0 this ought to work. The non-zero offset in the
testcase helps demonstrate that this offset isn't lost.)

gas: print full-width symbol values

The true (rather than truncated) value may be relevant to know if one is
already resorting to print_{expr,symbol}().

gas: distinguish local symbol flavors when printing symbols

Ordinary symbols fulfilling S_IS_LOCAL() criteria aren't the same as local
symbols. Make sure one can tell them apart in print_symbol_value()'s (and
print_expr()'s) output.

gas: have print_expr() recognize O_index

If expr.h is to be trusted, ->X_add_number shouldn't be taken into
consideration here.

LoongArch: Fix Build pr29655

Build pr29655 added in 15b1f65448f.

Don't set pointer_equality_needed for GOT relocations.
If h with a plt entry and !h->pointer_equality_needed,
clear the symbol value to zero.

Automatic date update in version.in

aarch64: Remove constraints on sysp operands

The CRn and CRm operands of sysp were unnecessarily constrained to the
ranges C8-C9 and C0-C7.  This constraint has been removed from the
architecture spec, and was never implemented in LLVM, so remove it here
as well.

Additionally, add some more tests to cover the full range of valid sysp
operands, including omitting the pair of optional operands.

aarch64: Cleanup optional_operand_p

Every time I looked at this function I initially misread the
implementation.  Make it less confusing.

aarch64: Disallow movprfx before revd

An architectural relaxation in 2024 (listed in the "Known issues in
Issue K.a" of the Arm ARM) removed support for revd to be prefixed by a
movprfx instruction.

Remove two movprfx/revd tests from sme-9.s, and replace the
unnecessarily strict address checks with more permissive regexes

aarch64: Reject no-Xt SYS aliases when Rt != 31 in disassembly

For SYS-encoding aliases that do not take Xt (for example TLBI ALLE1,
PLBI ALLE1), disassembly should not print the alias form when Rt != 31.
In that case, disassemble as the generic sys form instead.

Add a focused gas test that checks:
- Rt=31 still disassembles to aliases for no-Xt forms.
- Rt!=31 disassembles to sys ... , xN for those no-Xt forms.
- A valid Xt alias (TLBI VALE1) continues to disassemble as the alias.

opcodes/ChangeLog:

* aarch64-dis.c (aarch64_ext_regrt_sysins): Mark present as
whether Rt is non-default or the SYS op accepts Xt, so aliases
that do not take Xt are rejected when Rt != 31.

gas/ChangeLog:

* testsuite/gas/aarch64/sys-rt-alias.s: New test.
* testsuite/gas/aarch64/sys-rt-alias.d: New test.

aarch64: Add support for %dtprel(var) and R_AARCH64_TLS_DTPREL64

This patch allows R_AARCH64_TLS_DTPREL64 relocations in non-allocated
sections, which is required for DWARF debug information when using
Thread Local Storage. This matches the behavior in LLD.

Also a new syntax to parse dtprel operator use to describe tls
location in debug information. Please see the reference 3 below.

References:
  - https://github.com/llvm/llvm-project/pull/146572
    [AArch64] Support TLS variables in debug info
  - https://github.com/llvm/llvm-project/pull/183962
    [LLD][AArch64] Handle R_AARCH64_TLS_DTPREL64 in non-alloc sections
  - https://github.com/ARM-software/abi-aa/pull/330
    [AAELF64] Allow R_AARCH64_TLS_DTPREL to be used statically.

bfd/
        * elfnn-aarch64.c (elfNN_aarch64_final_link_relocate): Handle
        BFD_RELOC_AARCH64_TLS_DTPREL.

gas/
* config/tc-aarch64.c (s_aarch64_cons): Parse %dtprel(var) syntax.
* testsuite/gas/aarch64/tls-debug.s: New test.
* testsuite/gas/aarch64/tls-debug.d: Run the test.

ld/
* testsuite/ld-aarch64/tls-debug.s: New test.
* testsuite/ld-aarch64/tls-debug.d: Run the test.

Bug: https://sourceware.org/PR28351

Signed-off-by: Shivam Gupta <shivam98.tkg@gmail.com>

Report aux buffer overrun in coff_get_normalized_symtab

Use the xcofflink.c pr34053 error message for objdump, nm etc.

* coffgen.c (coff_get_normalized_symtab): Use _bfd_mul_overflow.
Report error message on aux entry buffer overrun.

PR 34053 buffer overflow in xcoff_link_add_symbols

This patch adds two sanity checks with error reporting in
xcoff_link_add_symbols before reading symbol aux entries, add extends
assertions in later functions.  A whole lot of unnecessary casts are
also tidied.

PR 34053
* xcofflink.c: Remove unnecessary casts throughout.
(xcoff_link_add_symbols): Sanity check aux entries are within
symbol buffer.
(bfd_xcoff_build_dynamic_sections): Assert the above is true.
(xcoff_link_input_bfd): Likewise.

gdb: add AUTO_LOAD_SCOPED_DEBUG_ENTER_EXIT

Add the AUTO_LOAD_SCOPED_DEBUG_ENTER_EXIT macro, and make use of it in
one place.

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

binutils/readelf: Remove unused static variables

Remove static variables do_ctf and do_sframe that are set but never
read, causing build failures with LLVM's extended
-Wunused-but-set-variable warning.

These variables are dead code:
- Declared at lines 244-245 as static booleans
- Set to true when --ctf or --sframe options are parsed
- Never actually used or read anywhere in the code
- The actual dump functionality is triggered by request_dump() calls

Build error with -Werror enabled:

binutils/readelf.c:244:13: error: variable 'do_ctf' set but not used
  [-Werror,-Wunused-but-set-variable]
binutils/readelf.c:245:13: error: variable 'do_sframe' set but not used
  [-Werror,-Wunused-but-set-variable]

bfd: drop ENUMEQ{,X}

These are now unused, and perhaps it's better to drop them. If only to
avoid their bitrotting.

bfd/ELF: fold BFD_RELOC_<arch>_PCREL*

There's no need to have a separate reloc per arch; just like for other
more or less generic ones a single one will (mostly) do, as long as the
resulting reloc's properties fit such a generic use (in the assembler it
could, after all, also result from ordinary expressions or uses with the
.reloc directive). Arm64, C-Sky, and KVX - sadly - are once again
exceptions.

For cris it's a PLT reloc which is being replaced.

For msp430 also drop BFD_RELOC_MSP430_16_BYTE, which has already been
merely an alias of BFD_RELOC_16 (resolving to R_MSP430_16_BYTE).

bfd/Sparc: drop 64-bit BFD_RELOC_* aliases

For other relocations (e.g. BFD_RELOC_{8,16,32}{,_PCREL} or
BFD_RELOC_32_PCREL_S2) the generic enumerator is used. Plus use of such
aliases obfuscates where the generic types are actually in use.

bfd/ELF: fold BFD_RELOC_<arch>_GOTPC*

For many of the cases there's no need to have separate relocs per arch;
just like for other more or less generic ones a single one (per purpose;
a 64-bit generic one is being introduced) will do. C-Sky - sadly -
continues to be an exception.

bfd/s390+sh: don't abuse BFD_RELOC_32_GOT_PCREL

Neither R_390_GOT32 nor R_SH_GOT32 are PC-relative relocations, so don't
use a generic PC-relative enumerator for them. Doing so gets in the way
of properly using that enumerator.

bfd/ELF: fold BFD_RELOC_<arch>_GOTOFF*

For many of the cases there's no need to have separate relocs per arch;
just like for other more or less generic ones a single one (per purpose;
a 64-bit generic one is being introduced) will do. Arm64, C-Sky, and
KVX - sadly - continue to be exceptions.

Add function styling to error messages

This changes a number of error messages in gdb to use
function_name_style.

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