AVR: PR13129 - Overhaul c-avr.texi and document gs().

This patch adds documentation for gs() to the GAS manual
and overhauls gas/doc/c-avr.texi as a whole.

PR gas/13129
gas/
* doc/c-avr.texi: Overhaul and add gs() documentation.

elf32_arm_copy_special_section_fields wild read

This function has a number of loops with a controlling expression of
(i-- > 0) with tests in the loop to break out on finding something.
If that something is not found, the value of i is -1u on loop exit.
Code following the loop expects the "not found" value of i to be 0.
This can lead to an attempted access of oheaders[-1u].

oheaders is elf_elfsections(obfd), the ELF section header table.  We
are not interested here in anything at index zero of the array, so the
proper loop control is --i > 0, or equivalently, --i != 0.

* elf32-arm.c (elf32_arm_copy_special_section_fields): Correct
loop controlling expressions.

asan: index out of bounds in print_insn_tic6x

header.word_compact is a seven element array.  If fp_offset has values
of 29 to 31 then word_compact[7] is read to set num_bits which is then
never used since the function returns before its first use.

* tic6x-dis.c (print_insn_tic6x): Delay setting num_bits until
invalid fp_offset values are handled.

aarch64: segv on aarch64_stub_erratum_843419_veneer

With a patch I've had in my tree for a while that makes use of the
stub bfd for linker generated sections, I saw segfaults in the
testsuite linking ld-aarch64/erratum843419-adr and
ld-aarch64/erratum843419-far-adr.  Without my changes (that result in
stub_file->the_bfd->sections non-NULL), elf64_aarch64_build_stubs is
not called.  See aarch64elf.em finish function.  However, I believe it
is possible to hit the segfault with a testcase that generates other
stub types besides the aarch64_stub_erratum_843419_veneer.

The segfault occurs on the aarch64_build_one_stub assert that
stub_sec->output_section != NULL.  That happens because
_bfd_aarch64_add_stub_entry_after creates a stub_entry with stub_sec
NULL when fix_erratum_843419 is ERRAT_ADR.  Clearly we shouldn't be
doing anything in aarch64_build_one_stub when stub_sec is NULL, and
inspecting aarch64_size_one_stub reveals that these stubs are not
sized.

I found the test in aarch64_size_one_stub to exclude these stubs a
little obscure, needing to verify the possible values of
htab->fix_erratum_843419 to convince myself it was correct.  (It is.)
So I changed the test in both places to stub_entry->stub_sec being
non-NULL.   Which is how _bfd_aarch64_erratum_843419_branch_to_stub
distinguishes the variants of the stub.

* elfnn-aarch64.c (aarch64_build_one_stub): Don't segfault on
NULL stub_sec.
(aarch64_size_one_stub): Use the same condition here for
aarch64_stub_erratum_843419_veneer.

asan: buffer overflow in elf32_dlx_relocate26

* elf32-dlx.c (elf32_dlx_relocate26): Sanity check reloc offset.
(elf32_dlx_relocate16): Likewise.
(_bfd_dlx_elf_hi16_reloc): Likewise, and remove ineffective
existing check.

asan: use of uninitialised value in s_ifeqs

demand_copy_string returns NULL when a double-quoted string is not
found, and calls ignore_rest_of_line.  demand_copy_C_string can also
return NULL when finding an embedded \0, but doesn't call
ignore_rest_of_line for this condition.  This makes it difficult to
handle errors.

I believe ignore_rest_of_line should only be called at the level of
functions handling an entire line.  It will typically appear then only
in functions that call demand_empty_rest_of_line.  So this patch
removes the ignore_rest_of_file call in demand_copy_string, moving it
to callers of these functions.  Missing error handling is added in the
second part of the changelog below.

* read.c (demand_copy_string): Don't call ignore_rest_of_file.
(demand_copy_C_string): Don't zero length on error.
(s_file, s_incbin, s_include): Call ignore_rest_of_file on
demand_copy_string error.
(s_errwarn, s_print): Call ignore_rest_of_file on
demand_copy_C_string error.
(s_linefile): Move ignore_rest_of_line call for negative linenum
earlier and similarly for missing file, reducing block
indentation.
* config/tc-tic54x.c (tic54x_mlib): Call ignore_rest_of_line
after demand_copy_C_string error.
* dwarf2dbg.c (dwarf2_directive_filename): Likewise.
* stabs.c (s_stab_generic, s_xstab): Likewise.

* cond.c (s_ifeqs): Handle NULL return from demand_copy_C_string.
* config/tc-ia64.c (dot_pred_rel): Likewise.
* config/tc-ppc.c (ppc_rename, ppc_stabx, ppc_biei, ppc_bc): Likewise.
* config/tc-tic54x.c (tic54x_asg, tic54x_sect, tic54x_include),
(tic54x_message, tic54x_sblock, subsym_get_arg): Likewise.
* ecoff.c (ecoff_directive_file): Likewise.
* config/tc-alpha.c (s_alpha_file): Handle NULL return from
demand_copy_string.
* config/tc-ppc.c (ppc_file): Likewise.

asan: buffer overflow in m32r_elf_generic_reloc

The existing sanity check didn't take into account the size of the
reloc field.  So a field that started before the end of section, but
extended past it, accessed past the end of the contents buffer.

* elf32-m32r.c (m32r_elf_generic_reloc): Properly check reloc
offset.
(m32r_elf_do_10_pcrel_reloc): Likewise.

Automatic date update in version.in

gdbserver/linux-low: carry over stop_expected flag after exec (avoid spurious SIGSTOPs)

Running test gdb.base/vfork-follow-parent.exp on the native-gdbserver
board is flaky.  This test has GDB debugging a vfork parent and child.
When resuming the child, we expect it to run through an exec, and then
exit, like so:

    continue
    Continuing.
    [New inferior 2 (process 3286309)]
    process 3286309 is executing new program: /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.base/vfork-follow-parent/vforked-prog
    [Inferior 2 (process 3286309) exited normally]
    (gdb) PASS: gdb.base/vfork-follow-parent.exp: exec_file=vfork-follow-parent-exec: target-non-stop=off: non-stop=off: resolution_method=schedule-multiple: continue to end of inferior 2

Instead, we sometimes see it reporting a spurious SIGSTOP:

    continue
    Continuing.
    [New inferior 2 (process 3281383)]
    process 3281383 is executing new program: /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.base/vfork-follow-parent/vforked-prog

    Thread 2.1 "vforked-prog" received signal SIGSTOP, Stopped (signal).
    Cannot remove breakpoints because program is no longer writable.
    Further execution is probably impossible.
    0x00007ffff7fe0300 in ?? () from /lib64/ld-linux-x86-64.so.2
    (gdb) FAIL: gdb.base/vfork-follow-parent.exp: exec_file=vfork-follow-parent-exec: target-non-stop=off: non-stop=off: resolution_method=schedule-multiple: continue to end of inferior 2

Note that this case uses "target-non-stop=off", meaning that when one
thread reports a stop, GDBserver attempts to stop the other threads
itself before reporting the stop to GDB.  The bug is related to
GDBserver's bookkeeping of the threads.

When running the test 100 times, it failed 6 times.  Using taskset to
pin the process subtree to a single CPU seemed to make it more likely
to fail: on 100 runs, it failed 30 times.

The cause
=========

The steps occurring in the "pass" case are:

 1. Process P (Parent) is blocked inside the vfork system call, waiting
    for process C (Child) to exec or exit.
 2. Process C is currently stopped at its first instruction (right out
    of vfork).
 3. We resume process C (the "continue" seen in the logs above).
 4. Process C calls exec, as a result the kernel produces two events to
    be consumed by the tracer (GDBserver):

     - For P, a vfork done event (PTRACE_EVENT_VFORK_DONE)
     - For C, an exec event (PTRACE_EVENT_EXEC)

 5. Let's suppose here that waitpid happens to return the
    PTRACE_EVENT_EXEC for C first.
 6. Upon receiving the event, GDBserver calls stop_all_lwps, which sends
    a SIGSTOP to P, and sets `lwp->stop_expected` for P.
 7. GDBserver waits for P to stop, waitpid returns the
    PTRACE_EVENT_VFORK_DONE event.  GDBserver stashes it in
    lwp->status_pending.  The SIGSTOP for P is still pending at the
    kernel level.
 8. When we resume C, everything is fine, it runs until exit.
 9. When we resume P, GDBserver receives the SIGSTOP event for P, but
    suppresses it because `lwp->stop_expected` is set for P.

Now, for the failing case, imagine that at step 5 the kernel decided to
return the PTRACE_EVENT_VFORK_DONE event for P first.  The following
steps would play out like this:

 6. Upon receiving the event, GDBserver calls stop_all_lwps, which sends
    a SIGSTOP to C, and sets `lwp->stop_expected` for C.
 7. GDBserver waits for C to stop, waitpid returns the PTRACE_EVENT_EXEC
    event.
 8. In the handling of PTRACE_EVENT_EXEC (in
    linux_process_target::handle_extended_wait), GDBserver deletes the
    process and its threads (the mourn call), and creates a brand new
    process and lwp_info for C.  Note that this loses the previously set
    `lwp->stop_expected`.  The SIGSTOP for C is still pending at the
    kernel level.
 9. When we resume C, GDBserver receives the SIGSTOP event for C, and
    because `lwp->stop_expected` is not set, GDBserver doesn't recognize
    it as its own, and the stop is presented to the user.

The fix
=======

The (simplest) fix is to transfer the `lwp->stop_expected` from the old
lwp_info to the new one.  When doing so, when we resume C and GDBserver
receives the SIGSTOP event for C, it recognizes it as its own and
suppresses it.

Some care is needed in case process C is multi-threaded and the exec is
done by a non-leader thread.  When a non-leader thread execs, the kernel
scraps all other threads and renumbers this one to the tgid, so that it
becomes the new leader.  The PTRACE_EVENT_EXEC event is reported using
that new renumbered id.  But if a SIGSTOP was pending for the non-leader
exec'ing thread when the exec happened, it will still be pending
post-exec for that thread under its new post-exec leader identity.

Here is a hypothetical but more concrete scenario:

 - There are two threads, 100.100 (the leader) and 100.101.
 - Thread 100.101 is stopped at the entry of the execve system call (so
   the effects of execve haven't occurred yet) when GDBserver sends it a
   SIGSTOP and sets `lwp->stop_expected`.  The SIGSTOP becomes pending
   in the kernel.
 - When 100.101 is resumed, the exec occurs, the kernel deletes thread
   100.100 and renumbers 100.101 to 100.100.  The latter still has the
   SIGSTOP pending.
 - GDBserver receives a PTRACE_EVENT_EXEC event for thread 100.100.
 - Upon resumption, GDBserver then receives an event for the SIGSTOP,
   for thread 100.100.

All this to say that when transferring the `lwp->stop_expected` flag
from the old lwp_info to the new, we must take care to read the exec'ing
thread's flag.  If we use the id reported for the PTRACE_EVENT_EXEC to
look up an lwp_info, then we'll get the leader's lwp_info, which may not
have `lwp->stop_expected` set.  Instead, we must get the exec'ing
thread's original id using PTRACE_GETEVENTMSG, and use that to source
the right lwp_info to transfer the `lwp->stop_expected` flag.

There is a comment about using PTRACE_GETEVENTMSG with PTRACE_EVENT_EXEC
in gdb/linux-nat.c:

    ...
    tid to the tgid, and the previous leader vanishes.  Since
    Linux 3.0, the former thread ID can be retrieved with
    PTRACE_GETEVENTMSG, but since we support older kernels, don't
    bother with it, and just walk the LWP list.  Even with
    ...

Linux 3.0 was released in 2011, so I think it's fine to use that.

With the fix, I don't get any failures after 100 test runs (even with
taskset).

Kernel behavior experiments
===========================

The fix relies on assumptions about how the kernel orders ptrace events
and handles pending signals across exec.  I experimented with these
using standalone ptrace programs (mostly written by my buddy Claude).
The programs would drive a thread of the tracee to the execve syscall
entry, deliver a SIGSTOP to a thread, resume things and then look at
what events would come out of waitpid.  Here are the scenarios I tried:

  - Single-threaded: a tracee stopped at execve syscall entry is sent a
    SIGSTOP, then allowed to exec.  The kernel reports PTRACE_EVENT_EXEC first,
    then the SIGSTOP.

  - Multi-threaded, non-leader exec: a non-leader thread stopped at
    execve syscall entry is sent a SIGSTOP, then allowed to exec.  The
    kernel reports PTRACE_EVENT_EXEC, then the SIGSTOP, both under the
    leader id (the exec'ing non-leader got renumbered).

  - Multi-threaded, leader has a pending SIGSTOP while a non-leader
    execs: the leader is sent a SIGSTOP, which stays pending, then we
    let the non-leader thread exec (giving it a few seconds to be sure).
    The kernel reports PTRACE_EVENT_EXEC under the leader id (the
    exec'ing non-leader got renumbered) and the SIGSTOP has vanished.

What about GDB
==============

I tried to check if the same bug could happen with GDB's linux-nat
target, and if the same fix was needed.  linux-nat takes a different
approach when handling PTRACE_EVENT_EXEC.  It wipes all lwp_infos except
the leader:

      for (lwp_info &other_lp : all_lwps_safe ())
if (&other_lp != lp && other_lp.ptid.pid () == lp->ptid.pid ())
  exit_lwp (&other_lp);

Here, LP is an lwp_info obtained using the event ptid of the
PTRACE_EVENT_EXEC, therefore the leader's lwp_info (even if the exec was
done by a non-leader).

If the exec is done by the leader, as is the case with
gdb.base/vfork-follow-parent.exp, we are ok.  Because GDB doesn't delete
and re-create the lwp_info, the equivalent of GDBserver's
`lwp_info::stop_expected`, `lwp_info::signalled`, survives the exec.

If the exec is done by a non-leader, then we could be in trouble.  If
the leader's signalled flag is not set, but the exec'ing non-leader's
flag is set, then we'll lose it.  I suppose we could fix GDB to use
PTRACE_GETEVENTMSG to get the exec'ing thread former id, look up the
lwp_info for that id, and preserve that lwp_info.

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

Automatic date update in version.in

Disable gdb.ada/dgopt.exp with gnat-llvm

gdb.ada/dgopt.exp fails with gnat-llvm.

Looking into it, it turns out that this test case relies on a bug in
GNAT.  In particular, despite the use of -gnatDG, GNAT will still put
a reference to "x.adb" into both the DWARF .debug_info and into the
line table.  The test relies on this, because the original problem
being fixed here is that, when the test was written, there was a bug
causing these references to be dropped when writing .debug_names.

gnat-llvm does not have this same bug -- it only emits references to
x.adb.dg.

This patch disables this test for gnat-llvm.  There's not really a
good way to tell that gnatmake is llvm-based, so while I've added a
new caching proc for this, it is just a proxy for an existing proc.

Since this only affects gnat-llvm, and was discussed internally, I am
going to check it in.

Printing of Fortran arrays with dynamic elements

This bug points out a case where a Fortran array has dynamic elements,
and each element must have its dynamic type resolved separately.

I took the test case directly from the bug, figuring it was ok as the
author is at AMD and has some tags in the repository already.

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

Handle nested Ada functions with gnat-llvm

In Ada, a nested function can refer to variables in lexically
enclosing outer scopes.  Ordinarily this is implemented in DWARF using
DW_AT_static_link, so that the correct outer function invocation can
be found from the nested function.

However, LLVM does not implement the DWARF DW_AT_static_link feature,
so this approach isn't possible.

gnat-llvm, though, implements "unnesting" manually, passing an
activation record parameter to nested functions.  This activation
record can be used to find the correct outer frame.

This patch adds a new language method to enable this.  A new test case
is included; this test will fail if the static link or some similar
feature is not implemented (i.e., a naive unwind looking for the next
instance of the outer function will fail).

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

Remove ARI

I was reminded that while we turned off ARI reports a little while
ago, we never did remove ARI from gdb itself.  This patch does so.

ARI was an attempt at enforcing some gdb coding standards.  However,
it seemed to get in the way more than it helped.

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

gdb: Fix build for aarch64-windows

When reload_context was removed from windows_thread_info, it
was missed at one point in aarch64-windows-nat.c:

../../gdb/aarch64-windows-nat.c:260:20: error: no member named 'reload_context' in 'windows_nat::windows_thread_info'
  260 |   gdb_assert (!th->reload_context);
      |                ~~  ^

This removes it.

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

gdb+gdbserver: Fix build for aarch64-windows

Some time ago siginfo_re was made per-thread state, but
not every use location was adjusted, giving this error:

../../gdb/aarch64-windows-nat.c:139:31: error: no member named 'siginfo_er' in 'aarch64_windows_per_inferior'
  139 |   if (aarch64_windows_process.siginfo_er.ExceptionCode != EXCEPTION_BREAKPOINT
      |       ~~~~~~~~~~~~~~~~~~~~~~~ ^

Fix by looking up the exception-record of the current thread.

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

RISC-V: Minor fix the gas march-help.l testcase

MAINTAINERS: Update my email address

Automatic date update in version.in

gdb: fix indentation in dwarf2/expr.c

Fix some mis-indented lines, pointed out in a review.

Change-Id: I523f461881dab4b23e59efa76914b1d5ce8cc817

windows gdb: Fix -target-attach result

This patch fixes a Windows issue with "-target-attach <pid>", where
"running" is emitted instead of "done". The "done" message should be
synchronous for "-target-attach", but "mi_proceeded" variable is
incorrectly set to "1" when clear_proceed_status(0, true) is
called. As a result, "mi_interp::on_about_to_proceed" sets mi_proceed
to 1, and later "mi_interp::on_resume" emits "running" instead of
"done".

Remove redundant clear_proceed_status(0) call (the notify argument is
set to true by default). The init_wait_for_inferior(), which runs on
the very next line, already calls clear_proceed_status (0, false). A
new test is added too.

Signed-off-by: Claudiu Zissulescu <claudiu.zissulescu-ianculescu@amd.com>
Approved-By: Pedro Alves <pedro@palves.net>
Approved-By: Simon Marchi <simon.marchi@efficios.com>

AVR: Fix GNU coding style.

This patch uses TABs for indentation in all places instead of blanks.

gas/
* config/tc-avr.c: Fix indentations to follow GNU style.
* config/tc-avr.h: Same.

gas/ELF: Allow local symbol with non-protected visibility

In the source code extracted from glibc:

extern void _dl_sysinfo_int80 (void)
  __attribute__ ((visibility ("hidden")));

asm (".text\n\t"
     ".type _dl_sysinfo_int80,@function\n"
     "_dl_sysinfo_int80:\n\t"
     "int $0x80;\n\t"
     "ret");

uintptr_t
foo ()
{
  return (uintptr_t) _dl_sysinfo_int80;
}

_dl_sysinfo_int80 is a local function, but it is defined in an asm
statement.  Since it is referenced in C, it is declared as hidden,
which leads to an assembler warning:

Warning: local symbol `_dl_sysinfo_int80' has non-default visibility

Symbol binding and visiblity are orthogonal.  One is for link-editing,
the other for runtime linking.  In principle, all combinations are "okay"
(if questionable), and have obvious implementations.  But it's only that
specific combination STB_LOCAL+STV_PROTECTED that is explicitely made
ill-formed in the spec (despite it being also obviously implementable).
Warning on that combination can be done on the grounds of following the
spec.  But no other combination is so spelled out, so there's no basis
for trying to disallow them.

Partially revert:

commit c4150acbda1b3ce0602f79cbb7700b39e577be7e
Author: Jan Beulich <jbeulich@suse.com>
Date:   Fri May 8 11:45:04 2026 +0200

    gas/ELF: warn upon non-default visibility of local symbols

and update elf_adjust_symtab to only warn local symbol with protected
visibility.

binutils/

PR gas/34312
* testsuite/binutils-all/localize-hidden-1.l: Adjusted.
* testsuite/binutils-all/nm-ver.s: Revert commit c4150acbda1.

gas/

PR gas/34312
* config/obj-elf.c (elf_adjust_symtab): Allow local symbol with
non-protected visibility.
* testsuite/gas/elf/visibility.l: Adjusted.
* testsuite/gas/i386/tlsnopic.s: Revert commit c4150acbda1.

ld/

PR gas/34312
* testsuite/ld-aarch64/ifunc-21.s: Revert commit c4150acbda1.
* testsuite/ld-aarch64/ifunc-21.s: Likewise.
* testsuite/ld-tic6x/shlib-1.rd: Likewise.
* testsuite/ld-tic6x/shlib-1.s: Likewise.
* testsuite/ld-tic6x/shlib-1b.rd: Likewise.
* testsuite/ld-tic6x/shlib-1r.dd: Likewise.
* testsuite/ld-tic6x/shlib-1r.rd: Likewise.
* testsuite/ld-tic6x/shlib-1rb.dd: Likewise.
* testsuite/ld-tic6x/shlib-1rb.rd: Likewise.
* testsuite/ld-tic6x/shlib-noindex.rd: Likewise.
* testsuite/ld-tic6x/static-app-1.rd: Likewise.
* testsuite/ld-tic6x/static-app-1b.rd: Likewise.
* testsuite/ld-tic6x/static-app-1r.dd: Likewise.
* testsuite/ld-tic6x/static-app-1r.rd: Likewise.
* testsuite/ld-tic6x/static-app-1rb.dd: Likewise.
* testsuite/ld-tic6x/static-app-1rb.rd: Likewise.

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

Automatic date update in version.in

RISC-V: Add support for Smpmpmt v0.6 extension

This implements the Smpmpmt (PMP-based Memory Types) extension,
version 1.0[1].

The Smpmpmt extension provides a mechanism to control memory
attributes at the granularity of PMP regions, analogous to Svpbmt
but associated with PMP registers rather than page-table entries.

The extension is currently in frozen state[2].

[1] https://github.com/riscv/riscv-isa-manual/blob/smpmpmt/src/smpmpmt.adoc
[2] https://riscv.atlassian.net/browse/RVS-2948

[JL] Since this patch was originally posted, the spec has moved to v1.0.  I've
adjusted the patch & ChangeLog accordingly.

bfd/ChangeLog:

* elfxx-riscv.c: Add Smpmpmt v1.6 extension.

gas/ChangeLog:

* NEWS: Updated.
* testsuite/gas/riscv/march-help.l: Ditto.

Signed-off-by: Jerry Zhang Jian <jerry.zhangjian@sifive.com>

gdbsupport: Remove some use after move instances

We ran the Coverity static analysis tool on GDB and it pointed out some
instances of "use after move" in GDB. The instances that could be easily
removed are related to move constructors for exceptions, that were using
the parameter's reason in an assert, when they could instead just use
their own internal "reason" member. One such example is the following:

Error: USE_AFTER_MOVE (CWE-457):
gdb-17.1/gdbsupport/common-exceptions.h:281:7: move: "ex" is moved (indicated by "std::move(ex)").
gdb-17.1/gdbsupport/common-exceptions.h:283:5: use_after_move: "ex" is used after it has been already moved.
 #  281|       : gdb_exception (std::move (ex))
 #  282|     {
 #  283|->     gdb_assert (ex.reason == RETURN_ERROR);
 #  284|     }
 #  285|   };

This patch fixes that small oversight.

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

Make target shareable accross fork inferiors in AIX.

Currently in AIX when we follow a child or do not dtach the child during multi-process debugging we get,

(gdb) set detach-on-fork off
(gdb) r
Starting program: /gdb_tests/multi-thread-fork
[New inferior 2 (process 32965026)]
target.c:1194: internal-error: Attempt to push unshareable target: native.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
----- Backtrace -----
0x10092c69b gdb_internal_backtrace_1
        /home/binutils-gdb/gdb/bt-utils.c:122
0x10092c7bf _Z22gdb_internal_backtracev
        /home/binutils-gdb/gdb/bt-utils.c:175
0x10004fdef internal_vproblem
        /home/binutils-gdb/gdb/utils.c:424
0x100050307 _Z15internal_verrorPKciS0_Pc
        /home/binutils-gdb/gdb/utils.c:504

The reason being AIX missed out on making the rs6000_nat_target sharable for the child.

So align AIX native fork handling with Linux by marking rs6000_nat_target shareable.
This avoids internal errors during fork (), during detach-on-fork off and follow-fork-mode child.

Approved By: Ulrich Weigand <Ulrich.Weigand@de.ibm.com>

Fix AIX SIGSEGV for multi thread debugging.

When we run threads debugging in AIX we get,

Reading symbols from //gdb_tests/continue-pending-status...
(gdb) r
Starting program: /gdb_tests/continue-pending-status

Program received signal SIGSEGV, Segmentation fault.
0x7fe00008 in ?? ()
(gdb) q
A debugging session is active.

The reason being in AIX, the __pthread_init symbol returned by pthdb_session_pthreaded() is a function descriptor
and not the the direct code address. When GDB set a breakpoint using ms.value_address(), it was setting the breakpoint on the descriptor itself (0xf16365dc) rather than the actual function code. This caused the program to crash at an invalid address (0x7fe00008) when trying to execute from the descriptor location.

Debugging further and looking at the history, GDB-17.1/GDB-17.2 knew __pthread_init was a function because STABS symbol was recored with proper type, so we knew it was a function descriptor. After STABS removal symbol is recoreded without type and ms.value_address() returns descriptor address directly.

if (cs->c_naux > 1 && ISFCN (cs->c_type))
      {
        fcn_start_addr = cs->c_value;
      }
case XMC_PR:
  /* A function entry point.  */

  record_minimal_symbol
    (reader, namestring, unrelocated_addr (symbol.n_value),
     sclass == C_HIDEXT ? mst_file_text : mst_text,
     symbol.n_scnum, objfile);
  misc_func_recorded = 1;
  break;

The code snippet above was one of the things STABS used to do that helped identify the entry point before.

This patch is the fix to the same.

Approved By: Ulrich Weigand <Ulrich.Weigand@de.ibm.com>

gdb: convert sentinel_frame to a frame_info_ptr

The global sentinel_frame object is currently held as a raw frame_info
pointer.  In contrast, most frames are managed through a
frame_info_ptr, and the global selected_frame is itself a
frame_info_ptr.

This commit converts the sentinel_frame to a frame_info_ptr.

The frame_info_ptr constructor registers the new object in the global
frame_list, so we need to ensure that the frame_list has been
constructed before the sentinel_frame (now a frame_info_ptr) is
constructed.  This is achieved by moving the frame_list global earlier
within the frame.c file.

I chose to also move the selected_frame, selected_frame_id, and
selected_frame_level globals.  This isn't required, but keeps similar
and related objects (the frame_list, selected_frame*, and
sentinel_frame) together in the file.

In get_current_frame, when assigning to the sentinel_frame global, we
no longer need to pull the raw frame_info pointer from the result of
calling create_sentinel_frame, this means we can drop the '.get ()'
call.  I took this opportunity to move the '=' operator onto the next
line inline with GDB style.

Additionally, in get_current_frame, we no longer need to convert
sentinel_frame into a frame_info_ptr.

There should be no user visible changes after this commit.

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

gdb: remove sentinel frame check in frame_find_by_id

While reviewing another patch Simon pointed out that the code in
frame_find_by_id for looking up the sentinel frame is no longer needed
since commit:

  commit 19f988359a62889b00d67fb59ef8c7d6d759fc98
  Date:   Mon Jan 30 15:02:49 2023 -0500

    gdb: give sentinel for user frames distinct IDs, register sentinel frames to the frame cache

Prior to this commit the sentinel_frame was not added to the frame
stash, so we needed a manual check to lookup the sentinel frame.
After this commit the sentinel frame is added to the stash so the
manual check, though perfectly valid, is just unnecessary complexity,
and can be removed.  A frame stash lookup is just a hash lookup, and
is relatively cheap, so switching to this isn't much extra cost.

While I was working in frame_find_by_id I made a couple of additional
changes:

  1. I moved the declarations of frame and prev_frame locals into the
     function body, closer to where they are first defined.

  2. Instead of treating a frame_info_ptr as a bool, I use a
     comparison against nullptr, which is inline with GDB's policy of
     not treating pointers as bools.

There should be no user visible changes after this commit.

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

Automatic date update in version.in

Fix amd_dbgapi_target::wait's handling of TARGET_WAITKIND_IGNORE

On Windows, a ROCgdb downstream testcase
(gdb.rocm/register-watchpoint.exp, which we can't upstream yet due to
missing support for DWARF 6 features upstream) currently fails with a
timeout, like so:

  (gdb) PASS: gdb.rocm/register-watchpoint.exp: continue to breakpoint: bit_extract_kernel
  watch $s32
  Watchpoint 3: $s32
  (gdb) PASS: gdb.rocm/register-watchpoint.exp: watchpoint on a stack pointer of the first wave
  continue
  Continuing.
  FAIL: gdb.rocm/register-watchpoint.exp: continue (timeout)

Running the test manualy with some extra logging, we see:

  [infrun] stop_all_threads:   6/7 waits_needed                          << extra
  [amd-dbgapi] wait: ptid = -1.0.0
  [windows events] get_windows_debug_event: kernel event for pid=7036 tid=0x4e8 code=EXCEPTION_DEBUG_EVENT
  [windows events] get_windows_debug_event: get_windows_debug_event - unexpected stop in suspended thread 0x4e8
  [windows events] continue_last_debug_event: ContinueDebugEvent (cpid=7036, ctid=0x4e8, DBG_REPLY_LATER)
  [windows events] wait: get_windows_debug_event returned [0.0.0 : status->kind = IGNORE, fake=0]
  [infrun] print_target_wait_results: target_wait (-1.0.0 [process -1], status) =
  [infrun] print_target_wait_results:   0.0.0 [process 0],
  [infrun] print_target_wait_results:   status->kind = IGNORE
  [infrun] print_target_wait_results:   from target 1 (native)
  [infrun] wait_one: about to block in interruptible_select              << extra

So we're in stop_all_threads, and we've pulled the stop events for all
CPU threads already, but then we hang in interruptible_select waiting
for the last stop event, which happens to be for the GPU wave.

In wait_one, before the interruptible_select call, we poll events from
the target, via target_wait with WNOHANG, and so we get here:

    ptid_t
    amd_dbgapi_target::wait (ptid_t ptid, struct target_waitstatus *ws,
     target_wait_flags target_options)
    {
  ...
      ptid_t event_ptid = beneath ()->wait (ptid, ws, target_options);
      if (event_ptid != minus_one_ptid)
{
  ...
  return event_ptid;
}
  ... handle dbgapi events ...

So above, we call the beneath target's wait.  On Windows that may hit
that "get_windows_debug_event - unexpected stop in suspended thread
0x4e8" path, which makes windows_nat_target::wait return
TARGET_WAITKIND_IGNORE.  The Windows target pairs that with event_ptid
== ptid_t(0,0,0) though, so the 'if then' branch is taken and we
return the TARGET_WAITKIND_IGNORE to the core without looking for
dbgapi events.  The event for the wave stop at this point has already
been flushed from the dbgapi library into amd-dbgapi-target's dbgapi
local event queue, and so wait_one ends up deadlocked in
interruptible_select, which results in the timeouts observed.

Nothing specifies that TARGET_WAITKIND_IGNORE must be returned with
minus_one_ptid.  infrun never looks at the event ptid if the status is
TARGET_WAITKIND_IGNORE.  So fix this by tweaking
amd_dbgapi_target::wait to not assume that either.

Approved-by: Lancelot Six <lancelot.six@amd.com> (amdgpu)
Change-Id: I6cbbeebdc8146e361ead72829b59f82531c90fc7

AVR: PR17107 - Add more .gnu.linkonce to avr.sc

This patch adds pattern rules for .gnu.linkonce.t* and .gnu.linkone.b*
to the .text resp. .bss output sections.  Though that's probably
not needed any more since G++ is using COMDAT today.
.gnu.linkonce.d* for .data and .gnu.linkone.r* for .rodata are
already there.

PR ld/17107
ld/
* scripttempl/avr.sc (.bss) [RELOCATING]: Add *(.gnu.linkonce.b*).
(.text) [RELOCATING]: Add *(.gnu.linkonce.t*).

Automatic date update in version.in

Update use of deque in _frame_iterator

_frame_iterator has an old comment about some hand-written code that
was needed when supporting Python 2.6.  This patch simplifies the code
by using a couple of features of collections.deque.

RISC-V: Support Zvabd extension instructions.

This patch adds support for the Zvabd extension instructions:
https://github.com/riscv/integer-vector-absolute-difference

The Zvabd extension provides RISC-V vector integer absolute difference
operations.

The widening accumulate mnemonics follow the current frozen specification
are vwabda.vv and vwabdau.vv.

bfd/ChangeLog:

* elfxx-riscv.c (riscv_multi_subset_supports): Add Zvabd implication
  of zve32x.
(riscv_multi_subset_supports_ext): Add Zvabd.

gas/ChangeLog:

* NEWS:
* testsuite/gas/riscv/march-help.l: Add Zvabd.
* testsuite/gas/riscv/zvabd.d: New test.
* testsuite/gas/riscv/zvabd.s: New test.

include/ChangeLog:

* opcode/riscv-opc.h (MATCH_VABS_V): New macro.
(MASK_VABS_V): Ditto.
(MATCH_VABD_VV): Ditto.
(MASK_VABD_VV): Ditto.
(MATCH_VABDU_VV): Ditto.
(MASK_VABDU_VV): Ditto.
(MATCH_VWABDA_VV): Ditto.
(MASK_VWABDA_VV): Ditto.
(MATCH_VWABDAU_VV): Ditto.
(MASK_VWABDAU_VV): Ditto.
* opcode/riscv.h (enum riscv_insn_class): New extension.

opcodes/ChangeLog:

* riscv-opc.c: New instructions.

RISC-V: Support Svrsw60t59b extension.

This patch adds RISC-V Svrsw60t59b extension minimal support.

https://github.com/riscv/riscv-isa-manual/blob/f30292bb486d735e186f06f705fcd7beff1e3e97/src/supervisor.adoc#L2550

bfd/ChangeLog:

* elfxx-riscv.c: New ext.

gas/ChangeLog:

* NEWS: New ext.
* testsuite/gas/riscv/march-help.l: Ditto.

RISC-V: Add SpacemiT vendor extension xsmtvdotii

SpacemiT defines Intrinsic Matrix Extension (IME) specification [1].
SpacemiT A100 implements version 1.0 of the SpacemiT Vector Dot Product
II Extension (XsmtVdotII v1.0) [2], a subset of the full IME specification.

[1] https://github.com/spacemit-com/riscv-ime-extension-spec/releases/download/v1.0/spacemit-ime-asciidoc.pdf
[2] https://github.com/spacemit-com/docs-ai/blob/main/en/architecture/ime_extension.md

RISC-V: Add SpacemiT vendor extension xsmtvdot

SpacemiT defines Intrinsic Matrix Extension (IME) specification [1].
SpacemiT X60 implements version 1.0 of the SpacemiT Vector Dot Product
Extension (XsmtVdot v1.0) [2], a subset of the full IME specification.

[1] https://github.com/spacemit-com/riscv-ime-extension-spec/releases/download/v1.0/spacemit-ime-asciidoc.pdf
[2] https://github.com/spacemit-com/docs-ai/blob/main/en/architecture/ime_extension.md

RISC-V: Support Zalasr extension.

This patch supports Zalasr extension(load-acquire/store-release) instructions.

https://github.com/riscv/riscv-zalasr

bfd/ChangeLog:

        * elfxx-riscv.c (riscv_multi_subset_supports): New ext.
        (riscv_multi_subset_supports_ext): Ditto.

gas/ChangeLog:

        * NEWS: Support Zalasr extension.
        * testsuite/gas/riscv/march-help.l: New ext.
        * testsuite/gas/riscv/zalasr.d: New test.
        * testsuite/gas/riscv/zalasr.s: New test.

include/ChangeLog:

        * opcode/riscv-opc.h (MATCH_LBA): New match opcode.
        (MASK_LBA): New mask opcode.
        (MATCH_LHA): New match opcode.
        (MASK_LHA): New mask opcode.
        (MATCH_LWA): New match opcode.
        (MASK_LWA): New mask opcode.
        (MATCH_LDA): New match opcode.
        (MASK_LDA): New mask opcode.
        (MATCH_SBR): New match opcode.
        (MASK_SBR): New mask opcode.
        (MATCH_SHR): New match opcode.
        (MASK_SHR): New mask opcode.
        (MATCH_SWR): New match opcode.
        (MASK_SWR): New mask opcode.
        (MATCH_SDR): New match opcode.
        (MASK_SDR): New mask opcode.
        (DECLARE_INSN): New insn declare.
        * opcode/riscv.h (enum riscv_insn_class): New ext.

opcodes/ChangeLog:

        * riscv-opc.c: New instructions def.

Automatic date update in version.in

AVR: PR34307 - Fix diagnostic for opcode unknown to MCU

When there is an AVR instruction in include/opcode/avr.h that
is not supported by a specific MCU, then gas will diagnose
with the mnemonic of the next instruction:

    mul 1,2
    mulsu 1,1
    lat

$ avr-as x.sx
x.sx: Assembler messages:
x.sx:1: Error: illegal opcode or for mcu avr2
x.sx:2: Error: illegal opcode fmul for mcu avr2
x.sx:3: Error: illegal opcode movw for mcu avr2

The reason is that in gas/config/tc-avr.c::md_assemble() we have:

   while ((opcode->isa & avr_mcu->isa) != opcode->isa)
     {
       opcode++;

       if (opcode->name && strcmp(op, opcode->name))
         {
           as_bad (_("illegal opcode %s for mcu %s"),
                   opcode->name, avr_mcu->name);
           return;
         }
     }

which in the as_bad case prints the next instruction's mnemonic
due to the opcode++ above.

gas/
* config/tc-avr.c (md_assemble): Use right index to diagnose
an opcode that are not supported by the MCU.
* testsuite/gas/avr/pr34307-1.d: New test.
* testsuite/gas/avr/pr34307-1.s: New test source.
* testsuite/gas/avr/pr34307-2.d: New test.
* testsuite/gas/avr/pr34307-2.s: New test source.

Log gdb_do_cache misses only, not hits

The verbose -log in gdb_do_cache fired unconditionally on every call,
including cache hits.  With many tests calling gdb_caching_procs like
get_compiler_info_1 per compilation, this produced dozens of repeated
identical lines per test file in the log, like so:

gdb_do_cache: get_compiler_info_1 ( c )
gdb_do_cache: get_compiler_info_1 ( c )
gdb_do_cache: get_compiler_info_1 ( c )
gdb_do_cache: get_compiler_info_1 ( c )
gdb_do_cache: get_compiler_info_1 ( c )
gdb_do_cache: get_compiler_info_1 ( c )
gdb_do_cache: get_compiler_info_1 ( c )
gdb_do_cache: get_compiler_info_1 ( c )

Move the log to just before actual computation, after both the
in-memory and on-disk cache checks. This helps keep the logs clean.

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

Automatic date update in version.in

libiberty: sync with gcc commit df3510f80e7c02d9

Sync the libiberty/ directory with gcc commit
df3510f80e7c02d9c19d7cb33759cd925880f53a.  This pulls in the following
gcc commits and the associated updates to 'libiberty/ChangeLog':

  * 06fb00cb66d libiberty: Fix typos in various files
  * fbf903e5b9f Re-flow lines made longer than 80 characters by typo fixes
  * cfb945957ee Regenerate some autoconf configure scripts after recent spelling fixes.
  * bc4d9b6aeb3 libiberty: avoid exponential back reference issue in D demangler

I have retained the changes that are in the following binutils-gdb
commit, which are not in gcc:

  commit 219822fd5db6305592b45677a3b38c02b523360e
  Date:   Tue Apr 9 06:39:21 2024 -0700

    mmap: Avoid the sanitizer configure check failure

Automatic date update in version.in

gdb/testsuite: fix gdb.rocm/code-object-load-while-breakpoint-hit.exp with native-gdbserver

ROCm tests don't work under the native-gdbserver board, but switch it to
use the new -inferior-args option anyway, to give the good example.

Change-Id: I684cd5e4328e033072735d5feca8037ca77b57c1
Reviewed-By: Tankut Baris Aktemur <TankutBaris.Aktemur@amd.com>

gdb/testsuite: use -inferior-args in gdb.base/gcore-buffer-overflow.exp

This test passes arguments to the inferior using "set args".  This
doesn't work under the native-gdbserver board.  It doesn't appear to
cause a failure though, because the test only verifies that a core dump
is successfully saved, which happens even if the test fails to pass the
argument to the test program.

Nevertheless, use the new -inferior-args option, that feels more
correct.

Change-Id: I8ef5b57d84b1b0c5b35d2636c4331a37bc159661
Reviewed-By: Tankut Baris Aktemur <TankutBaris.Aktemur@amd.com>

gdb/testsuite: make pie-execl.exp work with native-gdbserver

This test passes the path of an executable to execute as argv[1] to the
inferior.  This test is currently skipped with remote targets (e.g.
native-gdbserver), because it previously wasn't possible to pass
arguments to inferiors on such targets in the testsuite.  Remove that
check, and use the new -inferior-args runto option to pass the args to
the inferior.

Add

  require {!target_info exists noargs}

to reflect that the test relies on inferior args.

Change-Id: If3b884421b453d6ca93c19ca13314bbb7869218c
Reviewed-By: Tankut Baris Aktemur <TankutBaris.Aktemur@amd.com>

gdb/testsuite: fix step-over-thread-exit.exp with native-gdbserver

This test uses "set args N" to control how many threads the inferior
spawns: 1 in some cases and 100 in others.  However, "set args" doesn't
work with the native-gdbserver board.  As a result, with that board, the
inferior always uses its default of 100 threads.  It sometimes causes
failures like:

    p $_thread == 2
    $1 = 1
    (gdb) [New Thread 2790806.2790823 (id 3)]

    Thread 3 "step-over-threa" hit Breakpoint 2, 0x00005555555552ab in my_exit_syscall () at /.../testsuite/lib/my-syscalls.S:85
    85      SYSCALL (my_exit, __NR_exit)
    FAIL: gdb.threads/step-over-thread-exit.exp: step_over_mode=inline: non-stop=on: target-non-stop=on: schedlock=off: cmd=next: ns_stop_all=0: selected thread didn't change (timeout)

Here, GDB steps over thread 2's exit.  As soon as thread 2 exits, the
main thread spawns a new thread (thread 3), which hits the breakpoint
placed over the exit syscall, and that event gets reported
asynchronously, confusing the testsuite.  The point of setting n_threads
to 1 is exactly to avoid things like that.

Fix it by passing the args via the new -inferior-args option, which
works correctly with the native-gdbserver board.

Change the test program to requiring the number of threads to be passed
as an argument, which would have caught this problem.

Change-Id: Ifc8856aa582706fd7207d0035d35dee749eb83a5
Reported-By: Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
Reviewed-By: Tankut Baris Aktemur <TankutBaris.Aktemur@amd.com>

gdb/testsuite: add -inferior-args option to runto

Add a new -inferior-args option to proc runto, to allow passing
arguments to the test program.  Its value is forwarded to gdb_run_cmd,
which does the right thing, including with the native-gdbserver board,
where arguments need to be passed on the gdbserver command line.

The option is named -inferior-args (rather than the shorter -args)
because parse_args sets a variable in the caller's scope using the
option name.  Naming it "-args" would clash with the "args" parameter.

Subsequent patches use this new option.

Change-Id: If2483c22302ed432ccd6cebef8d235e3e1d35bb8
Reviewed-By: Tankut Baris Aktemur <TankutBaris.Aktemur@amd.com>

gdb/testsuite: make gdb_breakpoint, runto and runto_main use parse_args

In preparation to adding an option with argument to runto, change these
procs to use parse_args to manage their args (variable arguments).
These three procs have to be converted at the same time, because they
pass args to each other.

I would have like to allow passing options mixed with non-option
arguments, to allow:

  gdb_breakpoint -qualified the_function

But that would be a larger and more difficult change, so we'll have to
stick having options after, like this:

  gdb_breakpoint the_function -qualified

Change all callers that do use options to add the leading dash.

This patch removes the "last one wins" aspect of the message/no-message
options in gdb_breakpoint and runto, but I don't think it's important.
I don't think there is actually a spot that passes both.  I added some
checks in those procs to ensure that.

Change-Id: I1500c60c4b1705ad5cd982d9324b627900ce411b
Reviewed-By: Tankut Baris Aktemur <TankutBaris.Aktemur@amd.com>

gdb/testsuite: remove unused arguments to gdb_breakpoint

These arguments don't actually do anything, remove them.

Change-Id: Ifd6a18d3effc521ba410fd40280a197d37661b12
Reviewed-By: Tankut Baris Aktemur <TankutBaris.Aktemur@amd.com>

gas: arm: Support CPU-specific extensions with -mcpu

Previously, +ext/+noext feature modifiers were only available with
-march. Extend the same mechanism to -mcpu so that CPU-specific
extensions can be enabled and disabled with -mcpu=<cpu>+ext and
-mcpu=<cpu>+noext, matching GCC behaviour.

Add a per-CPU extension table (arm_ext_table) and a new ext_table
field to struct arm_cpu_option_table, reusing the existing
arm_parse_extension () infrastructure used by -march. Move the
ARM_EXT/ARM_ADD/ARM_REMOVE helpers, the ALL_FP/ALL_SIMD/ALL_FP_MVE_FP
masks and the CDE_EXTENSIONS list so they can be shared by both
-mcpu and -march extension tables.

Update ARM CPU feature definitions to match GCC CPU baselines. The
default feature set for each -mcpu remains unchanged; only support for
+ext/+noext modifiers is added.

Add tests covering supported CPU extension modifiers and the resulting
build attributes for each CPU.

gas/
    * config/tc-arm.c (struct arm_cpu_option_table): Add ext_table
    field.
    (ARM_EXT, ARM_ADD, ARM_REMOVE, ALL_FP, ALL_SIMD,
    ALL_FP_MVE_FP, CDE_EXTENSIONS): Move earlier.
    (cortex_*_ext_table, ...): New.
    (arm_cpus): Populate ext_table and update CPU feature baselines
    to match GCC.
    (arm_parse_cpu): Pass opt->ext_table to arm_parse_extension.

gas/testsuite/
    * gas/arm/feat-*.s: New test sources.
    * gas/arm/mcpu-*.d: New tests.
    * gas/arm/attr-cpu-directive.d: Update.

###
This version address the review comments from:
Message-ID: <2846ac09-3590-409d-8ecf-cc385c8929e8@arm.com>
https://inbox.sourceware.org/binutils/2846ac09-3590-409d-8ecf-cc385c8929e8@arm.com/
###

gdb: make symtab::compunit return a reference

The compunit symtab backlink of a symtab is never null (the constructor
asserts it), so make symtab::compunit return a reference instead of a
pointer, and have the symtab constructor take the compunit_symtab as a
reference too.  Update all callers accordingly.

This came up earlier in review, where a caller would check the result of
`symtab->compunit ()` for nullptr, and I pointed out that it was
unnecessary.  Returning a reference makes this clear.

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

x86-64: Intel64 adjustments for conditional jumps

Just like for unconditional direct JMP (and CALL), AMD and Intel differ
in their handling. Mirror JMP handling to Jcc (thus also better resolving
ambiguities outside of 64-bit mode).

x86: optimize XADD to ADD for same-register forms

ADD requires less execution resources and is shorter to encode.

x86: optimize XCHG to MOV for same-register forms

MOV requires far less execution resources.

Automatic date update in version.in

ld: Use 0x10000 as absolute symbol value in PR ld/25754 tests

PR ld/25754 tests verify that relocations against absolute symbol are
properly handled, using 42 as the absolute symbol value.  But GCC 17
treats 42 as the impossible symbol address, which is the absolute symbol
value and optimize out the symbol address check:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125869

Use 0x10000, instead of 42, as absolute symbol value to work with GCC 17.

PR ld/34298
* testsuite/ld-elf/pr25754-1a.c (main): Check against 0x10000
instead of 42.
* testsuite/ld-elf/pr25754-1b.s (bar): Replace 42 with 0x10000.

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

[gdb] Fix trailing whitespace in refcard.tex

Fix:
...
gdb/doc/refcard.tex:314: trailing whitespace.
+b \opt{\it file\tt:}{\it line}&set breakpoint at {\it line} number \opt{in \it file}\par
gdb/doc/refcard.tex:344: trailing whitespace.
+enable \opt{{\it n}}&enable breakpoints
gdb/doc/refcard.tex:347: trailing whitespace.
+enable once \opt{{\it n}}&enable breakpoints \opt{or breakpoint {\it n}};
gdb/doc/refcard.tex:350: trailing whitespace.
+enable del \opt{{\it n}}&enable breakpoints \opt{or breakpoint {\it n}};
gdb/doc/refcard.tex:494: trailing whitespace.
+\qquad {\it command-list}&create new GDB command {\it cmd};
gdb/doc/refcard.tex:498: trailing whitespace.
+\qquad {\it help-text}&create online documentation
gdb/doc/refcard.tex:595: trailing whitespace.
+list {\it lines}&display source surrounding {\it lines},
gdb/doc/refcard.tex:629: trailing whitespace.
+statement.\cr
...

Verified by checking refcard.pdf.

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

[gdb] Fix trailing whitespace in annotate.texinfo

Fix:
...
gdb/doc/annotate.texinfo:127: trailing whitespace.
+(gdb)
gdb/doc/annotate.texinfo:132: trailing whitespace.
+$
gdb/doc/annotate.texinfo:732: trailing whitespace.
+@code{step} or @code{continue},
gdb/doc/annotate.texinfo:738: trailing whitespace.
+is output.  When the program stops,
...

Verified by checking annotate.html.

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

[gdb] Ignore trailing whitespace in gdb/gdb-gdb.gdb.in

In gdb/gdb-gdb.gdb.in we have:
...
gdb/gdb-gdb.gdb.in:22: trailing whitespace.
+set prompt (top-gdb)
...

The trailing space is significant.

Fix this by dropping the trailing whitespace check for this file.

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

[gdb] Fix trailing whitespace in some files

Fix this:
...
gdb/configure.tgt:369: trailing whitespace.
+lm32-*-*)
gdb/configure.tgt:370: trailing whitespace.
+ gdb_target_obs="lm32-tdep.o"
gdb/configure.tgt:674: trailing whitespace.
+ # Target: TI C6X
gdb/config/djgpp/fnchange.lst:247: trailing whitespace.
+@V@/gdb/features/tic6x-core.xml @V@/gdb/features/c6x-core.xml
gdb/doc/stack_frame.txt:36: trailing whitespace.
+               |         |  Red Zone  |                      v
...

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

[gdb] Ignore whitespace in imported file gdb/exc_request.defs

The file gdb/exc_request.defs is imported.

Use .gitattributes to ignore whitespace in this file.

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

[gdb] Fix new blank line at EOF in a few xml files

Fix this:
...
gdb/features/sparc/sparc32-cp0.xml:19: new blank line at EOF.
gdb/features/sparc/sparc64-cp0.xml:17: new blank line at EOF.
gdb/features/sparc/sparc64-fpu.xml:60: new blank line at EOF.
gdb/features/s390-core64.xml:45: new blank line at EOF.
gdb/features/sparc/sparc32-fpu.xml:43: new blank line at EOF.
gdb/features/aarch64-pauth.xml:13: new blank line at EOF.
gdb/features/library-list-aix.dtd:18: new blank line at EOF.
...

I re-ran "make clean-cfiles cfiles" in gdb/features, no changes.

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

[gdb] Fix new blank line at EOF in a few scripts

Fix this:
...
gdb/contrib/ari/gdb_ari.sh:1216: new blank line at EOF.
gdb/contrib/ari/create-web-ari-in-src.sh:82: new blank line at EOF.
gdb/config/djgpp/djcheck.sh:48: new blank line at EOF.
...

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

[gdb] Fix leftover conflict marker in gdb/config/djgpp/README

For gdb/config/djgpp/README, we have:
...
gdb/config/djgpp/README:6: leftover conflict marker
...

This is a false positive, this is just some text formatting using '=':
...
General
=======
...
whose length happens to match the default value of git attribute
conflict-marker-size: 7.

Fix this by setting the conflict-marker-size to 80.

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

[gdb] Increase clean range in check-whitespace-pre-commit.py

The list of files completely checked by check-whitespace-pre-commit.py is
determined by this regexp:
...
re_clean = re.compile(
    "(^(gdb/testsuite/|gdbsupport/|gdbserver/)|[.](m4|ac|def|[chly])$|NEWS)"
)
...

Turn this around, and add a todo list of files not completely whitespace clean
yet, enabling complete checking for all other files.

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

Print command trace to gdb_stdlog

I recently wanted to enable some gdb logging when running the internal
AdaCore test suite.  To do this nicely, I enable debug-redirect early
in the test, so that the logging output does not affect the test
results.

I also wanted to the log the commands, to correlate what I see in the
debug log with what I see in the ordinary test suite log file (which
is basically like our own gdb.log).

However, I found that "set trace-commands on" will log to stdout, not
stdlog.  This patch changes this to log to the log file instead.

Boolify suppress_next_print_command_trace

This changes suppress_next_print_command_trace to use bool.

[gdb] Ignore codespell warnings about wrong encodings

With "pre-commit run codespell --all-files -v" we get warnings:
...
$ pre-commit run codespell --all-files -v
codespell................................................................Passed
- hook id: codespell
- duration: 1.52s

WARNING: Cannot decode file using encoding "utf-8": \
  gdb/testsuite/gdb.ada/non-ascii-latin-1/pack.adb
WARNING: Trying next encoding "iso-8859-1"
...

Disable these by setting quiet-level in gdb/pyproject.toml.

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

[gdb/contrib] Rename license-check-new-files.sh to .py

Rename gdb/contrib/license-check-new-files.sh to
gdb/contrib/license-check-new-files.py.

Fix the resulting flake8 fallout:
...
gdb/contrib/license-check-new-files.py:58:5: E722 do not use bare 'except'
gdb/contrib/license-check-new-files.py:106:9: E722 do not use bare 'except'
...

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

gdb, testsuite: unify 'Switching to thread' message

The 'normal_stop ()' function in infrun prints

  [Switching to Thread 0x155554dff6c0 (LWP 77976)]

on thread switch.  The 'print_selected_thread_frame ()' function
in thread.c prints

  [Switching to thread 2 (Thread 0x155554dff6c0 (LWP 96643))]

Ensure consistent output by updating the thread switch message in
'normal_stop'.

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

buffer overflow in fetch_indexed_addr

oss-fuzz found another case where sanity checks weren't good enough.

* dwarf.c (fetch_indexed_addr): Avoid integer overflow when
sanity checking field offset
(fetch_indexed_offset): Similarly.  Don't bother with "too small"
warning, which will be covered by field offset check.  Warn
about base and index rather than possibly overflowed calculation.

PR 29655 test: xfail more targets

Apparently some libraries (Qt5 is called out in PR 29655) want to know
if one of their functions has been overridden, and do so by comparing
the address of the function with the address of a local hidden alias.
This is a bug in every such library that tries that trick, because if
the main program is non-PIC and calls the function in question then
the globally visible address of the function is set to the PLT call
stub code for that function in the main executable.  This will happen
even when there is no real overriding of the function.

On the other hand if the main executable is PIC then there should be
no need to define function addresses on PLT call stub code, but some
linker target support still does so.  This is a minor bug in the
linker as it results in more work in ld.so and sligntly slower
startup.  However, I don't think it is an important issue if target
maintainers can't fix the problem.

* testsuite/ld-elf/shared.exp (pr29655): xfail more targets.

Automatic date update in version.in

elflink.c: remove unnecessary casts

I noticed when going through elflink.c looking for places where memory
allocation function return values weren't checked, that many places
still have the now unnecessary casts from K&R days.  This patch
removes them, and tidies some places that don't need to use a variable
to pass the size.

buffer_read_memory hardening

What drew my attention here was wondering if division of the buffer
length or the requested length by octets_per_byte could result in
trucation and thus an incomplete check for possible buffer overflow.
Rather than convincing myself that this couldn't happen, I decided to
rewrite the checks in a way that avoids the possibility of truncation,
and avoids any addition overflows too.

* dis-buf.c (buffer_read_memory): Rewrite buffer overflow
sanity checks.

move _bfd_mul_overflow from libbfd.h to bfd.h

Replace gas_mul_overflow with _bfd_mul_overflow, and don't include
libbfd.h outside of bfd/.

bfd/
* libbfd-in.h (_bfd_mul_overflow, _bfd_constant_p): Move to..
* bfd-in.h: ..here.  Include inttypes.h earlier.
* libbfd.h: Regenerate.
* bfd-in2.h: Regenerate.
gas/
* as.h (gas_mul_overflow): Don't define.
* read.c (do_repeat, s_space): Replace gas_mul_overflow with
_bfd_mul_overflow.
* symbols.c (notes_calloc): Likewise.
ld/
* emultempl/nto.em: Don't include libbfd.h.
* ldlang.c: Likewise.
* pdb.c: Likewise.
opcodes/
* kvx-opc.c: Don't include libbfd.h.

mep disassembler buffer overflow

mep_examine_vliw64_insns uses a buffer of size 4 to read 8 bytes.
Fix that, and tidy other places obscuring the code by using a macro to
size buffers.

cpu/
* mep.opc (mep_print_vliw_insns): Delete commented out insnbuf.
(mep_examine_vliw32_insns): Don't use CGEN_MAX_INSN_SIZE in
buf size.  Set buflength using sizeof.  Delete comment.
(mep_examine_vliw64_insns): Likewise.
(mep_examine_ivc2_insns): Likewise.
opcodes/
* mep-dis.c: Regenerate.

[pre-commit] Reorganize .pre-commit-config.yaml

Reorganize .pre-commit-config.yaml:
- unify indentation
- move local hooks to last
- add empty lines and header comments to make file more readable
- move detailed file selection comment from flake8 settings to
  "Python hooks" since it's valid for all python hooks, and
  explain why the types_or setting is needed.
- use anchors to avoid repetition

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

[pre-commit] Drop always_run setting for codespell-log

The pre-commit codespell-log hook has an always_run=true setting.

This doesn't seem necessary for a commit-msg stage hook.  Remove it.

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

[pre-commit] Remove stages setting for two hooks

Some hooks have a setting:
...
stages: [pre-commit]
...
but since that's identical to the default setting:
...
default_stages: [pre-commit]
...
we can just remove those.

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

[pre-commit] Remove pass_filenames setting for check-whitespace

The pre-commit hook check-whitespace has the following setting:
...
pass_filenames: true
...

Since true is the default for pass_filenames, remove the superfluous setting.

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

[pre-commit] Drop require_serial for pre-commit-setup

Now that we have pass_filenames=false for pre-commit hook pre-commit-setup,
there's no longer a requirement to have require_serial=true.

Remove the setting.

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

[pre-commit] Drop types_or filtering for tclint

The pre-commit tclint hook filters files using:
...
      types_or: [file]
      files: '^gdb/testsuite/.*\.(exp|tcl)$'
...

The types_or setting overrides the default file type of the hook.  In the case
of tclint, there's no such default.

So this setting is not required, and causes additional filtering to run.

It was probably added by using one of the python hooks as a starting point.

Remove it.

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

gdb/MAINTAINERS: Document the change of release managers

I am stepping down as GDB Release manager. Andrew Burgess and
Simon Marchi have both kindly volunteered to take on this role.
This commit updates the gdb/MAINTAINERS file accordingly.

gdb/amd-dbgapi-target: drop reference to amd_dbgapi_address_class_id_t

The rocm-dbgapi header defines a few handle types, and the
gdb/amd-dbgapi-target.h defines some generic helpers for them
(operator== and operator!=).  Nothing in GDB uses
amd_dbgapi_address_class_id_t, and this type will be removed from the
library.

Since this is not used and will be removed in the future, remove the
definition of operator== / operator!= for amd_dbgapi_address_class_id_t.

Build tested, no visible user impact expected.

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

Automatic date update in version.in

[pre-commit] Use pass_filenames=false for pre-commit-setup

I came across pre-commit setting pass_filenames, and realized we can use it
for the pre-commit-setup hook.

It saves about half a second for an all-files run.  Before:
...
$ ( time pre-commit run pre-commit-setup --all-files ) 2>&1 | grep real
real    0m1,136s
...
and after:
...
$ ( time pre-commit run pre-commit-setup --all-files ) 2>&1 | grep real
real    0m0,635s
...

gdb/testsuite: avoid PID in test name

In gdb.python/py-inf-exited-at-exit.exp, switch to using gdb_attach
proc when attaching in order to avoid including the process-id in the
test name.

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

[pre-commit] Stop using deprecated language script

In v4.4.0, pre-commit renamed language script to unsupported_script.

The rename was done to stress that pre-commit doesn't provide an environment
for the script to run in [1].

The language script is now a deprecated alias for unsupported_script, and the
plan seems to be to initially produce a deprecation warning, and eventually
remove support for the alias completely.

Start using the new name: unsupported_script.

Furthermore, the check-include-guards hook uses language python, and indeed it
uses a python script, but it doesn't really need a virtual environment.  It
imports modules fnmatch, re, sys and typing, all of which are available in
python 3.10 and later, which is the environment pre-commit itself requires
(because we require pre-commit v4.5.1 or later, and pre-commit requires python
3.10 since v4.4.0).  So while we're at it, use unsupported_script for this
hook as well, reducing the amount of environments pre-commit has to manage.

Tested using "pre-commit run --all-files" with python 3.10, as well as 3.13.

Approved-By: Simon Marchi <simon.marchi@efficios.com>
[1] https://github.com/pre-commit/pre-commit/pull/3577

AArch64 gas: Block section relative symbols in GOT relocations [PR30788]

By default, GAS changes GOT relocations of local symbols into section relative.
This is incorrect since GOT relocations do not support offsets.  Update
aarch64_fix_adjustable() to explicitly disallow this for GOT relocations.
This fixes PR30788.

ld: xfail pr29655 on SPARC [PR34151]

As described in PR ld/34151, the recent "Build pr29655" test FAILs on
SPARC, both Solaris and Linux.

Until this is fixed, this patch xfail's the test.

Tested on sparc{v9,}-sun-solaris2.11, sparc{64,}-unknown-linux-gnu, and
amd64-pc-solaris2.11.

2026-06-14  Rainer Orth  <ro@CeBiTec.Uni-Bielefeld.DE>

ld:
* testsuite/ld-elf/shared.exp (Build pr29655): xfail on SPARC.

Automatic date update in version.in

Port expandargstr from gcc/libiberty

Sync recent changes to libiberty.

include/ChangeLog:

* libiberty.h (expandargstr): Declare.

libiberty/ChangeLog:

* argv.c (expandargstr): New function.

Signed-off-by: Sunil Dora <sunilkumar.dora@windriver.com>

[gdb] Add endianity to codespell-ignore-words.txt

Add endianity to codespell-ignore-words.txt, as per this review comment [1].

[1] https://sourceware.org/pipermail/gdb-patches/2025-December/223137.html

[gdb] Expand dirs in codespell skip list

Replace all dirs in the codespell skip list with the actual files that are not
codespell-clean.  At this point, there's just ~60 of them.

This enables codespell checking for yet more files.

[gdb] Drop some files and a dir from codespell skip list

A recent codespell cleanup in gdb/testsuite made some files and a dir in the
codespell skip list codespell-clean.  Drop these from the skip list.