GDB: testsuite: riscv: Don't return value from top-level (manual)

This patch manually changes the "return -1" and "return 0" statements
that weren't caught by the sed command.

This happened only in one testcase due to the statements being inside a
foreach_with_prefix block, and in the others because the return
statement was in a misaligned line, which is now fixed.

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

GDB: testsuite: riscv: Don't return value from top-level (sed)

This patch is purely the result of running:

$ sed -i 's/^    return -1/    return/' riscv*.exp*

and

$ sed -i 's/^    return 0/    return/' riscv*.exp*

inside gdb/testsuite/gdb.arch.

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

GDB: testsuite: powerpc: Don't return value from top-level (manual)

This patch manually changes the "return -1" statements that weren't
caught by the sed command because they were in a misaligned line, which
is then aligned by this patch.

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

GDB: testsuite: powerpc: Don't return value from top-level (sed)

This patch is purely the result of running:

$ sed -i 's/^    return -1/    return/' \
      aix*.exp* altivec*.exp* e500*.exp* powerpc*.exp* ppc*.exp* vsx*.exp*

and

$ sed -i 's/^    return 0/    return/' \
      aix*.exp* altivec*.exp* e500*.exp* powerpc*.exp* ppc*.exp* vsx*.exp*

inside gdb/testsuite/gdb.arch.

I didn't include changes made to return statements inside procedures.

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

GDB: testsuite: x86, amd64, i386: Don't return value from top-level (manual)

This patch manually changes the "return -1" statements that weren't
caught by the sed command.

In amd64-shadow-stack-cmds.exp the return statements have extra
indentation due to being inside a save_vars block.

In i386-bp_permanent.exp this was caused by misaligned lines, which are
now fixed.

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

GDB: testsuite: x86, amd64, i386, ia64: Don't return value from top-level (sed)

This patch is purely the result of running:

$ sed -i 's/^    return -1/    return/' \
      amd64-*.exp* i386-*.exp* x86*.exp* ia64*.exp* core-file-pid0.exp

and

$ sed -i 's/^    return 0/    return/' \
      amd64-*.exp* i386-*.exp* x86*.exp* ia64*.exp* core-file-pid0.exp

inside gdb/testsuite/gdb.arch.

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

GDB: testsuite: aarch64, arm: Don't return value from top-level (manual)

This patch manually changes the "return -1" statements that weren't
caught by the sed command.

In aarch64-prologue.exp and arm-cmse-sgstubs.exp, this was caused by a
misaligned line, which is now fixed.

In aarch64-mte.exp, aarch64-non-address-bits.exp,
arm-pthread_cond_timedwait-bt.exp and thumb2-it.exp this is because the
return statements have extra indentation due to being inside
with_test_prefix, save_vars or gdb_test_multiple blocks.

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

GDB: testsuite: aarch64, arm: Don't return value from top-level (sed)

This patch is purely the result of running:

$ sed -i 's/^    return -1/    return/' \
      aarch64-*.exp* arm-*.exp* thumb*.exp* iwmmxt-regs.exp pr25124.exp

and

$ sed -i 's/^    return 0/    return/' \
      aarch64-*.exp* arm-*.exp* thumb*.exp* iwmmxt-regs.exp pr25124.exp

inside gdb/testsuite/gdb.arch.

I didn't include changes made to return statements inside procedures.

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

Use address style with throw_error

This changes a call to throw_error to use address_style.

Use function style with throw_error

This changes some calls to throw_error to use function_name_style.

Use command style with throw_error

This changes some calls to throw_error to use command_style.

Use file- and line-styling with throw_error

This changes some throw_error calls to apply file_name_style and
line_number_style.  This patch does both at the same time because the
two styles often appear in the same message.

Allow styling when using throw_* functions

The throw_* family of functions use the varargs constructor for
gdb_exception, which then calls string_vprintf.  This means that
styling cannot be applied here by gdb.

This patch changes this code to use a client-supplied formatting
function.  For gdbserver this remains string_vprintf, but for gdb it
now allows styling.

I did look at unifying 'error' and the throw_* functions a bit more,
but this would have meant unravelling some IPA code.

Add missing quote to a comment

I noticed that one particular comment was missing the closing double
quote around the word "auto".

Use bool in map_matching_symbols

This changes ada-lang.c:map_matching_symbols to take a bool parameter,
then fixes up the callers.

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

Use bool in ada_add_all_symbols

This changes ada_add_all_symbols to use bool, then fixes up the
callers.

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

include: add reference URLs in elf/amdgpu.h

During review, a question was "where are those numbers that you are
adding defined".  Add some URLs pointing to the source of truth for
those numbers.

Change-Id: I11b7cb351a9b818fca66a532bfcd27286ec0ddfd

readelf: Add support for AMDGPU code object V6

AMDGPU code object V6 adds the EF_AMDGPU_GENERIC_VERSION_V field.
Decode it when decoding the e_flags value for amdgpu.

The output for such generic GFX targets will look like:

$ readelf -h gpu.elf
  ELF Header:
    ...
    Flags:     0x1000151, gfx9-generic, xnack any, generic v1
                                                   ----------
    ...

... indicating that this ELF has the "generic code object v1" flag.

Change-Id: I0cb8014fc23150e16f43ab98adb3832ede253c88
Co-Authored-By: Simon Marchi <simon.marchi@efficios.com>

Add AMDGPU generic targets

Add the following generic AMDGPU architectures:

  - gfx9-generic
  - gfx9-4-generic
  - gfx10-1-generic
  - gfx10-3-generic
  - gfx11-generic
  - gfx12-generic
  - gfx12-5-generic

Change-Id: Ibf600d7c70ba8499f8ef75d8d57a71929f1cd4d4
Co-Authored-By: Simon Marchi <simon.marchi@efficios.com>

Update list of supported AMDGPU architectures

This patch updates the list of supported AMDGPU architectures in bfd/
binutils/ and include/elf/.

The following architectures have been added:

- gfx942
- gfx950
- gfx1150
- gfx1151
- gfx1152
- gfx1153
- gfx1200
- gfx1201
- gfx1250

The canonical source for these numbers is:

https://llvm.org/docs/AMDGPUUsage.html#amdgpu-ef-amdgpu-mach-table

Co-Authored-By: Laurent Morichetti <laurent.morichetti@amd.com>
Co-Authored-By: Simon Marchi <simon.marchi@efficios.com>
Co-Authored-By: Olu Ogunbowale <oogunbow@amd.com>
Co-Authored-By: Shahab Vahedi <shahab.vahedi@amd.com>
Co-Authored-By: Anurag Kumar <AnuragKumar.Vulisha@amd.com>
Change-Id: I80e76c8ec98b725937fe445883fae707097ec2b7

Objdump: Add "-M annotate" option to the AArch64 disassembler.

ld/doc: correct misrepresented wording

The file ld.texi contains two space-separated terms: 'subseque nt'. It was probably meant to be 'subsequent'.

Manual documentation in html format also contains this error. I submitted a patch for it too, which can be
link: https://sourceware.org/pipermail/binutils/2026-May/149206.html
Signed-off-by: PranavRJoshi <pranavrjoshi1@gmail.com>

objcopy: zap ELF visibility when localizing symbols

The spec explicitly precludes STB_LOCAL together with STV_PROTECTED (and,
implicitly, STV_HIDDEN or STV_INTERNAL), so we better wouldn't (entirely
silently) write out symbols violating this.

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

The spec explicitly precludes STB_LOCAL together with STV_PROTECTED (and,
implicity, STV_HIDDEN or STV_INTERNAL), so we better wouldn't entirely
silently write out symbols violating this.

LoongArch's tc_symbol_new_hook() simply needs dropping. If FAKE_LABEL_NAME
symbols can end up global, marking them hidden would need doing elsewhere.
There not being a need to make any testsuite adjustments suggests though
that this won't normally (ever?) happen.

A couple of testcases then also need adjustment.

gas/ELF: restrict visibility changes

Since the spec mandates that the most restricting visibility ought to
propagate when linking, the same rule should apply when assembling.

gdb/solib: use early return in solib_read_symbols

This reduces the indent a bit, and makes it clearer where the
"interesting" part of the function is.

At the same time, move the comment to solib.h.

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

Automatic date update in version.in

ld: Append LDFLAGS to flags variable in default_ld_link

The following change is needed to fix errors trying to load the
milli.a archive for the hppa*64*-*-hpux* target when the host
system isn't hpux.

We need to create a dummy milli.a archive for this target and
append the directory of this archive to LDFLAGS.

This assumes the testsuite takes the LDFLAGS environment variable
into account.  However, some tests in the ld testsuite use the
low-level `ld-link' procedure and it fails to take LDFLAGS into
account.

This change modifies the `default_ld_link' procedure to append
$LDFLAGS to the flags variable and fix the above issue.

This change potentially affects the `alpha*-*-*vms*' target but
currently no tests run for it make direct use of `ld-link'.

Suggested-by: Maciej W. Rozycki <macro@orcam.me.uk>
2026-04-27  John David Anglin  <danglin@gcc.gnu.org>

ld/ChangeLog:

* testsuite/lib/ld-lib.exp (default_ld_link): Append
LDFLAGS to `flags' variable.  Also use the append command
to append the board flags.

hppa64: Re-enable -gc-section support on hppa*64*-*-hpux*

The previous change to elf_hppa_final_link_relocate didn't eliminate
relocatios with invalid offsets.  Here we take a different approach
to handle invalid offsets on hpux.  We allocate 16 bytes at the start
of the .data section for the linker.  If we encounter a relocation
with an invalid offset, we set the relocation's offset to the start
of the data section.  As a result, the HP dynamic linker is happy
and we can re-enable -gc-section support.

2026-05-07  John David Anglin  <danglin@gcc.gnu.org>

bfd/ChangeLog:

* elf64-hppa.c (elf_hppa_final_link_relocate): Rework
handling of relocations with invalid offsets on hpux.
(elf_backend_can_gc_sections): Set to one on hpux.

ld/ChangeLog:

* emulparams/elf64hppa.sh (DATA_START_SYMBOLS): Define.
* testsuite/ld-elf/group8a.d: Revert commit d6ce0aa3f877.
* testsuite/ld-elf/group8b.d: Likewise.
* testsuite/ld-elf/group9a.d: Likewise.
* testsuite/ld-elf/group9b.d: Likewise.
* testsuite/ld-elf/pr12851.d: Likewise.
* testsuite/ld-elf/pr22677.d: Likewise.

Windows gdb: Avoid hang second attach/run

gdb.base/attach.exp starts a second inferior and tries to attach the
second inferior to the same process that inferior 1 is already
debugging.  The point is to make sure that the backend errors out when
it tries to attach to a process that is already being debugged.

windows_nat_target::attach and windows_nat_target::create_inferior
both hang in this situation, because they call into do_synchronously,
which hangs because the 'process_thread' thread is blocked in
WaitForDebugEvent.

E.g.:

  attach 4420
  FAIL: gdb.base/attach.exp: do_attach_failure_tests: fail to attach again (timeout)

Until the Windows backend is taught to debug multiple processes, which
will probably require having one process_thread thread per inferior,
detect the situation and error out before GDB hangs.

This results in the following progression in gdb.base/attach.exp:

 -FAIL: gdb.base/attach.exp: do_attach_failure_tests: fail to attach again (timeout)
 -FAIL: gdb.base/attach.exp: do_attach_failure_tests: set confirm off (timeout)
 -FAIL: gdb.base/attach.exp: do_attach_failure_tests: switch to inferior 1 (timeout)
 -FAIL: gdb.base/attach.exp: do_attach_failure_tests: exit after attach failures (timeout)
 -FAIL: gdb.base/attach.exp: do_attach_failure_tests: gdb_breakpoint: set breakpoint at main (timeout)
 -FAIL: gdb.base/attach.exp: do_attach_failure_tests: stop at main (timeout)
 +PASS: gdb.base/attach.exp: do_attach_failure_tests: fail to attach again
 +PASS: gdb.base/attach.exp: do_attach_failure_tests: set confirm off
 +PASS: gdb.base/attach.exp: do_attach_failure_tests: switch to inferior 1
 +PASS: gdb.base/attach.exp: do_attach_failure_tests: exit after attach failures
 +PASS: gdb.base/attach.exp: do_attach_failure_tests: stop at main

There are still other failures not addressed by this patch.

Tests that launch a second program with "run" exist, but are normally
gated by allow_multi_inferior_tests.

Approved-By: Tom Tromey <tom@tromey.com>
Change-Id: I55b4438795439673c49fa55f55ddf0191f4f0ea8
commit-id: 1caa5be0

Windows gdb: all-stop, interrupt with "stopped" instead of SIGTRAP

Currently, "interrupt" uses DebugBreakProcess (or equivalent), which
injects a new thread in the inferior that executes an int3 instruction
(on x86), which raises a SIGTRAP.  With the target backend in non-stop
mode, its easy to avoid all that and make interrupt in all-stop just
suspend a pre-existing thread and report "stopped", like "set non-stop
on" does (via target_stop).

E.g., before:

 (gdb) c&
 Continuing.
 ...
 (gdb) info threads
   Id   Target Id          Frame
 * 1    Thread 1180.0x1374 (running)
   2    Thread 1180.0xc3c  (running)
   3    Thread 1180.0x6ec  (running)
   5    Thread 1180.0x1378 (running)
 (gdb)
 ...
 [New Thread 1180.0xc70]
 [Thread 1180.0x1378 exited with code 0]
 [Thread 1180.0xc70 exited with code 0]
 [New Thread 1180.0xdc0]
 ...
 interrupt
 (gdb) [New Thread 1180.0x1010]

 Thread 8 received signal SIGTRAP, Trace/breakpoint trap.
 [Switching to Thread 1180.0x1010]
 0x00007ffa57490b71 in ntdll!DbgBreakPoint () from C:\Windows\SYSTEM32\ntdll.dll
 info threads
   Id   Target Id          Frame
   1    Thread 1180.0x1374 0x00007ffa5748d6e4 in ntdll!ZwDelayExecution () from C:\Windows\SYSTEM32\ntdll.dll
   2    Thread 1180.0xc3c  0x00007ffa57490ad4 in ntdll!ZwWaitForWorkViaWorkerFactory () from C:\Windows\SYSTEM32\ntdll.dll
   3    Thread 1180.0x6ec  0x00007ffa5748d6e4 in ntdll!ZwDelayExecution () from C:\Windows\SYSTEM32\ntdll.dll
   7    Thread 1180.0xdc0  0x00007ffa5748d6e4 in ntdll!ZwDelayExecution () from C:\Windows\SYSTEM32\ntdll.dll
 * 8    Thread 1180.0x1010 0x00007ffa57490b71 in ntdll!DbgBreakPoint () from C:\Windows\SYSTEM32\ntdll.dll
 (gdb)

After:

 (gdb) info threads
   Id   Target Id          Frame
 * 1    Thread 5912.0x394  (running)
   2    Thread 5912.0x608  (running)
   3    Thread 5912.0x1704 (running)
   10   Thread 5912.0x870  (running)
 (gdb)
 ...
 [Thread 5912.0x870 exited with code 0]
 ...
 (gdb) interrupt
 (gdb)
 Thread 1 stopped.
 0x00007ffa5748d6e4 in ntdll!ZwDelayExecution () from C:\Windows\SYSTEM32\ntdll.dll
 info threads
   Id   Target Id          Frame
 * 1    Thread 5912.0x394  0x00007ffa5748d6e4 in ntdll!ZwDelayExecution () from C:\Windows\SYSTEM32\ntdll.dll
   2    Thread 5912.0x608  0x00007ffa57490ad4 in ntdll!ZwWaitForWorkViaWorkerFactory () from C:\Windows\SYSTEM32\ntdll.dll
   3    Thread 5912.0x1704 0x00007ffa5748d6e4 in ntdll!ZwDelayExecution () from C:\Windows\SYSTEM32\ntdll.dll
   8    Thread 5912.0x1200 0x00007ffa5748d6e4 in ntdll!ZwDelayExecution () from C:\Windows\SYSTEM32\ntdll.dll
 (gdb)

Approved-By: Tom Tromey <tom@tromey.com>
Change-Id: I569fc69392ce9a070a2ebe1003388b7386412b14
commit-id: 8f6b76d2

Update the SECURITY.txt document. Clarify what is meant by a "direct compromise of security", emphasise that the tools do not provide a sevrice of any kind, and show that bugs that rely upon untrusted input must be able to cross a trust boundary in order to be considered as a security issue.

Automatic date update in version.in

Remove Andreas Jaeger from the x86_64 maintainers.

Automatic date update in version.in

hppa64: Disable -gc-section support on hppa*64*-*-hpux*

The HP-UX dynamic linker on hppa generates an error if it detects
a dynamic relocation with the R_PARISC_NONE type.  As a result,
there is no way to handle relocations in sections that are garbage
collected.  Although these can mostly be avoided, I think it best
to disable -gc-section support.

2026-05-06  John David Anglin  <danglin@gcc.gnu.org>

bfd/ChangeLog:

* elf64-hppa.c (elf_hppa_final_link_relocate): Rework
BFD_ASSERT to only trigger on hpux.  Zero rela if the
new offset is invalid.
(elf_backend_can_gc_sections): Set to zero on hpux.

ld/ChangeLog:

* testsuite/ld-elf/group8a.d: xfail hppa*64*-*-hpux*.
* testsuite/ld-elf/group8b.d: Likewise.
* testsuite/ld-elf/group9a.d: Likewise.
* testsuite/ld-elf/group9b.d: Likewise.
* testsuite/ld-elf/pr12851.d: Likewise.
* testsuite/ld-elf/pr22677.d: Likewise.

gdb/dwarf: Use the function scope for DW_TAG_imported_declaration

All Fortran imported variable aliases (`use module, alias => var`)
were being added to "global scope", regardless of whether they appeared
in:
- Program/module scope (should be global)
- Function scope (should be local)

This caused conflicts when different functions had the same alias name
pointing to different variables.

DW_TAG_imported_declaration and DW_TAG_namespace cases are now handled
separately.  This patch modifies the case for DW_TAG_imported_
declaration in the function new_symbol () to use cu->list_in_scope
instead of global symbols for all languages.  This ensures that
function-scoped aliases use the current scope rather than being forced
into the global scope.

Bug Scenario:

  subroutine sub1
    use mod1, var_i_alias=>var_i  ! alias points to mod1::var_i
    var_i_alias = 3
    var_i = 4
  end subroutine

  subroutine sub2
    use mod2, var_i_alias=>var_i  ! alias points to mod2::var_i
    var_i_alias = 23
    var_i = 25
  end subroutine

Before: var_i_alias in sub2 incorrectly resolved to mod1::var_i
(value 25)
After: Each function's alias correctly resolves to its own imported
variable (value 23)

New test files verify the fix and include regression tests for global
program-scope imports:
  - gdb/testsuite/gdb.fortran/module_declarations.exp
  - gdb/testsuite/gdb.fortran/module_declarations.f90

Before the change:
(gdb) print var_i_alias
$4 = 25
FAIL: gdb.fortran/module_declarations.exp: sub2_test: print var_i_alias

After the change:
(gdb) print var_i_alias
$4 = 23
PASS: gdb.fortran/module_declarations.exp: sub2_test: print var_i_alias

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

Automatic date update in version.in

gdb: notify of inferior switch when needed from 'thread' command

While working on the commit:

  commit 9959019545d8d6d71d927f20f088efba944b1e9c
  Date:   Sun Sep 28 16:16:53 2025 +0100

      gdb: fix for 'set suppress-cli-notifications on' missed case

I spotted this message in the gdb.mi/user-selected-context-sync.exp
test script:

  # Idea for the future: selecting a thread in a different inferior.  For now,
  # GDB doesn't show an inferior switch, but if it did, it would be a nice
  # place to test it.

What this message is talking about is this behaviour:

  (gdb) info threads
    Id   Target Id                              Frame
    1.1  Thread 0xf7dbc700 (LWP 818430) "thr" 0xf7eb2888 in clone () from /lib/libc.so.6
    1.2  Thread 0xf7dbbb40 (LWP 818433) "thr" 0xf7fd0579 in __kernel_vsyscall ()
    1.3  Thread 0xf73ffb40 (LWP 818434) "thr" breakpt () at thr.c:19
    2.1  Thread 0xf7dbc700 (LWP 818456) "thr" 0xf7eb2888 in clone () from /lib/libc.so.6
    2.2  Thread 0xf7dbbb40 (LWP 818457) "thr" breakpt () at thr.c:19
  * 2.3  Thread 0xf73ffb40 (LWP 818458) "thr" breakpt () at thr.c:19
  (gdb) inferior 1
  [Switching to inferior 1 [process 818430] (/home/andrew/tmp/thr)]
  [Switching to thread 1.1 (Thread 0xf7dbc700 (LWP 818430))]
  #0  0xf7eb2888 in clone () from /lib/libc.so.6
  (gdb) thread 2.2
  [Switching to thread 2.2 (Thread 0xf7dbbb40 (LWP 818457))]
  #0  breakpt () at thr.c:19
  19   while (stop)
  (gdb)

Notice that when we switch from thread 2.3 to 1.1 using the 'inferior
1' command, GDB tells us that the inferior has changed, and that the
thread has changed (and also that the frame has changed).

But, when we switch from 1.1 to 2.2 using the 'thread 2.2' command, we
are only told about the thread change.

The 'Switching to inferior ...' line includes some useful information,
the process PID and the executable name, and I think it is a shame
that these are not presented when using the 'thread' command to switch
inferior.

So, this commit addresses this issue.

A question that came up during review, and which I'm clarifying here:
this change only affects the output of GDB when the thread command is
also used to switch inferiors.  I am (in effect) arguing that the
command 'thread 2.2' should be treated as a shorthand for 'inferior 2;
thread 2', and should display all of the associated output.  If the
user is only switching threads within a single inferior then it is not
necessary to re-display the inferior information.

I acknowledge that this does mean the output of the 'thread' command
will now be different depending on whether the user changes inferior
or not.  However, I think this is better than the alternative, having
the 'thread' command always re-print the inferior information.  I
think this would introduce excess noise that is not useful.

There are changes in basically two areas.  The easy part is in
thread_command (thread.c).  Here we spot when the inferior has changed
as a result of the 'thread' command, and include
USER_SELECTED_INFERIOR in the set of state passed to the
notify_user_selected_context_changed function.

The change in mi/mi-main.c is a little more involved.  In the
mi_cmd_execute function we use an instance of user_selected_context to
spot if any inferior state (frame, thread, or inferior) changes after
an MI command, this is then used to decide if there should be a call
to interps_notify_user_selected_context_changed.

First, by calling interps_notify_user_selected_context_changed
directly, instead of notify_user_selected_context_changed, we fail to
trigger the Python selected_context event, which feels like a
mistake.  If the context is changed via an MI command, I think we
should still trigger the Python event.  So the first thing I did was
change the interps_notify_user_selected_context_changed call into a
call to notify_user_selected_context_changed.  I updated the
gdb.python/py-selected-context.exp test to cover this case.

After that, in mi_cmd_execute, notify_user_selected_context_changed is
always passed 'USER_SELECTED_THREAD | USER_SELECTED_FRAME'.  This
makes sense, the MI doesn't allow "switching inferiors" as a command,
instead, an MI frontend must switch threads, and the inferior is
switched as a consequence.  But this does mean that if a user has a
CLI and MI interpreter running, and the MI switches threads, the CLI
will only receive the thread switch style notifications, that is,
there will be no "Switching to inferior ..." line.

What I've done is rename user_selected_context::has_changed to
user_selected_context::what_changed, this function is now responsible
for returning the set of USER_SELECTED_* flags that indicate what
changed.

If anything has changed then we always return USER_SELECTED_THREAD |
USER_SELECTED_FRAME as a minimum.  This retains the existing
behaviour, but is possibly more aggressive than we need to be; the
-stack-select-frame command can only change the frame, so maybe in
this case we should only return USER_SELECTED_FRAME?  I've left that
for the future though.

However, the important change is that in ::what_changed, I now spot
when the inferior has changed and include USER_SELECTED_INFERIOR in
the set of flags that are returned.

In mi_cmd_execute we now call the new what_changed function, and use
the set of flags returned when calling
notify_user_selected_context_changed.  This means that the CLI will
now receive inferior changed notifications when appropriate.

The gdb.mi/user-selected-context-sync.exp script has been updated,
replacing the comment I quoted above with an actual test that the
inferior change is announced correctly.

Reviewed-By: Guinevere Larsen <guinevere@redhat.com>
Reviewed-By: Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>

gdb, fortran: Fix local variable lookup in Fortran parser

This change fixes https://sourceware.org/bugzilla/show_bug.cgi?id=34059.

The Fortran expression parser in GDB ("gdb/f-exp.y") previously performed
symbol lookup in this order when parsing identifiers:

- SEARCH_STRUCT_DOMAIN (types/structs)
- SEARCH_VFT ("C-like" name lookups for variables/types/functions)
- SEARCH_MODULE_DOMAIN (modules)

It searched for "types before variables", causing type names from shared
libraries to shadow local variable names.

For a reproducer like the one given below, the Fortran parser fails to
look up local variable name "array" and treats it as a type value instead
of a variable, because there's a conflicting "array" type from system
libraries.

1 program test
2
3  ! Declare variables used in this test.
4  integer, dimension (-2:2) :: array
5
6  array = 1
7
8  print *, ""           ! Break here
9  print *, array
10
11 end program test

Before the change, GDB shows:

'''
./gdb --data-directory=./data-directory --args /tmp/a.out
GNU gdb (GDB) 18.0.50.20260408-git
Copyright (C) 2026 Free Software Foundation, Inc.
...
Reading symbols from /tmp/a.out...
(gdb) break 8
Breakpoint 1 at 0x11b3: file test.f90, line 8.
(gdb) run
Starting program: /tmp/a.out
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Breakpoint 1, test () at test.f90:8
8         print *, ""           ! Break here
(gdb) info locals
array = (1, 1, 1, 1, 1)
(gdb) print array
Attempt to use a type name as an expression
(gdb) ptype array
type = Type array
    Type, C_Union :: :: u
    PTR TO -> ( char :: scratch(0:15 ))
End Type array
'''

This issue is fixed in the Fortran expression parser in GDB ("gdb/f-exp.y")
by prioritizing SEARCH_VFT over other search domains during symbol lookup.
After the change, the 'array' variable is resolved to the correct value.

'''
(gdb) print array
$1 = (1, 1, 1, 1, 1)
(gdb) ptype array
type = integer(kind=4) (-2:2)
'''

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

Automatic date update in version.in

gprof: Fix strchr discarded qualifier call

In annotate_source strrchr is called on a const char *. So the result
should also be stored in a const char *.

* gprof/source.c (annotate_source): Make name_only a const char *.

ld: Fix calls to strchr that discard or use wrong const qualifiers

* ld/emultempl/pe.em (pe_fixup_stdcalls): Make at a const char *.
(gldEMULATION_NAME_after_open): Make pnt a const char *.
(gldEMULATION_NAME_place_orphan): Make dollar a const char *.
* ld/emultempl/pep.em (pep_fixup_stdcalls): Make at a
const char *. Introduce at2 as non-const char *.
(gldEMULATION_NAME_after_open): Make pnt a const char *.
(gldEMULATION_NAME_place_orphan): Make dollar a const char *.
* ld/emultempl/spuelf.em (spu_elf_load_ovl_mgr): Make p a
const char *. Introduce np as char *.
* ld/ldelf.c (ldelf_search_needed): Call strchr on freeme, so
slash is non-const, then assign freeme to replacement.

Simplify elf64_alpha_relocate_section

Prior to Nick implementing _bfd_elf_make_dynamic_reloc_section, alpha
made no use of elf_section_data(sec)->sreloc to store the dynamic
relocation section associated with sec.  After commit 83bac4b01082 the
elf_section_data was set but not used in relocate_section.

* elf64-alpha.c (elf64_alpha_relocate_section): Use
elf_section_data to get dynamic relocation section associated
with the input section.

Fix the strrchr error for DOS based filesystem

Fix the strrchr error like:

gprof/source.c:130:28: error: initialization discards ‘const’ qualifier from pointer target type [-Werror=discarded-qualifiers]
  130 |             char *bslash = strrchr (sf->name, '\\');

binutils/

* bucomm.c (template_in_dir): Make bslash const char *.

gprof/

* source.c (annotate_source): Make bslash const char *.

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

Automatic date update in version.in

libctf: Remove unused variable initialized to itself

* ctf-link.c: Remove unused variable initialized to itself.

Fix discarded-qualifiers problems in ldlang.c

Assign strchr return to a const char* to match its arg in a couple of
places.  archive_path now returns a const char*, and
input_statement_is_archive_path now has a const char* sep arg.  If
you follow where these args come from in ldgram.y it can be seen that
they are in fact in writable memory, so it isn't necessary to copy
file_spec to poke in a zero which is restored before the function
returns.

Signed-off-by: Calvin Owens <calvin@wbinvd.org>
Signed-off-by: Alan Modra <amodra@gmail.com>

gdb/dwarf2: pass around DWARF expressions as gdb::array_view

This patch converts a bunch of functions to take or return DWARF
expressions as `gdb::array_view<const gdb_byte>`, instead of raw pointer
and size.  It doesn't do any non-trivial change to function
implementations, but the idea is that we could change them (for example
dwarf_expr_context::execute_stack_op) to operate on the array view
directly, giving us bounds checking when building in debug mode.  But
that is not as trivial.

This patch also doesn't change structure fields to array_views (for
instance, dwarf2_loclist_baton), because that would make them
non-trivially constructible, and we'd (technically) need to change how
they are allocated.

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

Automatic date update in version.in

gdb/linux: handle missing NT_FILE note when opening core files

This patch originated from this mailing list discussion:

  https://inbox.sourceware.org/gdb-patches/b9b5bf03c59b58e02ca27b522338c6103d5ae49f.camel@gnu.org

The user has some core files which lack an NT_FILE note.  They
wondered why GDB was still unable to find the shared libraries based
on their build-id.

The reason right now is that GDB only records the build-id information
for mappings based on the entries in the NT_FILE note.  With the
entries in this note we build several lookup tables; a filename to
build-id table, a soname (extracted from the file if it is a shared
library) to build-id table, and an address range to build-id table.

When a shared library is being loaded we perform a lookup using two
pieces of information; the shared library's filename, and an address
that we know is within the shared library.  If either of these give a
build-id, then we can use that build-id to ensure GDB loads the
shared library that matches the core file.

If the NT_FILE note is missing then none of the lookup tables are
created, and so the shared library build-id lookup fails, meaning that
all GDB can do is look for the shared library by name on the local
file system.  This often results in the wrong library version being
loaded, or the library not being found at all.

However, Linux core files also have the segment table.  This table
gives address ranges.  The segment table doesn't tell us what file was
mapped in, or the offset within the file that was mapped in.  But if
we go back to the three lookup tables, we can use the segment table to
build the address to build-id lookup table, and that would be enough
to allow GDB to find the build-id for a shared library in most cases.

So, here's what this patch does: linux_read_core_file_mappings (in
linux-tdep.c) is updated to first parse the NT_FILE note as it
currently does.  But after this we also walk the segment table (BFD
actually converts these into sections with the LOAD flag set), and if
a segment has a build-id, and doesn't correspond to an entry found in
the NT_FILE note, we create an anonymous mapping.  An anonymous
mapping is just like a mapping from the NT_FILE note, but without a
filename and file offset.  This mapping is passed through the callback
just like the traditional, non-anonymous, mappings.

Then in corelow.c various functions are updated in order to handle
anonymous mappings.

Back in linux-tdep.c, function linux_core_info_proc_mappings gets a
small update to handle anonymous mappings.

The corefile-buildid.exp test is updated to remove the NT_FILE notes
and rerun the tests.  This should make no difference as all this test
is checking is that GDB is able to find and load the shared libraries
and executable based on their build-ids; this is something we can do
fine now without the NT_FILE note.

I have also had to update the Python core file API documentation after
this commit.  Previously we claimed that CorefileMappedFile.filename
would never be empty, but this is now possible.  Luckily, this API has
not yet been in a released version of GDB, so this minor tweak isn't
going to break any existing user code.  I did consider having
CorefileMappedFile.filename be a non-empty string or None, but I
couldn't see much value in this, so I just documented that the string
could be empty, and what this means.

The py-corefile.exp test needed a minor update to filter out anonymous
mappings (those without a filename), this matches the behaviour of the
builtin 'info proc mappings' command.

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

gdb: remove pre-loop callback from gdbarch_read_core_file_mappings

Currently only one target, Linux, implements
gdbarch_read_core_file_mappings, with
linux_read_core_file_mappings. There is one use of
gdbarch_read_core_file_mappings in corelow.c, and one direct use of
linux_read_core_file_mappings in linux-tdep.c.

The gdbarch_read_core_file_mappings takes two callbacks, a pre-loop
callback, which is called once, then a loop callback which is called
multiple times for each mapping that is discovered.

The only user of the pre-loop callback is in linux-tdep.c.  Within
corelow.c, the pre-loop callback is not used.

In the next commit I plan to change linux_read_core_file_mappings, and
as a result of this change the use of linux_read_core_file_mappings in
linux-tdep.c will no longer be able to make use of the pre-loop
callback.  This means that, after the next commit, there will be no
users of the pre-loop callback.

Additionally, the pre-loop callback takes an argument, the number of
mappings found.

After the next commit it is no longer clear what number we should pass
here as the next commit will introduce the idea of there being two
types of mapping, anonymous and non-anonymous.  Should the number
passed to the pre-loop callback be the combined total?  Or should we
count each separately?

I could try to answer this question.

Or I could just delete the pre-loop callback from
gdbarch_read_core_file_mappings.

This commit takes the second approach and deletes the callback.

As part of this work I've updated linux_core_info_proc_mappings, which
is the function that calls linux_read_core_file_mappings, so that the
pre-loop callback is no longer used.  The lambda capture on the loop
callback needed to change from [=] to [&] with this commit so
`emitter` from the enclosing scope can be modified.

There is one subtle change of behaviour in
linux_core_info_proc_mappings after this commit.  Previously,
linux_core_info_proc_mappings would print the table header so long as
the core file had a valid NT_FILE note, even if that note contained no
actual file mappings.

With the removal of the pre-loop callback I had a choice, either
always print the table header, or only print the table header if I saw
some entries being printed.  I selected the second choice as that
seemed like the smallest change, but there is a change here.  If a
user has a core file with an NT_FILE note containing no mapped files,
then the table header will no longer be printed.  Hopefully this isn't
too disruptive.

This is a refactoring commit in preparation for the next one.

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

gdb: remove 'num' argument from gdbarch_read_core_file_mappings callback

The gdbarch_read_core_file_mappings method takes two callback
functions.  The second of these, the loop_cb takes a 'num' parameter
that is never used.  It's not entirely clear what this 'num'
represents, and in later commits I'm going to be tweaking what gets
sent through this callback, and it's not clear to me how 'num' should
be changed.

So let's just remove the 'num' argument, this will make the later
commits easier.

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

gdb/testsuite: restructure gdb.base/corefile-buildid.exp

Restructure the gdb.base/corefile-buildid.exp test.  Previously this
test focused on testing that GDB could find the executable for a core
file based on the executable's build-id.  The test did include
building an executable that made use of shared libraries, but the test
never tried to confirm that GDB could find these shared libraries
based on their build-id, only the executable was being tested.

This rewrite extends the test so that, for the shared library using
executable, both of the shared libraries are moved into the debug
directory, we then check that they are found when the core file is
opened.  As the debug directory is indexed by build-id, this indicates
that GDB can find the shared libraries for a core file based on the
build-id of the shared libraries.  The existing executable lookup
tests are unchanged, this is just adding additional testing.

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

gdb/testsuite: improve corefile-no-threads.py script

Extend the Python script gdb.base/corefile-no-threads.py so that core
file note types can be specified by name, e.g. NT_PRSTATUS, rather
than having to use their hex value.

I've only added a few names for now.  The existing test only needs
NT_PRSTATUS, but I plan to reuse this script for a new test, in which
case I'll also need NT_FILE.  Additional names can be added in the
future as needed.

I then updated the gdb.base/corefile-no-threads.exp script to make use
of this functionality, and I improved the test pattern so that it
actually checks that a note was updated.

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

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

Update more tests for gnat-llvm

I found a few more tests where a simple change would preserve the
behavior of the test while also making it pass with gnat-llvm.

As this is Ada and gnat-llvm-specific, I am checking it in.

Use fully-qualified name in var_decl_name

While testing gdb against a version of gnat-llvm that emits
unqualified names (in a hierarchical structure), I found that
gdb.ada/array_of_symbolic_length.exp would fail.

The DWARF in question looks like this:

 <1><11a1>: Abbrev Number: 2 (DW_TAG_module)
    <11a2>   DW_AT_name        : (indirect string, offset: 0xe65): pck
 <2><11a6>: Abbrev Number: 3 (DW_TAG_variable)
    <11a7>   DW_AT_name        : (indirect string, offset: 0xe69): my_length_LAST
[...]
 <3><11df>: Abbrev Number: 5 (DW_TAG_subrange_type)
    <11e0>   DW_AT_type        : <0x12ab>
    <11e4>   DW_AT_upper_bound : <0x11a6>

That is, an array's upper bound refers to my_length_LAST.  gdb
represents this as a PROP_VARIABLE_NAME -- but only the local name of
the variable was used in this case.

This patch changes var_decl_name to use the correct full name for the
variable.

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

[gdb/tui] Simplify tui_enable

I noticed some code in tui_enable doing:
...
if (...)
  error (...);
else if (...)
...
which is the "Don’t use else after a return" anti-pattern [1].

Fix this by using:
...
if (...)
  error (...);

if (...)
...

Approved-By: Tom Tromey <tom@tromey.com>
[1] https://llvm.org/docs/CodingStandards.html#id41

Avoid crash in dwarf2/read.c:determine_prefix

I found a gdb crash when using some changes to gnat-llvm to have it
emit unqualified names in the DWARF.  The crash happens because
determine_prefix does this:

  return dwarf2_full_name (nullptr, parent, cu);

However, dwarf2_full_name can return NULL, causing a crash in the
caller.

The particular DWARF causing this is pretty strange -- it is a
function nested inside another nameless function.  This may be a bug
in gnat-llvm, something I plan to investigate.

Meanwhile, gdb shouldn't crash.  This patch changes determine_prefix
to avoid possible crashes here, by following its contract and not
returning NULL.

I'm not sure if it's worthwhile to write a test case for this.

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

Remove symbol lookup of arguments

gdb has some code that looks up argument variables a second time.  So
for instance in mi-cmd-stack.c:

      if (sym->is_argument ())
sym2 = (lookup_symbol_search_name
(sym->search_name (),
 block, SEARCH_VAR_DOMAIN).symbol);
      else
sym2 = sym;

I believe this is a leftover artifact of stabs.  I'm not really
certain (I never really learned stabs) but I think in stabs a function
argument had two symbols: one for the parameter and a second one that
described the location of the argument after the prologue.

DWARF doesn't do this, and there's no need to keep this code around
any more.

This patch removes these vestiges.  In the Ada code, removing the
special argument handling also left the "found_sym" code unused,
leading to more deletions.

For block_lookup_symbol, while the comment there explains that the
"best symbol" hack isn't needed in this situation, it seemed to me
that (1) it might in fact be (because I think a function block could
very well have locals and types as well), and (2) making this function
simpler and removing the argument hack is the better approach anyway.

Regression tested on x86-64 Fedora 43.

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

Remove unused str_backtrace_unavailable variable

The str_backtrace_unavailable variable is initialized but never
used anywhere in the codebase.

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

PR 34062 type confusion in elf64_ia64_hash_copy_indirect

The output bfd determines the linker hash table type and symbol entry
type, so the output bfd functions should be used when manipulating
hash table symbols.

* elflink.c (_bfd_elf_add_default_symbol): Get elf backend data
from output bfd, not input.
(elf_link_add_object_symbols): Likewise for e_b_hide_symbol and
e_b_copy_symbol.
(_bfd_elf_merge_symbol): Likewise.
(_bfd_elf_fix_symbol_flags): Likewise.

Delete _bfd_elf_get_dynamic_reloc_section

When _bfd_elf_make_dynamic_reloc_section is used by a target's
check_relocs, it guarantees elf_section_data(sec)->sreloc is set to
the dynamic reloc section associated with the input section.  That
means there is no need to later search for the dynamic reloc section
via name lookup.

* elflink.c (_bfd_elf_get_dynamic_reloc_section): Delete.
* elf-bfd.h (_bfd_elf_get_dynamic_reloc_section): Don't declare.
* elf-m10300.c (mn10300_elf_final_link_relocate): Get dynamic
reloc section via elf_section_data.
* elf32-arc.c (elf_arc_relocate_section): Likewise.
* elf32-arm.c (elf32_arm_final_link_relocate): Likewise.
* elf32-cris.c (cris_elf_relocate_section): Likewise.
(elf_cris_discard_excess_dso_dynamics): Likewise.
* elf32-m32r.c (m32r_elf_relocate_section): Likewise.
* elf32-sh.c (sh_elf_relocate_section): Likewise.
* elf32-vax.c (elf_vax_relocate_section): Likewise.

Remove check_relocs_after_open_input

After commit 5c3261b0e834 there was no need for this flag.  Remove it
and tidy places that used it.

include/
* bfdlink.h (struct bfd_link_info): Delete
check_relocs_after_open_input.
ld/
* emultempl/aarch64elf.em (before_parse): Don't set
link_info.check_relocs_after_open_input.
* emultempl/armelf.em (before_parse): Likewise.
* emultempl/elf.em (before_parse): Likewise.
* emultempl/scoreelf.em (before_parse): Likewise.
* emultempl/mmix-elfnmmo.em (mmix_before_parse): Delete.
(LDEMUL_BEFORE_PARSE): Don't define.
* emultempl/mmixelf.em (elfmmix_before_parse): Call elf.em
before_parse.
* ldlang.c (lang_check_relocs): Don't test
link_info.check_relocs_after_open_input.

Re: LoongArch: Enforce 4-byte align for machine instructions

readelf output is different for 32-bit objects.  Fix the test for
loongarch32 by not overspecifying the match.

gprof support for split debuginfo, tweak 2

This reverts commit a2ceac895716f71daf67eca5b5897bf316500749,
but adds back unconditional BFD_DECOMPRESS, as per amodra:
https://inbox.sourceware.org/binutils/afPQ5BGfFQHYBny1@squeak.grove.modra.org/

Signed-off-by: Frank Ch. Eigler <fche@elastic.org>

Automatic date update in version.in

Mention Windows non-stop support in NEWS

Add a note to gdb/NEWS mentioning Windows native target non-stop
support.

Approved-By: Eli Zaretskii <eliz@gnu.org>
Change-Id: Id0e28525c06e57120c47b07f978581d1627d70f3
commit-id:0f56dd46

Windows gdb: Always non-stop (default to "maint set target-non-stop on")

Since having the target backend work in non-stop mode adds features
compared to old all-stop mode (signal/exception passing/suppression is
truly per-thread), this switches the backend to do
all-stop-on-top-of-non-stop, by having
windows_nat_target::always_non_stop_p return true if non-stop mode is
possible.

To be clear, this just changes how the backend works in coordination
with infrun.  The user-visible mode default mode is still all-stop.

The difference is that infrun is responsible for stopping all threads
when needed, instead of the backend (actually the kernel) always doing
that before reporting an event to infrun.

Approved-By: Tom Tromey <tom@tromey.com>
Change-Id: I83d23dbb1edc7692d5d8b37f5b9e0264c74d4940
commit-id:6f7924dc

infrun: with AS+NS, prefer process exit over thread exit

This patch fixes gdb.base/ending-run.exp for Windows when the target
backend supports notifying infrun about thread exit events (which is
added by the Windows non-stop support, later).

Without this patch, and with the Windows target in non-stop mode
("maint set target-non-stop on"), we get, when stepping out of main:

 (gdb) PASS: gdb.base/ending-run.exp: Step to return
 next
 32      }
 (gdb) next
 [Thread 7956.0x2658 exited]
 [Thread 7956.0x2500 exited]
 [Thread 7956.0x2798 exited]
 Command aborted, thread exited.
 (gdb) FAIL: gdb.base/ending-run.exp: step out of main

With the patch, we get:

 (gdb) next
 [Thread 9424.0x40c exited]
 [Inferior 1 (process 9424) exited normally]
 (gdb) PASS: gdb.base/ending-run.exp: step out of main

In the failing case, what happens is that "next" enables
target_thread_events.  Then, the main thread causes the whole process
to exit.  On Windows, that makes the main thread report a thread exit
event, followed by thread exit events for all other threads, except
the last thread that happens to be the one that exits last.  That last
one reports an exit-process event instead.

Since "next" enabled target_thread_events, the Windows target backend
reports the main thread's exit event to infrun.  And then, since the
thread that was stepping reported a thread-exit, GDB aborts the "next"
command.

Stepping out of main is a very common thing to do, and I think
reporting the thread exit in this case when the whole process is
exiting isn't very useful.  I think we can do better.  So instead, if
we're about to report a thread exit in all-stop mode with the backend
in non-stop mode, and while stopping all threads, we see a
whole-process-exit event, prefer processing that event instead of
reporting the original thread exit.

A similar issue can be triggered on GNU/Linux as well, if we step over
an exit syscall that is called by any thread other than main.  This
scenario is exercised by the new testcase added by this patch.

Without the patch, the testcase shows:

 (gdb) next
 [Thread 0x7ffff7a00640 (LWP 3207243) exited]
 warning: error removing breakpoint 0 at 0x5555555551c3
 warning: error removing breakpoint 0 at 0x5555555551c3
 warning: error removing breakpoint 0 at 0x5555555551c3
 Command aborted, thread exited.
 Cannot remove breakpoints because program is no longer writable.
 Further execution is probably impossible.
 (gdb)

This is fixed for GNU/Linux by the patch, which results in:

 (gdb) next
 [Thread 0x7ffff7a00640 (LWP 3230550) exited]
 warning: error removing breakpoint 0 at 0x5555555551c3
 warning: error removing breakpoint 0 at 0x5555555551c3
 warning: error removing breakpoint 0 at 0x5555555551c3
 [Inferior 1 (process 3230539) exited normally]
 (gdb)

Pure all-stop targets (such as GNU/Linux GDBserver unless you force
non-stop with "maint set target-non-stop on") will unfortunately still
have the "Further execution is probably impossible." behavior, because
GDB can't see the process-exit event until the target is re-resumed.
That's unfortunate, but I don't think that should prevent improving
non-stop targets.  (And eventually I would like remote targets to be
always "maint set target-non-stop on" by default if possible, too.)

Change-Id: I56559f13e04aeafd812d15e4b408c8337bca5294

Add gdb.threads/leader-exit-schedlock.exp

This adds a new test for letting the main thread exit the process with
scheduler-locking on, while there are other threads live.

On Linux, when the main thread exits without causing a whole-process
exit (e.g., via the main thread doing pthread_exit), the main thread
becomes zombie but does not report a thread exit event.  When
eventually all other threads of the process exit, the main thread is
unblocked out of its zombie state and reports its exit which we
interpret as the whole-process exit.

If the main-thread-exit causes a whole-process exit (e.g., via the
exit syscall), the process is the same, except that the exit syscall
makes the kernel force-close all threads immediately.

Importantly, the main thread on Linux is always the last thread that
reports the exit event.

On Windows, the main thread exiting is not special at all.  When the
main thread causes a process exit (e.g., for ExitProcess or by
returning from main), the debugger sees a normal thread exit event for
the main thread.  All other threads will follow up with a thread-exit
event too, except whichever thread happens to be the last one.  That
last one is the one that reports a whole-process-exit event instead of
an exit-thread event.  So, since programs are typically multi-threaded
on Windows (because the OS/runtime spawns some threads), when the main
thread just returns from main(), it is very typically _not_ the main
thread that reports the whole-process exit.

As a result, stepping the main thread with schedlock on Windows
results in the main thread exiting and the continue aborting due to
no-resumed-threads left instead of a whole-process exit as seen on
Linux:

(gdb) info threads
  Id   Target Id                                    Frame
* 1    Thread 11768.0x1bc "leader-exit-schedlock"   main () at .../gdb.threads/leader-exit-schedlock.c:55
  2    Thread 11768.0x31e0 (in kernel)              0x00007ffbb23dfc77 in ntdll!ZwWaitForWorkViaWorkerFactory () from C:/WINDOWS/SYSTEM32/ntdll.dll
  3    Thread 11768.0x2dec "sig" (in kernel)        0x00007ffbb23dc087 in ntdll!ZwReadFile () from C:/WINDOWS/SYSTEM32/ntdll.dll
  4    Thread 11768.0x2530 (in kernel)              0x00007ffbb23dfc77 in ntdll!ZwWaitForWorkViaWorkerFactory () from C:/WINDOWS/SYSTEM32/ntdll.dll
  5    Thread 11768.0x3384 "leader-exit-schedlock"  0x00007ffbb23dcb17 in ntdll!ZwWaitForMultipleObjects () from C:/WINDOWS/SYSTEM32/ntdll.dll
  6    Thread 11768.0x3198 "leader-exit-schedlock"  0x00007ffbb23dcb17 in ntdll!ZwWaitForMultipleObjects () from C:/WINDOWS/SYSTEM32/ntdll.dll
  7    Thread 11768.0x1ab8 "leader-exit-schedlock"  0x00007ffbb23dcb17 in ntdll!ZwWaitForMultipleObjects () from C:/WINDOWS/SYSTEM32/ntdll.dll
  8    Thread 11768.0x3fe4 "leader-exit-schedlock"  0x00007ffbb23dcb17 in ntdll!ZwWaitForMultipleObjects () from C:/WINDOWS/SYSTEM32/ntdll.dll
  9    Thread 11768.0x3b5c "leader-exit-schedlock"  0x00007ffbb23dcb17 in ntdll!ZwWaitForMultipleObjects () from C:/WINDOWS/SYSTEM32/ntdll.dll
  10   Thread 11768.0x45c "leader-exit-schedlock"   0x00007ffbb23dcb17 in ntdll!ZwWaitForMultipleObjects () from C:/WINDOWS/SYSTEM32/ntdll.dll
  11   Thread 11768.0x3724 "leader-exit-schedlock"  0x00007ffbb23dcb17 in ntdll!ZwWaitForMultipleObjects () from C:/WINDOWS/SYSTEM32/ntdll.dll
  12   Thread 11768.0x1e44 "leader-exit-schedlock"  0x00007ffbb23dcb17 in ntdll!ZwWaitForMultipleObjects () from C:/WINDOWS/SYSTEM32/ntdll.dll
  13   Thread 11768.0x23f0 "leader-exit-schedlock"  0x00007ffbb23dcb17 in ntdll!ZwWaitForMultipleObjects () from C:/WINDOWS/SYSTEM32/ntdll.dll
  14   Thread 11768.0x3b80 "leader-exit-schedlock"  0x00007ffbb23dcb17 in ntdll!ZwWaitForMultipleObjects () from C:/WINDOWS/SYSTEM32/ntdll.dll
(gdb) set scheduler-locking on
(gdb) c
Continuing.
[Thread 11768.0x1bc exited]
No unwaited-for children left.
(gdb) info threads
  Id   Target Id                                                     Frame
  2    Thread 11768.0x31e0 (exiting)                                 0x00007ffbb23dfc77 in ntdll!ZwWaitForWorkViaWorkerFactory () from C:/WINDOWS/SYSTEM32/ntdll.dll
  3    Thread 11768.0x2dec "sig" (exiting)                           0x00007ffbb23dc087 in ntdll!ZwReadFile () from C:/WINDOWS/SYSTEM32/ntdll.dll
  4    Thread 11768.0x2530 (exiting)                                 0x00007ffbb23dfc77 in ntdll!ZwWaitForWorkViaWorkerFactory () from C:/WINDOWS/SYSTEM32/ntdll.dll
  5    Thread 11768.0x3384 "leader-exit-schedlock" (exiting)         0x00007ffbb23dcb17 in ntdll!ZwWaitForMultipleObjects () from C:/WINDOWS/SYSTEM32/ntdll.dll
  6    Thread 11768.0x3198 "leader-exit-schedlock" (exiting)         0x00007ffbb23dcb17 in ntdll!ZwWaitForMultipleObjects () from C:/WINDOWS/SYSTEM32/ntdll.dll
  7    Thread 11768.0x1ab8 "leader-exit-schedlock" (exiting)         0x00007ffbb23dcb17 in ntdll!ZwWaitForMultipleObjects () from C:/WINDOWS/SYSTEM32/ntdll.dll
  8    Thread 11768.0x3fe4 "leader-exit-schedlock" (exiting)         0x00007ffbb23dcb17 in ntdll!ZwWaitForMultipleObjects () from C:/WINDOWS/SYSTEM32/ntdll.dll
  9    Thread 11768.0x3b5c "leader-exit-schedlock" (exiting)         0x00007ffbb23dcb17 in ntdll!ZwWaitForMultipleObjects () from C:/WINDOWS/SYSTEM32/ntdll.dll
  10   Thread 11768.0x45c "leader-exit-schedlock" (exiting)          0x00007ffbb23dcb17 in ntdll!ZwWaitForMultipleObjects () from C:/WINDOWS/SYSTEM32/ntdll.dll
  11   Thread 11768.0x3724 "leader-exit-schedlock" (exiting)         0x00007ffbb23dcb17 in ntdll!ZwWaitForMultipleObjects () from C:/WINDOWS/SYSTEM32/ntdll.dll
  12   Thread 11768.0x1e44 "leader-exit-schedlock" (exiting)         0x00007ffbb23dcb17 in ntdll!ZwWaitForMultipleObjects () from C:/WINDOWS/SYSTEM32/ntdll.dll
  13   Thread 11768.0x23f0 "leader-exit-schedlock" (exiting)         0x00007ffbb23dcb17 in ntdll!ZwWaitForMultipleObjects () from C:/WINDOWS/SYSTEM32/ntdll.dll
  14   Thread 11768.0x3b80 "leader-exit-schedlock" (exiting process) 0x00007ffbb23dcb17 in ntdll!ZwWaitForMultipleObjects () from C:/WINDOWS/SYSTEM32/ntdll.dll

The current thread <Thread ID 1> has terminated.  See `help thread'.
(gdb)

The "(exiting)" and "(exiting process)" threads are threads for which
the kernel already reported their exit to GDB's Windows backend (via
WaitForDebugEvent), but the Windows backend hasn't yet reported the
event to infrun.  The events are still pending in windows-nat.c.

The "(exiting process)" thread above (thread 14) is the one that won
the process-exit event lottery on the Windows kernel side (because it
was the last to exit).  Continuing the (exiting) threads with
schedlock enabled should result in the Windows backend reporting that
thread's pending exit to infrun.  While continuing thread 14 should
result in the inferior exiting.  Vis:

 (gdb) c
 Continuing.
 [Thread 11768.0x31e0 exited]
 No unwaited-for children left.
 (gdb) t 14
 [Switching to thread 14 (Thread 11768.0x3b80)]
 #0  0x00007ffbb23dcb17 in ntdll!ZwWaitForMultipleObjects () from C:/WINDOWS/SYSTEM32/ntdll.dll
 (gdb) c
 Continuing.
 [Inferior 1 (process 11768) exited normally]

The testcase continues all the (exiting) threads, one by one, and then
finally continues the (exiting process) one, expecting an inferior
exit.

The testcase also tries a similar scenario: instead immediately
continue the (exiting process) thread without continuing the others.
That should result in the inferior exiting immediately.

It is actually not guaranteed that the Windows backend will consume
all the thread and process exit events out of the kernel before the
first thread exit event is processed by infrun.  So often we will see
for example, instead:

(gdb) info threads
  Id   Target Id                                                     Frame
  2    Thread 11768.0x31e0 (exiting)                                 0x00007ffbb23dfc77 in ntdll!ZwWaitForWorkViaWorkerFactory () from C:/WINDOWS/SYSTEM32/ntdll.dll
  3    Thread 11768.0x2dec "sig" (exiting)                           0x00007ffbb23dc087 in ntdll!ZwReadFile () from C:/WINDOWS/SYSTEM32/ntdll.dll
  4    Thread 11768.0x2530 (exiting)                                 0x00007ffbb23dfc77 in ntdll!ZwWaitForWorkViaWorkerFactory () from C:/WINDOWS/SYSTEM32/ntdll.dll
  5    Thread 11768.0x3384 "leader-exit-schedlock" (exiting)         0x00007ffbb23dcb17 in ntdll!ZwWaitForMultipleObjects () from C:/WINDOWS/SYSTEM32/ntdll.dll
  6    Thread 11768.0x3198 "leader-exit-schedlock" (exiting)         0x00007ffbb23dcb17 in ntdll!ZwWaitForMultipleObjects () from C:/WINDOWS/SYSTEM32/ntdll.dll
  7    Thread 11768.0x1ab8 "leader-exit-schedlock" (exiting)         0x00007ffbb23dcb17 in ntdll!ZwWaitForMultipleObjects () from C:/WINDOWS/SYSTEM32/ntdll.dll
  8    Thread 11768.0x3fe4 "leader-exit-schedlock" (exiting)         0x00007ffbb23dcb17 in ntdll!ZwWaitForMultipleObjects () from C:/WINDOWS/SYSTEM32/ntdll.dll
  9    Thread 11768.0x3b5c "leader-exit-schedlock" (exiting)         0x00007ffbb23dcb17 in ntdll!ZwWaitForMultipleObjects () from C:/WINDOWS/SYSTEM32/ntdll.dll
  10   Thread 11768.0x45c "leader-exit-schedlock"                    0x00007ffbb23dcb17 in ntdll!ZwWaitForMultipleObjects () from C:/WINDOWS/SYSTEM32/ntdll.dll
  11   Thread 11768.0x3724 "leader-exit-schedlock"                   0x00007ffbb23dcb17 in ntdll!ZwWaitForMultipleObjects () from C:/WINDOWS/SYSTEM32/ntdll.dll
  12   Thread 11768.0x1e44 "leader-exit-schedlock"                   0x00007ffbb23dcb17 in ntdll!ZwWaitForMultipleObjects () from C:/WINDOWS/SYSTEM32/ntdll.dll
  13   Thread 11768.0x23f0 "leader-exit-schedlock" (exiting)         0x00007ffbb23dcb17 in ntdll!ZwWaitForMultipleObjects () from C:/WINDOWS/SYSTEM32/ntdll.dll
  14   Thread 11768.0x3b80 "leader-exit-schedlock" (exiting)         0x00007ffbb23dcb17 in ntdll!ZwWaitForMultipleObjects () from C:/WINDOWS/SYSTEM32/ntdll.dll

Above, we can't tell which thread will get the exit-process event,
there is no "(exiting process)" thread.  We do know it'll be one of
threads 10, 11, and 12, because those do not have "(exiting)".  The
Windows kernel has already decided which one it is at this point, we
just haven't seen the exit-process event yet.

This is actually what we _always_ see with "maint set target-non-stop
off" too, because in all-stop, the Windows backend only processes one
Windows debug event at a time.

So when the the test first continues all the (exiting) threads, one by
one, and then when there are no more "(exiting)" threads, if there is
no "(exiting process)" thread, it tries to exit the remaining threads,
(in the above case threads 10, 11 and 12), expecting that one of those
continues may cause an inferior exit.

On systems other than Windows, the testcase expects that continuing
the main thread results in an inferior exit.  If we find out that
isn't correct for some system, we can adjust the testcase then.

Approved-By: Tom Tromey <tom@tromey.com>
Change-Id: I52fb8de5e72bc12195ffb8bedd1d8070464332d3
commit-id:5f751d8e

Windows gdb: extra thread info => show exiting

Now that we have easy access to each thread's last event, we can
easily include some extra info in "info threads" output related to
each thread's last event.

This patch makes us show whether the thread is exiting, or causing a
whole-process exit.  This is useful when multiple threads hit events
at the same time, and the thread/process exit events are still pending
until the user re-resumes the program.

This is similar to how linux-thread-db.c also shows "Exiting" in its
target_extra_thread_info implementation.

This will be relied on by the testcase added by the following patch.

Approved-By: Tom Tromey <tom@tromey.com>
Change-Id: I493b7ea3e14574dc972b1341eb5062fbbfda1521
commit-id:51b6d728

Windows gdb: Watchpoints while running (internal vs external stops)

Teach the Windows target to temporarily pause all threads when we
change the debug registers for a watchpoint.  Implements the same
logic as Linux uses:

    ~~~
      /*                             (...) if threads are running when the
         mirror changes, a temporary and transparent stop on all threads
         is forced so they can get their copy of the debug registers
         updated on re-resume.   (...)  */
    ~~~

On Linux, we send each thread a SIGSTOP to step them.  On Windows,
SuspendThread itself doesn't cause any asynchronous debug event to be
reported.  However, we've implemented windows_nat_target::stop such
that it uses SuspendThread, and then queues a pending GDB_SIGNAL_0
stop on the thread.  That results in a user-visible stop, while here
we want a non-user-visible stop.  So what we do is re-use that
windows_nat_target::stop stopping mechanism, but add an external vs
internal stopping kind distinction.  An internal stop results in
windows_nat_target::wait immediately re-resuming the thread.

Note we don't make the debug registers poking code SuspendThread ->
write debug registers -> ContinueThread itself, because SuspendThread
is actually asynchronous and may take a bit to stop the thread (a
following GetThreadContext blocks until the thread is actually
suspended), and, there will be several debug register writes when a
watchpoint is set, because we have to set all of DR0, DR1, DR2, DR3,
and DR7.  Defering the actual writes to ::wait avoids a bunch of
SuspendThread/ResumeThread sequences, so in principle should be
faster.

Reviewed-By: Tom Tromey <tom@tromey.com>
Change-Id: I39c2492c7aac06d23ef8f287f4afe3747b7bc53f
commit-id:22d7a7e0

Windows gdb: Add non-stop support

This patch adds non-stop support to the native Windows target.

This is made possible by the ContinueDebugEvent DBG_REPLY_LATER flag:

https://learn.microsoft.com/en-us/windows/win32/api/debugapi/nf-debugapi-continuedebugevent

  Supported in Windows 10, version 1507 or above, this flag causes
  dwThreadId to replay the existing breaking event after the target
  continues. By calling the SuspendThread API against dwThreadId, a
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  debugger can resume other threads in the process and later return to
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  the breaking.
  ^^^^^^^^^^^^

The patch adds a new comment section in gdb/windows-nat.c providing an
overall picture of how all-stop / non-stop work.

Without DBG_REPLY_LATER, if we SuspendThread the thread, and then
immediately ContinueDebugThread(DBG_CONTINUE) before getting back to
the prompt, we could still have non-stop mode working, however, then
users wouldn't have a chance to decide whether to pass the signal to
the inferior the next time they resume the program, as that is done by
passing DBG_EXCEPTION_NOT_HANDLED to ContinueDebugEvent, and that has
already been called.

The patch teaches the Windows native backend to use that
DBG_REPLY_LATER flag, and also adds support for target_stop, so the
core can pause threads at its discretion.  This pausing does not use
the same mechanisms used in windows_nat_target::interrupt, as that
injects a new thread in the inferior.  Instead, for each thread the
core wants paused, it uses SuspendThread, and enqueues a pending
GDB_SIGNAL_0 stop on the thread.

Since DBG_REPLY_LATER only exists on Windows 10 and later, we only
enable non-stop mode on Windows 10 and later.

There is no displaced stepping support, but that's "just" a missed
optimization to be done later.

Cygwin signals handling was a major headache, but I managed to get it
working.  See the "Cygwin signals" description section I added at the
top of windows-nat.c.

Another interesting bit, is that the use DBG_REPLY_LATER caused one
problem with detach.  The Windows kernel re-raises any exception
previously intercepted and deferred with DBG_REPLY_LATER in the
inferior after we detach.  We need to flush those events, and suppress
those which aren't meant to be seen by the inferior (e.g.,
breakpoints, single-steps, any with matching "handle SIG nopass",
etc.), otherwise the inferior dies immediately after the detach, due
to an unhandled exception.

Acked-By: Tom Tromey <tom@tromey.com>
Change-Id: Id71aef461c43c244120635b5bedc638fe77c31fb
commit-id:bbf38a26

Introduce windows_nat::event_code_to_string

Instead of:

   switch (event_code)
     {
     case FOO_DEBUG_EVENT:
      DEBUG_EVENTS (..., "FOO_DEBUG_EVENT");
      ...
     case BAR_DEBUG_EVENT:
      DEBUG_EVENTS (..., "BAR_DEBUG_EVENT");
      ...

... with one DEBUG_EVENTS call per event type, log the event just once
before the switch, and introduce a new event_code_to_string function
to handle the event code to string conversion.

Do the same on GDB's and gdbserver's Windows backends.

Approved-By: Tom Tromey <tom@tromey.com>
Change-Id: Id38b7e30df182e4742f3179538de3c643cf42668
commit-id:a8abf6a6

Windows GDB: make windows_thread_info be private thread_info data

With Windows non-stop support, we'll add support for
target_thread_events to the Windows target.

When that is supported, and the core wants to be notified of thread
exit events, the target backend does not delete the thread for which
the event is being reported.  Instead, infrun takes care of that.

That causes one problem on Windows, which is that Windows maintains
its own separate Windows threads list, in parallel with the struct
thread_info thread list maintained by the core.  In the
target_thread_events events scenario, when infrun deletes the thread,
the corresponding object in the Windows backend thread list is left
dangling, causing problems.

Fix this by eliminating the parallel thread list from the Windows
backend, instead making the windows_thread_info data by registered as
the private data associated with thread_info, like other targets do.

It also adds a all_windows_threads walker function, and associated
range and iterator classes, so that most of the Windows target code
can iterate over Windows threads without having to worry about
fetching the Windows thread data out of thread_info's private data.

Change-Id: I5058969b46e0dd238c89b6c28403c1848f083683

linux-nat: Factor out get_detach_signal code to common code

The Windows target backend will want to do most of what the
get_detach_signal function in gdb/linux-nat.c does, except for the
Linux-specific bits.  This commit moves the code that is shareable to
infrun.c, so that other targets can use it too.

Approved-By: Tom Tromey <tom@tromey.com>
Change-Id: Ifaa96b4a41bb83d868079af4d47633715c0e1940
commit-id:dac5b3f8

Windows gdb+gdbserver: Check whether DBG_REPLY_LATER is available

Per
<https://learn.microsoft.com/en-us/windows/win32/api/debugapi/nf-debugapi-continuedebugevent>,
DBG_REPLY_LATER is "Supported in Windows 10, version 1507 or above, ..."

Since we support versions of Windows older than 10, we need to know
whether DBG_REPLY_LATER is available.  And we need to know this before
starting any inferior.

This adds a function that probes for support (and caches the result),
by trying to call ContinueDebugEvent on pid=0,tid=0 with
DBG_REPLY_LATER, and inspecting the resulting error.

Suggested-by: Hannes Domani <ssbssa@yahoo.de>
Suggested-by: Eli Zaretskii <eliz@gnu.org>
Approved-By: Tom Tromey <tom@tromey.com>
Change-Id: Ia27b981aeecaeef430ec90cebc5b3abdce00449d
commit-id:9098a060

gprof support for split debuginfo, tweak

* gprof/corefile.c: Remove BFD_DECOMPRESS conditional, as per amodra.

Signed-off-by: Frank Ch. Eigler <fche@redhat.com>

gprof support for split debuginfo

Use debug BFD for symbol and line information when a separated
debuginfo file is found, enabling gprof to work correctly with
binaries stripped with "strip -g".  Baby steps toward possible
future debuginfod/dwz support.

gprof/ChangeLog:

2026-04-29  Frank Ch. Eigler  <fche@redhat.com>

        * corefile.c: Add support for separated debuginfo files.
        (core_debug_bfd): New static variable to store separated debug BFD.
        (open_separated_debug_file): New function to locate and open external
        debug files via .gnu_debuglink, .gnu_debugaltlink, or build-id.
        (core_init): Call open_separated_debug_file() after opening the main
        binary to locate external debug info.
        * testsuite/Makefile.am, testsuite/tst-gmon-gprof-l2.sh: Run -l
        test again, but against stripped version of test binary.
        * testsuite/Makefile.in: Regenerated.

Signed-off-by: Frank Ch. Eigler <fche@redhat.com>

Clarify "set non-stop" and "maint set target-non-stop" in GDB manual

This provides the following improvements to the GDB user manual, where
we document "set non-stop" and "maint set target-non-stop":

 - In the "set non-stop" section:

   - Names "all-stop" earlier.

   - Says what mode is the default.

   - Removes old pagination suggestion.

   - Clarifies text.

 - In the "maint set target-non-stop" section:

   - Clarifies "maint set target-non-stop" vs "set non-stop" .

   - Corrects the "auto" description to current reality.

   - Gives a couple examples of what "GDB targets" are.

   - Documents the "all-stop on top of non-stop" term.

Approved-By: Eli Zaretskii <eliz@gnu.org>
Change-Id: Ia720e5091dd57321fb19e6a306678b834ab822df
commit-id:dbc519ee

Fix one test case for gnat-llvm

LLVM is a bit eager about removing unused locals.  Investigating this
test case showed that the problem was that some array bounds, which
are stored in artificial locals, are not emitted.

Since this isn't really germane to the test, and because real code
doesn't normally do this kind of thing, I think it's best to simply
update the test to preserve the bounds.

As this patch is Ada-specific, I am checking it in.

gas: sframe: Error on open CFI at EOF; missing .cfi_endproc

Open CFI at end of file (i.e. .cfi_startproc without matching
.cfi_endproc) caused generation of SFrame strack trace information
to segfault.

Handle an open DWARF FDE in .sframe generation like it is handled
in .eh_frame and .debug_frame generation (see cfi_finish() in
gas/dw2gencfi.c).  Report the following error and set the DWARF FDE
end address to its start address:

  open CFI at the end of file; missing .cfi_endproc directive

gas/
PR/gas 34026
* gen-sframe.c (create_sframe_all): Error on open CFI.

gas/testsuite/
PR/gas 34026
* gas/cfi-sframe/cfi-sframe.exp: Run new test.
* gas/cfi-sframe/cfi-sframe-common-pr34026.d: New test.
* gas/cfi-sframe/cfi-sframe-common-pr34026.s: Likewise.

Signed-off-by: Jens Remus <jremus@linux.ibm.com>

Automatic date update in version.in

Include traits.h in function-view.h

function-view.h uses gdb::Or but does not include gdbsupport/traits.h.
This patch corrects the oversight.

gdb, testsuite: fix gdb.base/save-history.exp for native-extended-gdbserver

When executed with the native-extended-gdbserver board file, we get

  FAIL: gdb.base/save-history.exp: check history contents

This is because the history file contains an extra line for the
command 'target extended-remote ...'.  Address this in the test.

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

Automatic date update in version.in

GDB/testsuite: Fix schedlock.exp crash due to empty $after_args

Prevent gdb.threads/schedlock.exp from crashing due to a premature exit
of the debuggee causing an attempt to use a nil value as an arithmetic
operand:

[...]
(gdb) FAIL: gdb.threads/schedlock.exp: schedlock=off: cmd=next: call_function=0: next to increment, 9
bt
The current thread has terminated
(gdb) FAIL: gdb.threads/schedlock.exp: schedlock=off: cmd=next: call_function=0: find current thread, after
FAIL: gdb.threads/schedlock.exp: schedlock=off: cmd=next: call_function=0: next does not change thread (switched to thread )
print args
Cannot access memory at address 0x410ab0
(gdb) FAIL: gdb.threads/schedlock.exp: schedlock=off: cmd=next: call_function=0: listed args, after
ERROR: tcl error sourcing .../gdb/testsuite/gdb.threads/schedlock.exp.
ERROR: can't use empty string as operand of "-"
    while executing
"if {$cmd == "continue"
    || [lindex $before_args $i] == [lindex $after_args $i] - 10} {
    pass "$test"
} else {
    fail "$test (wrong amo..."
    (procedure "check_result" line 31)
    invoked from within
"check_result $cmd $curthread $before_args $locked"
    (procedure "test_step" line 26)
    invoked from within
"test_step $schedlock "next" $call_function"
    ("uplevel" body line 2)
    invoked from within
"uplevel 1 $body"
    invoked from within
"with_test_prefix "call_function=$call_function" {
    test_step $schedlock "next" $call_function
}"
    ("foreach" body line 2)
    invoked from within
"foreach call_function {0 1} {
with_test_prefix "call_function=$call_function" {
    test_step $schedlock "next" $call_function
}
    }"
    ("uplevel" body line 6)
    invoked from within
"uplevel 1 $body"
    invoked from within
"with_test_prefix "cmd=next" {
    # In GDB <= 7.9, with schedlock "step", "next" would
    # unlock threads when stepping over a function call.  Thi..."
    ("uplevel" body line 5)
    invoked from within
"uplevel 1 $body"
    invoked from within
"with_test_prefix "schedlock=$schedlock" {
with_test_prefix "cmd=step" {
    test_step $schedlock "step" 0
}
with_test_prefix "cmd=next" {
    # I..."
    ("foreach" body line 2)
    invoked from within
"foreach schedlock {"off" "step" "on"} {
    with_test_prefix "schedlock=$schedlock" {
with_test_prefix "cmd=step" {
    test_step $schedlock "step" ..."
    (file ".../gdb/testsuite/gdb.threads/schedlock.exp" line 297)
    invoked from within
"source .../gdb/testsuite/gdb.threads/schedlock.exp"
    ("uplevel" body line 1)
    invoked from within
"uplevel #0 source .../gdb/testsuite/gdb.threads/schedlock.exp"
    invoked from within
"catch "uplevel #0 source $test_file_name""
Remote debugging from host xx.xx.xx.xx, port 56596
monitor exit
(gdb) Killing process(es): 22658
testcase .../gdb/testsuite/gdb.threads/schedlock.exp completed in 32 seconds

Here `print args' has failed to produce output matching the pattern
expected by `get_args' and consequently an empty value has been assigned
to $after_args.  Subsequently a calculation is attempted on an element
of said value treated as a list: `[lindex $after_args $i] - 10' and that
has caused the crash because the resulting minuend is nil.

There are various expressions $after_args and other variables set from
the result of `get_args' are used in, however the majority are equality
operations, which succeed producing a result even where a nil operand is
involved.  Given that this is a test failure scenario anyway follow the
path of least resistance, ignore the other expressions and just prevent
the crash from triggering here by checking for an attempt to retrieve an
inexistent element of $after_args for this calculation, and report it as
a test failure outright letting the script proceed:

[...]
(gdb) FAIL: gdb.threads/schedlock.exp: schedlock=off: cmd=next: call_function=0: next to increment, 9
bt
The current thread has terminated
(gdb) FAIL: gdb.threads/schedlock.exp: schedlock=off: cmd=next: call_function=0: find current thread, after
FAIL: gdb.threads/schedlock.exp: schedlock=off: cmd=next: call_function=0: next does not change thread (switched to thread )
print args
Cannot access memory at address 0x410ab0
(gdb) FAIL: gdb.threads/schedlock.exp: schedlock=off: cmd=next: call_function=0: listed args, after
FAIL: gdb.threads/schedlock.exp: schedlock=off: cmd=next: call_function=0: current thread advanced - unlocked (no arg #1)
PASS: gdb.threads/schedlock.exp: schedlock=off: cmd=next: call_function=0: other threads ran - unlocked
set scheduler-locking off
(gdb) PASS: gdb.threads/schedlock.exp: schedlock=off: cmd=next: call_function=1: set scheduler-locking off
[...]

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

GDB: testsuite: Fix proc return value in gdb.python/py-prettyprint.exp

The callers of the procedure run_lang_tests expect it to return -1 in
case of error but in the case where runto_main fails, it will return
without any value.  Make it return -1 in that case as well.

Found by code inspection.

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

[gdb/symtab] Factor out new_symbol variant

Factor out a new_symbol variant out of new_symbol, containing mostly the
die->tag switch.

While we're at it, modernize the code using bool and nullptr.  Also, remove
some unnecessary braces, and apply this simplification:
...
if (c)
   foo (a);
else
   foo (b);
->
foo (c
     ? a
     : b);
...

I wondered about naming the new variant new_symbol_tag or new_symbol_1, but
I stuck with new_symbol.

Refactoring made we wonder why we use linkagename instead of sym->linkagename ()
after sym->set_linkage_name (), but since there are cornercases where these are
different, I've left it as is.

Also, I suspect the cp_scan_for_anonymous_namespaces can be hoisted, but I
also left that as is.

Finally, I noticed that physname == linkagename uses a pointer equivalence
test, which seems fragile to me.  Also that I left as is.

The patch is easier to view with git show -w.

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

[gdb/tui] Handle error in tui_enable

Say we simulate an error:
...
static void error_once () {
  static int v = 0;
  if (v == 1)
    return;

  v = 1;
  error (_("Oh no!!!"));
}
...
in the call to tui_set_initial_layout in tui_enable:
...
       tui_show_frame_info (deprecated_safe_get_selected_frame ());
+      error_once ();
       tui_set_initial_layout ();
...

After doing "tui enable"
...
$ gdb
(gdb) tui enable
...
the screen is cleared, and we have:
...
❌️ Oh no!!!
           (gdb) <blinking cursor>
...

After typing "apropos tui" (which is not echoed) and pressing enter, I run into
a segmentation violation here in tui_inject_newline_into_command_window:
...
    at /data/vries/gdb/leap-16-0/build/../../src/gdb/tui/tui-io.c:1084
1084   WINDOW *w = tui_cmd_win ()->handle.get ();
...
because:
...
$2 = (tui_cmd_window *) 0x0
(gdb) p tui_cmd_win ()
...

The problem is that tui_active is true, and so
tui_inject_newline_into_command_window get called:
...
static void
tui_command_line_handler (gdb::unique_xmalloc_ptr<char> &&rl)
{
 ...
  if (tui_active)
    tui_inject_newline_into_command_window ();
 ...
}
...

Fix this by catching the error in tui_enable, and resetting tui_active back to
false.

While this fixes the segmentation fault, and does allow "apropos tui" to run,
still the command is not echoed, and the output of the command is garbled by
runaway indentation.

Fix this by using endwin / delscreen, as borrowed from earlier in tui_enable:
...
      if (cap == NULL || cap == (char *) -1 || *cap == '\0')
        {
          endwin ();
          delscreen (s);
          error (_("Cannot enable the TUI: "
                   "terminal doesn't support cursor addressing [TERM=%s]"),
                 gdb_getenv_term ());
        }
...

Note that this doesn't allow a second attempt:
...
$ gdb -q
(gdb) tui enable
❌️ Oh no!!!
(gdb) tui enable
❌️ Cannot enable the TUI
(gdb)
...
because tui_finish_init is stuck at TRIBOOL_UNKNOWN.

IWBN to fix this in a way that allows the second "tui enable" to succeed.  I
tried this for a bit, but didn't get it to work.

Tested on x86_64-linux.

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

[1] https://sourceware.org/pipermail/gdb-patches/2025-May/217660.html

[gdb/testsuite] Fix duplicate copyright notices

I found two files in which there were two copyright notices, in both cases
with overlapping year ranges.

Fix this by merging the copyright notices, using a simple startyear-endyear
range, as per this text in gdb/copyright.py:
...
    # We want to use year intervals in the copyright notices, and
    # all years should be collapsed to one single year interval,
    # even if there are "holes" in the list of years found in the
    # original copyright notice (OK'ed by the FSF, case [gnu.org #719834]).
...

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

[gdb/testsuite] Fix copyright years in two files

I ran gdb/copyright.py, and encountered two files that were added in 2026 but
listed an older copyright year.  Fix this.

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

[gdb/breakpoints] Don't ignore <file> in rbreak <file>:<regexp>

PR breakpoints/34112 reports that "rbreak <file>:<regexp>" sets breakpoints in
files other than <file>.

This is a regression since commit c4c093a31f6 ("Make
global_symbol_searcher::filenames private"), which did:
...
   if (file_name != nullptr)
-    spec.filenames.push_back (file_name);
+    spec.add_filename (std::move (file_name));
...

The std::move nullifies file_name, so a subsequent file_name check:
...
  if (file_name != nullptr)
...
now always evaluates to false.

Fix this by:
- introducing a variable bool file_name_p, initialized before the
  std::move, and
- using that instead.

Tested on x86_64-linux.

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

[gdb/testsuite] Fix tclint errors in gdb.dwarf2/fission-dw-form-strx.exp

Fix two "expected braced word or word without substitutions in argument
interpreted as expr [command-args]" in gdb.dwarf2/fission-dw-form-strx.exp.

Automatic date update in version.in

Mention Windows scheduler-locking in NEWS

Add a note to gdb/NEWS mentioning Windows native target
scheduler-locking support.

Approved-By: Eli Zaretskii <eliz@gnu.org>
Change-Id: Id0e28525c06e57120c47b07f978581d1627d70f3
commit-id:ba1d5868

Restore windows_nat_target::wait is_sw_breakpoint change

Hannes noticed that commit db040a86c8 ("Windows gdb: Simplify
windows_nat_target::wait") inadvertently reverted the earlier
is_sw_breakpoint change in windows_nat_target::wait from 6fc89bae17
("Move software breakpoint recognition code into x86-windows-nat.c")
for Aarch64 support.  This commit restores it.

Change-Id: Ice2181bf4a6c8dcefd127a85ebfc660a3f430517
commit-id:546f39de

gdb.dwarf2: Fix fission-dw-form-strx.exp workflow

The test was using gdb_compile_shlib to create the .dwo file, which
runs the linker. This is incorrect for DWARF fission - .dwo files
should be created by objcopy extraction, not linking.

Per commit 6a29913eeb9, "it was a bad idea to generate a .dwo file
using the linker, since the idea behind .dwo files is that they do
not need to be linked."

GCC's assembler doesn't set the SHF_EXCLUDE flag on .debug_*.dwo
sections, so the linker preserves them in the output. Clang's
assembler sets SHF_EXCLUDE, causing the linker to exclude these
sections. Both approaches are valid, but only the GCC approach
happens to work with this test's incorrect use of the linker.

Rewrite the test to use build_executable_and_dwo_files with the
split-dwo option, matching all other fission-*.exp tests. This uses
objcopy to properly extract .dwo sections without involving the
linker.

Changes:
- Use build_executable_and_dwo_files instead of gdb_compile_shlib
- Generate both skeleton and DWO CUs in single Dwarf::assemble block
- Add debug_str_offsets section for DW_FORM_strx support
- Add is_remote host check (required for objcopy-based workflow)
- Fix DW_AT_dwo_name to match generated filename

Tested: GCC 13.3.0, Clang-23 (passes)

dwarf2: avoid decoding .debug_line for type units

Running gdb.dwarf2/pr13961.exp with clang fails with an internal error:

  gdb/dwarf2/read.c: internal-error: decode_line_header_for_cu:
  Assertion `!cu->per_cu->is_debug_types ()' failed.

pr13961 is a legacy .S test that references a .debug_line label from
both a CU and a TU.  The assembly includes an empty .debug_line section
declaration:

  .section .debug_line,"",%progbits
.Ldebug_line0:

With gcc this results in a dummy (valid, but content-less) .debug_line
header being emitted, so GDB can build a line header and resolve file
indices.  With clang the .debug_line section can be missing/empty,
leaving the line header unset.

During symbol creation, new_symbol may then try to lazily decode the
CU-only line header while processing a type unit, which triggers the
assertion above.

Fix this by only decoding the line header for non-type units.  If no
line header is available, emit a complaint and continue without setting
the symtab rather than attempting CU-only line decoding from a TU.

Tested: gdb.dwarf2/pr13961.exp (CC_FOR_TARGET=clang-23)