| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This commit is the result of the following actions:
- Running gdb/copyright.py to update all of the copyright headers to
include 2024,
- Manually updating a few files the copyright.py script told me to
update, these files had copyright headers embedded within the
file,
- Regenerating gdbsupport/Makefile.in to refresh it's copyright
date,
- Using grep to find other files that still mentioned 2023. If
these files were updated last year from 2022 to 2023 then I've
updated them this year to 2024.
I'm sure I've probably missed some dates. Feel free to fix them up as
you spot them.
|
|
Similar to the previous commit, this commit ensures that the dwarf-5
index files are generated identically as the number of worker-threads
changes.
Building the dwarf-5 index makes use of a closed hash table, the
bucket_hash local within debug_names::build(). Entries are added to
bucket_hash from m_name_to_value_set, which, in turn, is populated
by calls to debug_names::insert() in write_debug_names. The insert
calls are ordered based on the entries within the cooked_index, and
the ordering within cooked_index depends on the number of worker
threads that GDB is using.
My proposal is to sort each chain within the bucket_hash closed hash
table prior to using this to build the dwarf-5 index.
The buckets within bucket_hash will always have the same ordering (for
a given GDB build with a given executable), and by sorting the chains
within each bucket, we can be sure that GDB will see each entry in a
deterministic order.
I've extended the index creation test to cover this case.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
It was observed that changing the number of worker threads that GDB
uses (maintenance set worker-threads NUM) would have an impact on the
layout of the generated gdb-index.
The cause seems to be how the CU are distributed between threads, and
then symbols that appear in multiple CU can be encountered earlier or
later depending on whether a particular CU moves between threads.
I certainly found this behaviour was reproducible when generating an
index for GDB itself, like:
gdb -q -nx -nh -batch \
-eiex 'maint set worker-threads NUM' \
-ex 'save gdb-index /tmp/'
And then setting different values for NUM will change the generated
index.
Now, the question is: does this matter?
I would like to suggest that yes, this does matter. At Red Hat we
generate a gdb-index as part of the build process, and we would
ideally like to have reproducible builds: for the same source,
compiled with the same tool-chain, we should get the exact same output
binary. And we do .... except for the index.
Now we could simply force GDB to only use a single worker thread when
we build the index, but, I don't think the idea of reproducible builds
is that strange, so I think we should ensure that our generated
indexes are always reproducible.
To achieve this, I propose that we add an extra step when building the
gdb-index file. After constructing the initial symbol hash table
contents, we will pull all the symbols out of the hash, sort them,
then re-insert them in sorted order. This will ensure that the
structure of the generated hash will remain consistent (given the same
set of symbols).
I've extended the existing index-file test to check that the generated
index doesn't change if we adjust the number of worker threads used.
Given that this test is already rather slow, I've only made one change
to the worker-thread count. Maybe this test should be changed to use
a smaller binary, which is quicker to load, and for which we could
then try many different worker thread counts.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
I noticed in passing that out algorithm for generating the gdb-index
file is incorrect. When building the hash table in add_index_entry we
count every incoming entry rehash when the number of entries gets too
large. However, some of the incoming entries will be duplicates,
which don't actually result in new items being added to the hash
table.
As a result, we grow the gdb-index hash table far too often.
With an unmodified GDB, generating a gdb-index for GDB, I see a file
size of 90M, with a hash usage (in the generated index file) of just
2.6%.
With a patched GDB, generating a gdb-index for the _same_ GDB binary,
I now see a gdb-index file size of 30M, with a hash usage of 41.9%.
This is a 67% reduction in gdb-index file size.
Obviously, not every gdb-index file is going to see such big savings,
however, the larger a program, and the more symbols that are
duplicated between compilation units, the more GDB would over count,
and so, over-grow the index.
The gdb-index hash table we create has a minimum size of 1024, and
then we grow the hash when it is 75% full, doubling the hash table at
that time. Given this, then we expect that either:
a. The hash table is size 1024, and less than 75% full, or
b. The hash table is between 37.5% and 75% full.
I've include a test that checks some of these constraints -- I've not
bothered to check the upper limit, and over full hash table isn't
really a problem here, but if the fill percentage is less than 37.5%
then this indicates that we've done something wrong (obviously, I also
check for the 1024 minimum size).
Approved-By: Tom Tromey <tom@tromey.com>
|
|
7.5.0 some more
With a gdb build with -O2 -flto=auto and gcc 7.5.0 and test-case
gdb.gdb/python-helper.exp I run into:
...
(outer-gdb) continue^M
Continuing.^M
print 1^M
^M
Thread 1 "xgdb" hit Breakpoint 2, \
_Z11value_printP5valueP7ui_filePK19value_print_options (val=0x22e2590, \
stream=0x1f65480, options=0x7fffffffcdc0) at gdb/valprint.c:1193^M
1193 {^M
(outer-gdb) FAIL: gdb.gdb/python-helper.exp: hit breakpoint in outer gdb
...
This is the "value_print" variant of the problem with "c_print_type" I fixed
in commit 0d332f11122 ("[gdb/testsuite] Fix gdb.gdb/python-helper.exp with -O2
-flto=auto and gcc 7.5.0").
Fix this likewise.
Tested on x86_64-linux.
|
|
With a gdb build with -O2 -flto=auto using gcc 7.5.0, I run into:
...
(gdb) ptype global_c^M
^M
Thread 1 "xgdb" hit Breakpoint 3, \
_Z12c_print_typeP4typePKcP7ui_fileii8languagePK18type_print_options () at \
gdb/c-typeprint.c:175^M
175 {^M
(outer-gdb) FAIL: gdb.gdb/python-helper.exp: hit breakpoint in outer gdb again
...
This is a problem with the debug info, which marks the CU containing the
function declaration as C rather than C++. This is fixed in gcc 8 and later.
Work around this compiler problem by allowing the mangled name.
Tested on x86_64-linux.
PR testsuite/30648
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30648
|
|
When editing gdb.gdb/python-helper.exp, auto-indent is broken in my editor
(emacs).
The problem is that this:
...
if { 1 } {
foo "{" "}"<ENTER>bar
}
...
produces this:
...
if { 1 } {
foo "{" "}"
bar
}
...
Note that this doesn't happen for "{}".
Fix this by using "\{" and "\}".
Tested on x86_64-linux.
|
|
On openSUSE Leap 15.4, with gcc 7.5.0, when building gdb with
-O2 -g -flto=auto, I run into:
...
FAIL: gdb.gdb/python-helper.exp: hit breakpoint in outer gdb
FAIL: gdb.gdb/python-helper.exp: print integer from DWARF info
FAIL: gdb.gdb/python-helper.exp: print *type->main_type
...
Fix the first two FAILs by using $bkptno_numopt_re.
The last FAIL is due to:
...
(outer-gdb) print *type->main_type^M
A syntax error in expression, near `->main_type'.^M
(outer-gdb) FAIL: gdb.gdb/python-helper.exp: print *type->main_type
...
because:
...
(outer-gdb) print type^M
Attempt to use a type name as an expression^M
...
Fix this by making the test unresolved if "print type" or
"print type->main_type" doesn't succeed.
On openSUSE Tumbleweed, with gcc 13.0.1, when building gdb with
-O2 -g -flto=auto, I run into timeouts due to the breakpoint in c_print_type
not hitting. Fix this by detecting the situation and bailing out.
Tested on x86_64-linux.
|
|
Whenever we start gdb in the testsuite, we have the rather verbose:
...
$ gdb
GNU gdb (GDB) 14.0.50.20230405-git
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".
(gdb)
...
This makes gdb.log longer than necessary and harder to read.
We do need to test that the output is produced, but that should be limited to
one or a few test-cases.
Fix this by adding -q to INTERNAL_GDBFLAGS, such that we simply have:
...
$ gdb -q
(gdb)
...
Tested on x86_64-linux.
|
|
Fix test-case gdb.gdb/unittest.exp for remote host, by:
- disabling the completion tests if readline is not used, and
- not using with_gdb_cwd $dir for remote host (because it does
not support changing to ".").
Tested on x86_64-linux.
|
|
The type allocation changes introduced a failure in python-helper.exp
that I did not notice. The bug is that, with these patches,
arch-allocated integer types have a TYPE_SPECIFIC_INT object attached.
This patch updates the test to allow this.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30253
|
|
This changes many tests to use 'require' when checking target_info.
In a few spots, the require is hoisted to the top of the file, to
avoid doing any extra work when the test is going to be skipped
anyway.
|
|
When debugging GDB, I find it a bit tedious to inspect htab_t objects.
It is possible to find the entries by poking at the fields, but it's
annoying to do each time. I think a pretty printer would help. Add a
basic one to gdb-gdb.py.
The pretty printer advertises itself as "array-like", and the result
looks like:
(top-gdb) p bfcache
$3 = htab_t with 3 elements = {0x6210003252a0, 0x62100032caa0, 0x62100033baa0}
The htab_t itself doesn't know about the type of pointed objects. But
it's easy enough to cast the addresses to the right type to use them:
(top-gdb) print *((btrace_frame_cache *) 0x6210003252a0)
$6 = {tp = 0x61700002ed80, frame = 0x6210003251e0, bfun = 0x62000000b390}
Change-Id: Ia692e3555fe7a117b7ec087840246b1260a704c6
Reviewed-By: Tom Tromey <tom@tromey.com>
|
|
This renames all the fields of struct value, in preparation for the
coming changes.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
Following commit 4e2a80ba606 ("gdb/testsuite: expect SIGSEGV from top
GDB spawn id"), the next failure I get in gdb.gdb/selftest.exp, using
the native-extended-gdbserver, is:
(gdb) PASS: gdb.gdb/selftest.exp: send ^C to child process
signal SIGINT
Continuing with signal SIGINT.
FAIL: gdb.gdb/selftest.exp: send SIGINT signal to child process (timeout)
The problem is that in this gdb_test_multiple:
set description "send SIGINT signal to child process"
gdb_test_multiple "signal SIGINT" "$description" {
-re "^signal SIGINT\r\nContinuing with signal SIGINT.\r\nQuit\r\n.* $" {
pass "$description"
}
}
The "Continuing with signal SIGINT" portion is printed by the top GDB,
while the Quit portion is printed by the bottom GDB. As the
gdb_test_multiple is written, it expects both the the top GDB's spawn
id.
Fix this by splitting the gdb_test_multiple in two. The first one
expects the "Continuing with signal SIGINT" from the top GDB. The
second one expect "Quit" and the "(xgdb)" prompt from
$inferior_spawn_id. When debugging natively, this spawn id will be the
same as the top GDB's spawn id, but it's different when debugging with
GDBserver.
Change-Id: I689bd369a041b48f4dc9858d38bf977d09600da2
|
|
When testing with the native-extended-gdbserver, I get:
Thread 1 "xgdb" received signal SIGSEGV, Segmentation fault.
0x00007ffff6d828f2 in GC_find_limit_with_bound () from /usr/lib/x86_64-linux-gnu/libgc.so.1
(gdb) FAIL: gdb.gdb/selftest.exp: xgdb is at prompt
This is because the -re that is supposed to match this SIGSEGV is after
`-i $inferior_spawn_id`. On native, the top and bottom GDB are on the
same spawn id, so it ends up working. But with a gdbserver board,
that's not the case. Move the SIGSEGV -re before the `-i
$inferior_spawn_id` line, such that it matches what the top GDB outputs.
Do the same fix in gdb.gdb/python-helper.exp.
Change-Id: I3291630e218a5a3a6a47805b999ddbc9b968c927
Approved-By: Tom Tromey <tom@tromey.com>
|
|
This changes skip_python_tests to invert the sense, and renames it to
allow_python_tests.
|
|
This changes gdb_skip_xml_test to invert the sense, and renames it to
allow_xml_test.
|
|
This changes various tests to use "require" for the Python feature.
|
|
This changes some tests to use "require !gdb_debug_enabled".
|
|
This commit is the result of running the gdb/copyright.py script,
which automated the update of the copyright year range for all
source files managed by the GDB project to be updated to include
year 2023.
|
|
The gdb.gdb self-tests were timing out for me, which turned out to be
PR testsuite/29325. Looking into it, the problem is that the version
of the Boehm GC that is used by Guile on my machine causes a SEGV
during stack probing. This unexpected stop confuses the tests and
causes repeated timeouts.
This patch adapts the two failing tests. This makes them work for me,
and reduces the running time of gdb.gdb from 20 minutes to about 11
seconds.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29325
|
|
$_hit_locno PR breakpoints/12464
This implements the request given in PR breakpoints/12464.
Before this patch, when a breakpoint that has multiple locations is reached,
GDB printed:
Thread 1 "zeoes" hit Breakpoint 1, some_func () at somefunc1.c:5
This patch changes the message so that bkpt_print_id prints the precise
encountered breakpoint:
Thread 1 "zeoes" hit Breakpoint 1.2, some_func () at somefunc1.c:5
In mi mode, bkpt_print_id also (optionally) prints a new table field "locno":
locno is printed when the breakpoint hit has more than one location.
Note that according to the GDB user manual node 'GDB/MI Development and Front
Ends', it is ok to add new fields without changing the MI version.
Also, when a breakpoint is reached, the convenience variables
$_hit_bpnum and $_hit_locno are set to the encountered breakpoint number
and location number.
$_hit_bpnum and $_hit_locno can a.o. be used in the command list of a
breakpoint, to disable the specific encountered breakpoint, e.g.
disable $_hit_bpnum.$_hit_locno
In case the breakpoint has only one location, $_hit_locno is set to
the value 1, so as to allow a command such as:
disable $_hit_bpnum.$_hit_locno
to disable the breakpoint even when the breakpoint has only one location.
This also fixes a strange behaviour: when a breakpoint X has only
one location,
enable|disable X.1
is accepted but transforms the breakpoint in a multiple locations
breakpoint having only one location.
The changes in RFA v4 handle the comments of Tom Tromey:
- Changed convenience var names from $bkptno/$locno to
$_hit_bpnum/$_hit_locno.
- updated the tests and user manual accordingly.
User manual also explictly describes that $_hit_locno is set to 1
for a breakpoint with a single location.
- The variable values are now set in bpstat_do_actions_1 so that
they are set for silent breakpoints, and when several breakpoints
are hit at the same time, that the variables are set to the printed
breakpoint.
The changes in RFA v3 handle the additional comments of Eli:
GDB/NEW:
- Use max 80-column
- Use 'code location' instead of 'location'.
- Fix typo $bkpno
- Ensure that disable $bkptno and disable $bkptno.$locno have
each their explanation inthe example
- Reworded the 'breakpoint-hit' paragraph.
gdb.texinfo:
- Use 'code location' instead of 'location'.
- Add a note to clarify the distinction between $bkptno and $bpnum.
- Use @kbd instead of examples with only one command.
Compared to RFA v1, the changes in v2 handle the comments given by
Keith Seitz and Eli Zaretskii:
- Use %s for the result of paddress
- Use bkptno_numopt_re instead of 2 different -re cases
- use C@t{++}
- Add index entries for $bkptno and $locno
- Added an example for "locno" in the mi interface
- Added examples in the Break command manual.
|
|
I spotted that the gdb.gdb/unittest.exp script causes a temporary file
inserters_extractors-2.txt to be created in build/gdb/testsuite/
instead of in build/gdb/testsuite/output/gdb.gdb/unittest/.
This is because some of the 'maint selftest' tests create temporary
files in GDB's current directory, specifically, the two source files:
gdb/unittests/basic_string_view/inserters/wchar_t/2.cc
gdb/unittests/basic_string_view/inserters/char/2.cc
both create a temporary file called inserters_extractors-2.txt, though
we only run the second of these as part of GDB's selftests.
I initially proposed just using GDB's 'cd' command in unittest.exp to
switch to the test output directory before running the selftests,
however, Pedro pointed out that there was a risk here that, if GDB
crashed during shutdown, the generated core file would be left in the
test output directory rather than in the testsuite directory. As a
result, our clever core file spotting logic would fail to spot the
core file and alert the user.
Instead, I propose this slightly more involved solution. I've added a
new with_gdb_cwd directory proc, used like this:
with_gdb_cwd $directory {
# Tests here...
}
The new proc temporarily switches to $directory and then runs the
tests within the block. After running the tests the previous current
working directory is restored.
Additionally, after switching back to the previous cwd, we check that
GDB is still responsive. This means that if GDB crashed immediately
prior to restoring the previous directory, and left the core file in
the wrong place, then the responsiveness check will fail, and a FAIL
will be emitted, this should be enough to alert the user that
something has gone wrong.
With this commit in place the unittest.exp script now leaves its
temporary file in the test output directory.
|
|
If some command in there gives the wrong answer, we currently have to
wait for a timeout for the test to continue. For instance, I currently
see:
print *val->type
$1 = Python Exception <class 'gdb.error'>: Cannot take address of method length.
(outer-gdb) FAIL: gdb.gdb/python-helper.exp: pretty print type (timeout)
We can avoid this and modernize the test at the same time by using the
-prompt option of gdb_test.
gdb_test_no_output currently accepts a -prompt_re option (the variable
name passed to parse_args defines the option name), but I think
it's a typo. It's supposed to be -prompt, like gdb_test. I can't find
anything using -prompt_re using grep. Change it to just "prompt".
Change-Id: Icc0a9a0ef482e62460c708bccdd544c11d711eca
|
|
The register_test_foreach_arch is used to instantiate a given selftest
for all architectures supported by GDB. It is used in many _initialize_*
functions (under initialize_all_files, called by gdb_init).
Because the call is done during GDB's initialization, and because there
is no guaranty about the order in which all the _initialize_* functions
are executed, when register_test_foreach_arch is called, GDB is not
fully initialized. Specifically, when a particular initialize function
is executed, only the architectures registered at that point are listed
by gdbarch_printable_names.
As a consequence, the list of selftest effectively executed depends on
the order the _initialize_* functions are called. This can be observed
with the following:
$ ./gdb/gdb \
-data-directory ./gdb/data-directory \
-quiet -batch -ex "maint selftest" 2>&1 \
| grep -E "Ran [0-9]+ unit tests"
Ran 145 unit tests, 0 failed
$ GDB_REVERSE_INIT_FUNCTIONS=1 ./gdb/gdb \
-data-directory ./gdb/data-directory \
-quiet -batch -ex "maint selftest" 2>&1 \
| grep -E "Ran [0-9]+ unit tests"
Ran 82 unit tests, 0 failed
To fix this, make register_test_foreach_arch register a lazy selftest
generator. This way when the test generator is eventually executed, all
architectures are registered and we do not have a dependency on the
order the initialize functions are executed in.
Tested on x86_64-linux
Change-Id: I88eefebf7d372ad672f42d3a103e89354bc8a925
|
|
This commit brings all the changes made by running gdb/copyright.py
as per GDB's Start of New Year Procedure.
For the avoidance of doubt, all changes in this commits were
performed by the script.
|
|
This commit updates uses of 'loc' and 'loc_kind' to 'm_loc' and
'm_loc_kind' respectively, in gdb-gdb.py.in, which is required after
this commit:
commit cd3f655cc7a55437a05aa8e7b1fcc9051b5fe404
Date: Thu Sep 30 22:38:29 2021 -0400
gdb: add accessors for field (and call site) location
I have also incorporated this change:
https://sourceware.org/pipermail/gdb-patches/2021-September/182171.html
Which means we print 'm_name' instead of 'name' when displaying the
'm_name' member variable.
Finally, I have also added support for the new TYPE_SPECIFIC_INT
fields, which were added with this commit:
commit 20a5fcbd5b28cca88511ac5a9ad5e54251e8fa6d
Date: Wed Sep 23 09:39:24 2020 -0600
Handle bit offset and bit size in base types
I updated the gdb.gdb/python-helper.exp test to cover all of these
changes.
|
|
On a machine with gcc 11, I get:
FAIL: gdb.gdb/unittest.exp: test_completion: tab complete "maintenance selftest string_v" (second tab) (timeout)
FAIL: gdb.gdb/unittest.exp: test_completion: tab complete "maintenance selftest string_vie" (timeout)
That's because when compiling with C++ >= 17, we use the standard
version of string_view, and don't have a selftest for it. So the list
of selftests shown by the tab completion when completing "string_v"
differs.
Change the test to use the copy_* tests instead.
Change-Id: I85f6aa44ee5fc9652b9bd4451e0506b89773526b
|
|
A build with --disable-unit-tests currently run into:
...
ld: maint.o: in function \
`maintenance_selftest_completer(cmd_list_element*, completion_tracker&,
char const*, char const*)':
src/gdb/maint.c:1183: undefined reference to \
`selftests::for_each_selftest(
gdb::function_view<
void (std::__cxx11::basic_string<char,std::char_traits<char>,
std::allocator<char> > const&)>)'
...
Fix this by guarding the call to selftests::for_each_selftest in
maintenance_selftest_completer with GDB_SELF_TEST, such that the "-verbose"
completion still works.
Rebuild on x86_64-linux and ran gdb.gdb/unittest.exp.
|
|
After the previous commit, it is easy to add completion for selftest
names. Again, this is not particularly high value, but I rarely touched
completion, so it served as a simple example to get some practice.
Change the for_each_selftest_ftype parameter to gdb::function_view, so
that we can pass a lambda that captures things.
Change-Id: I87cac299ddca9ca7eb0ffab78342e850a98d954c
|
|
The test-case gdb.gdb/python-interrupts.exp:
- runs to captured_command_loop
- sets a breakpoint at set_active_ext_lang
- calls a python command
- verifies the command triggers the breakpoint
- sends a signal and verifies the result
The test-case is fragile, because (f.i. with -flto) it cannot be guaranteed
that captured_command_loop and set_active_ext_lang are available for setting
breakpoints.
Reimplement the test-case as unittest, using:
- execute_command_to_string to capture the output
- try/catch to catch the "Error while executing Python code" exception
- a new hook selftests::hook_set_active_ext_lang to raise the signal
Tested on x86_64-linux.
|
|
With a gdb configured to be somewhat minimal, while still supporting python:
...
$ gdb --configuration
This GDB was configured as follows:
configure --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu
--with-auto-load-dir=$debugdir:$datadir/auto-load
--with-auto-load-safe-path=$debugdir:$datadir/auto-load
--without-expat
--with-gdb-datadir=$install/share/gdb (relocatable)
--with-jit-reader-dir=$install/lib64/gdb (relocatable)
--without-libunwind-ia64
--without-lzma
--without-babeltrace
--without-intel-pt
--with-mpfr
--without-xxhash
--with-python=/usr
--with-python-libdir=/usr/lib
--with-debuginfod
--without-guile
--disable-source-highlight
--with-separate-debug-dir=/usr/lib/debug
--with-system-gdbinit=$devel/system-gdbinit
...
and using gcc 4.8 to build gdb (causing std::thread not to be used due to
PR28318) I ran into:
...
(gdb) PASS: gdb.gdb/python-helper.exp: start inner gdb
print 1^M
^M
Breakpoint 2, value_print () at src/gdb/valprint.c:1174^M
1174 scoped_value_mark free_values;^M
(xgdb) FAIL: gdb.gdb/python-helper.exp: hit breakpoint in inner gdb (timeout)
...
The problem is that the regexp expects "hit Breakpoint $decimal". The "hit"
part is missing.
The "hit" is printed by maybe_print_thread_hit_breakpoint, when
show_thread_that_caused_stop returns true:
...
int
show_thread_that_caused_stop (void)
{
return highest_thread_num > 1;
}
...
Apparently, that's not the case.
Fix this by removing "hit" from the regexp, making the regexp more similar to
what is used in say, continue_to_breakpoint.
Tested on x86_64-linux.
|
|
Minimize gdb restarts, applying the following rules:
- don't use prepare_for_testing unless necessary
- don't use clean_restart unless necessary
Also, if possible, replace build_for_executable + clean_restart
with prepare_for_testing for brevity.
Touches 68 test-cases.
Tested on x86_64-linux.
|
|
With a gdb build with --enable-targets=all we run into a KFAIL:
...
KFAIL: gdb.gdb/unittest.exp: executable loaded: maintenance selftest, \
failed none (PRMS: gdb/27891)
...
due to:
...
Running selftest print_one_insn.^M
Self test failed: arch armv8.1-m.main: self-test failed at \
disasm-selftests.c:165^M
...
The test fails because we expect disassembling of one arm insn to consume 4
bytes and produce (using verbose = true in disasm-selftests.c):
...
arm mov r0, #0
...
but instead the disassembler uses thumb mode and only consumes 2
bytes and produces:
...
arm movs r0, r0
...
The failure does not show up in the "no executable loaded" variant because
this code in gdb_print_insn_arm isn't triggered:
...
if (current_program_space->exec_bfd () != NULL)
info->flags |= USER_SPECIFIED_MACHINE_TYPE;
...
and consequently we do this in print_insn:
...
if ((info->flags & USER_SPECIFIED_MACHINE_TYPE) == 0)
info->mach = bfd_mach_arm_unknown;
...
and don't set force_thumb to true in select_arm_features.
The code in gdb_print_insn_arm makes the assumption that the disassembly
architecture matches the exec architecture, which in this case is incorrect,
because the exec architecture is x86_64, and the disassembly architecture is
armv8.1-m.main. Fix that by explicitly checking it:
...
if (current_program_space->exec_bfd () != NULL
&& (current_program_space->exec_bfd ()->arch_info
== gdbarch_bfd_arch_info (gdbarch)))
...
This fixes the print_one_insn failure, so remove the KFAIL.
Tested on x86_64-linux.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27891
|
|
With a gdb build with CFLAGS "-O2 -g -flto=auto", I run into:
...
#7 gdb_main (args=0x7fffffffd220) at src/gdb/main.c:1368^M
#8 main (argc=<optimized out>, argv=<optimized out>) at src/gdb/gdb.c:32^M
(gdb) FAIL: gdb.gdb/selftest.exp: backtrace through signal handler
...
which means that this regexp in proc test_with_self fails:
...
-re "#0.*(read|poll).*in main \\(.*\\) at .*gdb\\.c.*$gdb_prompt $" {
...
The problem is that gdb_main has been inlined into main, and consequently the
backtrace uses:
...
#x <fn> ...
...
instead of
...
#x <address> in <fn> ...
...
Fix this by updating the regexp to not require "in" before " main".
Tested on x86_64-linux.
|
|
The test-case gdb.gdb/python-selftest.exp:
- patches the gdb_python_initialized variable in gdb to 0
- checks that the output of a python command is "Python not initialized"
Reimplement gdb.gdb/python-selftest.exp as unittest, using:
- execute_command_to_string to capture the output
- try/catch to catch the "Python not initialized" exception.
Tested on x86_64-linux.
|
|
When building gdb with "-Wall -O2 -g -flto=auto", I run into:
...
(gdb) call clear_complaints()^M
No symbol "clear_complaints" in current context.^M
(gdb) FAIL: gdb.gdb/complaints.exp: clear complaints
...
The problem is that lto has optimized away the clear_complaints function
and consequently the selftest doesn't work.
Fix this by reimplementing the selftest as a unit test.
Factor out two new functions:
- void
execute_fn_to_ui_file (struct ui_file *file, std::function<void(void)> fn);
- std::string
execute_fn_to_string (std::function<void(void)> fn, bool term_out);
and use the latter to capture the complaints output.
Tested on x86_64-linux.
|
|
When building gdb with "-Wall -O2 -g -flto=auto", I run into:
...
(gdb) call clear_complaints()^M
No symbol "clear_complaints" in current context.^M
(gdb) FAIL: gdb.gdb/complaints.exp: clear complaints
...
The problem is that lto has optimized away clear_complaints, and consequently
the selftests cannot run.
Fix this by:
- using info function to detect presence of clear_complaints
- handling the absence of clear_complaints by calling untested
...
(gdb) UNTESTED: gdb.gdb/complaints.exp: \
Cannot find clear_complaints, skipping test
...
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2021-09-03 Tom de Vries <tdevries@suse.de>
* gdb.gdb/complaints.exp: Use untested if clear_complaints cannot
be found.
|
|
I spotted that 'maint selftest' with an executable loaded into GDB,
would (when GDB was compiled for all targets) crash GDB. I fixed this
with a commit to bfd:
commit 427e4066afd13d1bf52c849849475f536e285d66
Date: Thu May 20 09:16:41 2021 +0100
gdb/bfd: avoid crash when architecture is forced to csky or riscv
However, this issue was not spotted as we currently only run 'maint
selftest' without an executable loaded.
This commit extends the testsuite to run 'maint selftest' both with
and without an executable loaded into GDB.
Currently, when no executable is loaded into GDB all of the selftest
pass (i.e. the fail count is 0), however, when running with an
executable loaded, I am seeing 1 failure (on an x86-64 GNU/Linux
host).
This failure is from the ARM disassembler tests, it appears that the
disassembler somehow gets itself into a state where it thinks it is in
thumb mode; when running the same test without an executable loaded
this doesn't happen.
This commit doesn't fix the ARM disassembler issue, but I thought it
was worth adding this anyway, as this will spot if GDB again starts to
crash when 'maint selftest' is run.
gdb/testsuite/ChangeLog:
* gdb.gdb/unittest.c: New file.
* gdb.gdb/unittest.exp: Run with and without a binary file loaded
into GDB.
|
|
In commit:
commit 5b7d941b90d1a232dc144dc14850dd2fb63c35da
Date: Fri Jan 22 12:21:09 2021 -0500
gdb: add owner-related methods to struct type
two fields of struct maint_type were renamed. 'flag_objfile_owned'
became 'm_flag_objfile_owned' and 'owner' became 'm_owner'. Update
our python helper script to take this into account.
I've added a basic test that uses the self-test framework to load the
pretty printers, and print a type.
The test relies on stopping in GDB's `value_print` function.
gdb/ChangeLog:
* gdb-gdb.py.in (StructMainTypePrettyPrinter) <owner_to_string>:
Updated fields names flag_objfile_owned to m_flag_objfile_owned,
and owner to m_owner.
gdb/testsuite/ChangeLog:
* gdb.gdb/python-helper.exp: New file.
|
|
This commits the result of running gdb/copyright.py as per our Start
of New Year procedure...
gdb/ChangeLog
Update copyright year range in copyright header of all GDB files.
|
|
Suppose we have the script file below:
break main
commands
print 123
end
run
If started with this script file, GDB executes the breakpoint command:
$ gdb -q -x myscript --args ./test
Reading symbols from ./test...
Breakpoint 1 at 0x114e: file test.c, line 2.
Breakpoint 1, main () at test.c:2
2 return 0;
$1 = 123
(gdb)
However, if we remove the "run" line from the script and pass it with
the '-ex' option instead, the command is not executed:
$ gdb -q -x myscript_no_run --args ./test
Reading symbols from ./test...
Breakpoint 1 at 0x114e: file test.c, line 2.
Starting program: /path/to/test
Breakpoint 1, main () at test.c:2
2 return 0;
(gdb)
If the user enters a command at this point, the breakpoint command
is executed, yielding weird output:
$ gdb -q -x myscript_no_run --args ./test
Reading symbols from ./test...
Breakpoint 1 at 0x114e: file test.c, line 2.
Starting program: /path/to/test
Breakpoint 1, main () at test.c:2
2 return 0;
(gdb) print "a"
$1 = "a"
$2 = 123
When consuming script files, GDB runs bp actions after executing a
command. See `command_handler` in event-top.c:
if (c[0] != '#')
{
execute_command (command, ui->instream == ui->stdin_stream);
/* Do any commands attached to breakpoint we stopped at. */
bpstat_do_actions ();
}
However, for '-ex' commands, `bpstat_do_actions` is not invoked.
Hence, the misaligned output explained above occurs. To fix the
problem, add a call to `bpstat_do_actions` after executing a command.
gdb/ChangeLog:
2020-12-07 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* main.c (catch_command_errors): Add a flag parameter; invoke
`bpstat_do_actions` if the flag is set.
(execute_cmdargs): Update a call to `catch_command_errors`.
gdb/testsuite/ChangeLog:
2020-12-07 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* gdb.base/bp-cmds-run-with-ex.c: New file.
* gdb.base/bp-cmds-run-with-ex.exp: New file.
* gdb.base/bp-cmds-run-with-ex.gdb: New file.
* gdb.gdb/python-interrupts.exp: Update the call to
'catch_command_errors' with the new argument.
* gdb.gdb/python-selftest.exp: Ditto.
|
|
When GDB is compiled with --enable-targets=all I would sometimes see
the 'maintenance selftest' in gdb.gdb/unittest.exp test timeout.
This one command causes GDB to run many separate self tests, this can
take some time. The output of this command basically follows this
pattern:
(gdb) maintenance selftest
Running selftest aarch64-analyze-prologue.
Running selftest aarch64-process-record.
Running selftest arm-record.
Running selftest arm_analyze_prologue.
Running selftest array_view.
Running selftest child_path.
Running selftest cli_utils.
..... snip lots more lines ....
Ran 79 unit tests, 0 failed
Currently the expect script waits for the final summary line ("Ran 79
unit test, 0 failed") before declaring pass or fail. The problem is
that if the summary line takes too long to appear the test will
timeout.
As this test makes use of gdb_test_multiple then all I've done is add
an extra pattern that matches the 'Running selftest ....' lines and
then calls exp_continue. Doing this means we find matches much more
frequently, and each time we do the timeout timer resets, preventing
the overall test from timing out.
gdb/testsuite/ChangeLog:
* gdb.gdb/unittest.exp: Spot 'Running...' lines.
|
|
There are 3 test directories with one duplicate test-name: gdb.gdb, gdb.opt
and gdb.xml. The duplicates are:
...
DUPLICATE: gdb.gdb/complaints.exp: call complaint_internal ($cstr)
DUPLICATE: gdb.opt/inline-locals.exp: info locals above bar 2 \
(PRMS: gdb/25695)
DUPLICATE: gdb.xml/tdesc-regs.exp: ptype $extrareg
...
Fix as appropriate.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-05-12 Tom de Vries <tdevries@suse.de>
* gdb.gdb/complaints.exp: Use with_test_prefix.
* gdb.xml/tdesc-regs.exp: Same.
* gdb.opt/inline-locals.exp: Fix test name.
|
|
gdb/ChangeLog:
Update copyright year range in all GDB files.
|
|
With gdb.gdb/selftest.exp, we get:
...
(xgdb) PASS: gdb.gdb/selftest.exp: send SIGINT signal to child process
^M
Thread 1 "xgdb" received signal SIGINT, Interrupt.^M
0x00007ffff5bf01db in poll () from /lib64/libc.so.6^M
(gdb) FAIL: gdb.gdb/selftest.exp: send ^C to child process again
...
The failure is due to gdb printing 'Thread 1 "xgdb" received signal SIGINT',
but the regexp in the test-case expecting 'Program received signal SIGINT'.
Fix this by updating the regexp, similar to how that is done earlier in the
test-case.
gdb/testsuite/ChangeLog:
2019-08-13 Tom de Vries <tdevries@suse.de>
* gdb.gdb/selftest.exp (send ^C to child process again): Accept also
Thread.
|
|
After the sync there is one testsuite regression, the test
"signal SIGINT" in gdb.gdb/selftest.exp which now FAILs. Previously,
the readline 6.2 SIGINT handler would temporarily reinstall the
underlying application's SIGINT handler and immediately re-raise SIGINT
so that the orginal handler gets invoked. But now (since readline 6.3)
its SIGINT handler does not re-raise SIGINT or directly invoke the
original handler; it now sets a flag marking that SIGINT was raised, and
waits until readline explicitly has control to call the application's
SIGINT handler. Anyway, because SIGINT is no longer re-raised from
within readline's SIGINT handler, doing "signal SIGINT" with a stopped
inferior gdb process will no longer resume and then immediately stop the
process (since there is no 2nd SIGINT to immediately catch). Instead,
the inferior gdb process will now just print "Quit" and continue to run.
So with this commit, this particular test case is adjusted to reflect
this change in behavior (we now have to send a 2nd SIGINT manually to
stop it).
gdb/testsuite/ChangeLog
2019-08-12 Patrick Palka <patrick@parcs.ath.cx>
* gdb.gdb/selftest.exp (test_with_self): Update test to now
expect the GDB inferior to no longer immediately stop after
being resumed with "signal SIGINT".
|
|
Fix up all failures encountered when running the testsuite with
GDB_DEBUG="infrun".
Some tests rely on enabling debugging for various components. With
debugging on, this will be lost to the debug file.
Disable separate tty for mi tests when debugging. This currently
does not work.
disasm.c should send errors to the stderr instead of the logfile.
Note that enabling debug for other components might still cause
additional errors above what has been fixed here.
gdb/ChangeLog:
* disasm.c (set_disassembler_options): Send errors to stderr.
gdb/testsuite/ChangeLog:
* gdb.base/breakpoint-in-ro-region.exp: Disable when debugging.
* gdb.base/debug-expr.exp: Likewise.
* gdb.base/foll-fork.exp: Likewise.
* gdb.base/foll-vfork.exp: Likewise.
* gdb.base/fork-print-inferior-events.exp: Likewise.
* gdb.base/gdb-sigterm.exp: Likewise.
* gdb.base/gdbinit-history.exp: Likewise.
* gdb.base/osabi.exp: Likewise.
* gdb.base/sss-bp-on-user-bp-2.exp: Likewise.
* gdb.base/ui-redirect.exp: Likewise.
* gdb.gdb/unittest.exp: Likewise.
* gdb.mi/mi-break.exp: Disable separate-mi-tty when debugging.
* gdb.mi/mi-watch.exp: Likewise.
* gdb.mi/new-ui-mi-sync.exp: Likewise.
* gdb.mi/user-selected-context-sync.exp: Likewise.
* gdb.python/python.exp: Disable debug test when debugging.
* gdb.threads/check-libthread-db.exp: Disable when debugging.
* gdb.threads/signal-while-stepping-over-bp-other-thread.exp:
Likewise.
* gdb.threads/stepi-random-signal.exp: Likewise.
|
|
This commit applies all changes made after running the gdb/copyright.py
script.
Note that one file was flagged by the script, due to an invalid
copyright header
(gdb/unittests/basic_string_view/element_access/char/empty.cc).
As the file was copied from GCC's libstdc++-v3 testsuite, this commit
leaves this file untouched for the time being; a patch to fix the header
was sent to gcc-patches first.
gdb/ChangeLog:
Update copyright year range in all GDB files.
|
