I noticed my IDE (VSCode) starting to automatically trim trailing
whitespaces on save, despite the setting for it being disabled. I
realized that this is because the .editorconfig file now has
trim_trailing_whitespace = true
for many file types. If we have this EditorConfig setting forcing
editors to trim trailing whitespaces, I think it would make sense to
clean up trailing whitespaces from our files. Otherwise, people will
always get spurious whitespace changes when editing these files.
I did a mass cleanup using this command:
$ find gdb gdbserver gdbsupport -type f \( \
-name "*.c" -o \
-name "*.h" -o \
-name "*.cc" -o \
-name "*.texi" -o \
-name "*.exp" -o \
-name "*.tcl" -o \
-name "*.py" -o \
-name "*.s" -o \
-name "*.S" -o \
-name "*.asm" -o \
-name "*.awk" -o \
-name "*.ac" -o \
-name "Makefile*" -o \
-name "*.sh" -o \
-name "*.adb" -o \
-name "*.ads" -o \
-name "*.d" -o \
-name "*.go" -o \
-name "*.F90" -o \
-name "*.f90" \
\) -exec sed -ri 's/[ \t]+$//' {} +
I then did an autotools regen, because we don't actually want to change
the Makefile and Makefile.in files that are generated.
Change-Id: I6f91b83e3b8c4dc7d5d51a2ebf60706120efe691
This updates the copyright headers to include 2025. I did this by
running gdb/copyright.py and then manually modifying a few files as
noted by the script.
Approved-By: Eli Zaretskii <eliz@gnu.org>
Store the regcache pointer in thread_info as a unique_ptr. This
allows us delete the thread_info destructor.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Convert the `free_register_cache` function into a destructor of the
regcache struct. In one place, we completely remove the call to free
the regcache object by stack-allocating the object.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Remove the 'struct' keyword in occurrences of 'struct thread_info'.
This is a code clean-up.
Tested by rebuilding.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Make the field private, change the free function to be a method.
Change-Id: I05010e7d1bd58ce3895802eb263c029528427758
Approved-By: Tom Tromey <tom@tromey.com>
Make the field private, change the free functions to be methods.
Change-Id: Ifd8ed2775dddefc73a0e00126182e1db02688af4
Approved-By: Tom Tromey <tom@tromey.com>
This function doesn't seem so useful, use `thread_info:🆔:pid`
directly instead.
Change-Id: I7450c4223e5b0bf66788eeb5b070ab6f5287f798
Reviewed-By: Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
This function doesn't seem so useful. Use `thread_info:🆔:lwp`
directly.
Change-Id: Ib4a86eeeee6c1342bc1c092f083589ce28009be1
Reviewed-By: Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
This function doesn't seem so useful. Use `thread_info::id` directly.
Change-Id: I158cd06a752badd30f68424e329aa42d275e43b7
Reviewed-By: Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
I think it just makes things more obscure. Use `thread_info::id`
directly instead.
Change-Id: I141d5fb08ebf45c13cc32c4bba62773249fcb356
Reviewed-By: Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
Same idea as the previous patch, but for `remove_thread`.
Change-Id: I7e227655be5fcf29a3256e8389eb32051f27882d
Reviewed-By: Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
Since thread_info objects are now basically children of process_info
objects, I think that makes sense.
Change-Id: I7f0a67b921b468e512851cb2f36015d1003412d7
Reviewed-By: Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
In a few spots, we need to get to a process from a thread. Having a
backlink from thread to process is cheap and makes the operation
trivial, add it.
Change-Id: I8a94b2919494b1dcaf954de2246386794308aa82
Reviewed-By: Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
Remove this overload, prefer to use `process_info::for_each_thread`. In
many instances, the `process_info` is already available, so this saves a
map lookup. In other instances, add the `process_info` lookup at the
call site.
In `linux-arm-low.cc` and `win32-i386-low.cc`, use `current_process ()`
instead of `current_thread->id.pid ()`. I presume that if
`current_process ()` and `current_thread` don't match, it's a bug
orthogonal to this change.
Change-Id: I751ed497cb1f313cf937b35125151bee9316fc51
Reviewed-By: Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
Replace the servers global thread list with a process specific thread
list and a ptid -> thread map similar to 'inferior::ptid_thread_map' on
GDB side. Optimize the 'find_thread' and 'find_thread_ptid' functions
to use std::unordered_map::find for faster lookup of threads without
iterating over all processes and threads, if applicable. This becomes
important when debugging applications with a large thread count, e.g.,
in the context of GPU debugging.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
This patch replaces the 'std::list' type of 'all_processes' and
'all_threads' with the more lightweight 'owning_intrusive_list'
type.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
clangd reports gdbsupport/common-gdbthread.h as unused in gdbthread.h,
which seems right, so remove it. Add it to two files that need it, but
were relying on the now-removed include.
Change-Id: I12916a044d0b15f346c4ad0e6527ce99a6d460e4
Remove the templated versions of 'find_thread', 'for_each_thread' and
'find_thread_in_random' and replace the template function argument with
'gdb::function_view'. The usage of 'gdb::function_view' produces less
cryptic messages on errors and documents well the types of the
parameters taken by the callback and its return type.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
This commit is the result of the following actions:
- Running gdb/copyright.py to update all of the copyright headers to
include 2024,
- Manually updating a few files the copyright.py script told me to
update, these files had copyright headers embedded within the
file,
- Regenerating gdbsupport/Makefile.in to refresh it's copyright
date,
- Using grep to find other files that still mentioned 2023. If
these files were updated last year from 2022 to 2023 then I've
updated them this year to 2024.
I'm sure I've probably missed some dates. Feel free to fix them up as
you spot them.
A previous patch taught GDB about a new TARGET_WAITKIND_THREAD_CLONED
event kind, and made the Linux target report clone events.
A following patch will teach Linux GDBserver to do the same thing.
However, for remote debugging, it wouldn't be ideal for GDBserver to
report every clone event to GDB, when GDB only cares about such events
in some specific situations. Reporting clone events all the time
would be potentially chatty. We don't enable thread create/exit
events all the time for the same reason. Instead we have the
QThreadEvents packet. QThreadEvents is target-wide, though.
This patch makes GDB instead explicitly request that the target
reports clone events or not, on a per-thread basis.
In order to be able to do that with GDBserver, we need a new remote
protocol feature. Since a following patch will want to enable thread
exit events on per-thread basis too, the packet introduced here is
more generic than just for clone events. It lets you enable/disable a
set of options at once, modelled on Linux ptrace's PTRACE_SETOPTIONS.
IOW, this commit introduces a new QThreadOptions packet, that lets you
specify a set of per-thread event options you want to enable. The
packet accepts a list of options/thread-id pairs, similarly to vCont,
processed left to right, with the options field being a number
interpreted as a bit mask of options. The only option defined in this
commit is GDB_THREAD_OPTION_CLONE (0x1), which ask the remote target
to report clone events. Another patch later in the series will
introduce another option.
For example, this packet sets option "1" (clone events) on thread
p1000.2345:
QThreadOptions;1:p1000.2345
and this clears options for all threads of process 1000, and then sets
option "1" (clone events) on thread p1000.2345:
QThreadOptions;0:p1000.-1;1:p1000.2345
This clears options of all threads of all processes:
QThreadOptions;0
The target reports the set of supported options by including
"QThreadOptions=<supported options>" in its qSupported response.
infrun is then tweaked to enable GDB_THREAD_OPTION_CLONE when stepping
over a breakpoint.
Unlike PTRACE_SETOPTIONS, fork/vfork/clone children do NOT inherit
their parent's thread options. This is so that GDB can send e.g.,
"QThreadOptions;0;1:TID" without worrying about threads it doesn't
know about yet.
Documentation for this new remote protocol feature is included in a
documentation patch later in the series.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=19675
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27830
Reviewed-By: Andrew Burgess <aburgess@redhat.com>
Change-Id: Ie41e5093b2573f14cf6ac41b0b5804eba75be37e
This commit is the result of running the gdb/copyright.py script,
which automated the update of the copyright year range for all
source files managed by the GDB project to be updated to include
year 2023.
The recent commit 421490af33 ("gdbserver/linux: Access memory even
if threads are running") caused a regression in
gdb.threads/access-mem-running-thread-exit.exp with gdbserver, which I
somehow missed. Like so:
(gdb) print global_var
Cannot access memory at address 0x555555558010
(gdb) FAIL: gdb.threads/access-mem-running-thread-exit.exp: non-stop: access mem (print global_var after writing, inf=2, iter=1)
The problem starts with GDB telling GDBserver to select a thread, via
the Hg packet, which GDBserver complies with, then that thread exits,
and GDB, without knowing the thread is gone, tries to write to memory,
through the context of the previously selected Hg thread.
GDBserver's GDB-facing memory access routines, gdb_read_memory and
gdb_write_memory, call set_desired_thread to make GDBserver re-select
the thread that GDB has selected with the Hg packet. Since the thread
is gone, set_desired_thread returns false, and the memory access
fails.
Now, to access memory, it doesn't really matter which thread is
selected. All we should need is the target process. Even if the
thread that GDB previously selected is gone, and GDB does not yet know
about that exit, it shouldn't matter, GDBserver should still know
which process that thread belonged to.
Fix this by making GDBserver track the current process separately,
like GDB also does. Add a new set_desired_process routine that is
similar to set_desired_thread, but just sets the current process,
leaving the current thread as NULL. Use it in the GDB-facing memory
read and write routines, to avoid failing if the selected thread is
gone, but the process is still around.
Change-Id: I4ff97cb6f42558efbed224b30d5c71f6112d44cd
This commit brings all the changes made by running gdb/copyright.py
as per GDB's Start of New Year Procedure.
For the avoidance of doubt, all changes in this commits were
performed by the script.
Introduce a class for restoring the current thread and a function to
switch to the given thread. This is a preparation for a refactoring
that aims to remove direct assignments to 'current_thread'.
I stumbled on a bug caused by the fact that a code path read
target_waitstatus::value::sig (expecting it to contain a gdb_signal
value) while target_waitstatus::kind was TARGET_WAITKIND_FORKED. This
meant that the active union field was in fact
target_waitstatus::value::related_pid, and contained a ptid. The read
signal value was therefore garbage, and that caused GDB to crash soon
after. Or, since that GDB was built with ubsan, this nice error
message:
/home/simark/src/binutils-gdb/gdb/linux-nat.c:1271:12: runtime error: load of value 2686365, which is not a valid value for type 'gdb_signal'
Despite being a large-ish change, I think it would be nice to make
target_waitstatus safe against that kind of bug. As already done
elsewhere (e.g. dynamic_prop), validate that the type of value read from
the union matches what is supposed to be the active field.
- Make the kind and value of target_waitstatus private.
- Make the kind initialized to TARGET_WAITKIND_IGNORE on
target_waitstatus construction. This is what most users appear to do
explicitly.
- Add setters, one for each kind. Each setter takes as a parameter the
data associated to that kind, if any. This makes it impossible to
forget to attach the associated data.
- Add getters, one for each associated data type. Each getter
validates that the data type fetched by the user matches the wait
status kind.
- Change "integer" to "exit_status", "related_pid" to "child_ptid",
just because that's more precise terminology.
- Fix all users.
That last point is semi-mechanical. There are a lot of obvious changes,
but some less obvious ones. For example, it's not possible to set the
kind at some point and the associated data later, as some users did.
But in any case, the intent of the code should not change in this patch.
This was tested on x86-64 Linux (unix, native-gdbserver and
native-extended-gdbserver boards). It was built-tested on x86-64
FreeBSD, NetBSD, MinGW and macOS. The rest of the changes to native
files was done as a best effort. If I forgot any place to update in
these files, it should be easy to fix (unless the change happens to
reveal an actual bug).
Change-Id: I0ae967df1ff6e28de78abbe3ac9b4b2ff4ad03b7
Add a constructor and a destructor. The constructor takes care of the
initialization that happened in add_thread, while the destructor takes
care of the freeing that happened in free_one_thread. This is needed to
make target_waitstatus non-POD, as thread_info contains a member of that
type.
Change-Id: I1db321b4de9dd233ede0d5c101950f1d6f1d13b7
This commits the result of running gdb/copyright.py as per our Start
of New Year procedure...
gdb/ChangeLog
Update copyright year range in copyright header of all GDB files.
This patch moves gdbserver to the top level.
This patch is as close to a pure move as possible -- gdbserver still
builds its own variant of gnulib and gdbsupport. Changing this will
be done in a separate patch.
[v2] Note that, per Simon's review comment, this patch changes the
tree so that gdbserver is not built for or1k or score. This makes
sense, because there is apparently not actually a gdbserver port here.
[v3] This version of the patch also splits out some configury into a
new file, gdbserver/configure.host, so that the top-level configure
script can simply rely on it in order to decide whether gdbserver
should be built.
[v4] This version adds documentation and removes some unnecessary
top-level dependencies.
[v5] Update docs to mention "make all-gdbserver" and change how
top-level configure decides whether to build gdbserver, switching to a
single, shared script.
Tested by the buildbot.
ChangeLog
2020-02-07 Tom Tromey <tom@tromey.com>
Pedro Alves <palves@redhat.com>
* src-release.sh (GDB_SUPPORT_DIRS): Add gdbserver.
* gdbserver: New directory, moved from gdb/gdbserver.
* configure.ac (host_tools): Add gdbserver.
Only build gdbserver on certain systems.
* Makefile.in, configure: Rebuild.
* Makefile.def (host_modules, dependencies): Add gdbserver.
* MAINTAINERS: Add gdbserver.
gdb/ChangeLog
2020-02-07 Tom Tromey <tom@tromey.com>
* README: Update gdbserver documentation.
* gdbserver: Move to top level.
* configure.tgt (build_gdbserver): Remove.
* configure.ac: Remove --enable-gdbserver.
* configure: Rebuild.
* Makefile.in (distclean): Don't mention gdbserver.
Change-Id: I826b7565b54604711dc7a11edea0499cd51ff39e
