aboutsummaryrefslogtreecommitdiff
path: root/gdb/mi
AgeCommit message (Collapse)AuthorFilesLines
9 daysUse gnulib c-ctype module in gdbTom Tromey5-12/+7
PR ada/33217 points out that gdb incorrectly calls the <ctype.h> functions. In particular, gdb feels free to pass a 'char' like: char *str = ...; ... isdigit (*str) This is incorrect as isdigit only accepts EOF and values that can be represented as 'unsigned char' -- that is, a cast is needed here to avoid undefined behavior when 'char' is signed and a character in the string might be sign-extended. (As an aside, I think this API seems obviously bad, but unfortunately this is what the standard says, and some systems check this.) Rather than adding casts everywhere, this changes all the code in gdb that uses any <ctype.h> API to instead call the corresponding c-ctype function. Now, c-ctype has some limitations compared to <ctype.h>. It works as if the C locale is in effect, so in theory some non-ASCII characters may be misclassified. This would only affect a subset of character sets, though, and in most places I think ASCII is sufficient -- for example the many places in gdb that check for whitespace. Furthermore, in practice most users are using UTF-8-based locales, where these functions aren't really informative for non-ASCII characters anyway; see the existing workarounds in gdb/c-support.h. Note that safe-ctype.h cannot be used because it causes conflicts with readline.h. And, we canot poison the <ctype.h> identifiers as this provokes errors from some libstdc++ headers. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33217 Approved-By: Simon Marchi <simon.marchi@efficios.com>
9 daysUse c-ctype.h (not safe-ctype.h) in gdbTom Tromey1-1/+0
This changes gdb and related programs to use the gnulib c-ctype code rather than safe-ctype.h. The gdb-safe-ctype.h header is removed. This changes common-defs.h to include the c-ctype header, making it available everywhere in gdb. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33217 Approved-By: Simon Marchi <simon.marchi@efficios.com>
2025-08-19gdb: rename address_class -> location_classSimon Marchi1-1/+1
The enum address_class and related fields and methods seem misnamed to me. Generalize it to "location_class". The enumerators in address_class are already prefixed with LOC, so the new name seems logical to me. Rename related fields and methods as well. Plus, address_class could easily be mistaken for other unrelated things named "address class" in GDB or DWARF. Tested by rebuilding. Change-Id: I0dca3738df412b350715286c608041b08e9b4d82 Approved-by: Kevin Buettner <kevinb@redhat.com>
2025-06-26Change file initialization to use INIT_GDB_FILE macroTom Tromey4-12/+4
This patch introduces a new macro, INIT_GDB_FILE. This is used to replace the current "_initialize_" idiom when introducing a per-file initialization function. That is, rather than write: void _initialize_something (); void _initialize_something () { ... } ... now you would write: INIT_GDB_FILE (something) { ... } The macro handles both the declaration and definition of the function. The point of this approach is that it makes it harder to accidentally cause an initializer to be omitted; see commit 2711e475 ("Ensure cooked_index_entry self-tests are run"). Specifically, the regexp now used by make-init-c seems harder to trick. New in v2: un-did some erroneous changes made by the script. The bulk of this patch was written by script. Regression tested on x86-64 Fedora 41.
2025-05-29gdb/solib: move solist.h content to solib.hSimon Marchi2-2/+1
I don't think that the file solist.h is useful. It would make sense to have `struct solib` in solib.h. And then, all that would remain is `struct solib_ops` and some solib-related function declarations. So, move it all to solib.h. Change-Id: I20ecf19787c378066f2c7a6a8a737c1db7c55d9a Reviewed-By: Guinevere Larsen <guinevere@redhat.com>
2025-05-29gdb/solib: remove so_ prefix from so_name and so_original_nameSimon Marchi2-5/+5
The `so_` prefix is unnecessary here, it's already clear by the fact that they are field of the solib type (and previously so_list). Change-Id: I2c6773afc121d7631901e602913ea8a068840d0b Reviewed-By: Guinevere Larsen <guinevere@redhat.com>
2025-04-29gdb: add scoped_time_itSimon Marchi1-1/+1
New in v2: - actually use m_enabled in the constructor and destructor - output using gdb_stdlog->write_async_safe instead of gdb_printf scoped_time_it is a small utility that measures and prints how much time a given thread spent in a given scope. Similar to the time(1) command, it prints the time spent in user mode, system mode, and the wall clock time. It also prints the CPU utilization percentage, which is: (user + sys) / wall This can help spot cases where the workload is not well balanced between workers, or the CPU utilization is not optimal (perhaps due to contention around a lock for example). To use it, just add it in some scope. For instance, a subsequent patch adds it here: workers.add_task ([this, task_count, iter, last] () { scoped_time_it time_it ("DWARF indexing worker"); process_cus (task_count, iter, last); }); On destruction, if enabled, it prints a line showing the time spent by that thread, similar to what time(1) prints. The example above prints this (one line for each worker thread): Time for "DWARF indexing worker": wall 0.173, user 0.120, sys 0.034, user+sys 0.154, 89.0 % CPU Time for "DWARF indexing worker": wall 0.211, user 0.144, sys 0.047, user+sys 0.191, 90.5 % CPU Time for "DWARF indexing worker": wall 0.368, user 0.295, sys 0.057, user+sys 0.352, 95.7 % CPU Time for "DWARF indexing worker": wall 0.445, user 0.361, sys 0.072, user+sys 0.433, 97.3 % CPU Time for "DWARF indexing worker": wall 0.592, user 0.459, sys 0.113, user+sys 0.572, 96.6 % CPU Time for "DWARF indexing worker": wall 0.739, user 0.608, sys 0.115, user+sys 0.723, 97.8 % CPU Time for "DWARF indexing worker": wall 0.831, user 0.677, sys 0.140, user+sys 0.817, 98.3 % CPU Time for "DWARF indexing worker": wall 0.949, user 0.789, sys 0.144, user+sys 0.933, 98.3 % CPU The object is only enabled if per_command_time (controlled by "maint set per-command time") is true at construction time. I wanted to avoid adding a new command for now, but eventually if there are too many scoped_time_it around the code base and we want to be able to enabled them selectively (e.g. just the ones in the DWARF reader, or in the symbol searching functions, etc), we could have a dedicated command for that. I added this functionality to GDB because it relies on gdb_printf and per_command_time, but if we ever need it in gdbsupport, I'm sure we could find a way to put it there. Change-Id: I5416ac1448f960f44d85f8449943d994198a271e Approved-By: Tom Tromey <tom@tromey.com>
2025-04-29gdbsupport: move run_time_clock::now(user, system) out of run_time_clockSimon Marchi1-1/+1
It is completely unrelated to run_time_clock, so I don't think it makes sense to have it as a static function there. Move it to be a free function named "get_run_time". Change-Id: I0c3e4d3cc44ca37e523c94d72f7cd66add95645e Approved-By: Tom Tromey <tom@tromey.com>
2025-04-08Update copyright dates to include 2025Tom Tromey27-27/+27
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>
2025-03-17gdbsupport: add some -Wunused-* warning flagsSimon Marchi2-2/+0
Add a few -Wunused-* diagnostic flags that look useful. Some are known to gcc, some to clang, some to both. Fix the fallouts. -Wunused-const-variable=1 is understood by gcc, but not clang. -Wunused-const-variable would be undertsood by both, but for gcc at least it would flag the unused const variables in headers. This doesn't make sense to me, because as soon as one source file includes a header but doesn't use a const variable defined in that header, it's an error. With `=1`, gcc only warns about unused const variable in the main source file. It's not a big deal that clang doesn't understand it though: any instance of that problem will be flagged by any gcc build. Change-Id: Ie20d99524b3054693f1ac5b53115bb46c89a5156 Approved-By: Tom Tromey <tom@tromey.com>
2025-03-11Use gdb map in mi-cmds.cTom Tromey1-2/+2
This changes mi-cmds.c to use gdb::unordered_map. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2025-03-11Use gdb set and map in mi-main.cTom Tromey1-7/+7
This changes mi-main.c to use gdb::unordered_set and gdb::unordered_map. this may change the order of core ids that are emitted, but that seems fine as MI generally doesn't guarantee ordering. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2025-03-11Use gdb::function_view in iterate_over_threadsTom Tromey1-66/+34
This C++-ifies iterate_over_threads, changing it to accept a gdb::function_view and to return bool. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2025-02-25Remove struct print_one_inferior_dataTom Tromey1-6/+0
struct print_one_inferior_data is not used, so remove it.
2025-02-19gdb/mi: Fix segfault when attaching a rocm process with MILancelot Six1-1/+1
When using the MI interpreter, if someone was to attach to a ROCm process which has active GPU waves, GDB would issue a segfault as follows: attach 1994813 &"attach 1994813\n" ~"Attaching to process 1994813\n" =thread-group-started,id="i1",pid="1994813" =thread-created,id="1",group-id="i1" =thread-created,id="2",group-id="i1" ~"[New LWP 1994828]\n" *running,thread-id="2" =thread-created,id="3",group-id="i1" ~"[New LWP 1994825]\n" *running,thread-id="3" =thread-created,id="4",group-id="i1" ~"[New LWP 1994823]\n" *running,thread-id="4" ^done =library-loaded,... [...] ~"[Thread debugging using libthread_db enabled]\n" ~"Using host libthread_db library \"/lib/x86_64-linux-gnu/libthread_db.so.1\".\n" =thread-created,id="5",group-id="i1" &"\n\n" &"Fatal signal: " &"Segmentation fault" &"\n" &"----- Backtrace -----\n" &"Backtrace unavailable\n" &"---------------------\n" &"A fatal error internal to GDB has been detected, further\ndebugging is not possible. GDB will now terminate.\n\n" &"This is a bug, please report it." &" For instructions, see:\n" &"<https://github.com/ROCm-Developer-Tools/ROCgdb/issues>" &"." &"\n\n" Segmentation fault The issue comes from using a non-initialized pointer in mi_on_resume_1: if (!mi->running_result_record_printed && mi->mi_proceeded) { gdb_printf (mi->raw_stdout, "%s^running\n", mi->current_token ? mi->current_token : ""); } In this instance, "mi->current_token" has an uninitialized value. This is a regression introduced by: commit def2803789208a617c429b5dcf2026decb25ce0c Date: Wed Sep 6 11:02:00 2023 -0400 gdb/mi: make current_token a field of mi_interp Before this patch, current_token was a global implicitly 0-initialized. Since it is now a class field, it is not 0-initialized by default anymore. This patch changes this. Change-Id: I3f00b080318a70405d881ff0abe02b2c5cb1f9d8 Approved-By: Simon Marchi <simon.marchi@efficios.com> Approved-By: Tom Tromey <tom@tromey.com>
2025-02-11gdb: cleanup includes in mi/Simon Marchi10-20/+1
Remove a few includes reported as unused by clangd. Change-Id: I7365b7cce04c9ef1a4164764191303914da42ef9
2025-02-09gdb/mi: include ranges in =library-unloaded eventAndrew Burgess1-8/+16
Having looked at the dlmopen support in GDB, it occurred to me that the current MI =library-unloaded event doesn't incude enough information to be useful. Consider the gdb.mi/mi-dlmopen.exp test, this test loads libraries into multiple linker namespaces, and then unloads these libraries. We should probably figure out a way to include the linker namepsace ID in GDB's output, e.g. in the =library-loaded and =library-unloaded MI events, and in the output of 'info sharedlibrary'. But this commit is not about doing that. This commit includes the 'ranges' information in the =library-unloaded event output. This is the same ranges information as is included in the =library-loaded output. Even without the linker namespace ID, this should allow MI consumers to figure out which library instance is being unloaded. Here is the 'info sharedlibrary' output for mi-dlmopen.exp at the point where all the shared libraries are loaded: info sharedlibrary &"info sharedlibrary\n" ~"From To Syms Read Shared Object Library\n" ~"0x00007ffff7fca000 0x00007ffff7ff03f5 Yes /lib64/ld-linux-x86-64.so.2\n" ~"0x00007ffff7eda3d0 0x00007ffff7f4e898 Yes /lib64/libm.so.6\n" ~"0x00007ffff7d0e800 0x00007ffff7e6dccd Yes /lib64/libc.so.6\n" ~"0x00007ffff7fbd040 0x00007ffff7fbd116 Yes /tmp/build/gdb/testsuite/outputs/gdb.mi/mi-dlmopen/dlmopen-lib.1.so\n" ~"0x00007ffff7fb8040 0x00007ffff7fb80f9 Yes /tmp/build/gdb/testsuite/outputs/gdb.mi/mi-dlmopen/dlmopen-lib-dep.so\n" ~"0x00007ffff7bfe3d0 0x00007ffff7c72898 Yes /lib64/libm.so.6\n" ~"0x00007ffff7a32800 0x00007ffff7b91ccd Yes /lib64/libc.so.6\n" ~"0x00007ffff7fca000 0x00007ffff7ff03f5 Yes /lib64/ld-linux-x86-64.so.2\n" ~"0x00007ffff7fb3040 0x00007ffff7fb3116 Yes /tmp/build/gdb/testsuite/outputs/gdb.mi/mi-dlmopen/dlmopen-lib.1.so\n" ~"0x00007ffff7fae040 0x00007ffff7fae0f9 Yes /tmp/build/gdb/testsuite/outputs/gdb.mi/mi-dlmopen/dlmopen-lib-dep.so\n" ~"0x00007ffff7ce1040 0x00007ffff7ce1116 Yes /tmp/build/gdb/testsuite/outputs/gdb.mi/mi-dlmopen/dlmopen-lib.1.so\n" ~"0x00007ffff7cdc040 0x00007ffff7cdc0f9 Yes /tmp/build/gdb/testsuite/outputs/gdb.mi/mi-dlmopen/dlmopen-lib-dep.so\n" ~"0x00007ffff79253d0 0x00007ffff7999898 Yes /lib64/libm.so.6\n" ~"0x00007ffff7759800 0x00007ffff78b8ccd Yes /lib64/libc.so.6\n" ~"0x00007ffff7fca000 0x00007ffff7ff03f5 Yes /lib64/ld-linux-x86-64.so.2\n" ~"0x00007ffff7cd7040 0x00007ffff7cd7116 Yes /tmp/build/gdb/testsuite/outputs/gdb.mi/mi-dlmopen/dlmopen-lib.2.so\n" ^done (gdb) Notice that dlmopen-lib.1.so is loaded multiple times. Here is the =library-unloaded event when one copy of this library is unloaded before this patch: =library-unloaded,id="/tmp/build/gdb/testsuite/outputs/gdb.mi/mi-dlmopen/dlmopen-lib.1.so", target-name="/tmp/build/gdb/testsuite/outputs/gdb.mi/mi-dlmopen/dlmopen-lib.1.so", host-name="/tmp/build/gdb/testsuite/outputs/gdb.mi/mi-dlmopen/dlmopen-lib.1.so", thread-group="i1", It is not possible, given this information, to know which copy of dlmopen-lib.1.so has actually been unloaded. An MI consumer would need to query the full shared library list and update from that information. After this patch the new output is: =library-unloaded,id="/tmp/build/gdb/testsuite/outputs/gdb.mi/mi-dlmopen/dlmopen-lib.1.so", target-name="/tmp/build/gdb/testsuite/outputs/gdb.mi/mi-dlmopen/dlmopen-lib.1.so", host-name="/tmp/build/gdb/testsuite/outputs/gdb.mi/mi-dlmopen/dlmopen-lib.1.so", thread-group="i1", ranges=[{from="0x00007ffff7fbd040",to="0x00007ffff7fbd116"}], still-in-use="false" The new 'ranges' field allows an MI consumer to uniquely identify which library instance was just unmapped. A frontent could, e.g. update a library list with no need to query the full shared library list. To include the 'ranges' field I updated mi_interp::on_solib_unloaded to call a new helper function. The new helper function is split out from the existing mi_output_solib_attribs. I was tempted to just call mi_output_solib_attribs, but doing so would mean that the 'symbols-loaded' field was also added to the =library-unloaded event, however, the docs for 'symbols-unloaded' on =library-loaded says: The @var{symbols-loaded} field is emitted only for backward compatibility and should not be relied on to convey any useful information. And it seemed silly to add a fields to =library-unloaded, which I would then document as something that should be ignored. The new helper function means I can avoid emitting the 'symbols-loaded' field. I have also added a 'still-in-use' field. When true this indicates that the library was removed from the inferior's library list, but the mapping was not removed from the inferior's address space as there is another copy of the library that is still using the library. In the above list, notice that ld-linux-x86-64.so.2 appears 3 times, but each instance is mapped as 0x00007ffff7fca000. When one copy of ld-linux-x86-64.so.2 is unloaded, here's the event: =library-unloaded,id="/lib64/ld-linux-x86-64.so.2", target-name="/lib64/ld-linux-x86-64.so.2", host-name="/lib64/ld-linux-x86-64.so.2", thread-group="i1", ranges=[{from="0x00007ffff7fca000",to="0x00007ffff7ff03f5"}], still-in-use="true" The 'still-in-use' field is 'true', this indicates there are at least one instance of this library remaining mapped at 0x00007ffff7fca000. Reviewed-By: Eli Zaretskii <eliz@gnu.org>
2025-02-09gdb: include a still-mapped flag in solib unload notificationAndrew Burgess2-2/+2
Consider the gdb.base/dlmopen.exp test case. The executable in this test uses dlmopen to load libraries into multiple linker namespaces. When a library is loaded into a separate namespace, its dependencies are also loaded into that namespace. This means that an inferior can have multiple copies of some libraries, including the dynamic linker, loaded at once. However, glibc optimises at least the dynamic linker case. Though the library appears to be mapped multiple times (it is in the inferior's solib list multiple times), there is really only one copy mapped into the inferior's address space. Here is the 'info sharedlibrary' output on an x86-64/Linux machine once all the libraries are loaded: (gdb) info sharedlibrary From To Syms Read Shared Object Library 0x00007ffff7fca000 0x00007ffff7ff03f5 Yes /lib64/ld-linux-x86-64.so.2 0x00007ffff7eda3d0 0x00007ffff7f4e898 Yes /lib64/libm.so.6 0x00007ffff7d0e800 0x00007ffff7e6dccd Yes /lib64/libc.so.6 0x00007ffff7fbd040 0x00007ffff7fbd116 Yes /tmp/build/gdb/testsuite/outputs/gdb.base/dlmopen/dlmopen-lib.1.so 0x00007ffff7fb8040 0x00007ffff7fb80f9 Yes /tmp/build/gdb/testsuite/outputs/gdb.base/dlmopen/dlmopen-lib-dep.so 0x00007ffff7bfe3d0 0x00007ffff7c72898 Yes /lib64/libm.so.6 0x00007ffff7a32800 0x00007ffff7b91ccd Yes /lib64/libc.so.6 0x00007ffff7fca000 0x00007ffff7ff03f5 Yes /lib64/ld-linux-x86-64.so.2 0x00007ffff7fb3040 0x00007ffff7fb3116 Yes /tmp/build/gdb/testsuite/outputs/gdb.base/dlmopen/dlmopen-lib.1.so 0x00007ffff7fae040 0x00007ffff7fae0f9 Yes /tmp/build/gdb/testsuite/outputs/gdb.base/dlmopen/dlmopen-lib-dep.so 0x00007ffff7ce1040 0x00007ffff7ce1116 Yes /tmp/build/gdb/testsuite/outputs/gdb.base/dlmopen/dlmopen-lib.1.so 0x00007ffff7cdc040 0x00007ffff7cdc0f9 Yes /tmp/build/gdb/testsuite/outputs/gdb.base/dlmopen/dlmopen-lib-dep.so 0x00007ffff79253d0 0x00007ffff7999898 Yes /lib64/libm.so.6 0x00007ffff7759800 0x00007ffff78b8ccd Yes /lib64/libc.so.6 0x00007ffff7fca000 0x00007ffff7ff03f5 Yes /lib64/ld-linux-x86-64.so.2 0x00007ffff7cd7040 0x00007ffff7cd7116 Yes /tmp/build/gdb/testsuite/outputs/gdb.base/dlmopen/dlmopen-lib.2.so Notice that every copy of /lib64/ld-linux-x86-64.so.2 is mapped at the same address. As the inferior closes the libraries that it loaded, the various copies of the dynamic linker will also be unloaded. Currently, when this happens GDB calls notify_solib_unloaded, which triggers the gdb::observers::solib_unloaded observer. This observer will call disable_breakpoints_in_unloaded_shlib (in breakpoint.c), which disables any breakpoints in the unloaded solib. The problem with this, is that, when the dynamic linker (or any solib) is only really mapped once as is the case here, we only want to disable breakpoints in the library when the last instance of the library is unloaded. The first idea that comes to mind is that GDB should not emit the solib_unloaded notification if a shared library is still in use, however, this could break MI consumers. Currently, every time a copy of ld-linux-x86-64.so.2 is unloaded, GDB's MI interpreter will emit a =library-unloaded event. An MI consumer might use this to update the library list that it displays to the user, and fewer notify_solib_unloaded calls will mean fewer MI events, which will mean the MI consumer's library list could get out of sync with GDB. Instead I propose that we extend GDB's solib_unloaded event to add a new flag. The new flag indicates if the library mapping is still in use within the inferior. Now the MI will continue to emit the expected =library-unloaded events, but disable_breakpoints_in_unloaded_shlib can check the new flag, when it is true (indicating that the library is still mapped into the inferior), no breakpoints should be disabled. The other user of the solib_unloaded observer, in bsd-uthread.c, should, I think, do nothing if the mapping is still in use. This observer is also disabling breakpoints when a library is unloaded. Most of the changes in this commit relate to passing the new flag around for the event. The interesting changes are mostly in solib.c, where the flag value is determined, and in breakpoint.c and bsd-uthread.c, where the flag value is read. There's a new MI test, the source of which is mostly copied from the gdb.base/dlmopen.exp test. This new test is checking we see all the expected =library-unloaded events.
2024-12-18Run check-include-guards.pyTom Tromey9-27/+27
This patch is the result of running check-include-guards.py on the current tree. Running it a second time causes no changes. Reviewed-By: Tom de Vries <tdevries@suse.de>
2024-11-23[gdb/contrib] Add two rules in common-misspellings.txtTom de Vries1-1/+1
Eli mentioned [1] that given that we use US English spelling in our documentation, we should use "behavior" instead of "behaviour". In wikipedia-common-misspellings.txt there's a rule: ... behavour->behavior, behaviour ... which leaves this as a choice. Add an overriding rule to hardcode the choice to common-misspellings.txt: ... behavour->behavior ... and add a rule to rewrite behaviour into behavior: ... behaviour->behavior ... and re-run spellcheck.sh on gdb*. Tested on x86_64-linux. [1] https://sourceware.org/pipermail/gdb-patches/2024-November/213371.html
2024-09-30Add line-number stylingTom Tromey2-7/+9
This patch adds separate styling for line numbers. That is, whenever gdb prints a source line number, it uses this style. v2 includes a change to ensure that %ps works in query. Reviewed-By: Eli Zaretskii <eliz@gnu.org> Reviewed-by: Keith Seitz <keiths@redhat.com>
2024-09-27gdb/symtab: pass program space to lookup_symtab and iterate_over_symtabsSimon Marchi2-2/+3
Make the current program space references bubble up. In collect_symtabs_from_filename, remove the calls to set_current_program_space and just pass the relevant pspaces. This appears safe to do, because nothing in the `collector` callback cares about the current pspace. Change-Id: I00a7ed484bfbe5264f01a6abf0d33b51de373cbb Reviewed-by: Keith Seitz <keiths@redhat.com>
2024-08-15Add another constructor to scoped_restore_current_languageTom Tromey1-4/+1
While working on something else, I noticed that this is relatively common: scoped_restore_current_language save; set_language (something); This patch adds a second constructor to scoped_restore_current_language to simplify this idiom. Reviewed-By: Tom de Vries <tdevries@suse.de>
2024-08-12gdb: drop struct keyword when using bound_minimal_symbolSimon Marchi1-2/+1
This is a simple find / replace from "struct bound_minimal_symbol" to "bound_minimal_symbol", to make things shorter and more consisten througout. In some cases, move variable declarations where first used. Change-Id: Ica4af11c4ac528aa842bfa49a7afe8fe77a66849 Reviewed-by: Keith Seitz <keiths@redhat.com> Approved-By: Andrew Burgess <aburgess@redhat.com>
2024-07-15gdb: pass program space to get_current_source_symtab_and_lineSimon Marchi1-2/+2
Make the current program space reference bubble up one level. Change-Id: I6ba6dc4a2cb188720cbb61b84ab5c954aac105c6 Approved-By: Tom Tromey <tom@tromey.com> Reviewed-By: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
2024-06-07gdb: make progspace::exec_filename private, add getter / setterSimon Marchi1-5/+2
Just like the title says... I think this makes things a bit clearer, for instance where the exec filename is set. It also makes the read call sites a bit nicer, avoiding the `.get ()`. Change-Id: If8b58ae8f6270c8a34b868f6ca06128c6671ea3c Approved-By: Tom Tromey <tom@tromey.com>
2024-05-30gdb: remove unused includes in utils.hSimon Marchi4-0/+4
Remove some includes reported as unused by clangd. Add some includes in other files that were previously relying on the transitive include. Change-Id: Ibdd0a998b04d21362a20d0ca8e5267e21e2e133e
2024-05-17Remove gdb_stdtargerrTom Tromey1-2/+0
This patch removes gdb_stdtargerr. There doesn't seem to be a need for this -- it is always the same as stdtarg, and (I believe) has been for many years. Approved-By: Andrew Burgess <aburgess@redhat.com>
2024-04-25gdb: remove gdbcmd.hSimon Marchi1-1/+1
Most files including gdbcmd.h currently rely on it to access things actually declared in cli/cli-cmds.h (setlist, showlist, etc). To make things easy, replace all includes of gdbcmd.h with includes of cli/cli-cmds.h. This might lead to some unused includes of cli/cli-cmds.h, but it's harmless, and much faster than going through the 170 or so files by hand. Change-Id: I11f884d4d616c12c05f395c98bbc2892950fb00f Approved-By: Tom Tromey <tom@tromey.com>
2024-04-23gdb: move a bunch of quit-related things to event-top.{c,h}Simon Marchi1-0/+1
Move some declarations related to the "quit" machinery from defs.h to event-top.h. Most of the definitions associated to these declarations are in event-top.c. The exceptions are `quit()` and `maybe_quit()`, that are defined in utils.c. For consistency, move these two definitions to event-top.c. Include "event-top.h" in many files that use these things. Change-Id: I6594f6df9047a9a480e7b9934275d186afb14378 Approved-By: Tom Tromey <tom@tromey.com>
2024-04-22gdb: move store/extract integer functions to extract-store-integer.{c,h}Simon Marchi1-0/+1
Move the declarations out of defs.h, and the implementations out of findvar.c. I opted for a new file, because this functionality of converting integers to bytes and vice-versa seems a bit to generic to live in findvar.c. Change-Id: I524858fca33901ee2150c582bac16042148d2251 Approved-By: John Baldwin <jhb@FreeBSD.org>
2024-03-26gdb, gdbserver, gdbsupport: remove includes of early headersSimon Marchi18-18/+0
Now that defs.h, server.h and common-defs.h are included via the `-include` option, it is no longer necessary for source files to include them. Remove all the inclusions of these files I could find. Update the generation scripts where relevant. Change-Id: Ia026cff269c1b7ae7386dd3619bc9bb6a5332837 Approved-By: Pedro Alves <pedro@palves.net>
2024-02-20gdb: pass frames as `const frame_info_ptr &`Simon Marchi2-5/+5
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-07Fix raw-frame-arguments in combination with frame-filtersHannes Domani1-3/+12
Currently, if frame-filters are active, raw-values is used instead of raw-frame-arguments to decide if a pretty-printer should be invoked for frame arguments in a backtrace. In this example, "super struct" is the output of the pretty-printer: (gdb) disable frame-filter global BasicFrameFilter (gdb) bt #0 foo (x=42, ss=super struct = {...}) at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:47 #1 0x004016aa in main () at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:57 If no frame-filter is active, then the raw-values print option does not affect the backtrace output: (gdb) set print raw-values on (gdb) bt #0 foo (x=42, ss=super struct = {...}) at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:47 #1 0x004016aa in main () at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:57 (gdb) set print raw-values off Instead, the raw-frame-arguments option disables the pretty-printer in the backtrace: (gdb) bt -raw-frame-arguments on #0 foo (x=42, ss=...) at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:47 #1 0x004016aa in main () at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:57 But if a frame-filter is active, the same rules don't apply. The option raw-frame-arguments is ignored, but raw-values decides if the pretty-printer is used: (gdb) enable frame-filter global BasicFrameFilter (gdb) bt #0 foo (x=42, ss=super struct = {...}) at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:47 #1 0x004016aa in main () at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:57 (gdb) set print raw-values on (gdb) bt #0 foo (x=42, ss=...) at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:47 #1 0x004016aa in main () at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:57 (gdb) set print raw-values off (gdb) bt -raw-frame-arguments on #0 foo (x=42, ss=super struct = {...}) at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:47 #1 0x004016aa in main () at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:57 So this adds the PRINT_RAW_FRAME_ARGUMENTS flag to frame_filter_flag, which is then used in the frame-filter to override the raw flag in enumerate_args. Then the output is the same if a frame-filter is active, the pretty-printer for backtraces is only disabled with the raw-frame-arguments option: (gdb) enable frame-filter global BasicFrameFilter (gdb) bt #0 foo (x=42, ss=super struct = {...}) at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:47 #1 0x004016aa in main () at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:57 (gdb) set print raw-values on (gdb) bt #0 foo (x=42, ss=super struct = {...}) at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:47 #1 0x004016aa in main () at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:57 (gdb) set print raw-values off (gdb) bt -raw-frame-arguments on #0 foo (x=42, ss=...) at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:47 #1 0x004016aa in main () at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:57 Co-Authored-By: Andrew Burgess <aburgess@redhat.com> Approved-By: Tom Tromey <tom@tromey.com>
2024-02-05gdb: rename struct shobj -> struct solibSimon Marchi3-7/+7
`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-28Use domain_search_flags in lookup_symbol et alTom Tromey1-2/+3
This changes lookup_symbol and associated APIs to accept domain_search_flags rather than a domain_enum. Note that this introduces some new constants to Python and Guile. I chose to break out the documentation patch for this, because the internals here do not change until a later patch, and it seemed simpler to patch the docs just once, rather than twice.
2024-01-28Replace search_domain with domain_search_flagsTom Tromey1-16/+17
This patch changes gdb to replace search_domain with domain_search_flags everywhere. search_domain is removed.
2024-01-28Simplify symbol_to_info_stringTom Tromey1-1/+1
Thi simplifies symbol_to_info_string, removing the 'kind' parameter and instead having it use the symbol's domain.
2024-01-19gdb: Buffer output streams during events that might download debuginfoAaron Merey1-0/+3
Introduce new ui_file buffering_file to temporarily collect output written to gdb_std* output streams during print_thread, print_frame_info and print_stop_event. This ensures that output during these functions is not interrupted by debuginfod progress messages. With the addition of deferred debuginfo downloading it is possible for download progress messages to print during these events. Without any intervention we can end up with poorly formatted output: (gdb) backtrace [...] #8 0x00007fbe8af7d7cf in pygi_invoke_c_callable (Downloading separate debug info for /lib64/libpython3.11.so.1.0 function_cache=0x561221b224d0, state=<optimized out>... To fix this we buffer writes to gdb_std* output streams while allowing debuginfod progress messages to skip the buffers and print to the underlying output streams immediately. Buffered output is then written to the output streams. This ensures that progress messages print first, followed by uninterrupted frame/thread/stop info: (gdb) backtrace [...] Downloading separate debug info for /lib64/libpython3.11.so.1.0 #8 0x00007fbe8af7d7cf in pygi_invoke_c_callable (function_cache=0x561221b224d0, state=<optimized out>... Co-Authored-By: Andrew Burgess <aburgess@redhat.com> Approved-By: Andrew Burgess <aburgess@redhat.com>
2024-01-12Update copyright year range in header of all files managed by GDBAndrew Burgess27-27/+27
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-14gdb: change value_of_register and value_of_register_lazy to take the next frameSimon Marchi1-1/+2
Some functions related to the handling of registers in frames accept "this frame", for which we want to read or write the register values, while other functions accept "the next frame", which is the frame next to that. The later is needed because we sometimes need to read register values for a frame that does not exist yet (usually when trying to unwind that frame-to-be). value_of_register and value_of_register_lazy both take "this frame", even if what they ultimately want internally is "the next frame". This is annoying if you are in a spot that currently has "the next frame" and need to call one of these functions (which happens later in this series). You need to get the previous frame only for those functions to get the next frame again. This is more manipulations, more chances of mistake. I propose to change these functions (and a few more functions in the subsequent patches) to operate on "the next frame". Things become a bit less awkward when all these functions agree on which frame they take. So, in this patch, change value_of_register_lazy and value_of_register to take "the next frame" instead of "this frame". This adds a lot of get_next_frame_sentinel_okay, but if we convert the user registers API to also use "the next frame" instead of "this frame", it will get simple again. Change-Id: Iaa24815e648fbe5ae3c214c738758890a91819cd Reviewed-By: John Baldwin <jhb@FreeBSD.org>
2023-12-13Use unique_xmalloc_ptr in explicit_location_specTom Tromey1-3/+3
This changes explicit_location_spec to use unique_xmalloc_ptr, removing some manual memory management. Reviewed-By: John Baldwin <jhb@FreeBSD.org>
2023-11-29Remove gdb_static_assertTom Tromey1-1/+1
C++17 makes the second parameter to static_assert optional, so we can remove gdb_static_assert now.
2023-11-29Use C++17 [[fallthrough]] attributeTom Tromey1-1/+1
This changes gdb to use the C++17 [[fallthrough]] attribute rather than special comments. This was mostly done by script, but I neglected a few spellings and so also fixed it up by hand. I suspect this fixes the bug mentioned below, by switching to a standard approach that, presumably, clang supports. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=23159 Approved-By: John Baldwin <jhb@FreeBSD.org> Approved-By: Luis Machado <luis.machado@arm.com> Approved-By: Pedro Alves <pedro@palves.net>
2023-11-21gdb: Replace gdb::optional with std::optionalLancelot Six7-16/+16
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-11-21gdb: Use C++17's std::make_unique instead of gdb::make_uniqueLancelot Six2-4/+4
gdb::make_unique is a wrapper around std::make_unique when compiled with C++17. Now that C++17 is required, use std::make_unique directly in the codebase, and remove gdb::make_unique. Change-Id: I80b615e46e4b7c097f09d78e579a9bdce00254ab Approved-By: Tom Tromey <tom@tromey.com> Approved-By: Pedro Alves <pedro@palves.net
2023-11-17gdb: remove get_current_regcacheSimon Marchi1-2/+1
Remove get_current_regcache, inlining the call to get_thread_regcache in callers. When possible, pass the right thread_info object known from the local context. Otherwise, fall back to passing `inferior_thread ()`. This makes the reference to global context bubble up one level, a small step towards the long term goal of reducing the number of references to global context (or rather, moving those references as close as possible to the top of the call tree). No behavior change expected. Change-Id: Ifa6980c88825d803ea586546b6b4c633c33be8d6
2023-10-19gdb: rename struct so_list to shobjSimon Marchi3-7/+7
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: link so_list using intrusive_listSimon Marchi1-4/+4
Replace the hand-made linked list implementation with intrusive_list, simplying management of list items. Change-Id: I7f55fd88325bb197cc655c9be5a2ec966d8cc48d Approved-By: Pedro Alves <pedro@palves.net> Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>
2023-10-19gdb: make so_list::{so_original_name,so_name} std::stringsSimon Marchi1-2/+3
Change these two fields, simplifying memory management and copying. Change-Id: If2559284c515721e71e1ef56ada8b64667eebe55 Approved-By: Pedro Alves <pedro@palves.net> Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>