aboutsummaryrefslogtreecommitdiff
path: root/gdb/observable.h
AgeCommit message (Collapse)AuthorFilesLines
2024-11-01Add gdb.events.tui_enabledTom Tromey1-0/+2
This adds a new event source so that Python scripts can track whether or not the TUI is presently enabled. v2 of the patch renames "status" -> "enabled". Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32162 Reviewed-By: Eli Zaretskii <eliz@gnu.org> Reviewed-by: Keith Seitz <keiths@redhat.com>
2024-02-20gdb: pass frames as `const frame_info_ptr &`Simon Marchi1-1/+1
We currently pass frames to function by value, as `frame_info_ptr`. This is somewhat expensive: - the size of `frame_info_ptr` is 64 bytes, which is a bit big to pass by value - the constructors and destructor link/unlink the object in the global `frame_info_ptr::frame_list` list. This is an `intrusive_list`, so it's not so bad: it's just assigning a few points, there's no memory allocation as if it was `std::list`, but still it's useless to do that over and over. As suggested by Tom Tromey, change many function signatures to accept `const frame_info_ptr &` instead of `frame_info_ptr`. Some functions reassign their `frame_info_ptr` parameter, like: void the_func (frame_info_ptr frame) { for (; frame != nullptr; frame = get_prev_frame (frame)) { ... } } I wondered what to do about them, do I leave them as-is or change them (and need to introduce a separate local variable that can be re-assigned). I opted for the later for consistency. It might not be clear why some functions take `const frame_info_ptr &` while others take `frame_info_ptr`. Also, if a function took a `frame_info_ptr` because it did re-assign its parameter, I doubt that we would think to change it to `const frame_info_ptr &` should the implementation change such that it doesn't need to take `frame_info_ptr` anymore. It seems better to have a simple rule and apply it everywhere. Change-Id: I59d10addef687d157f82ccf4d54f5dde9a963fd0 Approved-By: Andrew Burgess <aburgess@redhat.com>
2024-02-05gdb: rename struct shobj -> struct solibSimon Marchi1-3/+3
`struct so_list` was recently renamed to `struct shobj` (in 3fe0dfd1604f ("gdb: rename struct so_list to shobj")). In hindsight, `solib` would have been a better name. We have solib.c, the implementations in solib-*.c, many functions with solib in their name, the solib_loaded / solib_unloaded observables, etc. Rename shobj to solib. Change-Id: I0af1c7a9b29bdda027e9af633f6d37e1cfcacd5d Approved-By: Tom Tromey <tom@tromey.com>
2024-01-12Update copyright year range in header of all files managed by GDBAndrew Burgess1-1/+1
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.
2023-12-20Fix thread target ID of exited wavesPedro Alves1-0/+5
Currently, if you step over kernel exit, you see: stepi [AMDGPU Wave ?:?:?:1 (?,?,?)/? exited] Command aborted, thread exited. (gdb) Those '?' are because the thread/wave is already gone by the time GDB prints the "exited" notification, we can't ask dbgapi for any info about the wave anymore. This commit fixes it by caching the wave's coordinates as soon as GDB sees the wave for the first time, and making amd_dbgapi_target::pid_to_str use the cached info. At first I thought of clearing the wave_info object from a thread_exited observer. However, that is too soon, resulting in this: (gdb) si [AMDGPU Wave 1:4:1:1 (0,0,0)/0 exited] Command aborted, thread exited. (gdb) thread [Current thread is 6 (AMDGPU Wave ?:?:?:0 (?,?,?)/?) (exited)] We need instead to clear the wave info when the thread is ultimately deleted, so we get: (gdb) si [AMDGPU Wave 1:4:1:1 (0,0,0)/0 exited] Command aborted, thread exited. (gdb) thread [Current thread is 6 (AMDGPU Wave 1:4:1:1 (0,0,0)/0) (exited)] And for that, we need a new thread_deleted observable. Approved-By: Simon Marchi <simon.marchi@efficios.com> Approved-By: Lancelot Six <lancelot.six@amd.com> (amdgpu) Change-Id: I6c3e22541f051e1205f75eb657b04dc15e547580
2023-11-21gdb: Replace gdb::optional with std::optionalLancelot Six1-1/+1
Since GDB now requires C++17, we don't need the internally maintained gdb::optional implementation. This patch does the following replacing: - gdb::optional -> std::optional - gdb::in_place -> std::in_place - #include "gdbsupport/gdb_optional.h" -> #include <optional> This change has mostly been done automatically. One exception is gdbsupport/thread-pool.* which did not use the gdb:: prefix as it already lives in the gdb namespace. Change-Id: I19a92fa03e89637bab136c72e34fd351524f65e9 Approved-By: Tom Tromey <tom@tromey.com> Approved-By: Pedro Alves <pedro@palves.net>
2023-10-19gdb: rename struct so_list to shobjSimon Marchi1-3/+3
Now that so_list lists are implemented using intrusive_list, it doesn't really make sense for the element type to be named "_list". Rename to just `struct shobj` (`struct so` was deemed to be not greppable enough). Change-Id: I1063061901298bb40fee73bf0cce44cd12154c0e Approved-By: Pedro Alves <pedro@palves.net> Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>
2023-10-19gdb: replace some so_list parameters to use referencesSimon Marchi1-3/+2
A subsequent patch changes so_list to be linked using intrusive_list. Iterating an intrusive_list yields some references to the list elements. Convert some functions accepting so_list objects to take references, to make things easier and more natural. Add const where possible and convenient. Change-Id: Id5ab5339c3eb6432e809ad14782952d6a45806f3 Approved-By: Pedro Alves <pedro@palves.net> Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>
2023-10-16gdb: replace architecture_changed with new_architecture observerAndrew Burgess1-4/+3
This commit replaces the architecture_changed observer with a new_architecture observer. Currently the only user of the architecture_changed observer is the Python code, which uses this observer to register the Python unwinder with the architecture. The problem is that the architecture_changed observer is triggered from inferior::set_arch(), which only sees the inferior-wide gdbarch value. For targets that use thread-specific architectures, these never trigger the architecture_changed observer, and so never have the Python unwinder registered with them. When it comes to unwinding GDB makes use of the frame's gdbarch, which is based on the thread's regcache gdbarch, which is set in get_thread_regcache to the value returned from target_thread_architecture, which is not always the inferiors gdbarch value, it might be a thread-specific gdbarch which has not passed through inferior::set_arch(). The new_architecture observer will be triggered from gdbarch_find_by_info, whenever a new gdbarch is created and initialised. As GDB caches and reuses gdbarch values, we should expect to see each new architecture trigger the new_architecture observer just once. After this commit, targets that make use of thread-specific architectures should be able to make use of Python unwinders. As I don't have access to a machine that makes use of thread-specific architectures right now, I asked Luis to confirm that an AArch64 target that uses SVE/SME can't use the Python unwinders in threads that are using a thread-specific architectures, and he confirmed that this is indeed the case, see this discussion: https://inbox.sourceware.org/gdb/87wmvsat8i.fsf@redhat.com Tested-By: Lancelot Six <lancelot.six@amd.com> Tested-By: Luis Machado <luis.machado@arm.com> Reviewed-By: Luis Machado <luis.machado@arm.com> Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-10-10gdb: add inferior parameter to architecture_changed observableSimon Marchi1-2/+3
This is to make it explicit which inferior's architecture just changed, and that the callbacks should not assume it is the current inferior. Update the only caller, pyuw_on_new_gdbarch, to add the parameter, although it doesn't use it currently. Change-Id: Ieb7f21377e4252cc6e7b1ce2cc812cd1a1840e0e Reviewed-By: John Baldwin <jhb@FreeBSD.org> Approved-By: Andrew Burgess <aburgess@redhat.com>
2023-10-05gdb: add all_objfiles_removed observerSimon Marchi1-3/+4
The new_objfile observer is currently used to indicate both when a new objfile is added to program space (when passed non-nullptr) and when all objfiles of a program space were just removed (when passed nullptr). I think this is confusing (and Andrew apparently thinks so too [1]). Add a new "all_objfiles_removed" observer to remove the second role from "new_objfile". Some existing users of new_objfile do nothing if the passed objfile is nullptr. For them, we can simply drop the nullptr check. For others, add a new all_objfiles_removed callback, and refactor things a bit to keep the existing behavior as much as possible. Some callbacks relied on current_program_space, and following the refactoring now use either objfile->pspace or the pspace passed to all_objfiles_removed. I think this should be relatively safe, and in general a step in the right direction. On the notify side, I found only one call site to change from new_objfile to all_objfiles_removed, in clear_symtab_users. It is not entirely clear to me that this is entirely correct. clear_symtab_users appears to be called in spots that don't remove all objfiles (functions finish_new_objfile, remove_symbol_file_command, reread_symbols, do_module_cleanups). But I think that this patch at least makes the current code clearer. [1] https://gitlab.com/gnutools/binutils-gdb/-/commit/a0a031bce0527b1521788b5dad640e7883b3a252 Change-Id: Icb648f72862e056267f30f44dd439bd4ec766f13 Approved-By: Tom Tromey <tom@tromey.com>
2023-10-02gdb: add Python events for program space addition and removalAndrew Burgess1-0/+6
Initially I just wanted a Python event for when GDB removes a program space, I'm writing a Python extension that caches information for each program space, and need to know when I should discard entries for a particular program space. But, it seemed easy enough to also add an event for when GDB adds a new program space, so I went ahead and added both new events. Of course, we don't currently have an observable for program space addition or removal, so I first needed to add these. After that it's pretty simple to add two new Python events and have these trigger. The two new event registries are: events.new_progspace events.free_progspace These emit NewProgspaceEvent and FreeProgspaceEvent objects respectively, each of these new event types has a 'progspace' attribute that contains the relevant gdb.Progspace object. There's a couple of things to be mindful of. First, it is not possible to catch the NewProgspaceEvent for the very first program space, the one that is created when GDB first starts, as this program space is created before any Python scripts are sourced. In order to allow this event to be caught we would need to defer creating the first program space, and as a consequence the first inferior, until some later time. But, existing scripts could easily depend on there being an initial inferior, so I really don't think we should change that -- and so, we end up with the consequence that we can't catch the event for the first program space. The second, I think minor, issue, is that GDB doesn't clean up its program spaces upon exit -- or at least, they are not cleaned up before Python is shut down. As a result, any program spaces in use at the time GDB exits don't generate a FreeProgspaceEvent. I'm not particularly worried about this for my use case, I'm using the event to ensure that a cache doesn't hold stale entries within a single GDB session. It's also easy enough to add a Python at-exit callback which can do any final cleanup if needed. Finally, when testing, I did hit a slightly weird issue with some of the remote boards (e.g. remote-stdio-gdbserver). As a consequence of this issue I see some output like this in the gdb.log: (gdb) PASS: gdb.python/py-progspace-events.exp: inferior 1 step FreeProgspaceEvent: <gdb.Progspace object at 0x7fb7e1d19c10> warning: cannot close "target:/lib64/libm.so.6": Cannot execute this command while the target is running. Use the "interrupt" command to stop the target and then try again. warning: cannot close "target:/lib64/libc.so.6": Cannot execute this command while the target is running. Use the "interrupt" command to stop the target and then try again. warning: cannot close "target:/lib64/ld-linux-x86-64.so.2": Cannot execute this command while the target is running. Use the "interrupt" command to stop the target and then try again. do_parent_stuff () at py-progspace-events.c:41 41 ++global_var; (gdb) PASS: gdb.python/py-progspace-events.exp: step The 'FreeProgspaceEvent ...' line is expected, that's my test Python extension logging the event. What isn't expected are all the blocks like: warning: cannot close "target:/lib64/libm.so.6": Cannot execute this command while the target is running. Use the "interrupt" command to stop the target and then try again. It turns out that this has nothing to do with my changes, this is just a consequence of reading files over the remote protocol. The test forks a child process which GDB stays attached too. When the child exits, GDB cleans up by calling prune_inferiors, which in turn can result in GDB trying to close some files that are open because of the inferior being deleted. If the prune_inferiors call occurs when the remote target is running (and in non-async mode) then GDB will try to send a fileio packet while the remote target is waiting for a stop reply, and the remote target will throw an error, see remote_target::putpkt_binary in remote.c for details. I'm going to look at fixing this, but, as I said, this is nothing to do with this change, I just mention it because I ended up needing to account for these warning messages in one of my tests, and it all looks a bit weird. Approved-By: Tom Tromey <tom@tromey.com> Reviewed-By: Eli Zaretskii <eliz@gnu.org>
2023-10-02gdb: remove solib::pspace fieldSimon Marchi1-3/+4
This backlink is not necessary, we always know the program space from the context. Pass it down the solib_unloaded observer. Change-Id: I45a503472dc791f517558b8141901472634e0556 Approved-By: Tom Tromey <tom@tromey.com>
2023-09-28gdb: pass more arguments to the executable_changed observerAndrew Burgess1-5/+13
This commit continues the work of the previous few commits. My goal is to expose the executable_changed observer through the Python API as an event. At this point adding executable_changed as an event to the Python API is trivial, but before I do that I would like to add some additional arguments to the observable, which currently has no arguments at all. The new arguments I wish to add are: 1. The program_space in which the executable was changed, and 2. A boolean flag that will indicate if the executable changed to a whole new path, or if GDB just spotted that the executable changed on disk (e.g. the user recompiled the executable). In this commit I change the signature of the observable and then pass the arguments through at the one place where this observable is notified. As there are (currently) no users of this observable nothing else needs updating. In the next commit I'll add a listener for this observable in the Python code, and expose this as an event in the Python API. Additionally, with this change, it should be possible to update the insight debugger to make use of this observable rather than using the deprecated_exec_file_display_hook (as it currently does), which will then allow this hook to be removed from GDB. There should be no user visible changes after this commit. Approved-By: Tom Tromey <tom@tromey.com>
2023-09-15gdb: add inferior_cloned observableSimon Marchi1-0/+4
The following patch makes the amdgpu port transfer a property from the original inferior to the new inferior when using the clone-inferior command. Add the inferior_cloned observable to help with this. Change-Id: Id845a799813ec49b1b7b2fcb97b07d0a1e5e2631 Approved-By: Tom Tromey <tom@tromey.com>
2023-08-23gdb: centralize "[Thread ...exited]" notificationsPedro Alves1-4/+7
Currently, each target backend is responsible for printing "[Thread ...exited]" before deleting a thread. This leads to unnecessary differences between targets, like e.g. with the remote target, we never print such messages, even though we do print "[New Thread ...]". E.g., debugging the gdb.threads/attach-many-short-lived-threads.exp with gdbserver, letting it run for a bit, and then pressing Ctrl-C, we currently see: (gdb) c Continuing. ^C[New Thread 3850398.3887449] [New Thread 3850398.3887500] [New Thread 3850398.3887551] [New Thread 3850398.3887602] [New Thread 3850398.3887653] ... Thread 1 "attach-many-sho" received signal SIGINT, Interrupt. 0x00007ffff7e6a23f in __GI___clock_nanosleep (clock_id=clock_id@entry=0, flags=flags@entry=0, req=req@entry=0x7fffffffda80, rem=rem@entry=0x7fffffffda80) at ../sysdeps/unix/sysv/linux/clock_nanosleep.c:78 78 in ../sysdeps/unix/sysv/linux/clock_nanosleep.c (gdb) Above, we only see "New Thread" notifications, even though threads were deleted. After this patch, we'll see: (gdb) c Continuing. ^C[Thread 3558643.3577053 exited] [Thread 3558643.3577104 exited] [Thread 3558643.3577155 exited] [Thread 3558643.3579603 exited] ... [New Thread 3558643.3597415] [New Thread 3558643.3600015] [New Thread 3558643.3599965] ... Thread 1 "attach-many-sho" received signal SIGINT, Interrupt. 0x00007ffff7e6a23f in __GI___clock_nanosleep (clock_id=clock_id@entry=0, flags=flags@entry=0, req=req@entry=0x7fffffffda80, rem=rem@entry=0x7fffffffda80) at ../sysdeps/unix/sysv/linux/clock_nanosleep.c:78 78 in ../sysdeps/unix/sysv/linux/clock_nanosleep.c (gdb) q This commit fixes this by moving the thread exit printing to common code instead, triggered from within delete_thread (or rather, set_thread_exited). There's one wrinkle, though. While most targest want to print: [Thread ... exited] the Windows target wants to print: [Thread ... exited with code <exit_code>] ... and sometimes wants to suppress the notification for the main thread. To address that, this commits adds a delete_thread_with_code function, only used by that target (so far). This fix was originally posted as part of a larger series: https://inbox.sourceware.org/gdb-patches/20221212203101.1034916-1-pedro@palves.net/ But didn't really need to be part of that series. In order to get this fix merged sooner, I (Andrew Burgess) have rebased this commit outside of the original series. Any bugs introduced while splitting this patch out and rebasing, are entirely my own. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30129 Co-Authored-By: Andrew Burgess <aburgess@redhat.com>
2023-05-30gdb: add interp::on_param_changed methodSimon Marchi1-7/+0
Same idea as previous patches, but for command_param_changed. Change-Id: I7c2196343423360da05f016f8ffa871c064092bb
2023-05-30gdb: add interp::on_tsv_modified methodSimon Marchi1-3/+0
Same idea as previous patches, but for tsv_modified. Change-Id: I55454a2386d5450040b3a353909b26f389a43682
2023-05-30gdb: add interp::on_tsv_deleted methodSimon Marchi1-4/+0
Same idea as previous patches, but for tsv_deleted. Change-Id: I71b0502b493da7b6e293bee02aeca98de83d4b75
2023-05-30gdb: add interp::on_tsv_created methodSimon Marchi1-3/+0
Same idea as previous patches, but for tsv_created. Change-Id: I9c30ecfdbd78ca015d613f43a0c0aef6c7eb32b5
2023-05-30gdb: add interp::on_traceframe_changed methodSimon Marchi1-6/+0
Same idea as previous patches, but for traceframe_changed. Change-Id: Ia473f07d70d57b30aca0094d0e0585d7e0d95637
2023-05-30gdb: add interp::on_record_changed methodSimon Marchi1-12/+0
Same idea as previous patches, but for record_changed Change-Id: I5eeeacd703af8401c315060514c94e8e6439cc40
2023-05-30gdb: add interp::on_command_error methodSimon Marchi1-3/+0
Same idea as the previous patches, but for command_error. Change-Id: If6098225dd72fad8be13b3023b35bc8bc48efb9d
2023-05-30gdb: add interp::on_sync_execution_done methodSimon Marchi1-3/+0
Same as previous patches, but for sync_execution_done. Except that here, we only want to notify the interpreter that is executing the command, not all interpreters. Change-Id: I729c719447b5c5f29af65dbf6fed9132e2cd308b
2023-05-30gdb: add interp::on_no_history methodSimon Marchi1-3/+0
Same as previous patches, but for no_history. Change-Id: I06930fe7cb4082138c6c5496c5118fe4951c10da
2023-05-30gdb: add interp::on_exited methodSimon Marchi1-3/+0
Same as previous patch, but for exited. Remove the exited observable, since nothing uses it anymore, and we don't have anything coming that will use it. Change-Id: I358cbea0159af56752dfee7510d6a86191e722bb
2023-05-30gdb: add interp::on_signal_exited methodSimon Marchi1-3/+0
Same as previous patch, but for signal_exited. Remove the signal_exited observable, since nothing uses it anymore, and we don't have anything coming that will use it. Change-Id: I0dca1eab76338bf27be755786e3dad3241698b10
2023-04-24gdb: remove end_stepping_range observableSimon Marchi1-3/+0
I noticed that this observable was never notified, which means we can probably safely remove it. The notification was removed in: commit 243a925328f8e3184b2356bee497181049c0174f Author: Pedro Alves <palves@redhat.com> Date: Wed Sep 9 18:23:24 2015 +0100 Replace "struct continuation" mechanism by something more extensible print_end_stepping_range_reason in turn becomes unused, so remote it as well. Change-Id: If5da5149276c282d2540097c8c4327ce0f70431a
2023-04-17gdb: add inferior_forked observableSimon Marchi1-0/+9
In the upcoming patch to support fork in the amd-dbgapi target, the amd-dbgapi target will need to be notified of fork events through an observer, to attach itself (attach in the amd-dbgapi sense, not ptrace sense) to the new inferior / process. The reason that this can't be done through target_ops::follow_fork is that the amd-dbgapi target isn't pushed on the inferior's target stack right away. It attaches itself to the process and only pushes itself on its target stack if and when the inferior initializes the ROCm runtime. If an inferior that is not using the ROCm runtime forks, we want to be notified of it, so we can attach to the child, and catch if the child starts using the ROCm runtime. So, add a new observable and notify it in follow_fork_inferior. It will be used later in this series. Change-Id: I67fced5a9cba6d5da72b9c7ea1c8397644ca1d54 Reviewed-By: Pedro Alves <pedro@palves.net>
2023-04-17gdb: pass execing and following inferior to inferior_execd observersSimon Marchi1-2/+6
The upcoming patch to support exec in the amd-dbgapi target needs to detach amd-dbgapi from the inferior doing the exec and attach amd-dbgapi to the inferior continuing the execution. They may or may not be the same, depending on the `set follow-exec-mode` setting. But even if they are the same, we need to do the detach / attach dance. With the current observable signature, the observers only receive the inferior in which execution continues (the "following" inferior). Change the signature to pass both inferiors, and update all existing observers. Change-Id: I259d1ea09f70f43be739378d6023796f2fce2659 Reviewed-By: Pedro Alves <pedro@palves.net>
2023-02-02gdb: add inferior_pre_detach observableSimon Marchi1-0/+3
Add an observable notified in target_detach just before calling the detach method on the inferior's target stack. This allows observer to do some work on the inferior while it's still ptrace-attached, in the case of a native Linux inferior. Specifically, the amd-dbgapi target will need it in order to call amd_dbgapi_process_detach before the process gets ptrace-detached. Change-Id: I28b6065e251012a4c2db8a600fe13ba31671e3c9 Approved-By: Andrew Burgess <aburgess@redhat.com>
2023-01-01Update copyright year range in header of all files managed by GDBJoel Brobecker1-1/+1
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.
2022-10-10Change GDB to use frame_info_ptrTom Tromey1-1/+1
This changes GDB to use frame_info_ptr instead of frame_info * The substitution was done with multiple sequential `sed` commands: sed 's/^struct frame_info;/class frame_info_ptr;/' sed 's/struct frame_info \*/frame_info_ptr /g' - which left some issues in a few files, that were manually fixed. sed 's/\<frame_info \*/frame_info_ptr /g' sed 's/frame_info_ptr $/frame_info_ptr/g' - used to remove whitespace problems. The changed files were then manually checked and some 'sed' changes undone, some constructors and some gets were added, according to what made sense, and what Tromey originally did Co-Authored-By: Bruno Larsen <blarsen@redhat.com> Approved-by: Tom Tomey <tom@tromey.com>
2022-06-02Fix ODR warning in observable.hTom Tromey1-0/+1
observable.h triggers an ODR warning because this line: extern observable<struct target_ops */* target */> target_changed; ... may be the only declaration of "struct target_ops" in scope (depending on the particular .c file) -- and this declares it in a namespace, resulting in confusion. This patch fixes the problem by adding a forward declaration. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=22395
2022-03-14Replace deprecated_target_wait_hook by observersPatrick Monnerat1-0/+6
Commit b60cea7 (Make target_wait options use enum flags) broke deprecated_target_wait_hook usage: there's a commit comment telling this hook has not been converted. Rather than trying to mend it, this patch replaces the hook by two target_wait observers: target_pre_wait (ptid_t ptid) target_post_wait (ptid_t event_ptid) Upon target_wait entry, target_pre_wait is notified with the ptid passed to target_wait. Upon exit, target_post_wait is notified with the event ptid returned by target_wait. Should an exception occur, event_ptid is null_ptid. This change benefits to Insight (out-of-tree): there's no real use of the late hook in gdb itself.
2022-01-01Automatic Copyright Year update after running gdb/copyright.pyJoel Brobecker1-1/+1
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.
2021-11-30gdb/python: introduce gdb.TargetConnection object typeAndrew Burgess1-0/+3
This commit adds a new object type gdb.TargetConnection. This new type represents a connection within GDB (a connection as displayed by 'info connections'). There's three ways to find a gdb.TargetConnection, there's a new 'gdb.connections()' function, which returns a list of all currently active connections. Or you can read the new 'connection' property on the gdb.Inferior object type, this contains the connection for that inferior (or None if the inferior has no connection, for example, it is exited). Finally, there's a new gdb.events.connection_removed event registry, this emits a new gdb.ConnectionEvent whenever a connection is removed from GDB (this can happen when all inferiors using a connection exit, though this is not always the case, depending on the connection type). The gdb.ConnectionEvent has a 'connection' property, which is the gdb.TargetConnection being removed from GDB. The gdb.TargetConnection has an 'is_valid()' method. A connection object becomes invalid when the underlying connection is removed from GDB (as discussed above, this might be when all inferiors using a connection exit, or it might be when the user explicitly replaces a connection in GDB by issuing another 'target' command). The gdb.TargetConnection has the following read-only properties: 'num': The number for this connection, 'type': e.g. 'native', 'remote', 'sim', etc 'description': The longer description as seen in the 'info connections' command output. 'details': A string or None. Extra details for the connection, for example, a remote connection's details might be 'hostname:port'.
2021-11-25gdb: rename source_styling_changed observerAndrew Burgess1-3/+3
In a later commit I plan to add disassembler styling. In the same way that we have a source_styling_changed observer I would need to add a disassembler_styling_changed observer. However, currently, these observers would only be notified from cli-style.c:set_style_enabled, and observed in tui-winsource.c, tui_source_window::style_changed, as a result, having two observers seems unnecessary right now, so, in this commit, I plan to rename source_styling_changed to just styling_changed, then, in the later commit, when disassembler styling is added, I can use the same observer for both source styling, and disassembler styling. There should be no user visible changes after this commit.
2021-11-08gdb: remove bpstat typedef, rename bpstats to bpstatSimon Marchi1-2/+2
I don't find that the bpstat typedef, which hides a pointer, is particularly useful. In fact, it confused me many times, and I just see it as something to remember that adds cognitive load. Also, with C++, we might want to be able to pass bpstats objects by const-reference, not necessarily by pointer. So, remove the bpstat typedef and rename struct bpstats to bpstat (since it represents one bpstat, it makes sense that it is singular). Change-Id: I52e763b6e54ee666a9e045785f686d37b4f5f849
2021-10-05gdb/python: add a new gdb_exiting eventAndrew Burgess1-1/+3
Add a new event, gdb.events.gdb_exiting, which is called once GDB decides it is going to exit. This event is not triggered in the case that GDB performs a hard abort, for example, when handling an internal error and the user decides to quit the debug session, or if GDB hits an unexpected, fatal, signal. This event is triggered if the user just types 'quit' at the command prompt, or if GDB is run with '-batch' and has processed all of the required commands. The new event type is gdb.GdbExitingEvent, and it has a single attribute exit_code, which is the value that GDB is about to exit with. The event is triggered before GDB starts dismantling any of its own internal state, so, my expectation is that most Python calls should work just fine at this point. When considering this functionality I wondered about using the 'atexit' Python module. However, this is triggered when the Python environment is shut down, which is done from a final cleanup. At this point we don't know for sure what other GDB state has already been cleaned up.
2021-01-01Update copyright year range in all GDB filesJoel Brobecker1-1/+1
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.
2020-12-04gdb: add inferior_execd observableSimon Marchi1-0/+3
I want to add another action (clearing displaced stepping state) that happens when an inferior execs. I think it would be cleaner to have an observer for this event, rather than have infrun know about each other sub-component. Replace the calls to solib_create_inferior_hook and jit_inferior_created_hook in follow_exec by observers. gdb/ChangeLog: * observable.h (inferior_execd): Declare new observable. * observable.c (inferior_execd): Declare new observable. * infrun.c (follow_exec): Notify inferior_execd observer. * jit.c (jit_inferior_created_hook): Make static. (_initialize_jit): Register inferior_execd observer. * jit.h (jit_inferior_created_hook): Remove declaration. * solib.c (_initialize_solib): Register inferior_execd observer. Change-Id: I000cce00094e23baa67df693d912646b6ae38e44
2020-10-25gdb: add inferior parameter to inferior_created observableSimon Marchi1-1/+1
I think it would make sense for the inferior_created observable to say which inferior is being dealt with, rather than relying on it being the current inferior. This patch adds an inferior parameter to inferior_created, but does not change the callbacks to use it. gdb/ChangeLog: * aix-thread.c (aix_thread_inferior_created): Add inferior parameter. * bsd-uthread.c (bsd_uthread_inferior_created): Likewise. * dummy-frame.c (cleanup_dummy_frames): Likewise. * jit.c (jit_inferior_created): Likewise. * linux-thread-db.c (thread_db_inferior_created): Likewise. * m68k-linux-tdep.c (m68k_linux_inferior_created): Likewise. * observable.h (inferior_created): Likewise. * ravenscar-thread.c (ravenscar_inferior_created): Likewise. * symfile-mem.c (add_vsyscall_page): Likewise. * infcmd.c (post_create_inferior): Pass inferior argument. Change-Id: I2543d19ff055a9df6b269929faea10b27d2adc5e
2020-10-02gdb: remove arguments from inferior_created observableSimon Marchi1-2/+1
I noticed that non of the listeners of the inferior_created observable used either of the arguments. Remove them. This in turn allows removing the target parameter of post_create_inferior. Tested only by rebuilding. gdb/ChangeLog: * observable.h <inferior_created>: Remove parameters. Update all listeners. * inferior.h (post_create_inferior): Remove target parameter. Update all callers. Change-Id: I8944cefdc4447ed5347dc927b75abf1e7a0e27e6
2020-08-07gdb: pass target to thread_ptid_changed observableSimon Marchi1-2/+4
I noticed what I think is a potential bug. I did not observe it nor was I able to reproduce it using actual debugging. It's quite unlikely, because it involves multi-target and ptid clashes. I added selftests that demonstrate it though. The thread_ptid_changed observer says that thread with OLD_PTID now has NEW_PTID. Now, if for some reason we happen to have two targets defining a thread with OLD_PTID, the observers don't know which thread this is about. regcache::regcache_thread_ptid_changed changes all regcaches with OLD_PTID. If there is a regcache for a thread with ptid OLD_PTID, but that belongs to a different target, this regcache will be erroneously changed. Similarly, infrun_thread_ptid_changed updates inferior_ptid if inferior_ptid matches OLD_PTID. But if inferior_ptid currently refers not to the thread is being changed, but to a thread with the same ptid belonging to a different target, then inferior_ptid will erroneously be changed. This patch adds a `process_stratum_target *` parameter to the `thread_ptid_changed` observable and makes the two observers use it. Tests for both are added, which would fail if the corresponding fix wasn't done. gdb/ChangeLog: * observable.h (thread_ptid_changed): Add parameter `process_stratum_target *`. * infrun.c (infrun_thread_ptid_changed): Add parameter `process_stratum_target *` and use it. (selftests): New namespace. (infrun_thread_ptid_changed): New function. (_initialize_infrun): Register selftest. * regcache.c (regcache_thread_ptid_changed): Add parameter `process_stratum_target *` and use it. (regcache_thread_ptid_changed): New function. (_initialize_regcache): Register selftest. * thread.c (thread_change_ptid): Pass target to thread_ptid_changed observable. Change-Id: I0599e61224b6d154a7b55088a894cb88298c3c71
2020-01-01Update copyright year range in all GDB files.Joel Brobecker1-1/+1
gdb/ChangeLog: Update copyright year range in all GDB files.
2019-12-20Add observable to watch current source symtabTom Tromey1-0/+6
This patch adds an observable, so that a later patch can change the TUI to notice when the user has selected a new source symtab, say via "list". gdb/ChangeLog 2019-12-20 Tom Tromey <tom@tromey.com> * source.c (struct current_source_location) <set, symtab, line>: New methods. <m_symtab, m_line>: Rename. Now private. (get_current_source_symtab_and_line) (set_default_source_symtab_and_line) (set_current_source_symtab_and_line) (clear_current_source_symtab_and_line, select_source_symtab) (info_source_command, print_source_lines_base) (info_line_command, search_command_helper): Update. * observable.h (current_source_symtab_and_line_changed): Declare observable. * observable.c (current_source_symtab_and_line_changed): Define observable. Change-Id: I3c0f6b40f2df84b590bdf5b5ec5ccd8423bb7f22
2019-11-22Restore parameter names in observable.hTom Tromey1-80/+89
Ages ago, when we switched observables to be templates, Joel asked me to restore the parameter names that were used in the old observer.texi. I've finally done this, putting the names into comments. I also updated the comments in this file to use the GNU metasyntactic variable convention as well. gdb/ChangeLog 2019-11-22 Tom Tromey <tom@tromey.com> * observable.h: Update comments. Change-Id: Id71bea7a7fcaa8f5d4491f33aa8861c56ba9c3f0
2019-07-09Rename common to gdbsupportTom Tromey1-1/+1
This is the next patch in the ongoing series to move gdbsever to the top level. This patch just renames the "common" directory. The idea is to do this move in two parts: first rename the directory (this patch), then move the directory to the top. This approach makes the patches a bit more tractable. I chose the name "gdbsupport" for the directory. However, as this patch was largely written by sed, we could pick a new name without too much difficulty. Tested by the buildbot. gdb/ChangeLog 2019-07-09 Tom Tromey <tom@tromey.com> * contrib/ari/gdb_ari.sh: Change common to gdbsupport. * configure: Rebuild. * configure.ac: Change common to gdbsupport. * gdbsupport: Rename from common. * acinclude.m4: Change common to gdbsupport. * Makefile.in (CONFIG_SRC_SUBDIR, COMMON_SFILES) (HFILES_NO_SRCDIR, stamp-version, ALLDEPFILES): Change common to gdbsupport. * aarch64-tdep.c, ada-lang.c, ada-lang.h, agent.c, alloc.c, amd64-darwin-tdep.c, amd64-dicos-tdep.c, amd64-fbsd-nat.c, amd64-fbsd-tdep.c, amd64-linux-nat.c, amd64-linux-tdep.c, amd64-nbsd-tdep.c, amd64-obsd-tdep.c, amd64-sol2-tdep.c, amd64-tdep.c, amd64-windows-tdep.c, arch-utils.c, arch/aarch64-insn.c, arch/aarch64.c, arch/aarch64.h, arch/amd64.c, arch/amd64.h, arch/arm-get-next-pcs.c, arch/arm-linux.c, arch/arm.c, arch/i386.c, arch/i386.h, arch/ppc-linux-common.c, arch/riscv.c, arch/riscv.h, arch/tic6x.c, arm-tdep.c, auto-load.c, auxv.c, ax-gdb.c, ax-general.c, ax.h, breakpoint.c, breakpoint.h, btrace.c, btrace.h, build-id.c, build-id.h, c-lang.h, charset.c, charset.h, cli/cli-cmds.c, cli/cli-cmds.h, cli/cli-decode.c, cli/cli-dump.c, cli/cli-option.h, cli/cli-script.c, coff-pe-read.c, command.h, compile/compile-c-support.c, compile/compile-c.h, compile/compile-cplus-symbols.c, compile/compile-cplus-types.c, compile/compile-cplus.h, compile/compile-loc2c.c, compile/compile.c, completer.c, completer.h, contrib/ari/gdb_ari.sh, corefile.c, corelow.c, cp-support.c, cp-support.h, cp-valprint.c, csky-tdep.c, ctf.c, darwin-nat.c, debug.c, defs.h, disasm-selftests.c, disasm.c, disasm.h, dtrace-probe.c, dwarf-index-cache.c, dwarf-index-cache.h, dwarf-index-write.c, dwarf2-frame.c, dwarf2expr.c, dwarf2loc.c, dwarf2read.c, event-loop.c, event-top.c, exceptions.c, exec.c, extension.h, fbsd-nat.c, features/aarch64-core.c, features/aarch64-fpu.c, features/aarch64-pauth.c, features/aarch64-sve.c, features/i386/32bit-avx.c, features/i386/32bit-avx512.c, features/i386/32bit-core.c, features/i386/32bit-linux.c, features/i386/32bit-mpx.c, features/i386/32bit-pkeys.c, features/i386/32bit-segments.c, features/i386/32bit-sse.c, features/i386/64bit-avx.c, features/i386/64bit-avx512.c, features/i386/64bit-core.c, features/i386/64bit-linux.c, features/i386/64bit-mpx.c, features/i386/64bit-pkeys.c, features/i386/64bit-segments.c, features/i386/64bit-sse.c, features/i386/x32-core.c, features/riscv/32bit-cpu.c, features/riscv/32bit-csr.c, features/riscv/32bit-fpu.c, features/riscv/64bit-cpu.c, features/riscv/64bit-csr.c, features/riscv/64bit-fpu.c, features/tic6x-c6xp.c, features/tic6x-core.c, features/tic6x-gp.c, filename-seen-cache.h, findcmd.c, findvar.c, fork-child.c, gcore.c, gdb_bfd.c, gdb_bfd.h, gdb_proc_service.h, gdb_regex.c, gdb_select.h, gdb_usleep.c, gdbarch-selftests.c, gdbthread.h, gdbtypes.h, gnu-nat.c, go32-nat.c, guile/guile.c, guile/scm-ports.c, guile/scm-safe-call.c, guile/scm-type.c, i386-fbsd-nat.c, i386-fbsd-tdep.c, i386-go32-tdep.c, i386-linux-nat.c, i386-linux-tdep.c, i386-tdep.c, i387-tdep.c, ia64-libunwind-tdep.c, ia64-linux-nat.c, inf-child.c, inf-ptrace.c, infcall.c, infcall.h, infcmd.c, inferior-iter.h, inferior.c, inferior.h, inflow.c, inflow.h, infrun.c, infrun.h, inline-frame.c, language.h, linespec.c, linux-fork.c, linux-nat.c, linux-tdep.c, linux-thread-db.c, location.c, machoread.c, macrotab.h, main.c, maint.c, maint.h, memattr.c, memrange.h, mi/mi-cmd-break.h, mi/mi-cmd-env.c, mi/mi-cmd-stack.c, mi/mi-cmd-var.c, mi/mi-interp.c, mi/mi-main.c, mi/mi-parse.h, minsyms.c, mips-linux-tdep.c, namespace.h, nat/aarch64-linux-hw-point.c, nat/aarch64-linux-hw-point.h, nat/aarch64-linux.c, nat/aarch64-sve-linux-ptrace.c, nat/amd64-linux-siginfo.c, nat/fork-inferior.c, nat/linux-btrace.c, nat/linux-btrace.h, nat/linux-namespaces.c, nat/linux-nat.h, nat/linux-osdata.c, nat/linux-personality.c, nat/linux-procfs.c, nat/linux-ptrace.c, nat/linux-ptrace.h, nat/linux-waitpid.c, nat/mips-linux-watch.c, nat/mips-linux-watch.h, nat/ppc-linux.c, nat/x86-dregs.c, nat/x86-dregs.h, nat/x86-linux-dregs.c, nat/x86-linux.c, nto-procfs.c, nto-tdep.c, objfile-flags.h, objfiles.c, objfiles.h, obsd-nat.c, observable.h, osdata.c, p-valprint.c, parse.c, parser-defs.h, ppc-linux-nat.c, printcmd.c, probe.c, proc-api.c, procfs.c, producer.c, progspace.h, psymtab.h, python/py-framefilter.c, python/py-inferior.c, python/py-ref.h, python/py-type.c, python/python.c, record-btrace.c, record-full.c, record.c, record.h, regcache-dump.c, regcache.c, regcache.h, remote-fileio.c, remote-fileio.h, remote-sim.c, remote.c, riscv-tdep.c, rs6000-aix-tdep.c, rust-exp.y, s12z-tdep.c, selftest-arch.c, ser-base.c, ser-event.c, ser-pipe.c, ser-tcp.c, ser-unix.c, skip.c, solib-aix.c, solib-target.c, solib.c, source-cache.c, source.c, source.h, sparc-nat.c, spu-linux-nat.c, stack.c, stap-probe.c, symfile-add-flags.h, symfile.c, symfile.h, symtab.c, symtab.h, target-descriptions.c, target-descriptions.h, target-memory.c, target.c, target.h, target/waitstatus.c, target/waitstatus.h, thread-iter.h, thread.c, tilegx-tdep.c, top.c, top.h, tracefile-tfile.c, tracefile.c, tracepoint.c, tracepoint.h, tui/tui-io.c, ui-file.c, ui-out.h, unittests/array-view-selftests.c, unittests/child-path-selftests.c, unittests/cli-utils-selftests.c, unittests/common-utils-selftests.c, unittests/copy_bitwise-selftests.c, unittests/environ-selftests.c, unittests/format_pieces-selftests.c, unittests/function-view-selftests.c, unittests/lookup_name_info-selftests.c, unittests/memory-map-selftests.c, unittests/memrange-selftests.c, unittests/mkdir-recursive-selftests.c, unittests/observable-selftests.c, unittests/offset-type-selftests.c, unittests/optional-selftests.c, unittests/parse-connection-spec-selftests.c, unittests/ptid-selftests.c, unittests/rsp-low-selftests.c, unittests/scoped_fd-selftests.c, unittests/scoped_mmap-selftests.c, unittests/scoped_restore-selftests.c, unittests/string_view-selftests.c, unittests/style-selftests.c, unittests/tracepoint-selftests.c, unittests/unpack-selftests.c, unittests/utils-selftests.c, unittests/xml-utils-selftests.c, utils.c, utils.h, valarith.c, valops.c, valprint.c, value.c, value.h, varobj.c, varobj.h, windows-nat.c, x86-linux-nat.c, xml-support.c, xml-support.h, xml-tdesc.h, xstormy16-tdep.c, xtensa-linux-nat.c, dwarf2read.h: Change common to gdbsupport. gdb/gdbserver/ChangeLog 2019-07-09 Tom Tromey <tom@tromey.com> * configure: Rebuild. * configure.ac: Change common to gdbsupport. * acinclude.m4: Change common to gdbsupport. * Makefile.in (SFILES, OBS, GDBREPLAY_OBS, IPA_OBJS) (version-generated.c, gdbsupport/%-ipa.o, gdbsupport/%.o): Change common to gdbsupport. * ax.c, event-loop.c, fork-child.c, gdb_proc_service.h, gdbreplay.c, gdbthread.h, hostio-errno.c, hostio.c, i387-fp.c, inferiors.c, inferiors.h, linux-aarch64-tdesc-selftest.c, linux-amd64-ipa.c, linux-i386-ipa.c, linux-low.c, linux-tic6x-low.c, linux-x86-low.c, linux-x86-tdesc-selftest.c, linux-x86-tdesc.c, lynx-i386-low.c, lynx-low.c, mem-break.h, nto-x86-low.c, regcache.c, regcache.h, remote-utils.c, server.c, server.h, spu-low.c, symbol.c, target.h, tdesc.c, tdesc.h, thread-db.c, tracepoint.c, win32-i386-low.c, win32-low.c: Change common to gdbsupport.
2019-03-14Make TUI react to "set style enabled"Tom Tromey1-0/+4
When the user toggles "set style enabled", the TUI should react by redrawing the source window, if necessary. This patch implements this behavior. No test because the TUI is generally not tested. This version of the patch incorporates Pedro's patch to provide a clean way to force the TUI to update the source window's contents. gdb/ChangeLog 2019-03-14 Pedro Alves <palves@redhat.com> Tom Tromey <tromey@adacore.com> * tui/tui-winsource.h (tui_refill_source_window): Declare. * tui/tui-winsource.c (tui_refill_source_window): New function, from... (tui_horizontal_source_scroll): ... here. Move some logic. * cli/cli-style.c (set_style_enabled): Notify new observable. * tui/tui-hooks.c (tui_redisplay_source): New function. (tui_attach_detach_observers): Attach or detach tui_redisplay_source. * observable.h (source_styling_changed): New observable. * observable.c: Define source_styling_changed observable.