| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
With test-case gdb.mi/mi-var-cp.exp I run into this duplicate:
...
PASS: gdb.mi/mi-var-cp.exp: run to mi-var-cp.cc:104 (set breakpoint)
PASS: gdb.mi/mi-var-cp.exp: create varobj for s
PASS: gdb.mi/mi-var-cp.exp: create varobj for s
DUPLICATE: gdb.mi/mi-var-cp.exp: create varobj for s
...
This is due to a duplicate test name here:
...
$ cat -n gdb/testsuite/gdb.mi/mi-var-cp.cc
...
100 int reference_to_struct ()
101 {
102 /*: BEGIN: reference_to_struct :*/
103 S s = {7, 8};
104 S& r = s;
105 /*:
106 mi_create_varobj S s "create varobj for s"
107 mi_create_varobj R r "create varobj for s"
...
Fix this by using "create varobj for r" instead.
Tested on x86_64-linux.
|
|
On openSUSE Tumbleweed with glibc-debuginfo installed I get:
...
(gdb) PASS: gdb.threads/linux-dp.exp: continue to breakpoint: thread 5's print
where^M
#0 print_philosopher (n=3, left=33 '!', right=33 '!') at linux-dp.c:105^M
#1 0x0000000000401628 in philosopher (data=0x40537c) at linux-dp.c:148^M
#2 0x00007ffff7d56b37 in start_thread (arg=<optimized out>) \
at pthread_create.c:435^M
#3 0x00007ffff7ddb640 in clone3 () \
at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81^M
(gdb) PASS: gdb.threads/linux-dp.exp: first thread-specific breakpoint hit
...
while without debuginfo installed I get instead:
...
(gdb) PASS: gdb.threads/linux-dp.exp: continue to breakpoint: thread 5's print
where^M
#0 print_philosopher (n=3, left=33 '!', right=33 '!') at linux-dp.c:105^M
#1 0x0000000000401628 in philosopher (data=0x40537c) at linux-dp.c:148^M
#2 0x00007ffff7d56b37 in start_thread () from /lib64/libc.so.6^M
#3 0x00007ffff7ddb640 in clone3 () from /lib64/libc.so.6^M
(gdb) FAIL: gdb.threads/linux-dp.exp: first thread-specific breakpoint hit
...
The problem is that the regexp used:
...
"\(from .*libpthread\|at pthread_create\|in pthread_create\)"
...
expects the 'from' part to match libpthread, but in glibc 2.34 libpthread has
been merged into libc.
Fix this by updating the regexp.
Tested on x86_64-linux.
|
|
Since commit e36788d1354 "[gdb/testsuite] Fix handling of nr_args < 3 in
mi_gdb_test" we run into:
...
PASS: gdb.mi/mi-breakpoint-changed.exp: test_auto_disable: mi runto main
Expecting: ^(-break-insert -f pendfunc1[^M
]+)?((&.*)*.*~"Breakpoint 2 at.*\\n".*=breakpoint-created,\
bkpt=\{number="2",type="breakpoint".*\}.*\n\^done[^M
]+[(]gdb[)] ^M
[ ]*)
-break-insert -f pendfunc1^M
^done,bkpt={number="2",type="breakpoint",disp="keep",enabled="y",\
addr="0x00007ffff7bd559e",func="pendfunc1",\
file="gdb/testsuite/gdb.mi/pendshr1.c",\
fullname="gdb/testsuite/gdb.mi/pendshr1.c",line="21",thread-groups=["i1"],\
times="0",original-location="pendfunc1"}^M
(gdb) ^M
FAIL: gdb.mi/mi-breakpoint-changed.exp: test_auto_disable: \
-break-insert -f pendfunc1 (unexpected output)
...
The regexp expects a breakpoint-created event, but that's actually suppressed
by the command:
...
DEF_MI_CMD_MI_1 ("break-insert", mi_cmd_break_insert,
&mi_suppress_notification.breakpoint),
...
Fix this by updating the regexp.
Likewise for the following:
...
PASS: gdb.mi/mi-breakpoint-changed.exp: test_auto_disable: \
-break-insert -f pendfunc1
Expecting: ^(-break-enable count 1 2[^M
]+)?(=breakpoint-modified,\
bkpt=\{number="2",type="breakpoint",disp="dis",enabled="y".*\}.*\n\^done[^M
]+[(]gdb[)] ^M
[ ]*)
-break-enable count 1 2^M
^done^M
(gdb) ^M
FAIL: gdb.mi/mi-breakpoint-changed.exp: test_auto_disable: \
-break-enable count 1 2 (unexpected out\
put)
...
Tested on x86_64-linux.
|
|
Add a new function to the Python API, gdb.architecture_names(). This
function returns a list containing all of the supported architecture
names within the current build of GDB.
The values returned in this list are all of the possible values that
can be returned from gdb.Architecture.name().
|
|
Update the expected pattern for two of the tests.
Matching pattern \" doesn't work. Use .* to match the \* pattern.
|
|
In commit 81e6b8eb208 "Make tui-winsource not use breakpoint_chain", a loop
body was transformed into a lambda function body:
...
- for (bp = breakpoint_chain;
- bp != NULL;
- bp = bp->next)
+ iterate_over_breakpoints ([&] (breakpoint *bp) -> bool
...
and consequently:
- a continue was replaced by a return, and
- a final return was added.
Then in commit 240edef62f0 "gdb: remove iterate_over_breakpoints function", we
transformed back to a loop body:
...
- iterate_over_breakpoints ([&] (breakpoint *bp) -> bool
+ for (breakpoint *bp : all_breakpoints ())
...
but without reverting the changes that introduced the two returns.
Consequently, breakpoints no longer show up in the tui source window.
Fix this by reverting the changes that introduced the two returns.
Build on x86_64-linux, tested with all .exp test-cases that contain
tuiterm_env.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28483
|
|
The test expect the runto_main to stop at the first line of the function.
Depending on the optimization level, gdb may stop in the prolog or after
the prolog at the first line. To ensure the test stops at the first line
of main, have it explicitly stop at a break point on the first line of the
function.
On PowerPC, the test passes when compiled with no optimization but fails
with all levels of optimization due to gdb stopping in the prolog.
|
|
The "add accessors for field (and call site) location" patch caused a
gdb crash when running the internal AdaCore testsuite. This turned
out to be a latent bug in ada-lang.c.
The immediate cause of the bug is that find_struct_field
unconditionally uses TYPE_FIELD_BITPOS. This causes an assert for a
dynamic type.
This patch fixes the problem by doing two things. First, it changes
find_struct_field to use a dummy value for the field offset in the
situation where the offset is not actually needed by the caller. This
works because the offset isn't used in any other way -- only as a
result.
Second, this patch assures that calls to find_struct_field use a
resolved type when the offset is needed. For
value_tag_from_contents_and_address, this is done by resolving the
type explicitly. In ada_value_struct_elt, this is done by passing
nullptr for the out parameters when they are not needed (the second
call in this function already uses a resolved type).
Note that, while we believe the parent field probably can't occur at a
variable offset, the patch still updates this code path, just in case.
I've updated an existing test case to reproduce the crash.
I'm checking this in.
|
|
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.
|
|
A customer-reported problem led us to a bug in dynamic type
resolution. resolve_dynamic_struct will recursively call
resolve_dynamic_type_internal, passing it the sub-object for the
particular field being resolved. While it offsets the address here,
it does not also offset the "valaddr" -- the array of bytes describing
the memory.
This patch fixes the bug, by offsetting both. A test case is included
that can be used to reproduce the bug.
|
|
Add .debug_loc support in the dwarf assembler, and use it in new test-case
gdb.dwarf2/loc-sec-offset.exp (which is based on
gdb.dwarf2/loclists-sec-offset.exp).
Tested on x86_64-linux.
|
|
When printing a variable x in a subroutine foo:
...
subroutine foo (x)
integer(4) :: x (*)
x(3) = 1
end subroutine foo
...
where x is an array with unknown bounds, we get:
...
$ gdb -q -batch outputs/gdb.fortran/array-no-bounds/array-no-bounds \
-ex "break foo" \
-ex run \
-ex "print x"
Breakpoint 1 at 0x4005cf: file array-no-bounds.f90, line 18.
Breakpoint 1, foo (x=...) at array-no-bounds.f90:18
18 x(3) = 1
$1 = <error reading variable>
...
Improve the error message by printing the details of the error, such that we
have instead:
...
$1 = <error reading variable: failed to get range bounds>
...
This is a change in gdb/valprint.c, and grepping through the sources reveals
that this is a common pattern.
Tested on x86_64-linux.
|
|
When running test-case gdb.fortran/call-no-debug.exp with target board
native-gdbserver, I run into:
...
(gdb) PASS: gdb.fortran/call-no-debug.exp: print string_func_ (&'abcdefg', 3)
call (integer) string_func_ (&'abcdefg', 3)^M
$2 = 0^M
(gdb) FAIL: gdb.fortran/call-no-debug.exp: call (integer) string_func_ (&'abcdefg', 3)
...
The problem is that gdb_test is used to match inferior output.
Fix this by using gdb_test_stdio.
Tested on x86_64-linux.
|
|
When running with target board native-gdbserver, we run into a number of FAILs
due to use of the start command (and similar), which is not supported when
use_gdb_stub == 1.
Fix this by:
- requiring use_gdb_stub == 0 for the entire test-case, or
- guarding some tests in the test-case with use_gdb_stub == 0.
Tested on x86_64-linux.
|
|
When running test-case gdb.python/python.exp, we have:
...
PASS: gdb.python/python.exp: starti via gdb.execute, not from tty
PASS: gdb.python/python.exp: starti via interactive input
...
The two tests are instances of the same test, with different values for
starti command argument from_tty, so it's strange that the test names are so
different.
This is due to using a gdb_test nested in a gdb_test_multiple, with the inner
one using a different test name than the outer one. [ That could still make
sense if both produced passes, but that's not the case here. ]
Fix this by using $gdb_test_name, such that we have:
...
PASS: gdb.python/python.exp: starti via gdb.execute, not from tty
PASS: gdb.python/python.exp: starti via gdb.execute, from tty
...
Also make this more readable by using variables.
Tested on x86_64-linux.
|
|
When running test-case gdb.base/batch-exit-status.exp with target board
native-gdbserver, I run into (added missing double quotes for clarity):
...
builtin_spawn $build/gdb/testsuite/../../gdb/gdb -nw -nx \
-data-directory $build/gdb/testsuite/../data-directory \
-iex "set height 0" -iex "set width 0" \
-ex "set auto-connect-native-target off" \
-iex "set sysroot" -batch ""^M
: No such file or directory.^M
PASS: gdb.base/batch-exit-status.exp: 1x: \
No such file or directory: [lindex $result 2] == 0
FAIL: gdb.base/batch-exit-status.exp: 1x: \
No such file or directory: [lindex $result 3] == $expect_status
...
As in commit a02a90c114c "[gdb/testsuite] Set sysroot earlier in
local-board.exp", the problem is the use of -ex for
"set auto-connect-native-target off", which makes that the last command to
be executed, and consequently determines the return status.
Fix this by using -iex instead.
Tested on x86_64-linux.
|
|
When running test-case gdb.arch/i386-mpx.exp with target board
native-gdbserver, I run into:
...
(gdb) PASS: gdb.arch/i386-mpx.exp: verify size for bnd0
Remote debugging from host ::1, port 42328^M
quit^M
A debugging session is active.^M
^M
Inferior 1 [process 19679] will be killed.^M
^M
Quit anyway? (y or n) monitor exit^M
Please answer y or n.^M
A debugging session is active.^M
^M
Inferior 1 [process 19679] will be killed.^M
^M
Quit anyway? (y or n) WARNING: Timed out waiting for EOF in server after monitor exit
...
The problem is that the test-case sends a quit at the end (without verifying
the result of this in any way):
...
send_gdb "quit\n"
...
Fix this by removing the quit.
Tested on x86_64-linux.
|
|
When running test-case gdb.mi/mi-var-child-f.exp on openSUSE Tumbleweed
(with glibc 2.34) I run into:
...
(gdb) ^M
PASS: gdb.mi/mi-var-child-f.exp: mi runto prog_array
Expecting: ^(-var-create array \* array[^M
]+)?(\^done,name="array",numchild="[0-9]+",value=".*",type=.*,has_more="0"[^M
]+[(]gdb[)] ^M
[ ]*)
-var-create array * array^M
&"Attempt to use a type name as an expression.\n"^M
^error,msg="-var-create: unable to create variable object"^M
(gdb) ^M
FAIL: gdb.mi/mi-var-child-f.exp: create local variable array (unexpected output)
...
The problem is that the name array is used both:
- as the name for a local variable
- as the name of a type in glibc, in file malloc/dynarray-skeleton.c, as included
by nss/nss_files/files-hosts.c.
Fix this by ignoring the shared lib symbols.
Likewise in a couple of other fortran tests.
Tested on x86_64-linux.
|
|
A mistake slipped in in commit a5ea23036d8 "[gdb/testsuite] Use function_range
in gdb.dwarf2/dw2-ref-missing-frame.exp".
Before the commit the main file was compiled with debug info, and the two
others not:
...
if {[prepare_for_testing_full "failed to prepare" \
[list $testfile {} $srcfile {} $srcfuncfile {} \
$srcmainfile debug]]} {
...
After the commit, all were compiled with debug info, and consequently, there
are two versions of debug info for $srcfuncfile. This shows up as a FAIL when
running the test-case with target boards readnow and cc-with-debug-names.
Fix this by using prepare_for_testing_full, as before.
Tested on x86_64-linux.
Fixes: a5ea23036d8 ("[gdb/testsuite] Use function_range in
gdb.dwarf2/dw2-ref-missing-frame.exp")
|
|
Replace:
...
if { [ensure_gdb_index $binfile] == -1 } {
return -1
}
...
with:
...
require {ensure_gdb_index $binfile} != -1
...
and consequently, add a missing UNTESTED message.
Tested on x86_64-linux, both with native and target board readnow.
|
|
When running test-case gdb.base/with-mf.exp with target board readnow, I run
into:
...
FAIL: gdb.base/with-mf.exp: check if index present
...
This is since commit 6010fb0c49e "[gdb/testsuite] Fix full buffer in
gdb.rust/dwindex.exp".
Before that commit, the proc ensure_gdb_index would treat the line:
...
.gdb_index: faked for "readnow"^M
...
as proof that an index is already present (which is incorrect).
Now, instead it generates aforementioned FAIL and continues to generate an
index.
Fix this by explicitly handling the readnow case in proc ensure_gdb_index,
such that we bail out instead.
Tested on x86_64-linux.
|
|
The test-case gdb.dwarf2/gdb-add-index-symlink.exp interpretes a failure to
add an index as a failure to add an index for a symlink:
...
if { [ensure_gdb_index $symlink] == -1 } {
fail "Unable to call gdb-add-index with a symlink to a symfile"
return -1
}
...
However, it's possible that the gdb-add-index also fails with a regular
file. Add a check for that situation.
Tested on x86_64-linux.
|
|
Add a new proc require in lib/gdb.exp, and use it to shorten:
...
if { [gdb_skip_xml_test] } {
# Valgrind gdbserver requires gdb with xml support.
untested "missing xml support"
return 0
}
...
into:
...
require gdb_skip_xml_test 0
...
Tested on x86_64-linux, both with and without a trigger patch that forces
gdb_skip_xml_test to return 1.
|
|
Consider the gdb output:
...
27 return SYSCALL_CANCEL (nanosleep, requested_time, remaining);^M
(gdb) ^M
Thread 2 "run-attach-whil" stopped.^M
...
When trying to match the gdb prompt using gdb_test which uses '$gdb_prompt $',
it may pass or fail.
This sort of thing needs to be fixed (see commit b0e2f96b56b), but there's
currently no way to reliably find this type of FAILs.
We have check-read1, but that one actually make the test pass reliably.
We need something like the opposite of check-read1: something that makes
expect read a bit slower, or more exhaustively.
Add a new test target check-readmore that implements this.
There are two methods of implementing this in read1.c:
- the first method waits a bit before doing a read
- the second method does a read and then decides whether to
return or to wait a bit and do another read, and so on.
The second method is potentially faster, has less risc of timeout and could
potentially detect more problems. The first method has a simpler
implementation.
The second method is enabled by default. The default waiting period is 10
miliseconds.
The first method can be enabled using:
...
$ export READMORE_METHOD=1
...
and the waiting period can be specified in miliseconds using:
...
$ export READMORE_SLEEP=9
...
Also a log file can be specified using:
...
$ export READMORE_LOG=$(pwd -P)/LOG
...
Tested on x86_64-linux.
Testing with check-readmore showed these regressions:
...
FAIL: gdb.base/bp-cmds-continue-ctrl-c.exp: run: stop with control-c (continue)
FAIL: gdb.base/bp-cmds-continue-ctrl-c.exp: attach: stop with control-c (continue)
...
I have not been able to find a problem in the test-case, and I think it's the
nature of both the test-case and readmore that makes it run longer. Make
these pass by increasing the alarm timeout from 60 to 120 seconds.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27957
|
|
When running these test-cases:
- gdb.fortran/info-modules.exp
- gdb.fortran/module.exp
- gdb.mi/mi-fortran-modules.exp
in conjunction with:
...
$ stress -c $(($(cat /proc/cpuinfo | grep -c "^processor") + 1))
...
I run into timeouts.
Fix this by using:
- "set auto-solib-add off" to avoid symbols of shared libs
(which doesn't work for libc, now that libpthread_name_p has been
updated to match libc)
- "nosharedlibrary" to avoid symbols of libc
Tested on x86_64-linux.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28133
|
|
When running test-case gdb.base/info-types-c++.exp in conjunction with:
...
$ stress -c $(($(cat /proc/cpuinfo | grep -c "^processor") + 1))
...
we get:
...
FAIL: gdb.base/info-types-c++.exp: info types (timeout)
...
Fix this by setting auto-solib-add to off.
Tested on x86_64-linux.
|
|
When running test-case gdb.base/info_sources_2.exp with check-read1, I run
into:
...
FAIL: gdb.base/info_sources_2.exp: args: : info sources (timeout)
...
Fix this by consuming a "$src1, $src2, ..., $srcn: line bit by bit rather than
as one whole line.
Also add the missing handling of "Objfile has no debug information".
Tested on x86_64-linux.
|
|
When running test-case gdb.mi/gdb2549.exp with check-read1, I run into:
...
FAIL: gdb.mi/gdb2549.exp: register values x (timeout)
...
Fix this by applying the same fix as for "register values t" in commit
478e490a4df "[gdb/testsuite] Fix gdb.mi/gdb2549.exp with check-read1".
Tested on x86_64-linux.
|
|
When running test-case gdb.base/bt-on-error-and-warning.exp with check-read1,
I run into:
...
(gdb) maint internal-error foobar^M
src/gdb/maint.c:82: internal-error: foobar^M
A problem internal to GDB has been detectedFAIL: \
gdb.base/bt-on-error-and-warning.exp: problem=internal-error, mode=on: \
scan for backtrace (GDB internal error)
Resyncing due to internal error.
,^M
...
The corresponding gdb_test_multiple in the test-case contains:
...
-early -re "^A problem internal to GDB has been detected,\r\n" {
incr header_lines
exp_continue
}
...
but instead this one triggers in gdb_test_multiple:
...
-re ".*A problem internal to GDB has been detected" {
fail "$message (GDB internal error)"
gdb_internal_error_resync
set result -1
}
...
Fix this by likewise shortening the regexp to before the comma.
Tested on x86_64-linux.
|
|
When running test-case gdb.dwarf2/dw2-restrict.exp on openSUSE Leap 15.2 with
gcc-PIE installed (switching compiler default to -fPIE/-pie), I get:
...
gdb compile failed, ld: outputs/gdb.dwarf2/dw2-restrict/dw2-restrict0.o: \
warning: relocation in read-only section `.text'
ld: warning: creating DT_TEXTREL in a PIE
UNTESTED: gdb.dwarf2/dw2-restrict.exp: failed to prepare
...
This is due to using a hardcoded .S file that was generated with -fno-PIE.
Fix this by adding the missing nopie.
Likewise in gdb.arch/amd64-tailcall-noret.exp.
Tested on x86_64-linux.
|
|
When running test-case gdb.threads/check-libthread-db.exp on openSUSE
Tumbleweed (with glibc 2.34) I get:
...
(gdb) continue^M
Continuing.^M
[Thread debugging using libthread_db enabled]^M
Using host libthread_db library "/lib64/libthread_db.so.1".^M
Stopped due to shared library event:^M
Inferior loaded /lib64/libm.so.6^M
/lib64/libc.so.6^M
(gdb) FAIL: gdb.threads/check-libthread-db.exp: user-initiated check: continue
...
The check expect the inferior to load libpthread, but since glibc 2.34
libpthread has been integrated into glibc, and consequently it's no longer
a dependency:
...
$ ldd outputs/gdb.threads/check-libthread-db/check-libthread-db
linux-vdso.so.1 (0x00007ffe4cae4000)
libm.so.6 => /lib64/libm.so.6 (0x00007f167c77c000)
libc.so.6 => /lib64/libc.so.6 (0x00007f167c572000)
/lib64/ld-linux-x86-64.so.2 (0x00007f167c86e000)
...
Fix this by updating the regexp to expect libpthread or libc.
Tested on x86_64-linux.
|
|
With gcc 7.5.0, I get:
...
(gdb) guile (print (type-range (field-type (type-field (value-type \
(value-dereference f)) "items"))))^M
= (0 0)^M
(gdb) PASS: gdb.guile/scm-type.exp: lang_cpp: test_range: \
on flexible array member: $cmd
...
but with gcc 4.8.5, I get instead:
...
(gdb) guile (print (type-range (field-type (type-field (value-type \
(value-dereference f)) "items"))))^M
= (0 -1)^M
(gdb) FAIL: gdb.guile/scm-type.exp: lang_cpp: test_range: \
on flexible array member: $cmd
...
There's a difference in debug info. With gcc 4.8.5, we have:
...
<2><224>: Abbrev Number: 15 (DW_TAG_member)
<225> DW_AT_name : items
<22b> DW_AT_type : <0x231>
<1><231>: Abbrev Number: 4 (DW_TAG_array_type)
<232> DW_AT_type : <0x105>
<2><23a>: Abbrev Number: 16 (DW_TAG_subrange_type)
<23b> DW_AT_type : <0x11a>
<23f> DW_AT_upper_bound : 0xffffffffffffffff
...
and with gcc 7.5.0, we have instead:
...
<2><89f>: Abbrev Number: 12 (DW_TAG_member)
<8a0> DW_AT_name : items
<8a6> DW_AT_type : <0x8ac>
<1><8ac>: Abbrev Number: 17 (DW_TAG_array_type)
<8ad> DW_AT_type : <0x29d>
<2><8b5>: Abbrev Number: 41 (DW_TAG_subrange_type)
<2><8b6>: Abbrev Number: 0
...
As mentioned in commit 858c8f2c1b9 "gdb/testsuite: adjust
gdb.python/flexible-array-member.exp expected pattern":
...
Ideally, GDB would present a consistent and documented value for an
array member declared with size 0, regardless of how the debug info
looks like.
...
As in gdb.python/flexible-array-member.exp, change the test to accept the two
values.
Tested on x86_64-linux.
|
|
On openSUSE tumbleweed I run into:
...
FAIL: gdb.base/annota1.exp: run until main breakpoint (timeout)
...
due to a message related to libthread_db:
...
^Z^Zstarting^M
[Thread debugging using libthread_db enabled]^M
Using host libthread_db library "/lib64/libthread_db.so.1".^M
^M
^Z^Zframes-invalid^M
...
which is not matched by the regexp.
Fix this by updating the regexp.
Tested on x86_64-linux.
|
|
Refactor regexp in gdb.base/annota1.exp to reduce indentation and repetition.
Tested on x86_64-linux.
|
|
When running test-case gdb.tui/corefile-run.exp on openSUSE Tumbleweed,
I run into:
...
PASS: gdb.tui/corefile-run.exp: load corefile
FAIL: gdb.tui/corefile-run.exp: run until the end
...
What's going on is easier to see when also doing dump_screen if
check_contents passes, and inspecting state at the preceding PASS:
...
+-------------------------------------------------------------------------+
exec No process In: L?? PC: ??
[New LWP 16629]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `/data/gdb_versions/devel/build/gdb/testsuite/output
s/gdb.tui/corefile-run/corefi'.
Program terminated with signal SIGTRAP, Trace/breakpoint trap.
#0 main ()
--Type <RET> for more, q to quit, c to continue without paging--
...
The problem is that we're getting a pagination prompt, and the subsequent run
command is interpreted as an answer to that prompt.
Fix this by:
- detecting the gdb prompt in response to "load corefile", such that
we detect the failure earlier, and
- doing a "set pagination off" in Term::clean_restart.
Tested on x86_64-linux.
|
|
Currently, tui testing is rather verbose. When using these RUNTESTFLAGS to
pick up all tui tests (17 in total):
...
rtf=$(echo $(cd src/gdb/testsuite/; find gdb.* -type f -name *.exp* \
| xargs grep -l tuiterm_env) )
...
we have:
...
$ wc -l gdb.log
120592 gdb.log
...
Most of the output is related to controlling the tui screen, but that does
not give a top-level sense of how the test-case progresses.
Put differently: a lot of bandwith is used to describe how we arrive at a
certain tui screen state. But we don't actually always show the state we
arrive at, unless there's a FAIL.
And if there's say, a PASS that should actually be FAILing, it's hard to
detect.
Fix this by:
- dropping the -log on the call to verbose in _log. We still can get the
same info back using runtest -v.
- dumping the screen or box that we're checking, also when the test passes.
Brings down verbosity to something more reasonable:
...
$ wc -l gdb.log
3221 gdb.log
...
Tested on x86_64-linux.
|
|
Factor out new proc Term::get_region and use it to implement a
new proc Term::dump_box, similar to Term::dump_screen.
Tested on x86_64-linux.
|
|
This makes the Ada-specific "varsize-limit" a synonym for
"max-value-size", and removes the Ada-specific checks of the limit.
I am not certain of the history here, but it seems to me that this
code is fully obsolete now. And, removing this makes it possible to
index large Ada arrays without triggering an error. A new test case
is included to demonstrate this.
|
|
Since commit e36788d1354 "[gdb/testsuite] Fix handling of nr_args < 3 in
mi_gdb_test" we run into:
...
PASS: gdb.mi/mi-nsmoribund.exp: print done = 1
Expecting: ^(.*[^M
]+)?([^
]*^M
\*running,thread-id="[0-9]+"^M
\*running,thread-id="[0-9]+"^M
\*running,thread-id="[0-9]+"^M
\*running,thread-id="[0-9]+"^M
\*running,thread-id="[0-9]+"^M
\*running,thread-id="[0-9]+"^M
\*running,thread-id="[0-9]+"^M
\*running,thread-id="[0-9]+"^M
\*running,thread-id="[0-9]+"^M
\*running,thread-id="[0-9]+"[^M
]+[(]gdb[)] ^M
[ ]*)
103-exec-continue --all^M
=library-loaded,id="/lib64/libgcc_s.so.1",target-name="/lib64/libgcc_s.so.1",\
host-name="/lib64/libgcc_s.so.1",symbols-loaded="0",thread-group="i1",\
ranges=[{from="0x00007ffff22a5010",to="0x00007ffff22b6365"}]^M
103^running^M
*running,thread-id="5"^M
(gdb) ^M
FAIL: gdb.mi/mi-nsmoribund.exp: 103-exec-continue --all (unexpected output)
...
The regexp expect running messages for all threads, but we only get one for
thread 5.
The test-case uses non-stop mode, and when the exec-continue --all command is
issued, thread 5 is stopped and all other threads are running. Consequently,
only thread 5 is resumed, and reported as running.
Fix this by updating the regexp.
Tested on x86_64-linux.
|
|
When a user creates a gdb.Inferior object for the first time a new
Python object is created. This object is then cached within GDB's
inferior object using the registry mechanism (see
inferior_to_inferior_object in py-inferior.c, specifically the calls
to inferior_data and set_inferior_data).
The Python Reference to the gdb.Inferior object held within the real
inferior object ensures that the reference count on the Python
gdb.Inferior object never reaches zero while the GDB inferior object
continues to exist.
At the same time, the gdb.Inferior object maintains a C++ pointer back
to GDB's real inferior object. We therefore end up with a system that
looks like this:
Python Reference
|
|
.----------. | .--------------.
| |------------------->| |
| inferior | | gdb.Inferior |
| |<-------------------| |
'----------' | '--------------'
|
|
C++ Pointer
When GDB's inferior object is deleted (say the inferior exits) then
py_free_inferior is called (thanks to the registry system), this
function looks up the Python gdb.Inferior object and sets the C++
pointer to nullptr and finally reduces the reference count on the
Python gdb.Inferior object.
If at this point the user still holds a reference to the Python
gdb.Inferior object then nothing happens. However, the gdb.Inferior
object is now in the non-valid state (see infpy_is_valid in
py-inferior.c), but otherwise, everything is fine.
However, if there are no further references to the Python gdb.Inferior
object, or, once the user has given up all their references to the
gdb.Inferior object, then infpy_dealloc is called.
This function currently checks to see if the inferior pointer within
the gdb.Inferior object is nullptr or not. If the pointer is nullptr
then infpy_dealloc immediately returns.
Only when the inferior point in the gdb.Inferior is not nullptr do
we (a) set the gdb.Inferior reference inside GDB's inferior to
nullptr, and (b) call the underlying Python tp_free function.
There are a number things wrong here:
1. The Python gdb.Inferior reference within GDB's inferior object
holds a reference count, thus, setting this reference to nullptr
without first decrementing the reference count would leak a
reference, however...
2. As GDB's inferior holds a reference then infpy_dealloc will never
be called until GDB's inferior object is deleted. Deleting a GDB
inferior ohject calls py_free_inferior, and so gives up the
reference. At this point there is no longer a need to call
set_inferior_data to set the field back to NULL, that field must
have been cleared in order to get the reference count to zero, which
means...
3. If we know that py_free_inferior must be called before
infpy_dealloc, then we know that the inferior pointer in
gdb.Inferior will always be nullptr when infpy_dealloc is called,
this means that the call to the underlying tp_free function will
always be skipped. Skipping this call will cause Python to leak the
memory associated with the gdb.Inferior object, which is what we
currently always do.
Given all of the above, I assert that the C++ pointer within
gdb.Inferior will always be nullptr when infpy_dealloc is called.
That's what this patch does.
I wrote a test for this issue making use of Pythons tracemalloc
module, which allows us to spot this memory leak.
|
|
Following 2 test points are failing with clang compiler
(gdb) FAIL: gdb.dwarf2/dw2-ref-missing-frame.exp: func_nofb print
(gdb) FAIL: gdb.dwarf2/dw2-ref-missing-frame.exp: func_loopfb print
As in commit f677852bbda "[gdb/testsuite] Use function_range in
gdb.dwarf2/dw2-abs-hi-pc.exp", the problem is that the CU and functions
have an empty address range, due to using asm labels in global scope,
which is a known source of problems, as explained in the comment of proc
function_range in gdb/testsuite/lib/dwarf.exp. Hence fix this also by
using function_range.
Tested on x86_64-linux with gcc and clang.
|
|
Add a new event, gdb.events.gdb_exiting, which is called once GDB
decides it is going to exit.
This event is not triggered in the case that GDB performs a hard
abort, for example, when handling an internal error and the user
decides to quit the debug session, or if GDB hits an unexpected,
fatal, signal.
This event is triggered if the user just types 'quit' at the command
prompt, or if GDB is run with '-batch' and has processed all of the
required commands.
The new event type is gdb.GdbExitingEvent, and it has a single
attribute exit_code, which is the value that GDB is about to exit
with.
The event is triggered before GDB starts dismantling any of its own
internal state, so, my expectation is that most Python calls should
work just fine at this point.
When considering this functionality I wondered about using the
'atexit' Python module. However, this is triggered when the Python
environment is shut down, which is done from a final cleanup. At
this point we don't know for sure what other GDB state has already
been cleaned up.
|
|
The test gdb.python/py-events.exp sets up a handler for the gdb.exited
event. Unfortunately the handler is slightly broken, it assumes that
the exit_code attribute will always be present. This is not always
the case.
In a later commit I am going to add more tests to py-events.exp test
script, and in so doing I expose the bug in our handling of gdb.exited
events.
Just to be clear, GDB itself is fine, it is the test that is not
written correctly according to the Python Events API.
So, in this commit I fix the Python code in the test, and extend the
test case to exercise more paths through the Python code.
Additionally, I noticed that the gdb.exited event is used as an
example in the documentation for how to write an event handler.
Unfortunately the same bug that we had in our test was also present in
the example code in the manual.
So I've fixed that too.
After this commit there is no functional change to GDB.
|
|
Since python 2 is no longer supported on most distributions, update the
script to run under python while while still being runnable under
python2.
|
|
While working on other problems, I encountered situations where GDB
fails to properly unwind the stack because some functions use the C.MV
instruction in the prologue. The prologue scanner stops when it hits
this instruction assuming its job is done at this point. Unfortunately
the prologue is not necessarily finished yet, preventing GDB to properly
unwind.
This commit adds support for handling such instruction in
riscv_scan_prologue.
Note that C.MV is part of the compressed instruction set. The MV
counterpart from the base ISA is a pseudo instruction that expands to
'ADDI RD,RS1,0' which is already supported.
Tested on riscv64-linux-gnu.
All feedback are welcome.
|
|
Change how rnglists and loclists procs to align them with how procs for
aranges (and other things in the DWARF assembler) work. Instead of
using "args" (variable number of parameters in TCL) and command-line
style option arguments, use one leading "option" parameters, used as a
kind of key/value dictionary of options parsed using `parse_options`.
Change-Id: I63e60d17ae16a020ce4d6de44baf3d152ea42a1a
|
|
When I wrote support for rnglists and loclists in the testsuite's DWARF
assembler, I made it with nested procs, for example proc "table" inside
proc "rnglists". The intention was that this proc "table" could only be
used by the user while inside proc "rnglists"'s body. I had chosen very
simple names, thinking there was no chance of name clashes. I recently
learned that this is not how TCL works. This ends up defining a proc
"table" in the current namespace ("Dwarf" in this case).
Things still work if you generate rnglists and loclists in the same
file, as each redefines its own procedures when executing. But if a
user of the assembler happened to define a convenience "table" or
"start_end" procedure, for example, it would get overriden.
I'd like to change how this works to reduce the chances of a name clash.
- Move the procs out of each other, so they are not defined in a nested
fashion.
- Prefix them with "_rnglists_" or "_loclists_".
- While calling $body in the various procs, temporarily make the procs
available under their "short" name. For example, while in rngllists'
body, make _rnglists_table available as just "table". This allows
existing code to keep working and keeps it not too verbose.
- Modify with_override to allow the overriden proc to not exist. In
that case, the temporary proc is deleted on exit.
Note the non-conforming indentation when calling with_override in
_loclists_list. This is on purpose: as we implement more loclists (and
rnglists) entry types, the indentation would otherwise get larger and
larger without much value for readability. So I think it's reasonable
here to put them on the same level.
Change-Id: I7bb48d26fcb0dba1ae4dada05c0c837212424328
|
|
Add untested in case missing xml support is detected in test-cases
gdb.base/valgrind*.exp.
Tested on x86_64-linux.
|
|
As follow-up to this discussion:
https://sourceware.org/pipermail/gdb-patches/2020-August/171385.html
... make runto_main not pass no-message to runto. This means that if we
fail to run to main, for some reason, we'll emit a FAIL. This is the
behavior we want the majority of (if not all) the time.
Without this, we rely on tests logging a failure if runto_main fails,
otherwise. They do so in a very inconsisteny mannet, sometimes using
"fail", "unsupported" or "untested". The messages also vary widly.
This patch removes all these messages as well.
Also, remove a few "fail" where we call runto (and not runto_main). by
default (without an explicit no-message argument), runto prints a
failure already. In two places, gdb.multi/multi-re-run.exp and
gdb.python/py-pp-registration.exp, remove "message" passed to runto.
This removes a few PASSes that we don't care about (but FAILs will still
be printed if we fail to run to where we want to). This aligns their
behavior with the rest of the testsuite.
Change-Id: Ib763c98c5f4fb6898886b635210d7c34bd4b9023
|
|
With running test-case gdb.debuginfod/fetch_src_and_symbols.exp with target
board unix/-bad, I get:
...
gcc: error: unrecognized command line option '-bad'^M
compiler exited with status 1
gdb compile failed, gcc: error: unrecognized command line option '-bad'
FAIL: gdb.debuginfod/fetch_src_and_symbols.exp: compile
...
Replace the FAIL with the usual:
...
UNTESTED: gdb.debuginfod/fetch_src_and_symbols.exp: failed to compile
...
Tested on x86_64-linux.
|
