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.
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
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>
Abdul Basit Ijaz [Tue, 14 Apr 2026 21:23:51 +0000 (23:23 +0200)]
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.
Mark Wielaard [Sat, 2 May 2026 16:56:52 +0000 (18:56 +0200)]
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.
Alan Modra [Sun, 3 May 2026 11:36:37 +0000 (21:06 +0930)]
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.
Calvin Owens [Sat, 2 May 2026 00:33:21 +0000 (10:03 +0930)]
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>
Simon Marchi [Wed, 29 Apr 2026 00:55:42 +0000 (20:55 -0400)]
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>
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.
Andrew Burgess [Tue, 10 Mar 2026 16:38:31 +0000 (16:38 +0000)]
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.
Andrew Burgess [Tue, 10 Mar 2026 16:20:46 +0000 (16:20 +0000)]
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.
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.
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.
Tom Tromey [Thu, 23 Apr 2026 12:22:43 +0000 (06:22 -0600)]
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.
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>
Tom Tromey [Tue, 21 Apr 2026 20:03:39 +0000 (14:03 -0600)]
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>
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.
Alan Modra [Fri, 1 May 2026 12:48:52 +0000 (22:18 +0930)]
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.
Alan Modra [Fri, 1 May 2026 01:23:03 +0000 (10:53 +0930)]
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.
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>
Pedro Alves [Fri, 16 May 2025 20:11:08 +0000 (21:11 +0100)]
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
Pedro Alves [Wed, 14 May 2025 18:02:34 +0000 (19:02 +0100)]
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.)
Pedro Alves [Wed, 7 May 2025 17:29:56 +0000 (18:29 +0100)]
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
Pedro Alves [Tue, 22 Apr 2025 10:28:11 +0000 (11:28 +0100)]
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
Pedro Alves [Fri, 11 Apr 2025 21:10:50 +0000 (22:10 +0100)]
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
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
Pedro Alves [Fri, 11 Apr 2025 21:36:10 +0000 (22:36 +0100)]
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
Pedro Alves [Thu, 10 Apr 2025 22:28:34 +0000 (23:28 +0100)]
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.
Pedro Alves [Fri, 17 May 2024 19:09:18 +0000 (20:09 +0100)]
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
Pedro Alves [Thu, 9 May 2024 11:32:53 +0000 (12:32 +0100)]
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
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.
Tom Tromey [Wed, 29 Apr 2026 19:41:35 +0000 (13:41 -0600)]
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.
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
[...]
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.
Tom de Vries [Tue, 28 Apr 2026 16:23:55 +0000 (18:23 +0200)]
[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.
Tom de Vries [Tue, 28 Apr 2026 14:36:34 +0000 (16:36 +0200)]
[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
Tom de Vries [Tue, 28 Apr 2026 14:31:01 +0000 (16:31 +0200)]
[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]).
...
Tom de Vries [Tue, 28 Apr 2026 13:57:26 +0000 (15:57 +0200)]
[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
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.
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
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.
LoongArch: Enforce 4-byte align for machine instructions
If no alignment is specified in the assembly file, LoongArch will not
perform forced alignment. When this object file (.o) is linked into an
executable, instructions may not be 4-byte aligned, which will
eventually cause instruction fetch errors.
For example, the above issue can occur when generating a shared object
file (.so) with the -nostdlib option.
Pedro Alves [Tue, 7 May 2024 19:41:37 +0000 (20:41 +0100)]
Windows gdb: Avoid writing debug registers if watchpoint hit pending
Several watchpoint-related testcases, such as
gdb.threads/watchthreads.exp for example, when tested with the backend
in non-stop mode, exposed an interesting detail of the Windows debug
API that wasn't considered before. The symptom observed is spurious
SIGTRAPs, like:
Thread 1 "watchthreads" received signal SIGTRAP, Trace/breakpoint trap.
0x00000001004010b1 in main () at .../src/gdb/testsuite/gdb.threads/watchthreads.c:48
48 args[i] = 1; usleep (1); /* Init value. */
After a good amount of staring at logs and headscratching, I realized
the problem:
#0 - It all starts with the fact that multiple threads can hit an
event at the same time. Say, a watchpoint for thread A, and a
breakpoint for thread B.
#1 - Say, WaitForDebugEvent reports the breakpoint hit for thread B
first, then GDB for some reason decides to update debug
registers, and continue. Updating debug registers means writing
the debug registers to _all_ threads, with SetThreadContext.
#2 - WaitForDebugEvent reports the watchpoint hit for thread A.
Watchpoint hits are reported as EXCEPTION_SINGLE_STEP.
#3 - windows-nat checks the Dr6 debug register to check if the step
was a watchpoint or hardware breakpoint stop, and finds that Dr6
is completely cleared. So windows-nat reports a plain SIGTRAP
(given EXCEPTION_SINGLE_STEP) to the core.
#4 - Thread A was not supposed to be stepping, so infrun reports the
SIGTRAP to the user as a random signal.
The strange part is #3 above. Why was Dr6 cleared?
Turns out that (at least in Windows 10 & 11), writing to _any_ debug
register has the side effect of clearing Dr6, even if you write the
same values the registers already had, back to the registers.
I confirmed it clearly by adding this hack to GDB:
if (th->context.ContextFlags == 0)
{
th->context.ContextFlags = CONTEXT_DEBUGGER_DR;
/* Get current values of debug registers. */
CHECK (GetThreadContext (th->h, &th->context));
[windows events] fill_thread_context: For 0x6a0 (once), Dr6=0xffff0ff1
[windows events] fill_thread_context: For 0x6a0 (twice), Dr6=0x0
This commit fixes the issue by detecting that a thread has a pending
watchpoint hit to report (Dr6 has interesting bits set), and if so,
avoid modifying any debug register. Instead, let the pending
watchpoint hit be reported by WaitForDebugEvent. If infrun did want
to modify watchpoints, it will still be done when the thread is
eventually re-resumed after the pending watchpoint hit is reported.
(infrun knows how to gracefully handle the case of a watchpoint hit
for a watchpoint that has since been deleted.)
Move the fill_thread_context method from windows_nat_target to
windows_per_inferior so it can be used by gdbserver too.
Approved-By: Tom Tromey <tom@tromey.com>
Change-Id: I21a3daa9e34eecfa054f0fea706e5ab40aabe70a
commit-id:a28f8d4e
Pedro Alves [Wed, 17 May 2023 16:05:43 +0000 (17:05 +0100)]
Windows gdb: cygwin_set_dr => windows_set_dr, etc.
The Windows backend functions that manipulate the x86 debug registers
are called "cygwin_foo", which is outdated, because native MinGW gdb
also uses those functions, they are not Cygwin-specific. Rename them
to "windows_foo" to avoid confusion.
Approved-By: Tom Tromey <tom@tromey.com>
Change-Id: I46df3b44f5272adadf960da398342a3cbdb98533
commit-id:896523e0
Pedro Alves [Mon, 22 May 2023 10:29:44 +0000 (11:29 +0100)]
Windows gdb: Change serial_event management
windows_nat_target::windows_continue, when it finds a resumed thread
that has a pending event, does:
/* There's no need to really continue, because there's already
another event pending. However, we do need to inform the
event loop of this. */
serial_event_set (m_wait_event);
return TRUE;
If we have more than one pending event ready to be consumed, and,
windows_nat_target::wait returns without calling
windows_nat_target::windows_continue, which it will with the non-stop
support in a later patch, then we will miss waking up the event loop.
This patch makes windows-nat.c manage the serial_event similarly to
how linux-nat.c does it. Clear it on entry to
windows_nat_target::wait, and set it if there may be more events to
process. With this, there's no need to set it from
windows_nat_target::wait_for_debug_event_main_thread, so the patch
also makes us not do it.
Approved-By: Tom Tromey <tom@tromey.com>
Change-Id: I44e1682721aa4866f1dbb052b3cfb4870fb13579
commit-id:669a42f6
Pedro Alves [Wed, 17 May 2023 13:34:53 +0000 (14:34 +0100)]
Windows gdb+gdbserver: Eliminate struct pending_stop
After the previous patches, struct pending_stop only contains one
field. So move that field into the windows_thread_info structure
directly, and eliminate struct pending_stop.
Approved-By: Tom Tromey <tom@tromey.com>
Change-Id: I7955884b3f378d8b39b908f6252d215f6568b367
commit-id:fb68c808
Pedro Alves [Fri, 30 Aug 2024 15:02:21 +0000 (16:02 +0100)]
Add backpointer from windows_thread_info to windows_process_info
The next patch will move some duplicated code in gdb and gdbserver to
gdb/nat/windows-nat.c, where it would be convenient to get at the
Windows process info of a given Windows thread info, from within a
windows_thread_info method.
I first thought of passing down the windows_process_info pointer as
argument to the windows_thread_info method, but that looked a bit odd.
I think it looks better to just add a back pointer, so that's what
this patch does. The following patch will then add a use of it.
I suspect this will help moving more duplicated code to
gdb/nat/windows-nat.c in the future, too.
Approved-By: Tom Tromey <tom@tromey.com>
Change-Id: I47fc0d3323be5b6f6fcfe912b768051a41910666
Pedro Alves [Mon, 22 May 2023 16:33:16 +0000 (17:33 +0100)]
Windows gdb+gdbserver: Make siginfo_er per-thread state
With non-stop mode support, each thread has its own "last event", and
so printing $_siginfo should print the siginfo of the selected thread.
Likewise, with all-stop and scheduler-locking.
This patch reworks the siginfo functions in gdb/windows-nat.c and
gdbserver/win32-low.cc to reuse the exception record already saved
within each thread's 'last_event' field.
Here's an example of what you'll see after the whole non-stop series:
This was in non-stop mode, and the program originally had two threads.
Thread 1 stopped for a breakpoint, then thread 2 was manually
interrupted/paused and then single-stepped. And then I typed Ctrl-C
in the inferior's terminal, which made Windows inject thread 3 in the
inferior, and report a DBG_CONTROL_C exception for it.
Approved-By: Tom Tromey <tom@tromey.com>
Change-Id: I5d4f1b62f59e8aef3606642c6524df2362b0fb7d
commit-id:e0f75dea
Pedro Alves [Thu, 11 May 2023 17:41:27 +0000 (18:41 +0100)]
Windows gdbserver: Eliminate soft-interrupt mechanism
I noticed that faked_breakpoint is write only. And then I hacked
win32_process_target::request_interrupt to force it to stop threads
using the soft_interrupt_requested mechanism (which suspends threads,
and then fakes a breakpoint event in the main thread), and saw that it
no longer works -- gdbserver crashes accessing a NULL current_thread,
because fake_breakpoint_event does not switch to a thread.
This code was originally added for Windows CE, as neither
GenerateConsoleCtrlEvent nor DebugBreakProcess worked there. Windows
CE support has since been removed.
We nowadays require Windows XP or later, and XP has DebugBreakProcess.
The soft_interrupt_requested mechanism has other problems, like for
example faking the event in the main thread, even if that thread was
previously stopped, due to scheduler-locking.
A following patch will add a similar mechanism stopping all threads
with SuspendThread to native GDB, for non-stop mode, which doesn't
have these problems. It's different enough from this old code that I
think we should just rip the old code out, and reimplement it from
scratch (based on gdb's version) when we need it.
Approved-By: Tom Tromey <tom@tromey.com>
Change-Id: I89e98233a9c40c6dcba7c8e1dacee08603843fb1
Pedro Alves [Thu, 11 May 2023 22:07:33 +0000 (23:07 +0100)]
Windows gdb: Enable "set scheduler-locking on"
Surprisingly (to me), enabling scheduler locking on Windows currently
fails:
(gdb)
set scheduler-locking on
Target 'native' cannot support this command.
The backend itself does support scheduler-locking. This patch
implements windows_nat_target::get_thread_control_capabilities so that
the core knows schedlocking works for this target.
Approved-By: Tom Tromey <tom@tromey.com>
Change-Id: Ie762d3768fd70e4ac398c8bcc03c3213bfa26a6a
Pedro Alves [Thu, 11 May 2023 11:15:36 +0000 (12:15 +0100)]
Windows gdbserver: Fix scheduler-locking
This rewrites win32_process_target::resume such that scheduler-locking
is implemented properly.
It also uses the new get_last_debug_event_ptid function to avoid
considering passing a signal to the wrong thread, like done for the
native side in a previous patch.
Note this code/comment being removed:
- /* Yes, we're ignoring resume_info[0].thread. It'd be tricky to make
- the Windows resume code do the right thing for thread switching. */
- tid = windows_process.current_event.dwThreadId;
This meant that scheduler-locking currently is broken badly unless you
stay in the thread that last reported an event. If you switch to a
different thread from the one that last reported an event and step,
you get a spurious SIGTRAP in the thread that last reported a stop,
not the one that you tried to step:
(gdb) t 1
[Switching to thread 1 (Thread 3908)]
#0 0x00007fffc768d6e4 in ntdll!ZwDelayExecution () from target:C:/Windows/SYSTEM32/ntdll.dll
(gdb) set scheduler-locking on
(gdb) set disassemble-next-line on
(gdb) frame
#0 0x00007fffc768d6e4 in ntdll!ZwDelayExecution () from target:C:/Windows/SYSTEM32/ntdll.dll
=> 0x00007fffc768d6e4 <ntdll!ZwDelayExecution+20>: c3 ret
(gdb) si
Thread 3 received signal SIGTRAP, Trace/breakpoint trap.
[Switching to Thread 2660]
0x00007fffc4e4e92e in KERNELBASE!EncodeRemotePointer () from target:C:/Windows/System32/KernelBase.dll
=> 0x00007fffc4e4e92e <KERNELBASE!EncodeRemotePointer+8254>: eb 78 jmp 0x7fffc4e4e9a8 <KERNELBASE!EncodeRemotePointer+8376>
(gdb)
Note how we switched to thread 1, stepped, and GDBserver still stepped
thread 3... This is fixed by this patch. We now get:
(gdb) info threads
Id Target Id Frame
1 Thread 920 0x00007ffe0372d6e4 in ntdll!ZwDelayExecution () from target:C:/Windows/SYSTEM32/ntdll.dll
2 Thread 8528 0x00007ffe03730ad4 in ntdll!ZwWaitForWorkViaWorkerFactory () from target:C:/Windows/SYSTEM32/ntdll.dll
3 Thread 3128 0x00007ffe03730ad4 in ntdll!ZwWaitForWorkViaWorkerFactory () from target:C:/Windows/SYSTEM32/ntdll.dll
* 4 Thread 7164 0x00007ffe0102e929 in KERNELBASE!EncodeRemotePointer () from target:C:/Windows/System32/KernelBase.dll
5 Thread 8348 0x00007ffe0372d6e4 in ntdll!ZwDelayExecution () from target:C:/Windows/SYSTEM32/ntdll.dll
6 Thread 2064 0x00007ffe0372d6e4 in ntdll!ZwDelayExecution () from target:C:/Windows/SYSTEM32/ntdll.dll
(gdb) t 1
[Switching to thread 1 (Thread 920)]
#0 0x00007ffe0372d6e4 in ntdll!ZwDelayExecution () from target:C:/Windows/SYSTEM32/ntdll.dll
(gdb) set scheduler-locking on
(gdb) si
0x00007ffe0372d6e4 in ntdll!ZwDelayExecution () from target:C:/Windows/SYSTEM32/ntdll.dll
(gdb) si
0x00007ffe00f9b44e in SleepEx () from target:C:/Windows/System32/KernelBase.dll
(gdb) si
0x00007ffe00f9b453 in SleepEx () from target:C:/Windows/System32/KernelBase.dll
I.e., we kept stepping the right thread, thread 1.
Note we stopped again at 0x00007ffe0372d6e4 the first time (same PC
the thread already was at before the first stepi) because the thread
had been stopped at a syscall, so that's normal:
(gdb) disassemble
Dump of assembler code for function ntdll!ZwDelayExecution:
0x00007ffe0372d6d0 <+0>: mov %rcx,%r10
0x00007ffe0372d6d3 <+3>: mov $0x34,%eax
0x00007ffe0372d6d8 <+8>: testb $0x1,0x7ffe0308
0x00007ffe0372d6e0 <+16>: jne 0x7ffe0372d6e5 <ntdll!ZwDelayExecution+21>
0x00007ffe0372d6e2 <+18>: syscall
=> 0x00007ffe0372d6e4 <+20>: ret
Approved-By: Tom Tromey <tom@tromey.com>
Change-Id: I44f4fe4cb98592517569c6716b9d189f42db25a0
commit-id:2a7b7d8e
Pedro Alves [Thu, 11 May 2023 11:27:27 +0000 (12:27 +0100)]
Windows gdb: Can't pass signal to thread other than last stopped thread
Passing a signal to a thread other than the one that last reported an
event will be later possible with DBG_REPLY_LATER and the Windows
backend working in non-stop mode.
With an all-stop backend that isn't possible, so at least don't
incorrectly consider passing DBG_EXCEPTION_NOT_HANDLED if the thread
that we're going to call ContinueDebugEvent for is not the one that
the user issued "signal SIG" on.
Approved-By: Tom Tromey <tom@tromey.com>
Change-Id: I27092ecfbf0904ebce02dff07d9104d22f3d8f0e
commit-id:30c8d0ce
Pedro Alves [Tue, 7 May 2024 15:04:50 +0000 (16:04 +0100)]
Windows gdb+gdbserver: Elim desired_stop_thread_id / rework pending_stops
windows_process.desired_stop_thread_id doesn't work for non-stop, as
in that case every thread will have its own independent
WaitForDebugEvent event.
Instead, detect whether we have been reported a stop that was not
supposed to be reported by simply checking whether the thread that is
reporting the event is suspended. This is now easilly possible since
each thread's suspend state is kept in sync with whether infrun wants
the thread executing or not.
windows_process.desired_stop_thread_id was also used as thread to pass
to windows_continue. However, we don't really need that either.
windows_continue is used to update the thread's registers, unsuspend
them, and then finally call ContinueDebugEvent. In most cases, we
only need the ContinueDebugEvent step, so we can convert the
windows_continue calls to continue_last_debug_event_main_thread calls.
The exception is when we see a thread creation event -- in that case,
we need to update the debug registers of the new thread. We can use
continue_one_thread for that.
Since the pending stop is now stored in windows_thread_info,
get_windows_debug_event needs to avoid reaching the bottom code if
there's no thread associated with the event anymore (i.e.,
EXIT_THREAD_DEBUG_EVENT / EXIT_PROCESS_DEBUG_EVENT).
I considered whether it would be possible to keep the pending_stop
handling code shared in gdb/nat/windows-nat.c, in this patch and
throughout the series, but I conclused that it isn't worth it, until
gdbserver is taught about async and non-stop as well.
The pending_stop struct will eventually be eliminated later down the
series.
Approved-By: Tom Tromey <tom@tromey.com>
Change-Id: Ib7c8e8d16edc0900b7c411976c5d70cf93931c1c
commit-id:0b93b3f0
Pedro Alves [Thu, 18 May 2023 18:13:45 +0000 (19:13 +0100)]
Windows gdb: Pending stop and current_event
I noticed that windows_nat_target::get_windows_debug_event does not
copy the event recorded in pending stop to
windows_process.current_event. This seems like an oversight. The
equivalent code in gdbserver/win32-low.cc does copy it.
This change will become moot later in the series, but I figure its
still clearer to correct the buglet as preparatory patch.
Approved-By: Tom Tromey <tom@tromey.com>
Change-Id: Ic8935d854cf67a3a3c4edcbc1a1e8957b800d907
Pedro Alves [Tue, 9 May 2023 19:34:50 +0000 (20:34 +0100)]
Windows gdb: Factor code out of windows_nat_target::windows_continue
This factors some code out of windows_nat_target::windows_continue
into a new windows_continue_one function. This will make the
following patch easier to read (as well as the resulting code itself).
Approved-By: Tom Tromey <tom@tromey.com>
Change-Id: I14a0386b1b8b03015e86273060af173b5130e375
Pedro Alves [Thu, 21 Oct 2021 17:16:58 +0000 (18:16 +0100)]
Windows gdb: Introduce windows_continue_flags
windows_continue already has two boolean parameters:
(..., int killed, bool last_call = false)
A patch later in the series would need a third. Instead, convert
windows_continue to use an optional enum-flags parameter instead of
multiple booleans.
Approved-By: Tom Tromey <tom@tromey.com>
Change-Id: I17c4d8a12b662190f972c380f838cb3317bd2e1e
commit-id:e669e7de
Pedro Alves [Thu, 21 Oct 2021 17:16:58 +0000 (18:16 +0100)]
Windows gdb: Introduce continue_last_debug_event_main_thread
We have code using do_synchronously to call continue_last_debug_event,
and later patches in the series would need to add the same code in few
more places. Factor it out to a continue_last_debug_event_main_thread
function so these other places in future patches can just call it.
Approved-By: Tom Tromey <tom@tromey.com>
Change-Id: I945e668d2b3daeb9de968219925a7b3c7c7ce9ed
commit-id:ee04461a
Pedro Alves [Tue, 9 May 2023 09:27:04 +0000 (10:27 +0100)]
Windows gdb+gdbserver: Move suspending thread to when returning event
The current code suspends a thread just before calling
GetThreadContext. You can only call GetThreadContext if the thread is
suspended. But, after WaitForDebugEvent, all threads are implicitly
suspended. So I don't think we even needed to call SuspendThread
explictly at all before our GetThreadContext calls.
However, suspending threads when we're about to present a stop to gdb
simplifies adding non-stop support later. This way, the windows
SuspendThread state corresponds to whether a thread is suspended or
resumed from the core's perspective. Curiously, I noticed that Wine's
winedbg does something similar:
https://github.com/wine-mirror/wine/blob/234943344f7495d1e072338f0e06fa2d5cbf0aa1/programs/winedbg/gdbproxy.c#L651
This makes it much easier to reason about a thread's suspend state,
and simplifies adding non-stop mode later on.
Approved-By: Tom Tromey <tom@tromey.com>
Change-Id: Ifd6889a8afc041fad33cd1c4500e38941da6781b
commit-id:c4d2c92e
Pedro Alves [Thu, 11 May 2023 12:16:09 +0000 (13:16 +0100)]
Windows gdb: Simplify windows_nat_target::wait
The logic in windows_nat_target::wait, where we decide what to do
depending on the result from get_windows_debug_event is harder to
grasp than it looks.
It is not easy to tell what should happen when in async mode
get_windows_debug_event returns that there's no event to process.
And then, if get_windows_debug_event returns null_ptid /
TARGET_WAITKIND_SPURIOUS, then we need to issue a ContinueDebugEvent.
There's also this comment in windows_nat_target::wait, which we're not
really implementing today:
~~~~
/* We loop when we get a non-standard exception rather than return
with a SPURIOUS because resume can try and step or modify things,
which needs a current_thread->h. But some of these exceptions mark
the birth or death of threads, which mean that the current thread
isn't necessarily what you think it is. */
~~~~
This patch changes things a bit so that the code is more obvious:
- look at the status kind, instead of ptid_t.
- add an explicit early return case for no-event.
- add an explicit case for TARGET_WAITKIND_SPURIOUS.
- with those, we no longer need to handle the case of find_thread not
finding a thread, so we can drop one indentation level.
Approved-By: Tom Tromey <tom@tromey.com>
Change-Id: I76c41762e1f893a7ff23465856ccf6a44af1f0e7
commit-id:aff7fc4a
Pedro Alves [Tue, 9 May 2023 09:13:08 +0000 (10:13 +0100)]
Windows gdb+gdbserver: Eliminate DONT_SUSPEND
There's a single call to thread_rec(DONT_SUSPEND), in
windows_process_info::handle_exception.
In GDB, the windows-nat.c thread_rec implementation avoids actually
calling SuspendThread on the event thread by doing:
th->suspended = -1;
I am not exactly sure why, but it kind of looks like it is done as an
optimization, avoiding a SuspendThread call? It is probably done for
the same reason as the code touched in the previous patch avoided
suspending the event thread.
This however gets in the way of non-stop mode, which will really want
to SuspendThread the event thread for DBG_REPLY_LATER.
In gdbserver's thread_rec implementation DONT_SUSPEND is ignored, and
thread_rec actually always suspends, which really suggests that
SuspendThread on the event thread is really not a problem. I really
can't imagine why it would be.
DONT_SUSPEND invalidates the thread's context, but there is no need to
invalidate the context when we get an event for a thread, because we
invalidate it when we previously resumed the thread.
So, we can just remove the thread_rec call from
windows_process_info::handle_exception. That's what this patch does.
Approved-By: Tom Tromey <tom@tromey.com>
Change-Id: I0f328542bda6d8268814ca1ee4ae7a478098ecf2
Pedro Alves [Mon, 8 May 2023 20:36:28 +0000 (21:36 +0100)]
Windows gdb+gdbserver: Eliminate thread_rec(INVALIDATE_CONTEXT) calls
Replace thread_rec(INVALIDATE_CONTEXT) calls with find_thread, and
invalidate_context / suspend calls in the spots that might need those.
I don't know why does the INVALIDATE_CONTEXT implementation in GDB
avoid suspending the event thread:
case INVALIDATE_CONTEXT:
if (ptid.lwp () != current_event.dwThreadId)
th->suspend ();
Checks for a global "current_event" get in the way of non-stop support
later in the series, as each thread will have its own "last debug
event". Regardless, it should be fine to suspend the event thread.
As a data point, the GDBserver implementation always suspends. So
this patch does not try to avoid suspending the event thread on the
native side either.
Approved-By: Tom Tromey <tom@tromey.com>
Change-Id: I8d2f0a749d23329956e62362a7007189902dddb5
Pedro Alves [Tue, 30 Apr 2024 14:33:58 +0000 (15:33 +0100)]
Windows gdb: Eliminate reload_context
We don't need reload_context, because we can get the same information
out of th->context.ContextFlags. If ContextFlags is zero, then we
need to fetch the context out of the inferior thread. This is what
gdbserver does too.
Approved-By: Tom Tromey <tom@tromey.com>
Change-Id: Ied566037c81383414c46c77713bdd1aec6377b23
Tom de Vries [Fri, 24 Apr 2026 17:30:41 +0000 (19:30 +0200)]
[gdb/tui] Expand WDB reference
In gdb/tui/tui.c I came across:
...
/* General functions for the WDB TUI.
...
Initially I thought this was a WDB->GDB typo, but after searching a bit I
found out that this is a reference to HP Wildebeest, a port of GDB to HP-UX.
Change the comment line to use "General functions for the GDB TUI", and
instead mention it here in a more descriptive form:
...
- Contributed by Hewlett-Packard Company.
+ Contributed by Hewlett-Packard Company. Developed as part of HP Wildebeest
+ (WDB), a port of GDB to HP-UX.
...
While we're at it, remove a pointless "This is a sample program for the HP WDB
debugger" note in gdb.base/average.c.
projects / thirdparty / binutils-gdb.git / log
