| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
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
|
|
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>
|
|
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
|
|
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>
|
|
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.
|
|
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>
|
|
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>
|
|
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>
|
|
Also, fix a type in "namespace".
Change-Id: I3e5d1d49c765a035217437c0635b12dc28e41bf6
|
|
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
|
|
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>
|
|
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
|
|
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>
|
|
In noticed two occurrences of "if (strpbrk (...))".
Fix this style issue by checking against nullptr.
|
|
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>
|
|
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>
|
|
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
|
|
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.
|
|
Fix a typo:
...
$ codespell --config gdbsupport/setup.cfg gdbsupport/common-debug.h
gdbsupport/common-debug.h:109: re-used ==> reused
...
|
|
Fix the following typo:
...
$ codespell --config gdbsupport/setup.cfg gdbsupport/
gdbsupport/common-inferior.h:57: elemets ==> elements
...
|
|
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>
|
|
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>
|
|
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>
|
|
Put them one per line and sort alphabetically.
Change-Id: Idb6947d444dc6e556a75645b04f97a915bba7a59
Approved-By: Tom Tromey <tom@tromey.com>
|
|
My earlier patch to introduce string-set.h used the wrong type in the
hash functions. This patch fixes the error.
|
|
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>
|
|
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>
|
|
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>
|
|
Fix typos:
...
mentionning -> mentioning
suppported -> supported
aligment -> alignment
...
|
|
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
|
|
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>
|
|
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>
|
|
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>
|
|
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
|
|
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
|
|
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>
|
|
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>
|
|
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>
|
|
Fix a typo.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
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.
|
|
Remove some includes reported as unused by clangd. Add some to files
that actually need it.
Change-Id: I01c61c174858c1ade5cb54fd7ee1f582b17c3363
|
|
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>
|
|
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
|
|
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>
|
|
Rerun autoreconf -f in gdbsupport, reverting "behaviour" -> "behavior" changes
in generated files aclocal.m4 and configure.
|
|
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
|
|
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>
|
|
Use gdb syscall wrappers to handle EINTR in event-pipe.cc.
Tested on aarch64-linux.
|
|
Use gdb syscall wrappers to handle EINTR in ser-event.c.
Tested on aarch64-linux.
|
|
Add gdb::wait, and use it in gdb/procfs.c, making sure that EINTR is handled.
Tested on x86_64-linux.
|
