| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Recent commit 32a5aa26256 ("[gdb/testsuite] Fix gdb.ada/float-bits.exp
for powerpc64le") started using command "maint print architecture", which
produces ~275 lines.
Rewrite the corresponding gdb_test_multiple to read line-by-line, to prevent
timeouts on slower test setups.
Note that this doesn't fix a timeout in the test-case on aarch64 due to:
...
gdbarch_dump: read_core_file_mappings = <0x817438>
(gdb) aarch64_dump_tdep: Lowest pc = 0x0x8000
...
Tested on x86_64-linux.
|
|
gdb.reverse/next-reverse-bkpt-over-sr.exp
The tests set a break point with the command break *func. This sets a
breakpoint on the first instruction of the function. PowerPC uses
Global Entry Points (GEP) and Local Entry Points (LEP). The first
instruction in the function is the GEP. The GEP sets up register
r2 before reaching the LEP. When the function is called with func() the
function is entered via the LEP and the test fails because GDB does not
see the breakpoint on the GEP. However, if the function is called via a
function pointer, execution begins at the GEP as the test expects.
Currently finish-reverse-bkpt.exp uses source file finish-reverse.c and
next-reverse-bpkt-over-sr.exp uses source file step-reverse.c A new
source file was created for tests finish-reverse-bkpt.exp and
next-reverse-bkpt-over-sr.exp. The new files use the new function
pointer method to call the functions so the tests will work correctly on
both PowerPC with a GEP and LEP as well as on other systems. The GEP is
the same as the LEP on non PowerPC systems.
The expect files were changed to use the new source files and to set the
initial break point for the rest of the test on the function pointer call
for the function.
This patch fixes two PowerPC test failures in each of the tests
gdb.reverse/finish-reverse-bkpt.exp and
gdb.reverse/next-reverse-bkpt-over-sr.exp.
Patch tested on PowerPC and Intel X86-64 with no regressions.
Reviewed-By: Bruno Larsen <blarsen@redhat.com>
|
|
PR symtab/29105 shows a number of situations where symbol lookup can
result in the expansion of too many CUs.
What happens is that lookup_signed_typename will try to look up a type
like "signed int". In cooked_index_functions::expand_symtabs_matching,
when looping over languages, the C++ case will canonicalize this type
name to be "int" instead. Then this method will proceed to expand
every CU that has an entry for "int" -- i.e., nearly all of them. A
crucial component of this is that the caller, objfile::lookup_symbol,
does not do this canonicalization, so when it tries to find the symbol
for "signed int", it fails -- causing the loop to continue.
This patch fixes the problem by introducing name canonicalization for
C. The idea here is that, by making C and C++ agree on the canonical
name when a symbol name can have multiple spellings, we avoid the bad
behavior in objfile::lookup_symbol (and any other such code -- I don't
know if there is any).
Unlike C++, C only has a few situations where canonicalization is
needed. And, in particular, due to the lack of overloading (thus
avoiding any issues in linespec) and due to the way c-exp.y works, I
think that no canonicalization is needed during symbol lookup -- only
during symtab construction. This explains why lookup_name_info is not
touched.
The stabs reader is modified on a "best effort" basis.
The DWARF reader needed one small tweak in dwarf2_name to avoid a
regression in dw2-unusual-field-names.exp. I think this is adequately
explained by the comment, but basically this is a scenario that should
not occur in real code, only the gdb test suite.
lookup_signed_typename is simplified. It used to search for two
different type names, but now gdb can search just for the canonical
form.
gdb.dwarf2/enum-type.exp needed a small tweak, because the
canonicalizer turns "unsigned integer" into "unsigned int integer".
It seems better here to use the correct C type name.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29105
Tested-by: Simon Marchi <simark@simark.ca>
Reviewed-by: Andrew Burgess <aburgess@redhat.com>
|
|
PR compile/29541 points out that some of the C++ tests in gdb.compile
will time out when the glibc debuginfo is installed. This was
interfering with my hacking on gdb by making test runs extremely long,
so I looked into it.
Internally the bug seems to be that gdb tries to convert multiple
symbols named "var" via the compiler interface; one such symbol (I
didn't track it down too far) causes the C++ compiler plugin to crash.
Unfortunately, the crash is reported as a timeout, as the gdb side of
the plugin simply hangs. This seems like a bug in the plugin RPC
mechanism and, worse, apparently when I wrote this stuff I didn't
really consider error reporting very much at all, so gdb can't really
detect failures in the first place.
Anyway... this patch works around the timeout by compiling a simple
test that should provoke this bug, and then using "untested" if it
notices a GCC crash.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29541
|
|
skip_compile_feature_tests checks for "Command not supported on this
host", but this error was removed by commit e8d8cce6 ("Import mkdtemp
gnulib module, fix mingw build"). This patch removes the obsolete
test.
|
|
I noticed that there are two identical copies of
skip_compile_feature_tests in the test suite. This removes one from
gdb.exp, in favor of the one in compile-support.exp.
|
|
When I run the gdb testsuite on a powerpc64le-linux system with (slow) nfs
file system, I run into timeouts due to core generation, like for instance:
...
(gdb) gcore $outputs/gdb.ada/task_switch_in_core/crash.gcore^M
FAIL: gdb.ada/task_switch_in_core.exp: save a corefile (timeout)
...
Fix this by using with_timeout_factor 3 in gdb_gcore_cmd.
Tested on powerpc64le-linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
On powerpc64le-linux, I run into:
...
(gdb) print 16llf#4000921fb54442d18469898cc51701b8#^M
$9 = <invalid float value>^M
(gdb) FAIL: gdb.ada/float-bits.exp: print \
16llf#4000921fb54442d18469898cc51701b8#
...
The problem is that we're using a hex string for the 128-bit IEEE quad long
double format, but the actual long double float format is:
...
gdbarch_dump: long_double_format = floatformat_ibm_long_double_little^M
...
Fix this by using the hex string obtained by compiling test.c:
...
long double a = 5.0e+25L;
...
like so:
...
$ gcc -mlittle test.c -c -g
...
and running gdb:
...
$ gdb -q -batch test.o -ex "p /x a"
$1 = 0xc1e1c000000000004544adf4b7320335
...
and likewise for -mbig:
...
$ gdb -q -batch test.o -ex "p /x a"
$1 = 0x4544adf4b7320335c1e1c00000000000
...
Tested on powerpc64le-linux.
I excercised the case of floatformat_ibm_long_double_big by
using "set endian big" in the test-case.
Note that for this patch to work correctly, recent commit aaa79cd62b8 ("[gdb]
Improve printing of float formats") is required.
PR testsuite/29816
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29816
Approved-By: Tom Tromey <tom@tromey.com>
|
|
On s390x-linux, I run into:
...
DUPLICATE: gdb.arch/s390-multiarch.exp: Linux v2
DUPLICATE: gdb.arch/s390-multiarch.exp: Linux v2
DUPLICATE: gdb.arch/s390-multiarch.exp: Linux v2
...
Fix this by using with_test_prefix.
Tested on s390x-linux.
|
|
--enable-targets=all
On s390x-linux, I run into:
...
DUPLICATE: gdb.arch/s390-disassembler-options.exp: \
show disassembler-options esa
...
First, reproduce this on x86_64-linux with --enable-targets=all, by replacing
the test for 'istarget "s390*-*-*"' with a test for 'get_set_option_choices
"set architecture" "s390"'.
Fix the DUPLICATE by using with_test_prefix.
Also modernize the test-case by using clean_restart instead of gdb_exit/gdb_start.
Tested on x86_64-linux.
|
|
On powerpc64le-linux, I run into:
...
(gdb) PASS: gdb.base/vla-optimized-out.exp: o1: printed optimized out vla
p sizeof (a)^M
$2 = <optimized out>^M
(gdb) FAIL: gdb.base/vla-optimized-out.exp: o1: \
printed size of optimized out vla
...
The problem happens as follows.
In order to find the size of the optimized out vla, gdb needs to evaluate:
...
<155> DW_AT_upper_bound : 13 byte block: f3 1 53 23 1 8 20 24 8 20 26 31 1c \
(DW_OP_GNU_entry_value: (DW_OP_reg3 (r3)); DW_OP_plus_uconst: 1;
DW_OP_const1u: 32; DW_OP_shl; DW_OP_const1u: 32; DW_OP_shra; DW_OP_lit1;
DW_OP_minus)
...
When trying to evaluate DW_OP_GNU_entry_value, it looks for a call site
matching the pc, but doesn't find it:
...
$ gdb -q -batch outputs/gdb.base/vla-optimized-out/vla-optimized-out-o1 \
-ex "break f1" -ex run -ex "set debug entry-values 1" -ex "print sizeof (a)"
Breakpoint 1 at 0x1000067c: file vla-optimized-out.c, line 34.
Breakpoint 1, f1 (i=5) at vla-optimized-out.c:34
34 }
DW_OP_entry_value resolving cannot find DW_TAG_call_site 0x100006b0 in main
$1 = <optimized out>
....
The call site lookup fails because the call site label .LVL4:
...
bl f1 # 11 *call_value_nonlocal_aixdi [length = 8]
nop
.LVL4:
...
is not placed directly after the bl insn. This is gcc PR target/107909.
However, after manually fixing the .s file we have instead:
...
Cannot find matching parameter at DW_TAG_call_site 0x10000690 at main
$1 = <optimized out>
...
due to the fact that the call site has no call site parameters.
The call site does have a reference to the corresponding function f1, with
parameter i, for which we find location list entries:
...
0037 1000067c 10000680 (DW_OP_reg3 (r3))
004a 10000680 10000690 (DW_OP_GNU_entry_value: (DW_OP_reg3 (r3));
DW_OP_stack_value)
...
and we could use the fact that the current pc is in the 1000067c-10000680
range, and that that the range starts at the start of the function, to deduce
that DW_OP_GNU_entry_value: (DW_OP_reg3 (r3)) == DW_OP_reg3 (r3).
But that's a non-trivial enhancement, filed as enhancement PR symtab/29836.
Fix this by allowing <optimized out> for target powerpc and the gcc compiler.
Reviewed-By: Carl Love <cel@us.ibm.com>
Tested-By: Carl Love <cel@us.ibm.com>
PR testsuite/29813
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29813
|
|
In the failure seen by Philippe here:
https://inbox.sourceware.org/gdb-patches/20221120173024.3647464-1-philippe.waroquiers@skynet.be/
gdb_unload crashed GDB, leaving no trace in the test results. Change it
to use gdb_test_multiple, so that it leaves an UNRESOLVED result. I
think it is good practice anyway.
Make it return the result of gdb_test_multiple directly, change
gdb.python/py-objfile.exp accordingly.
Change gdb.base/endian.exp as well to avoid duplicate test names.
Change gdb.base/gnu-debugdata.exp to avoid recording a test result,
since gdb_unload does it already now.
Change-Id: I59a1e4947691330797e6ce23277942547c437a48
Approved-By: Tom de Vries <tdevries@suse.de>
|
|
In the failure seen by Philippe here:
https://inbox.sourceware.org/gdb-patches/20221120173024.3647464-1-philippe.waroquiers@skynet.be/
... the testsuite only outputs PASSes, and an ERROR, resulting from an
uncaught exception. This is a bit sneaky, because ERRORs are not
reported in the test summary. In certain circumstances, it can be easy
to miss.
Normally, gdb_test_multiple outputs an UNRESOLVED when GDB crashes. But
this is only if it manages to send the command, and it's that command
that crashes GDB. Here, the ERROR is due to the fact that GDB had
already crashed by the time we entered gdb_test_multiple and tried to
send a command. GDB was crashed by the previous "file" command, sent by
gdb_unload. Because gdb_unload uses bare expect, it didn't record a
test failure when crashing GDB (this will be addressed separately).
In this patch, I propose to make gdb_test_multiple call unresolved
directly and return -1 send_gdb fails. This way, if GDB is already
crashed by the time we enter gdb_test_multiple, it will leave a trace in
the test results in the form of an UNRESOLVED. It will also spare us
the not-so-useful-in-my-opinion TCL backtrace.
Before, it looks like:
ERROR: Couldn't send python print(objfile.filename) to GDB.
ERROR: : spawn id exp9 not open
while executing
"expect {
-i exp9 -timeout 10
-re ".*A problem internal to GDB has been detected" {
fail "$message (GDB internal error)"
gdb_internal_error..."
("uplevel" body line 1)
invoked from within
"uplevel $body" NONE : spawn id exp9 not open
And after:
Couldn't send python print(objfile.filename) to GDB.
UNRESOLVED: gdb.python/py-objfile.exp: objfile.filename after objfile is unloaded
Change-Id: I72af8dc0d687826fc3f76911c27a9e5f91b677ba
Approved-By: Tom de Vries <tdevries@suse.de>
|
|
The canonical form of 'if' in modern TCL is 'if {} {}'. But there's
still a bunch of places in the testsuite where we make use of the
'then' keyword, and sometimes these get copies into new tests, which
just spreads poor practice.
This commit removes all use of the 'then' keyword from the testsuite
library files (in boards/, config/, and lib/). Previous commits have
removed all uses of the 'then' keyword from the test script files,
this commit just cleans up the library files.
There should be no changes in what is tested after this commit.
|
|
The canonical form of 'if' in modern TCL is 'if {} {}'. But there's
still a bunch of places in the testsuite where we make use of the
'then' keyword, and sometimes these get copies into new tests, which
just spreads poor practice.
This commit removes all use of the 'then' keyword from the remaining
gdb.*/*.exp scripts. Previous commits have done the bulk of this
removal, this commit just handles the remaining directories that each
contain a low number of instances.
There should be no changes in what is tested after this commit.
|
|
The canonical form of 'if' in modern TCL is 'if {} {}'. But there's
still a bunch of places in the testsuite where we make use of the
'then' keyword, and sometimes these get copies into new tests, which
just spreads poor practice.
This commit removes all use of the 'then' keyword from the gdb.multi/
test script directory.
There should be no changes in what is tested after this commit.
|
|
The canonical form of 'if' in modern TCL is 'if {} {}'. But there's
still a bunch of places in the testsuite where we make use of the
'then' keyword, and sometimes these get copies into new tests, which
just spreads poor practice.
This commit removes all use of the 'then' keyword from the gdb.fortran/
test script directory.
There should be no changes in what is tested after this commit.
|
|
The canonical form of 'if' in modern TCL is 'if {} {}'. But there's
still a bunch of places in the testsuite where we make use of the
'then' keyword, and sometimes these get copies into new tests, which
just spreads poor practice.
This commit removes all use of the 'then' keyword from the gdb.disasm/
test script directory.
There should be no changes in what is tested after this commit.
|
|
The canonical form of 'if' in modern TCL is 'if {} {}'. But there's
still a bunch of places in the testsuite where we make use of the
'then' keyword, and sometimes these get copies into new tests, which
just spreads poor practice.
This commit removes all use of the 'then' keyword from the gdb.reverse/
test script directory.
There should be no changes in what is tested after this commit.
|
|
The canonical form of 'if' in modern TCL is 'if {} {}'. But there's
still a bunch of places in the testsuite where we make use of the
'then' keyword, and sometimes these get copies into new tests, which
just spreads poor practice.
This commit removes all use of the 'then' keyword from the gdb.trace/
test script directory.
There should be no changes in what is tested after this commit.
|
|
The canonical form of 'if' in modern TCL is 'if {} {}'. But there's
still a bunch of places in the testsuite where we make use of the
'then' keyword, and sometimes these get copies into new tests, which
just spreads poor practice.
This commit removes all use of the 'then' keyword from the gdb.threads/
test script directory.
There should be no changes in what is tested after this commit.
|
|
The canonical form of 'if' in modern TCL is 'if {} {}'. But there's
still a bunch of places in the testsuite where we make use of the
'then' keyword, and sometimes these get copies into new tests, which
just spreads poor practice.
This commit removes all use of the 'then' keyword from the gdb.python/
test script directory.
There should be no changes in what is tested after this commit.
|
|
The canonical form of 'if' in modern TCL is 'if {} {}'. But there's
still a bunch of places in the testsuite where we make use of the
'then' keyword, and sometimes these get copies into new tests, which
just spreads poor practice.
This commit removes all use of the 'then' keyword from the gdb.cp/
test script directory.
There should be no changes in what is tested after this commit.
|
|
The canonical form of 'if' in modern TCL is 'if {} {}'. But there's
still a bunch of places in the testsuite where we make use of the
'then' keyword, and sometimes these get copies into new tests, which
just spreads poor practice.
This commit removes all use of the 'then' keyword from the gdb.arch/
test script directory.
There should be no changes in what is tested after this commit.
|
|
The canonical form of 'if' in modern TCL is 'if {} {}'. But there's
still a bunch of places in the testsuite where we make use of the
'then' keyword, and sometimes these get copies into new tests, which
just spreads poor practice.
This commit removes all use of the 'then' keyword from the gdb.base/
test script directory.
There should be no changes in what is tested after this commit.
|
|
The canonical form of 'if' in modern TCL is 'if {} {}'. But there's
still a bunch of places in the testsuite where we make use of the
'then' keyword, and sometimes these get copies into new tests, which
just spreads poor practice.
This commit removes all use of the 'then' keyword from the gdb.ada/
test script directory.
There should be no changes in what is tested after this commit.
|
|
The gdb.fortran/nested-funcs.exp test script has DOS line endings. I
can see no reason why this script needs DOS line endings.
Convert to UNIX line endings.
There should be no change in what is tested after this commit.
|
|
On powerpc64le-linux I run into:
...
(gdb) PASS: gdb.ada/task_watch.exp: info tasks before inserting breakpoint
watch -location value task 3^M
Watchpoint 2: -location value^M
(gdb) PASS: gdb.ada/task_watch.exp: watch -location value task 3
continue^M
Continuing.^M
[Thread 0x7ffff7ccf170 (LWP 65550) exited]^M
[Thread 0x7ffff7abf170 (LWP 65551) exited]^M
FAIL: gdb.ada/task_watch.exp: continue to watchpoint (timeout)
...
On x86_64-linux (where the test-case passes), a hardware watchpoint is used:
...
(gdb) PASS: gdb.ada/task_watch.exp: info tasks before inserting breakpoint
watch -location value task 3^M
Hardware watchpoint 2: -location value^M
...
and after forcing "set can-use-hw-watchpoints 0" we can intermittently
reproduce the same failure.
In the gdb documentation related to watchpoints in multi-threaded programs, we
read:
...
Warning: In multi-threaded programs, software watchpoints have only limited
usefulness. If GDB creates a software watchpoint, it can only watch the value
of an expression in a single thread. If you are confident that the expression
can only change due to the current thread’s activity (and if you are also
confident that no other thread can become current), then you can use software
watchpoints as usual. However, GDB may not notice when a non-current thread’s
activity changes the expression. (Hardware watchpoints, in contrast, watch an
expression in all threads.)
...
Since the ada task construct is mapped onto threads, it seems that the
same limitation holds for tasks.
Fix this by using skip_hw_watchpoint_tests.
Tested on powerpc64-linux.
Tested-By: Carl Love <cel@us.ibm.com>
|
|
On powerpc64le-linux, with test-case gdb.ada/out_of_line_in_inlined.exp I run
into:
...
(gdb) run ^M
Starting program: foo_o224_021-all ^M
^M
Breakpoint 1, 0x0000000010002f48 in foo_o224_021.child1.child2 (s=...) at \
foo_o224_021.adb:24^M
24 function Child2 (S : String) return Boolean is -- STOP^M
(gdb) FAIL: gdb.ada/out_of_line_in_inlined.exp: scenario=all: \
run to foo_o224_021.child1.child2
...
The breakpoint is correctly set at the local entry point, and given that the
local entry point doesn't correspond to a line number entry, the instruction
address of the breakpoint is shown.
The problem is that test-case doesn't expect the breakpoint address.
Fix this by allowing the breakpoint address to occur.
Tested on powerpc64le-linux.
|
|
I broke gdb.ada/start.exp, and did not notice it, because it outputs an
UNTESTED if gdb_start_cmd fails. I don't really see when start would
fail and it's not a problem that should be looked at. Change all spots
that call untested after a gdb_start_cmd failure, use fail instead.
Doing so caused some failures with the native-gdbserver board. Some
tests that use "start" were relying on the fact that start would fail
with that board to just return with "untested". Change them to add an
early return if use_gdb_stub returns true.
Some gdb.pascal tests also failed with native-gdbserver, because they
did use gdb_start_cmd to start the inferior, for no good reason.
Convert them to use runto_main instead, which does the right thing if
the target is a stub.
A further refactoring could be to make gdb_start_cmd match the expected
breakpoint hit and the prompt, which it doesn't do currently (it leaves
that to the callers, but not all of them do).
Change-Id: I097370851213e798ff29fb6cf8ba25ef7d2be007
Reviewed-By: Bruno Larsen <blarsen@redhat.com>
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
The code to create a range type has a heuristic to decide whether the
range is unsigned. However, this heuristic can fail if the upper
bound of the range has its high bit set, because the test is done
using LONGEST.
With this patch, if the underlying type of a range is unsigned, then
the range will always be unsigned. A new test is included.
Regression tested on x86-64 Fedora 34. We've also been using this
internally at AdaCore for a while.
|
|
New in this version:
- Better comment in target_kill
- Uncomment line in test to avoid hanging when exiting, when testing on
native-extended-gdbserver
PR 28275 shows that doing a sequence of:
- Run inferior in background (run &)
- kill that inferior
- Run again
We get into this assertion:
/home/smarchi/src/binutils-gdb/gdb/target.c:2590: internal-error: target_wait: Assertion `!proc_target->commit_resumed_state' failed.
#0 internal_error_loc (file=0x5606b344e740 "/home/smarchi/src/binutils-gdb/gdb/target.c", line=2590, fmt=0x5606b344d6a0 "%s: Assertion `%s' failed.") at /home/smarchi/src/binutils-gdb/gdbsupport/errors.cc:54
#1 0x00005606b6296475 in target_wait (ptid=..., status=0x7fffb9390630, options=...) at /home/smarchi/src/binutils-gdb/gdb/target.c:2590
#2 0x00005606b5767a98 in startup_inferior (proc_target=0x5606bfccb2a0 <the_amd64_linux_nat_target>, pid=3884857, ntraps=1, last_waitstatus=0x0, last_ptid=0x0) at /home/smarchi/src/binutils-gdb/gdb/nat/fork-inferior.c:482
#3 0x00005606b4e6c9c5 in gdb_startup_inferior (pid=3884857, num_traps=1) at /home/smarchi/src/binutils-gdb/gdb/fork-child.c:132
#4 0x00005606b50f14a5 in inf_ptrace_target::create_inferior (this=0x5606bfccb2a0 <the_amd64_linux_nat_target>, exec_file=0x604000039f50 "/home/smarchi/build/binutils-gdb/gdb/test", allargs="", env=0x61500000a580, from_tty=1)
at /home/smarchi/src/binutils-gdb/gdb/inf-ptrace.c:105
#5 0x00005606b53b6d23 in linux_nat_target::create_inferior (this=0x5606bfccb2a0 <the_amd64_linux_nat_target>, exec_file=0x604000039f50 "/home/smarchi/build/binutils-gdb/gdb/test", allargs="", env=0x61500000a580, from_tty=1)
at /home/smarchi/src/binutils-gdb/gdb/linux-nat.c:978
#6 0x00005606b512b79b in run_command_1 (args=0x0, from_tty=1, run_how=RUN_NORMAL) at /home/smarchi/src/binutils-gdb/gdb/infcmd.c:468
#7 0x00005606b512c236 in run_command (args=0x0, from_tty=1) at /home/smarchi/src/binutils-gdb/gdb/infcmd.c:526
When running the kill command, commit_resumed_state for the
process_stratum_target (linux-nat, here) is true. After the kill, when
there are no more threads, commit_resumed_state is still true, as
nothing touches this flag during the kill operation. During the
subsequent run command, run_command_1 does:
scoped_disable_commit_resumed disable_commit_resumed ("running");
We would think that this would clear the commit_resumed_state flag of
our native target, but that's not the case, because
scoped_disable_commit_resumed iterates on non-exited inferiors in order
to find active process targets. And after the kill, the inferior is
exited, and the native target was unpushed from it anyway. So
scoped_disable_commit_resumed doesn't touch the commit_resumed_state
flag of the native target, it stays true. When reaching target_wait, in
startup_inferior (to consume the initial expect stop events while the
inferior is starting up and working its way through the shell),
commit_resumed_state is true, breaking the contract saying that
commit_resumed_state is always false when calling the targets' wait
method.
(note: to be correct, I think that startup_inferior should toggle
commit_resumed between the target_wait and target_resume calls, but I'll
ignore that for now)
I can see multiple ways to fix this. In the end, we need
commit_resumed_state to be cleared by the time we get to that
target_wait. It could be done at the end of the kill command, or at the
beginning of the run command.
To keep things in a coherent state, I'd like to make it so that after
the kill command, when the target is left with no threads, its
commit_resumed_state flag is left to false. This way, we can keep
working with the assumption that a target with no threads (and therefore
no running threads) has commit_resumed_state == false.
Do this by adding a scoped_disable_commit_resumed in target_kill. It
clears the target's commit_resumed_state on entry, and leaves it false
if the target does not have any resumed thread on exit. That means,
even if the target has another inferior with stopped threads,
commit_resumed_state will be left to false, which makes sense.
Add a test that tries to cover various combinations of actions done
while an inferior is running (and therefore while commit_resumed_state
is true on the process target).
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28275
Change-Id: I8e6fe6dc1f475055921520e58cab68024039a1e9
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
New in this version: add a dedicated test.
When I do this:
$ ./gdb -nx --data-directory=data-directory -q \
/bin/sleep \
-ex "maint set target-non-stop on" \
-ex "tar ext :1234" \
-ex "set remote exec-file /bin/sleep" \
-ex "run 1231 &" \
-ex add-inferior \
-ex "inferior 2"
Reading symbols from /bin/sleep...
(No debugging symbols found in /bin/sleep)
Remote debugging using :1234
Starting program: /bin/sleep 1231
Reading /lib64/ld-linux-x86-64.so.2 from remote target...
warning: File transfers from remote targets can be slow. Use "set sysroot" to access files locally instead.
Reading /lib64/ld-linux-x86-64.so.2 from remote target...
Reading /usr/lib/debug/.build-id/a6/7a1408f18db3576757eea210d07ba3fc560dff.debug from remote target...
[New inferior 2]
Added inferior 2 on connection 1 (extended-remote :1234)
[Switching to inferior 2 [<null>] (<noexec>)]
(gdb) Reading /lib/x86_64-linux-gnu/libc.so.6 from remote target...
attach 3659848
Attaching to process 3659848
/home/smarchi/src/binutils-gdb/gdb/thread.c:85: internal-error: inferior_thread: Assertion `current_thread_ != nullptr' failed.
Note the "attach" command just above. When doing it on the command-line
with a -ex switch, the bug doesn't trigger.
The internal error of GDB is actually caused by GDBserver crashing, and
the error recovery of GDB is not on point. This patch aims to fix just
the GDBserver crash, not the GDB problem.
GDBserver crashes with a segfault here:
(gdb) bt
#0 0x00005555557fb3f4 in find_one_thread (ptid=...) at /home/smarchi/src/binutils-gdb/gdbserver/thread-db.cc:177
#1 0x00005555557fd5cf in thread_db_thread_handle (ptid=<error reading variable: Cannot access memory at address 0xffffffffffffffa0>, handle=0x7fffffffc400, handle_len=0x7fffffffc3f0)
at /home/smarchi/src/binutils-gdb/gdbserver/thread-db.cc:461
#2 0x000055555578a0b6 in linux_process_target::thread_handle (this=0x5555558a64c0 <the_x86_target>, ptid=<error reading variable: Cannot access memory at address 0xffffffffffffffa0>, handle=0x7fffffffc400,
handle_len=0x7fffffffc3f0) at /home/smarchi/src/binutils-gdb/gdbserver/linux-low.cc:6905
#3 0x00005555556dfcc6 in handle_qxfer_threads_worker (thread=0x60b000000510, buffer=0x7fffffffc8a0) at /home/smarchi/src/binutils-gdb/gdbserver/server.cc:1645
#4 0x00005555556e00e6 in operator() (__closure=0x7fffffffc5e0, thread=0x60b000000510) at /home/smarchi/src/binutils-gdb/gdbserver/server.cc:1696
#5 0x00005555556f54be in for_each_thread<handle_qxfer_threads_proper(buffer*)::<lambda(thread_info*)> >(struct {...}) (func=...) at /home/smarchi/src/binutils-gdb/gdbserver/gdbthread.h:159
#6 0x00005555556e0242 in handle_qxfer_threads_proper (buffer=0x7fffffffc8a0) at /home/smarchi/src/binutils-gdb/gdbserver/server.cc:1694
#7 0x00005555556e04ba in handle_qxfer_threads (annex=0x629000000213 "", readbuf=0x621000019100 '\276' <repeats 200 times>..., writebuf=0x0, offset=0, len=4097)
at /home/smarchi/src/binutils-gdb/gdbserver/server.cc:1732
#8 0x00005555556e1989 in handle_qxfer (own_buf=0x629000000200 "qXfer:threads", packet_len=26, new_packet_len_p=0x7fffffffd630) at /home/smarchi/src/binutils-gdb/gdbserver/server.cc:2045
#9 0x00005555556e720a in handle_query (own_buf=0x629000000200 "qXfer:threads", packet_len=26, new_packet_len_p=0x7fffffffd630) at /home/smarchi/src/binutils-gdb/gdbserver/server.cc:2685
#10 0x00005555556f1a01 in process_serial_event () at /home/smarchi/src/binutils-gdb/gdbserver/server.cc:4176
#11 0x00005555556f4457 in handle_serial_event (err=0, client_data=0x0) at /home/smarchi/src/binutils-gdb/gdbserver/server.cc:4514
#12 0x0000555555820f56 in handle_file_event (file_ptr=0x607000000250, ready_mask=1) at /home/smarchi/src/binutils-gdb/gdbsupport/event-loop.cc:573
#13 0x0000555555821895 in gdb_wait_for_event (block=1) at /home/smarchi/src/binutils-gdb/gdbsupport/event-loop.cc:694
#14 0x000055555581f533 in gdb_do_one_event (mstimeout=-1) at /home/smarchi/src/binutils-gdb/gdbsupport/event-loop.cc:264
#15 0x00005555556ec9fb in start_event_loop () at /home/smarchi/src/binutils-gdb/gdbserver/server.cc:3512
#16 0x00005555556f0769 in captured_main (argc=4, argv=0x7fffffffe0d8) at /home/smarchi/src/binutils-gdb/gdbserver/server.cc:3992
#17 0x00005555556f0e3f in main (argc=4, argv=0x7fffffffe0d8) at /home/smarchi/src/binutils-gdb/gdbserver/server.cc:4078
The reason is a wrong current process when find_one_thread is called.
The current process is the 2nd one, which was just attached. It does
not yet have thread_db data (proc->priv->thread_db is nullptr). As we
iterate on all threads of all process to fulfull the qxfer:threads:read
request, we get to a thread of process 1 for which we haven't read
thread_db information yet (lwp_info::thread_known is false), so we get
into find_one_thread. find_one_thread uses
`current_process ()->priv->thread_db`, assuming the current process
matches the ptid passed as a parameter, which is wrong. A segfault
happens when trying to dereference that thread_db pointer.
Fix this by making find_one_thread not assume what the current process /
current thread is. If it needs to call into libthread_db, which we know
will try to read memory from the current process, then temporarily set
the current process.
In the case where the thread is already know and we return early, we
don't need to switch process.
Add a test to reproduce this specific situation.
Change-Id: I09b00883e8b73b7e5f89d0f47cb4e9c0f3d6caaa
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
PR cli/29800 points out that "document" will now crash when the
argument is an undefined command. This is a regression due to the
"document user-defined aliases" patch.
Approved-By: Joel Brobecker <brobecker@adacore.com>
Reviewed-By: Philippe Waroquiers <philippe.waroquiers@skynet.be>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29800
|
|
On powerpc64le-linux, I run into:
...
(gdb) PASS: gdb.opt/solib-intra-step.exp: first-hit
step^M
28 { /* first-retry */^M
(gdb) FAIL: gdb.opt/solib-intra-step.exp: second-hit
...
It's a bit easier to understand what happens if we do a full stepping session:
...
Temporary breakpoint 1, main ()
at solib-intra-step-main.c:23
23 shlib_first ();
(gdb) step
shlib_first () at solib-intra-step-lib.c:29
29 shlib_second (0); /* first-hit */
(gdb) step
28 { /* first-retry */
(gdb) step
29 shlib_second (0); /* first-hit */
(gdb) step
shlib_second (dummy=0)
at solib-intra-step-lib.c:23
23 abort (); /* second-hit */
...
and compare that to the line info:
...
CU: solib-intra-step-lib.c:
File name Line number Starting address View Stmt
solib-intra-step-lib.c 22 0x710 x
solib-intra-step-lib.c 23 0x724 x
solib-intra-step-lib.c 28 0x740 x
solib-intra-step-lib.c 29 0x74c x
solib-intra-step-lib.c 28 0x750 x
solib-intra-step-lib.c 29 0x758 x
solib-intra-step-lib.c 30 0x760 x
solib-intra-step-lib.c - 0x77c
...
So we step from line 29 to line 28, and back to line 29, which is behaviour
that matches the line table. The peculiar order is due to using optimization.
The problem is that the test-case doesn't expect this order.
Fix this by allowing this order in the test-case.
Tested on powerpc64le-linux.
PR testsuite/29792
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29792
|
|
This commit addresses one of the issues identified in PR gdb/28275.
Bug gdb/28275 identifies a number of situations in which this assert:
Assertion `!proc_target->commit_resumed_state' failed.
could be triggered. There's actually a number of similar places where
this assert is found in GDB, the two of interest in gdb/28275 are in
target_wait and target_stop.
In one of the comments:
https://sourceware.org/bugzilla/show_bug.cgi?id=28275#c1
steps to trigger the assertion within target_stop were identified when
using a modified version of the gdb.threads/detach-step-over.exp test
script.
In the gdb.threads/detach-step-over.exp test, we attach to a
multi-threaded inferior, and continue the inferior in asynchronous
(background) mode. Each thread is continuously hitting a conditional
breakpoint where the condition is always false. While the inferior is
running we detach. The goal is that we detach while GDB is performing a
step-over for the conditional breakpoint in at least one thread.
While detaching, if a step-over is in progress, then GDB has to
complete the step over before we can detach. This involves calling
target_stop and target_wait (see prepare_for_detach).
As far as gdb/28275 is concerned, the interesting part here, is the
the process_stratum_target::commit_resumed_state variable must be
false when target_stop and target_wait are called.
This is currently ensured because, in detach_command (infrun.c), we
create an instance of scoped_disable_commit_resumed, this ensures that
when target_detach is called, ::commit_resumed_state will be false.
The modification to the test that I propose here, and which exposed
the bug, is that, instead of using "detach" to detach from the
inferior, we instead use "quit". Quitting GDB after attaching to an
inferior will cause GDB to first detach, and then exit.
When we quit GDB we end up calling target_detach via a different code
path, the stack looks like:
#0 target_detach
#1 kill_or_detach
#2 quit_force
#3 quit_command
Along this path there is no scoped_disable_commit_resumed created.
::commit_resumed_state can be true when we reach prepare_for_detach,
which calls target_wait and target_stop, so the assertion will trigger.
In this commit, I propose fixing this by adding the creation of a
scoped_disable_commit_resumed into target_detach. This will ensure
that ::commit_resumed_state is false when calling prepare_for_detach
from within target_detach.
I did consider placing the scoped_disable_commit_resumed in
prepare_for_detach, however, placing it in target_detach ensures that
the target's commit_resumed_state flag is left to false if the detached
inferior was the last one for that target. It's the same rationale as
for patch "gdb: disable commit resumed in target_kill" that comes later
in this series, but for detach instead of kill.
detach_command still includes a scoped_disable_commit_resumed too, but I
think it is still relevant to cover the resumption at the end of the
function.
Co-Authored-By: Simon Marchi <simon.marchi@efficios.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28275
Change-Id: Ie128f7aba6ef0e018859275eca372e6ea738e96f
|
|
Factor out some bits of gdb.threads/detach-step-over.exp to procs in
preparation to adding some new variations of the test. Rename the
existing "test" proc and make it use proc_with_prefix.
Co-Authored-By: Simon Marchi <simon.marchi@efficios.com>
Change-Id: Ib4412545c81c8556029e0f7bfa9dd48d7a9f3189
|
|
Before doing further changes to this file, change to use the :: notation
instead of declaring global variables with the `global` keyword.
Change-Id: I72301fd8f4693fea61aac054ba17245a1f4442fb
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
On powerpc64le-linux, using gcc 4.8.5, I run into:
...
(gdb) PASS: gdb.arch/altivec-regs.exp: next (1)
next^M
11 c = vec_add (a, b);^M
(gdb) PASS: gdb.arch/altivec-regs.exp: next (2)
print/x a^M
$67 = {0xfefefefe, 0xfefefefe, 0xfefefefe, 0xfefefefe}^M
(gdb) FAIL: gdb.arch/altivec-regs.exp: print vector parameter a
...
Looking at the disassembly and the debug info, it's clear why there's
a FAIL.
The debug info says that the variable can be found at some stack location, but
the instructions don't seem to be writing there.
We can work around this by marking variable a volatile. Likewise for b.
Note that marking the variables as volatile doesn't change the location
information.
Tested on power64le-linux.
|
|
When running test-case gdb.base/bt-on-fatal-signal.exp on powerpc64le-linux I
noticed:
...
FAIL: gdb.base/bt-on-fatal-signal.exp: SEGV: scan for backtrace (timeout)
...
The timeout is 10 seconds, but generating the core file takes more than a
minute, probably due to slow NFS.
I managed to reproduce this behaviour independently of gdb, by compiling
"int main (void) { __builtin_abort (); }" and running it, which took 1.5
seconds for a core file 50 times smaller than the one for gdb.
Fix this by preventing the core file from being generated, using a wrapper
around gdb that does "ulimit -c 0".
Tested on x86_64-linux.
|
|
If we instrument cc-with-tweaks.sh to remove the .gnu_debugaltlink file after
dwz has created it, with test-case
gdb.threads/access-mem-running-thread-exit.exp and target board cc-with-dwz-m
we run into:
...
(gdb) file access-mem-running-thread-exit^M
Reading symbols from access-mem-running-thread-exit...^M
could not find '.gnu_debugaltlink' file for access-mem-running-thread-exit^M
...
followed a bit later by:
...
(gdb) file access-mem-running-thread-exit^M
Reading symbols from access-mem-running-thread-exit...^M
gdb/dwarf2/read.c:7284: internal-error: create_all_units: \
Assertion `per_objfile->per_bfd->all_units.empty ()' failed.^M
...
The problem is that create_units does not catch the error thrown by
dwarf2_get_dwz_file.
Fix this by catching the error and performing the necessary cleanup, getting
the same result for the first and second file command.
PR symtab/29805
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29805
|
|
Move all the remaining tests to a single test_break proc. It's a bit
big, but all of these are kind of tied together. The procs starts by
setting breakpoints, checks that we can see them in "info breakpoints",
and tries stopping on them.
Move all the "set bp_locationX" calls together at the top.
Change-Id: Id05f98957e1a3462532d2dbd577cd0a7c7263900
Approved-By: Kevin Buettner <kevinb@redhat.com>
|
|
Leave setting bp_location11 in the global scope, so that it's accessible
to other procs.
Change-Id: I8928f01640d3a1e993649b2168b9eda0724ee1d9
Approved-By: Kevin Buettner <kevinb@redhat.com>
|
|
Change-Id: Ifa7070943f1de22c2839fedf5f346d6591bb5a76
Approved-By: Kevin Buettner <kevinb@redhat.com>
|
|
Change-Id: I4390dd5da23bae83ccc513ad0de0169ddff7df12
Approved-By: Kevin Buettner <kevinb@redhat.com>
|
|
One special thing here is that the part just above this one, that sets
catchpoints and verifies they are not hit, requires that we resume
execution to verify that the catchpoints are indeed not hit. I guess
it was previously achieved by the until command, but it doesn't happen
now that the until is moved into test_break_default. Add a
gdb_continue_to_end after setting the catchpoints. If any catchpoint
were to be hit, it would catch the problem.
Change-Id: I5d4b43da91886b1beda9f6e56b05aa04331a9c05
Approved-By: Kevin Buettner <kevinb@redhat.com>
|
|
This one is a bit tricky. The clear tests seem to depend on the various
breakpoints that have been set before, starting with the "silent"
breakpoints. So, move all this in a single chunk, it can always be
split later if needed.
Change-Id: I7ba61a5b130ade63eda0c4790534840339f8a72f
Approved-By: Kevin Buettner <kevinb@redhat.com>
|
|
Change-Id: I593002373da971a0a4d6b5355d3fe321873479ab
Approved-By: Kevin Buettner <kevinb@redhat.com>
|
|
Change-Id: I9151ce9db9435722b758f41c6606b461bf15f320
Approved-By: Kevin Buettner <kevinb@redhat.com>
|
|
Change-Id: Id84babed1eeb3ce7d14b94ff332795964e8ead51
Approved-By: Kevin Buettner <kevinb@redhat.com>
|
