aboutsummaryrefslogtreecommitdiff
path: root/gdbsupport
AgeCommit message (Collapse)AuthorFilesLines
2025-06-20gdbsupport: Use xsnprintf() instead of strcat() in print-utilsAleksandar Rikalo1-4/+2
Theoretically, in functions core_addr_to_string_nz() and core_addr_to_string(), strcat() can overflow, so use a safe approach using xsnprintf(). Change-Id: Ib9437450b3634dc35077234f462a03a8640242d4
2025-06-13gdbsupport: make gdb::parallel_for_each's n parameter a template parameterSimon Marchi1-6/+4
This value will likely never change at runtime, so we might as well make it a template parameter. This has the "advantage" of being able to remove the unnecessary param from gdb::sequential_for_each. Change-Id: Ia172ab8e08964e30d4e3378a95ccfa782abce674 Approved-By: Tom Tromey <tom@tromey.com>
2025-05-29gdb, gdbsupport: fix all `;;` instancesSimon Marchi1-1/+1
I forgot to fix a `;;` typo when pushing a previous patch. Fix it, and fix all the other instances I could find in the code base. Change-Id: I298f9ffb1a5157925076ef67b439579b1aeeaa2b
2025-05-29Fix build when RUSAGE_THREAD is not available & add warningPedro Alves2-2/+30
Building current GDB on Cygwin, fails like so: /home/pedro/gdb/src/gdbsupport/run-time-clock.cc: In function ‘void get_run_time(user_cpu_time_clock::time_point&, system_cpu_time_clock::time_point&, run_time_scope ’: /home/pedro/gdb/src/gdbsupport/run-time-clock.cc:52:13: error: ‘RUSAGE_THREAD’ was not declared in this scope; did you mean ‘SIGEV_THREAD’? 52 | who = RUSAGE_THREAD; | ^~~~~~~~~~~~~ | SIGEV_THREAD Cygwin does not implement RUSAGE_THREAD. Googling around, I see Cygwin is not alone, other platforms don't support it either. For example, here is someone suggesting an alternative for darwin/macos: https://stackoverflow.com/questions/5652463/equivalent-to-rusage-thread-darwin Fix this by falling back to process scope if thread scope can't be supported. I chose this instead of returning zero usage or some other constant, because if gdb is built without threading support, then process-scope run time usage is the right info to return. But instead of falling back silently, print a warning (just once), like so: (gdb) maint set per-command time on ⚠️ warning: per-thread run time information not available on this platform ... so that developers on other platforms at least have a hint upfront. This new warning also shows on platforms that don't have getrusage in the first place, but does not show if the build doesn't support threading at all. New tests are added to gdb.base/maint.exp, to expect the warning, and also to ensure other "mt per-command" sub commands don't trigger the new warning. Change-Id: Ie01b916b62f87006f855e31594a5ac7cf09e4c02 Approved-By: Simon Marchi <simon.marchi@efficios.com> Approved-By: Tom Tromey <tom@tromey.com>
2025-05-12gdbsupport/event-loop: do not truncate poll timeouts to lower secondPatrick Monnerat1-1/+2
In update_wait_timeout function, microseconds were not taken into account in poll timeout computation, resulting in 100% cpu time consumption in the event loop while waiting for a sub-second timeout. The bug has been introduced in commit c2c6d25. This patch adds the microseconds converted to milliseconds in poll timeout computation. Conversion by excess (ceil) is performed to avoid the same problem with sub-millisecond timeouts too.
2025-05-02[gdbsupport] Reimplement phex and phex_nz as templatesTom de Vries2-13/+33
Gdbsupport functions phex and phex_nz have a parameter sizeof_l: ... extern const char *phex (ULONGEST l, int sizeof_l); extern const char *phex_nz (ULONGEST l, int sizeof_l); ... and a lot of calls use: ... phex (l, sizeof (l)) ... Make this easier by reimplementing the functions as a template, allowing us to simply write: ... phex (l) ... Simplify existing code using: ... $ find gdb* -type f \ | xargs sed -i 's/phex (\([^,]*\), sizeof (\1))/phex (\1)/' $ find gdb* -type f \ | xargs sed -i 's/phex_nz (\([^,]*\), sizeof (\1))/phex_nz (\1)/' ... and manually review: ... $ find gdb* -type f | xargs grep "phex (.*, sizeof.*)" $ find gdb* -type f | xargs grep "phex_nz (.*, sizeof.*)" ... Tested on x86_64-linux. Approved-By: Tom Tromey <tom@tromey.com>
2025-04-29gdb: add scoped_time_itSimon Marchi2-4/+33
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 Marchi2-8/+9
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-24gdbsupport: add missing include guard to remote-args.hSimon Marchi1-1/+6
Also, fix a type in "namespace". Change-Id: I3e5d1d49c765a035217437c0635b12dc28e41bf6
2025-04-24Introduce attribute::signed_constantTom Tromey1-0/+10
This introduces a new method, attribute::signed_constant. This should be used wherever DWARF specifies a signed integer constant, or where this is implied by the context. It properly handles sign-extension for DW_FORM_data*. To my surprise, there doesn't seem to be a pre-existing sign-extension function. I've added one to common-utils.h alongside the align functions. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32680
2025-04-24gdb: move remote arg splitting and joining into gdbsupport/Andrew Burgess4-6/+107
This is a refactoring commit. When passing inferior arguments to gdbserver we have two actions that need to be performed, splitting and joining. On the GDB side, we take the inferior arguments, a single string, and split the string into a list of individual arguments. These are then sent to gdbserver over the remote protocol. On the gdbserver side we receive the list of individual arguments and join these back together into a single inferior argument string. In the next commit I plan to add some unit testing for this remote argument passing process. Ideally, for unit testing, we need the code being tested to be located in some easily callable function, rather than being inline at the site of use. So in this commit I propose to move the splitting and joining logic out into a separate file, we can then use this within GDB and gdbserver when passing arguments between GDB and gdbserver, but we can also call the same functions for some unit testing. In this commit I'm not adding the unit tests, they will be added next, so for now there should be no user visible changes after this commit. Tested-By: Guinevere Larsen <guinevere@redhat.com>
2025-04-09gdbsupport: fix Makefile.in copyright datesSimon Marchi1-1/+1
Commit d01e823438 ("Update copyright dates to include 2025") incorrectly changed the dates in Makefile.in. Re-run `autoreconf` in the gdbsupport directory to fix that up. Change-Id: Ifcdb6f2257e7a456439dfc3e7848db934a4b16b4
2025-04-08Update copyright dates to include 2025Tom Tromey153-153/+153
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-31[gdb] Check strpbrk against nullptrTom de Vries1-1/+1
In noticed two occurrences of "if (strpbrk (...))". Fix this style issue by checking against nullptr.
2025-03-31gdbsupport/common-inferior.c: Fix mingw buildLancelot SIX1-1/+1
A recent change (512ca2fca4b "gdb: split up construct_inferior_arguments") introduced a build failure for mingw: CXX common-inferior.o .../gdb/gdbsupport/common-inferior.cc: In function ‘std::string escape_characters(const char*, const char*)’: .../gdb/gdbsupport/common-inferior.cc:62:20: error: ‘argv’ was not declared in this scope; did you mean ‘arg’? 62 | if (strpbrk (argv[i], special)) | ^~~~ | arg .../gdb/gdbsupport/common-inferior.cc:62:25: error: ‘i’ was not declared in this scope 62 | if (strpbrk (argv[i], special)) | ^ This patch fixes that. Change-Id: I07ade607bc4516627b433085b07d9d198d8e4b4a Approved-By: Tom de Vries <tdevries@suse.de>
2025-03-31[pre-commit] Add codespell hookTom de Vries1-4/+0
Add a pre-commit codespell hook for directories gdbsupport and gdbserver, which are codespell-clean: ... $ pre-commit run codespell --all-files codespell................................................................Passed ... A non-trivial question is where the codespell configuration goes. Currently we have codespell sections in gdbsupport/setup.cfg and gdbserver/setup.cfg, but codespell doesn't automatically use those because the pre-commit hook runs codespell at the root of the repository. A solution would be to replace those 2 setup.cfg files with a setup.cfg in the root of the repository. Not ideal because generally we try to avoid adding files related to subdirectories at the root. Another solution would be to add two codespell hooks, one using --config gdbsupport/setup.cfg and one using --config gdbserver/setup.cfg, and add a third one once we start supporting gdb. Not ideal because it creates duplication, but certainly possible. I went with the following solution: a setup.cfg file in gdb/contrib (alongside codespell-ignore-words.txt) which is used for both gdbserver and gdbsupport. So, what can this new setup do for us? Let's demonstrate by simulating a typo: ... $ echo "/* aways */" >> gdbsupport/agent.cc ... We can check unstaged changes before committing: ... $ pre-commit run codespell --all-files codespell................................................................Failed - hook id: codespell - exit code: 65 gdbsupport/agent.cc:282: aways ==> always, away ... Likewise, staged changes (no need for the --all-files): ... $ git add gdbsupport/agent.cc $ pre-commit run codespell codespell................................................................Failed - hook id: codespell - exit code: 65 gdbsupport/agent.cc:282: aways ==> always, away ... Or we can try to commit, and run into the codespell failure: ... $ git commit -a black................................................(no files to check)Skipped flake8...............................................(no files to check)Skipped isort................................................(no files to check)Skipped codespell................................................................Failed - hook id: codespell - exit code: 65 gdbsupport/agent.cc:282: aways ==> always, away check-include-guards.................................(no files to check)Skipped ... which makes the commit fail. Approved-By: Tom Tromey <tom@tromey.com>
2025-03-27[gdb/contrib] Drop two words from codespell-ignore-words.txtTom de Vries2-2/+2
Tom Tromey mentioned [1] that the words "invokable" and "useable" present in codespell-ignore-words.txt should be dropped. Do so and fix the following typos: ... $ codespell --config gdbsupport/setup.cfg gdbsupport gdbsupport/common-debug.h:218: invokable ==> invocable gdbsupport/event-loop.cc:84: useable ==> usable ... Approved-By: Tom Tromey <tom@tromey.com> [1] https://sourceware.org/pipermail/gdb-patches/2025-March/216584.html
2025-03-27[gdbsupport] Ignore pathc in codespell check in gdb_tilde_expand.ccTom de Vries1-2/+2
Ignore the following codespell detections: ... $ codespell --config gdbsupport/setup.cfg gdbsupport gdbsupport/gdb_tilde_expand.cc:54: pathc ==> patch gdbsupport/gdb_tilde_expand.cc:99: pathc ==> patch ... by adding codespell:ignore comments.
2025-03-27[gdbsupport] Fix a typo in common-debug.hTom de Vries1-1/+1
Fix a typo: ... $ codespell --config gdbsupport/setup.cfg gdbsupport/common-debug.h gdbsupport/common-debug.h:109: re-used ==> reused ...
2025-03-20[gdbsupport] Fix typo in common-inferior.hTom de Vries1-1/+1
Fix the following typo: ... $ codespell --config gdbsupport/setup.cfg gdbsupport/ gdbsupport/common-inferior.h:57: elemets ==> elements ...
2025-03-18gdb: split up construct_inferior_argumentsAndrew Burgess2-46/+107
The function construct_inferior_arguments (gdbsupport/common-inferior.cc) currently escapes all special shell characters. After this commit there will be two "levels" of quoting: 1. The current "full" quoting, where all posix shell special characters are quoted, and 2. a new "reduced" quoting, where only the characters that GDB sees as special (quotes and whitespace) are quoted. After this, almost all construct_inferior_arguments calls will use the "full" quoting, which is the current quoting. The "reduced" quoting will be used in this commit to restore the behaviour that was lost in the previous commit (more details below). In the future, the reduced quoting will be useful for some additional inferior argument that I have planned. I already posted my full inferior argument work here: https://inbox.sourceware.org/gdb-patches/cover.1730731085.git.aburgess@redhat.com But that series is pretty long, and wasn't getting reviewed, so I'm posted the series in parts now. Before the previous commit, GDB behaved like this: $ gdb -eiex 'set startup-with-shell off' --args /tmp/exec '$FOO' (gdb) show args Argument list to give program being debugged when it is started is "$FOO". Notice that with 'startup-with-shell' off, the argument was left as just '$FOO'. But after the previous commit, this changed to: $ gdb -eiex 'set startup-with-shell off' --args /tmp/exec '$FOO' (gdb) show args Argument list to give program being debugged when it is started is "\$FOO". Now the '$' is escaped with a backslash. This commit restores the original behaviour, as this is (currently) the only way to unquoted shell special characters into arguments from the GDB command line. The series that I listed above includes a new command line option for GDB which provides a better approach for controlling the quoting of special shell characters, but that work requires these patches to be merged first. I've split out the core of construct_inferior_arguments into the new function escape_characters, which takes a set of characters to escape. Then the two functions escape_shell_characters and escape_gdb_characters call escape_characters with the appropriate character sets. Finally, construct_inferior_arguments, now takes a boolean which indicates if we should perform full shell escaping, or just perform the reduced escaping. I've updated all uses of construct_inferior_arguments to pass a suitable value to indicate what escaping to perform (mostly just 'true', but one case in main.c is different), also I've updated inferior::set_args to take the same boolean flag, and pass it through to construct_inferior_arguments. Tested-By: Guinevere Larsen <guinevere@redhat.com>
2025-03-18gdb: remove the !startup_with_shell path from construct_inferior_argumentsAndrew Burgess1-67/+41
In the commit: commit 0df62bf09ecf242e3a932255d24ee54407b3c593 Date: Fri Oct 22 07:19:33 2021 +0000 gdb: Support some escaping of args with startup-with-shell being off nat/fork-inferior.c was updated such that when we are starting an inferior without a shell we now remove escape characters. The benefits of this are explained in that commit, but having made this change we can now make an additional change. Currently, in construct_inferior_arguments, when startup_with_shell is false we construct the inferior argument string differently than when startup_with_shell is true; when true we apply some escaping to special shell character, when false we don't. This commit simplifies construct_inferior_arguments by removing the !startup_with_shell case, and instead we now apply escaping in all cases. This is fine because, thanks to the above commit the escaping will be correctly removed again when we call into nat/fork-inferior.c. We should think of construct_inferior_arguments and nat/fork-inferior.c as needing to cooperate in order for argument handling to work correctly. construct_inferior_arguments converts a list of separate arguments into a single string, and nat/fork-inferior.c splits that single string back into a list of arguments. It is critical that, if nat/fork-inferior.c is expecting to remove a "layer" of escapes, then construct_inferior_arguments must add that expected "layer", otherwise, we end up stripping more escapes than expected. The great thing (I think) about the new configuration, is that GDB no longer cares about startup_with_shell at the point the arguments are being setup. We only care about startup_with_shell at the point that the inferior is started. This means that a user can set the inferior arguments, and then change the startup-with-shell setting, and GDB will do what they expect. Under the previous system, where construct_inferior_arguments changed its behaviour based on startup_with_shell, the user had to change the setting, and then set the arguments, otherwise, GDB might not do what they expect. There is one slight issue with this commit though, which will be addressed by the next commit. For GDB's native targets construct_inferior_arguments is reached via two code paths; first when GDB starts and we combine arguments from the command line, and second when the Python API is used to set the arguments from a sequence. It's the command line argument handling which we are interested in. Consider this: $ gdb --args /tmp/exec '$FOO' (gdb) show args Argument list to give program being debugged when it is started is "\$FOO". Notice that the argument has become \$FOO, the '$' is now quoted. This is because, by quoting the argument in the shell command that started GDB, GDB was passed a literal $FOO with no quotes. In order to ensure that the inferior sees this same value, GDB added the extra escape character. When GDB starts with a shell we pass \$FOO, which results in the inferior seeing a literal $FOO. But what if the user _actually_ wanted to have the shell GDB uses to start the inferior expand $FOO? Well, it appears this can't be done from the command line, but from the GDB prompt we can just do: (gdb) set args $FOO (gdb) show args Argument list to give program being debugged when it is started is "$FOO". And now the inferior will see the shell expanded version of $FOO. It might seem like we cannot achieve the same result from the GDB command line, however, it is possible with this trick: $ gdb -eiex 'set startup-with-shell off' --args /tmp/exec '$FOO' (gdb) show args Argument list to give program being debugged when it is started is "$FOO". (gdb) show startup-with-shell Use of shell to start subprocesses is off. And now the $FOO is not escaped, but GDB is no longer using a shell to start the inferior, however, we can extend our command line like this: $ gdb -eiex 'set startup-with-shell off' \ -ex 'set startup-with-shell on' \ --args /tmp/exec '$FOO' (gdb) show args Argument list to give program being debugged when it is started is "$FOO". (gdb) show startup-with-shell Use of shell to start subprocesses is on. Use an early-initialisation option to disable startup-with-shell, this is done before command line argument processing, then a normal initialisation option turns startup-with-shell back on after GDB has processed the command line arguments! Is this useful? Yes, absolutely. Is this a good user experience? Absolutely not. And I plan to add a new command line option to GDB (and gdbserver) that will allow users to achieve the same result (this trick doesn't work in gdbserver as there's no early-initialisation there) without having to toggle the startup-with-shell option. The new option can be found in the series here: https://inbox.sourceware.org/gdb-patches/cover.1730731085.git.aburgess@redhat.com The problem is that, that series is pretty long, and getting it reviewed is just not possible. So instead I'm posting the individual patches in smaller blocks, to make reviews easier. So, what's the problem? Well, by removing the !startup_with_shell code path from GDB, there is no longer a construct_inferior_arguments code path that doesn't quote inferior arguments, and so there's no longer a way, from the command line, to set an unquoted '$FOO' as an inferior argument. Obviously, this can still be done from GDB's CLI prompt. The trick above is completely untested, so this regression isn't going to show up in the testsuite. And the breakage is only temporary. In the next commit I'll add a fix which restores the above trick. Of course, I hope that this fix will itself, only be temporary. Once the new command line options that I mentioned above are added, then the fix I add in the next commit can be removed, and user should start using the new command line option. After this commit a whole set of tests that were added as xfail in the above commit are now passing. A change similar to this one can be found in this series: https://inbox.sourceware.org/gdb-patches/20211022071933.3478427-1-m.weghorn@posteo.de/ which I reviewed before writing this patch. I don't think there's any one patch in that series that exactly corresponds with this patch though, so I've listed the author of the original series as co-author on this patch. Co-Authored-By: Michael Weghorn <m.weghorn@posteo.de> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28392 Tested-By: Guinevere Larsen <guinevere@redhat.com>
2025-03-17gdbsupport: add some -Wunused-* warning flagsSimon Marchi2-0/+12
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-17gdbsupport: re-format and sort warning flagsSimon Marchi2-24/+40
Put them one per line and sort alphabetically. Change-Id: Idb6947d444dc6e556a75645b04f97a915bba7a59 Approved-By: Tom Tromey <tom@tromey.com>
2025-03-12Use correct types in string-set.hTom Tromey1-2/+2
My earlier patch to introduce string-set.h used the wrong type in the hash functions. This patch fixes the error.
2025-03-10Add string cache and use it in cooked indexTom Tromey1-0/+129
The cooked index needs to allocate names in some cases -- when canonicalizing or when synthesizing Ada package names. This process currently uses a vector of unique_ptrs to manage the memory. Another series I'm writing adds another spot where this allocation must be done, and examining the result showed that certain names were allocated multiple times. To clean this up, this patch introduces a string cache object and changes the cooked indexer to use it. I considered using bcache here, but bcache doesn't work as nicely with string_view -- because bcache is fundamentally memory-based, a temporary copy of the contents must be made to ensure that bcache can see the trailing \0. Furthermore, writing a custom class lets us avoid another copy when canonicalizing C++ names. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2025-03-10Fix check-include-guards.pyTom Tromey1-3/+3
I noticed that check-include-guards.py doesn't error in certain situations -- but in situations where the --update flag would cause a file to be changed. This patch changes the script to issue an error for any discrepancy. It also fixes the headers that weren't correct. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2025-03-06[gdbsupport] Add codespell section in setup.cfgTom de Vries1-0/+4
When running codespell on gdbsupport, we get: ... $ codespell gdbsupport gdbsupport/common-debug.h:218: invokable ==> invocable gdbsupport/osabi.h:51: configury ==> configurable gdbsupport/ChangeLog-2020-2021:344: ro ==> to, row, rob, rod, roe, rot gdbsupport/ChangeLog-2020-2021:356: contaning ==> containing gdbsupport/common.m4:19: configury ==> configurable gdbsupport/Makefile.am:97: configury ==> configurable gdbsupport/Makefile.in:811: configury ==> configurable gdbsupport/event-loop.cc:84: useable ==> usable gdbsupport/configure:15904: assigment ==> assignment ... Some of these files we want to skip in a spell check, because they're generated. We also want to skip ChangeLogs, we don't actively maintain those. Add a file gdbsupport/setup.cfg with a codespell section, that skips those files. The choice for setup.cfg (rather than say .codespellrc) comes from the presence of gdb/setup.cfg. That leaves invokable, configury and useable. I think configury is a common expression in our context, and for invokable and useable I don't manage to find out whether they really need rewriting, so I'd rather leave them alone for now. Add these to a file gdb/contrib/codespell-ignore-words.txt, and use the file in gdbsupport/setup.cfg. This makes the directory codespell clean: ... $ codespell --config gdbsupport/setup.cfg gdbsupport $ ... Because codespell seems to interpret filenames relative to the working directory rather than relative to the config file, and the filename used in gdbsupport/setup.cfg is gdb/contrib/codespell-ignore-words.txt, this simple invocation doesn't work: ... $ cd gdbsupport $ codespell ... because codespell can't find gdbsupport/gdb/contrib/codespell-ignore-words.txt. We could fix this by using ../gdb/contrib/codespell-ignore-words.txt instead, but likewise that breaks this invocation: ... $ codespell --config gdbsupport/setup.cfg gdbsupport ... I can't decide which one is worse, so I'm sticking with gdb/contrib/codespell-ignore-words.txt for now. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2025-03-06[gdbsupport] Fix some typosTom de Vries3-4/+4
Fix typos: ... mentionning -> mentioning suppported -> supported aligment -> alignment ...
2025-02-27gdb, gdbserver, gdbsupport: fix some namespace comment formattingSimon Marchi2-9/+9
I noticed a // namespace selftests comment, which doesn't follow our comment formatting convention. I did a find & replace to fix all the offenders. Change-Id: Idf8fe9833caf1c3d99e15330db000e4bab4ec66c
2025-02-25Fix mkdir_recursive on windows when CWD is rootCiaran Woodward1-0/+7
On windows, when creating a directory with an absolute path, mkdir_recursive would start by trying to make 'C:'. On windows, this has a special meaning, which is "the current directory on the C drive". So the first thing it tries to do is create the current directory. Most of the time, this fails with EEXIST, so the function continues as expected. However if the current directory is C:/, trying to create that causes EPERM, which causes the function to prematurely terminate. (The same applies for any drive letter.) This patch resolves this issue, by skipping the drive letter so that it is never sent to the mkdir call. Approved-By: Tom Tromey <tom@tromey.com>
2025-02-10gdbsupport: add gdb::make_array_view overload to create from an arraySimon Marchi1-0/+9
I think this overload will be useful for the following reasons. Consider a templated function like this: template <typename T> void func(gdb::array_view<T> view) {} Trying to pass an array to this function doesn't work, as template argument deduction fails: test.c:698:8: error: no matching function for call to ‘func(int [12])’ 698 | func (array); | ~~~~~^~~~~~~ test.c:686:6: note: candidate: ‘template<class T> void func(gdb::array_view<U>)’ 686 | void func(gdb::array_view<T> view) {} | ^~~~ test.c:686:6: note: template argument deduction/substitution failed: test.c:698:8: note: mismatched types ‘gdb::array_view<U>’ and ‘int*’ 698 | func (array); | ~~~~~^~~~~~~ Similarly, trying to compare a view with an array doesn't work. This: int array[12]; gdb::array_view<int> view; if (view == array) {} ... fails with: test.c:698:8: error: no matching function for call to ‘func(int [12])’ 698 | func (array); | ~~~~~^~~~~~~ test.c:686:6: note: candidate: ‘template<class T> void func(gdb::array_view<U>)’ 686 | void func(gdb::array_view<T> view) {} | ^~~~ test.c:686:6: note: template argument deduction/substitution failed: test.c:698:8: note: mismatched types ‘gdb::array_view<U>’ and ‘int*’ 698 | func (array); | ~~~~~^~~~~~~ With this new overload, we can do: func (gdb::make_array_view (array)); and if (view == gdb::make_array_view (array)) {} This is not ideal, I wish that omitting `gdb::make_array_view` would just work, but at least it allows creating an array view and have the element type automatically deduced from the array type. If someone knows how to make these cases "just work", I would be happy to know how. Change-Id: I6a71919d2d5a385e6826801d53f5071b470fef5f Approved-By: Tom Tromey <tom@tromey.com>
2025-01-29gdbserver: introduce and use new gdb::argv_vec classAndrew Burgess1-0/+139
In gdbserver there are a couple of places where we perform manual memory management using a 'std::vector<char *>' with the vector owning the strings within it. We need to take care to call free_vector_argv() before leaving the scope to cleanup the strings within the vector. This commit introduces a new class gdb::argv_vec which wraps around a 'std::vector<char *>' and owns the strings within the vector, taking care to xfree() them when the gdb::argv_vec is destroyed. Right now I plan to use this class in gdbserver. But this class will also be used to address review feedback on this commit: https://inbox.sourceware.org/gdb-patches/72227f1c5a2e350ca70b2151d1b91306a0261bdc.1736860317.git.aburgess@redhat.com where I tried to introduce another 'std::vector<char *>' which owns the strings. That patch will be updated to use gdb::argv_vec instead. The obvious question is, instead of introducing this new class, could we change the APIs to avoid having a std::vector<char *> that owns the strings? Could we use 'std::vector<std::string>' or 'std::vector<gdb::unique_xmalloc_ptr<char>>' instead? The answer is yes we could. I originally posted this larger patch set: https://inbox.sourceware.org/gdb-patches/cover.1730731085.git.aburgess@redhat.com however, getting a 14 patch series reviewed is just not possible, so instead, I'm posting the patches one at a time. The earlier patch I mentioned is pulled from the larger series. The larger series already includes changes to gdbserver which removes the need for the 'std::vector<char *>', however, getting those changes in depends (I think) on the patch I mention above. Hence we have a bit of a circular dependency. My proposal is to merge this patch (adding gdb::argv_vec) and make use of it in gdbserver. Then I'll update the patch above to also use gdb::argv_vec, which will allow the above patch to get reviewed and merged. Then I'll post, and hopefully merge additional patches from my larger inferior argument series, which will remove the need for gdb::argv_vec from gdbserver. At this point, the only use of gdb::argv_vec will be in the above patch, where I think it will remain, as I don't think that location can avoid using 'std::vector<char *>'. Approved-By: Tom Tromey <tom@tromey.com>
2025-01-10[gdb/build, c++20] Fix build with gcc 10Tom de Vries1-2/+2
With gcc 10 and -std=c++20, we run into the same problem as reported in commit 6feae66da1d ("[gdb/build, c++20] Handle deprecated std::allocator::construct"). The problem was fixed using: ... -template<typename T, typename A = std::allocator<T>> +template<typename T, + typename A +#if __cplusplus >= 202002L + = std::pmr::polymorphic_allocator<T> +#else + = std::allocator<T> +#endif + > ... but that doesn't work for gcc 10, because it defines __cplusplus differently: ... $ echo | g++-10 -E -dD -x c++ - -std=c++20 2>&1 | grep __cplusplus #define __cplusplus 201709L $ echo | g++-11 -E -dD -x c++ - -std=c++20 2>&1 | grep __cplusplus #define __cplusplus 202002L ... Fix this by using the library feature test macro __cpp_lib_polymorphic_allocator [1], which is undefined for c++17 and defined for c++20: ... $ echo | g++-10 -E -dD -x c++ - -include memory_resource -std=c++17 2>&1 \ | grep __cpp_lib_polymorphic_allocator $ echo | g++-10 -E -dD -x c++ - -include memory_resource -std=c++20 2>&1 \ | grep __cpp_lib_polymorphic_allocator #define __cpp_lib_polymorphic_allocator 201902L $ ... A similar problem exists for commit 3173529d7de ("[gdb/guile, c++20] Work around Werror=volatile in libguile.h"). Fix this by testing for 201709L instead. Tested on x86_64-linux, by building gdb with {gcc 10, clang 17.0.6} x {-std=c++17, -std=c++20}. PR build/32503 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32503 Approved-By: Tom Tromey <tom@tromey.com> [1] https://en.cppreference.com/w/cpp/feature_test#cpp_lib_polymorphic_allocator
2025-01-08GDB, gdbserver: Convert regcache_register_size function to methodThiago Jung Bauermann1-15/+5
The regcache_register_size function has one implementation in GDB, and one in gdbserver. Both of them have a gdb::checked_static_cast to their corresponding regcache class. This can be avoided by defining a pure virtual register_size method in the reg_buffer_common class, which is then implemented by the reg_buffer class in GDB, and by the regcache class in gdbserver. Calls to the register_size () function from methods of classes in the reg_buffer_common hierarchy need to be changed to calls to the newly defined method, otherwise the compiler complains that a matching method cannot be found. Co-Authored-By: Simon Marchi <simon.marchi@efficios.com> Approved-By: Simon Marchi <simon.marchi@efficios.com> Reviewed-By: Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> Change-Id: I7f4f74a51e96c42604374e87321ca0e569bc07a3
2025-01-06Simplify traits.h using C++17Tom Tromey1-46/+9
This patch simplifies gdbsupport/traits.h by reusing some C++17 type traits. I kept the local names, since they are generally better. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31423 Approved-By: Simon Marchi <simon.marchi@efficios.com>
2024-12-22Fix -Wenum-constexpr-conversion in enum-flags.hCarlos Galvez1-34/+69
This fixes PR 31331: https://sourceware.org/bugzilla/show_bug.cgi?id=31331 Currently, enum-flags.h is suppressing the warning -Wenum-constexpr-conversion coming from recent versions of Clang. This warning is intended to be made a compiler error (non-downgradeable) in future versions of Clang: https://github.com/llvm/llvm-project/issues/59036 The rationale is that casting a value of an integral type into an enumeration is Undefined Behavior if the value does not fit in the range of values of the enum: https://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1766 Undefined Behavior is not allowed in constant expressions, leading to an ill-formed program. In this case, in enum-flags.h, we are casting the value -1 to an enum of a positive range only, which is UB as per the Standard and thus not allowed in a constexpr context. The purpose of doing this instead of using std::underlying_type is because, for C-style enums, std::underlying_type typically returns "unsigned int". However, when operating with it arithmetically, the enum is promoted to *signed* int, which is what we want to avoid. This patch solves this issue as follows: * Use std::underlying_type and remove the custom enum_underlying_type. * Ensure that operator~ is called always on an unsigned integer. We do this by casting the input enum into std::size_t, which can fit any unsigned integer. We have the guarantee that the cast is safe, because we have checked that the underlying type is unsigned. If the enum had negative values, the underlying type would be signed. This solves the issue with C-style enums, but also solves a hidden issue: enums with underlying type of std::uint8_t or std::uint16_t are *also* promoted to signed int. Now they are all explicitly casted to the largest unsigned int type and operator~ is safe to use. * There is one more thing that needs fix. Currently, operator~ is implemented as follows: return (enum_type) ~underlying(e); After applying ~underlying(e), the result is a very large value, which we then cast to "enum_type". This cast is Undefined Behavior if the large value does not fit in the range of the enum. For C++ enums (scoped and/or with explicit underlying type), the range of the enum is the entire range of the underlying type, so the cast is safe. However, for C-style enums, the range is the smallest bit-field that can hold all the values of the enumeration. So the range is a lot smaller and casting a large value to the enum would invoke Undefined Behavior. To solve this problem, we create a new trait EnumHasFixedUnderlyingType, to ensure operator~ may only be called on C++-style enums. This behavior is roughly the same as what we had on trunk, but relying on different properties of the enums. * Once this is implemented, the following tests fail to compile: CHECK_VALID (true, int, true ? EF () : EF2 ()) This is because it expects the enums to be promoted to signed int, instead of unsigned int (which is the true underlying type). I propose to remove these tests altogether, because: - The comment nearby say they are not very important. - Comparing 2 enums of different type like that is strange, relies on integer promotions and thus hurts readability. As per comments in the related PR, we likely don't want this type of code in gdb code anyway, so there's no point in testing it. - Most importantly, this type of comparison will be ill-formed in C++26 for regular enums, so enum_flags does not need to emulate that. Since this is the only place where the warning was suppressed, remove also the corresponding macro in include/diagnostics.h. The change has been tested by running the entire gdb test suite (make check) and comparing the results (testsuite/gdb.sum) against trunk. No noticeable differences have been observed. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31331 Tested-by: Keith Seitz <keiths@redhat.com> Approved-By: Tom Tromey <tom@tromey.com>
2024-12-18Run check-include-guards.pyTom Tromey81-243/+243
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-12-17gdbsupport: fix a typo in a comment in common-regcache.hTankut Baris Aktemur1-4/+4
Fix a typo. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2024-12-09gdb: allow core file containing special characters on the command lineAndrew Burgess2-0/+26
After the commit: commit 03ad29c86c232484f9090582bbe6f221bc87c323 Date: Wed Jun 19 11:14:08 2024 +0100 gdb: 'target ...' commands now expect quoted/escaped filenames it was no longer possible to pass GDB the name of a core file containing any special characters (white space or quote characters) on the command line. For example: $ gdb -c /tmp/core\ file.core Junk after filename "/tmp/core": file.core (gdb) The problem is that the above commit changed the 'target core' command to expect quoted filenames, so before the above commit a user could write: (gdb) target core /tmp/core file.core [New LWP 2345783] Core was generated by `./mkcore'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x0000000000401111 in ?? () (gdb) But after the above commit the user must write: (gdb) target core /tmp/core\ file.core or (gdb) target core "/tmp/core file.core" This is part of a move to make GDB's filename argument handling consistent. Anyway, the problem with the '-c' command line flag is that it forwards the filename unmodified through to the 'core-file' command, which in turn forwards to the 'target core' command. So when the user, at a shell writes: $ gdb -c "core file.core" this arrives in GDB as the unquoted string 'core file.core' (without the single quotes). GDB then forwards this to the 'core-file' command as if the user had written this at a GDB prompt: (gdb) core-file core file.core Which then fails to parse due to the unquoted white space between 'core' and 'file.core'. The solution I propose is to escape any special characters in the core file name passed from the command line before calling 'core-file' command from main.c. I've updated the corefile.exp test to include a test for passing a core file containing a white space character. While I was at it I've modernised the part of corefile.exp that I was touching.
2024-12-06gdb, gdbserver, gdbsupport: remove some unused gdb_vecs.h includesSimon Marchi1-1/+0
Remove some includes reported as unused by clangd. Add some to files that actually need it. Change-Id: I01c61c174858c1ade5cb54fd7ee1f582b17c3363
2024-12-04[gdb/build] Fix build breaker on mingw-w64Simon Marchi4-0/+31
The mingw-w64 build breaks currently: ... In file included from gdb/cli/cli-cmds.c:58: gdbsupport/eintr.h: In function ‘pid_t gdb::waitpid(pid_t, int*, int)’: gdbsupport/eintr.h:77:35: error: ‘::waitpid’ has not been declared; \ did you mean ‘gdb::waitpid’? 77 | return gdb::handle_eintr (-1, ::waitpid, pid, wstatus, options); | ^~~~~~~ | gdb::waitpid gdbsupport/eintr.h:75:1: note: ‘gdb::waitpid’ declared here 75 | waitpid (pid_t pid, int *wstatus, int options) | ^~~~~~~ ... This is a regression since commit 658a03e9e85 ("[gdbsupport] Add gdb::{waitpid,read,write,close}"), which moved the use of ::waitpid from run_under_shell, where it was used conditionally: ... #if defined(CANT_FORK) || \ (!defined(HAVE_WORKING_VFORK) && !defined(HAVE_WORKING_FORK)) ... #else ... int ret = gdb::handle_eintr (-1, ::waitpid, pid, &status, 0); ... to gdb::waitpid, where it's used unconditionally: ... inline pid_t waitpid (pid_t pid, int *wstatus, int options) { return gdb::handle_eintr (-1, ::waitpid, pid, wstatus, options); } ... Likewise for ::wait. Guard these uses with HAVE_WAITPID and HAVE_WAIT. Reproduced and tested by doing a mingw-w64 cross-build on x86_64-linux. Reported-By: Simon Marchi <simark@simark.ca> Co-Authored-By: Tom de Vries <tdevries@suse.de>
2024-12-02gdb, gdbserver, gdbsupport: flatten and sort some list in configure filesSimon Marchi2-15/+76
This makes the lists easier sort read and modify. There are no changes in the generated config.h files, so I'm confident this brings no functional changes. Change-Id: Ib6b7fc532bcd662af7dbb230070fb1f4fc75f86b
2024-11-25gdbsupport: add unordered_dense.h 4.4.0Simon Marchi3-0/+2105
Add a copy of unordered_dense.h from [1]. This file implements an efficient hash map and hash set with a nice C++ interface (a near drop-in for std::unordered_map and std::unordered_set). This is expected to be used to replace uses of `htab_t`, for improved code readability and type safety. Performance-wise, it is preferred to the std types (std::unordered_map and std::unordered_set) due to it using open addressing vs closed addressing for the std types. I chose this particular implementation because it is simple to use, it's a standalone header and it typically performs well in benchmarks I have seen (e.g. [2]). The license being MIT, my understanding is that it's not a problem to use it and re-distribute it. Add two additional files, gdbsupport/unordered_map.h and gdbsupport/unordered_set.h, which make the map and set offered by gdbsupport/unordered_dense.h available as gdb::unordered_map and gdb::unordered_set. [1] https://github.com/martinus/unordered_dense [2] https://jacksonallan.github.io/c_cpp_hash_tables_benchmark/#conclusion-which-hash-table-to-choose Change-Id: I0c7469ccf9a14540465479e58b2a5140a2440a7d Approved-By: Tom Tromey <tom@tromey.com>
2024-11-23[gdbsupport] Rerun autoreconf -fTom de Vries2-2/+2
Rerun autoreconf -f in gdbsupport, reverting "behaviour" -> "behavior" changes in generated files aclocal.m4 and configure.
2024-11-23[gdb/contrib] Add two rules in common-misspellings.txtTom de Vries3-3/+3
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-11-22gdb: Introduce RAII signal handler setterGuinevere Larsen1-0/+73
This patch is motivated by the wait function for the record-full target, that would install a custom signal handler for SIGINT, but could throw an exception and never reset the SIGINT handler. This is clearly a bad idea, so this patch introduces the class scoped_signal_handler in a new .h file. The file is added to gdbsupport, even though only gdb code is using it, because it feels like an addition that would be useful for more than just directly gdb. The implementation of the RAII class is based on the implementation on gdb/utils.c. That is, it uses preprocessor ifdefs to probe for sigaction support, and uses it if possible, defaulting to a raw call to signal only if sigaction isn't supported. sigaction is preferred based on the "portability" section of the manual page for the signal function. There are 3 places where this class can just be dropped in, gdb/record-full.c, gdb/utils.c and gdb/extension.c. This third place already had a specialized RAII signal handler setter, but it is substituted for the new general purpose one. Approved-By: Tom Tromey <tom@tromey.com>
2024-11-22[gdbsupport] Handle EINTR in event-pipe.ccTom de Vries1-13/+8
Use gdb syscall wrappers to handle EINTR in event-pipe.cc. Tested on aarch64-linux.
2024-11-22[gdb] Handle EINTR in ser-event.cTom de Vries1-0/+11
Use gdb syscall wrappers to handle EINTR in ser-event.c. Tested on aarch64-linux.
2024-11-22[gdb] Add gdb::waitTom de Vries1-0/+6
Add gdb::wait, and use it in gdb/procfs.c, making sure that EINTR is handled. Tested on x86_64-linux.
generated by cgit v1.1 at 2025-07-10 15:27:15 +0000