| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Replace the manual with_test_prefix in the do_test proc with using
foreach_with_prefix at the top-level. This helps reduce the indentation
level of the code a bit, and makes the test names in sync with the
variable names used in the code.
gdb/testsuite/ChangeLog:
* gdb.threads/non-ldr-exc-1.exp: Use foreach_with_prefix.
(do_test): Don't use with_test_prefix.
* gdb.threads/non-ldr-exc-2.exp: Use foreach_with_prefix.
(do_test): Don't use with_test_prefix.
* gdb.threads/non-ldr-exc-3.exp: Use foreach_with_prefix.
(do_test): Don't use with_test_prefix.
* gdb.threads/non-ldr-exc-4.exp: Use foreach_with_prefix.
(do_test): Don't use with_test_prefix.
Change-Id: I3af1df2eee1a8add427a67b6048bb6dede41cbeb
|
|
Maybe there's something I don't understand in that test, but the comment
seems wrong. It checks what happens when the non-leader thread does an
exit, not the leader.
gdb/testsuite/ChangeLog:
* gdb.threads/non-ldr-exit.exp: Fix comment.
Change-Id: I35c96a70c097fa9529737874f54f3f78036008a4
|
|
Clang fails to compile gdb.threads/tls-so_extern_main.c, giving the
following error:
/gdbtest/src/gdb/testsuite/gdb.threads/tls-so_extern_main.c:28:1:
warning: non-void function does not return a value [-Wreturn-type]
This commit adds a return statement to the offending function.
gdb/testsuite/ChangeLog:
* gdb.threads/tls-so_extern_main.c (tls_ptr): Add missing return
statement.
|
|
With test-case gdb.threads/tls.exp, we get these:
...
DUPLICATE: gdb.threads/tls.exp: selected thread: 4
DUPLICATE: gdb.threads/tls.exp: selected thread: 2
DUPLICATE: gdb.threads/tls.exp: selected thread: 3
...
Fix these using with_test_prefix.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-10-29 Tom de Vries <tdevries@suse.de>
* gdb.threads/tls.exp: Fix DUPLICATEs.
|
|
This commit does 's/runto main/runto_main/g' throughout.
gdb/testsuite/ChangeLog:
* gdb.ada/fun_in_declare.exp: Use "runto_main" instead of
"runto main".
* gdb.ada/small_reg_param.exp: Likewise.
* gdb.arch/powerpc-d128-regs.exp: Likewise.
* gdb.base/annota1.exp: Likewise.
* gdb.base/anon.exp: Likewise.
* gdb.base/breakpoint-in-ro-region.exp: Likewise.
* gdb.base/dprintf-non-stop.exp: Likewise.
* gdb.base/dprintf.exp: Likewise.
* gdb.base/gdb11530.exp: Likewise.
* gdb.base/gdb11531.exp: Likewise.
* gdb.base/gnu_vector.exp: Likewise.
* gdb.base/interrupt-noterm.exp: Likewise.
* gdb.base/memattr.exp: Likewise.
* gdb.base/step-over-syscall.exp: Likewise.
* gdb.base/watch-cond-infcall.exp: Likewise.
* gdb.base/watch-read.exp: Likewise.
* gdb.base/watch-vfork.exp: Likewise.
* gdb.base/watch_thread_num.exp: Likewise.
* gdb.base/watchpoint-stops-at-right-insn.exp: Likewise.
* gdb.guile/scm-frame-inline.exp: Likewise.
* gdb.linespec/explicit.exp: Likewise.
* gdb.opt/inline-break.exp: Likewise.
* gdb.python/py-frame-inline.exp: Likewise.
* gdb.reverse/break-precsave.exp: Likewise.
* gdb.reverse/break-reverse.exp: Likewise.
* gdb.reverse/consecutive-precsave.exp: Likewise.
* gdb.reverse/consecutive-reverse.exp: Likewise.
* gdb.reverse/finish-precsave.exp: Likewise.
* gdb.reverse/finish-reverse.exp: Likewise.
* gdb.reverse/fstatat-reverse.exp: Likewise.
* gdb.reverse/getresuid-reverse.exp: Likewise.
* gdb.reverse/i386-precsave.exp: Likewise.
* gdb.reverse/i386-reverse.exp: Likewise.
* gdb.reverse/i386-sse-reverse.exp: Likewise.
* gdb.reverse/i387-env-reverse.exp: Likewise.
* gdb.reverse/i387-stack-reverse.exp: Likewise.
* gdb.reverse/insn-reverse.exp: Likewise.
* gdb.reverse/machinestate-precsave.exp: Likewise.
* gdb.reverse/machinestate.exp: Likewise.
* gdb.reverse/pipe-reverse.exp: Likewise.
* gdb.reverse/readv-reverse.exp: Likewise.
* gdb.reverse/recvmsg-reverse.exp: Likewise.
* gdb.reverse/rerun-prec.exp: Likewise.
* gdb.reverse/s390-mvcle.exp: Likewise.
* gdb.reverse/solib-precsave.exp: Likewise.
* gdb.reverse/solib-reverse.exp: Likewise.
* gdb.reverse/step-precsave.exp: Likewise.
* gdb.reverse/step-reverse.exp: Likewise.
* gdb.reverse/time-reverse.exp: Likewise.
* gdb.reverse/until-precsave.exp: Likewise.
* gdb.reverse/until-reverse.exp: Likewise.
* gdb.reverse/waitpid-reverse.exp: Likewise.
* gdb.reverse/watch-precsave.exp: Likewise.
* gdb.reverse/watch-reverse.exp: Likewise.
* gdb.threads/kill.exp: Likewise.
* gdb.threads/tid-reuse.exp: Likewise.
Change-Id: I70f457253836019880b4d7fb981936afa56724c2
|
|
Commit 1eb8556f5a8b ("gdb: add infrun_debug_printf macro") changed the
debug output format for `set debug infrun 1`. The test
gdb.threads/stepi-random-signal.exp uses that debug output, and was
updated, but not correctly. It results in this failure:
FAIL: gdb.threads/stepi-random-signal.exp: stepi (no random signal)
Fix it by adjusting the pattern in the test.
gdb/testsuite/ChangeLog:
PR gdb/26532
* gdb.threads/stepi-random-signal.exp: Update pattern.
Change-Id: If5fa525e9545e32a286effe6a6184358374bd37c
|
|
Introduce this macro to print debug statements in the infrun.c file,
same idea as what was done in 9327494e0eeb ("gdb: add
linux_nat_debug_printf macro").
Although in this case, there are places outside infrun.c that print
debug statements if debug_infrun is set. So the macro has to be
declared in the header file, so that it can be used in these other
files.
Note one special case. In stop_all_threads, I've used an explicit
if (debug_infrun)
infrun_debug_printf_1 ("stop_all_threads", "done");
for the message in the SCOPE_EXIT. Otherwise, the message appears like
this:
[infrun] operator(): done
Until we find a better solution for extracting a meaningful function
name for lambda functions, I think it's fine to handle these special
cases manually, they are quite rare.
Some tests need to be updated, because they rely on some infrun debug
statements.
gdb/ChangeLog:
* infrun.h (infrun_debug_printf_1): New function declaration.
(infrun_debug_printf): New macro.
* infrun.c (infrun_debug_printf_1): Use infrun_debug_printf
throughout.
(infrun_debug_printf): New function.
* breakpoint.c (should_be_inserted): Use infrun_debug_printf.
(handle_jit_event): Likewise.
gdb/testsuite/ChangeLog:
* gdb.base/gdb-sigterm.exp (do_test): Update expected regexp.
* gdb.threads/signal-while-stepping-over-bp-other-thread.exp:
Likewise.
* gdb.threads/stepi-random-signal.exp: Likewise.
Change-Id: I66433c8a9caa64c8525ab57c593022b9d1956d5c
|
|
In openmp test-case gdb.threads/omp-par-scope.exp we xfail and kfail dependent
on omp_get_thread_num (). Since execution order of the threads can vary from
execution to execution, this can cause changes in test results.
F.i., we can see this difference between two test runs:
...
-KFAIL: single_scope: first thread: print i3 (PRMS: gdb/22214)
+PASS: single_scope: first thread: print i3
-PASS: single_scope: second thread: print i3
+KFAIL: single_scope: second thread: print i3 (PRMS: gdb/22214)
...
In both cases, the KFAIL is for omp_get_thread_num () == 1, but in one case
that corresponds to the first thread executing that bit of code, and in the
other case to the second thread.
Get rid of this difference by stabilizing execution order.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-07-20 Tom de Vries <tdevries@suse.de>
* gdb.threads/omp-par-scope.c (lock, lock2): New variable.
(omp_set_lock_in_order): New function.
(single_scope, multi_scope, nested_func, nested_parallel): Use
omp_set_lock_in_order and omp_unset_lock.
(main): Init and destroy lock and lock2.
|
|
gdb.threads/attach-slow-waitpid.exp
When building gdb using CFLAGS/CXXFLAGS+=-fsanitizer=address and
LDFLAGS+=-lasan, and running test-case gdb.threads/attach-slow-waitpid.exp,
we get:
...
spawn gdb -nw -nx -data-directory data-directory^M
==16079==ASan runtime does not come first in initial library list; \
you should either link runtime to your application or manually preload \
it with LD_PRELOAD.^M
ERROR: (eof) GDB never initialized.
ERROR: : spawn id exp10 not open
while executing
"expect {
-i exp10 -timeout 120
-re "Kill the program being debugged. .y or n. $" {
send_gdb "y\n" answer
verbose "\t\tKilling previous pro..."
("uplevel" body line 1)
invoked from within
"uplevel $body" NONE : spawn id exp10 not open
WARNING: remote_expect statement without a default case
ERROR: : spawn id exp10 not open
while executing
"expect {
-i exp10 -timeout 120
-re "Reading symbols from.*LZMA support was disabled.*$gdb_prompt $" {
verbose "\t\tLoaded $arg into $GDB; .gnu_..."
("uplevel" body line 1)
invoked from within
"uplevel $body" NONE : spawn id exp10 not open
ERROR: Couldn't load attach-slow-waitpid into GDB (eof).
ERROR: Couldn't send attach 16070 to GDB.
UNRESOLVED: gdb.threads/attach-slow-waitpid.exp: attach to target
...
Bail out at the first ERROR, such that we have instead:
...
ERROR: (eof) GDB never initialized.
UNTESTED: gdb.threads/attach-slow-waitpid.exp: \
Couldn't start GDB with preloaded lib
...
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-07-20 Tom de Vries <tdevries@suse.de>
* gdb.threads/attach-slow-waitpid.exp: Bail out if gdb_start fails.
|
|
Starting glibc 2.30, unistd.h declares gettid (for _GNU_SOURCE).
This clashes with a static gettid in test source
clone-new-thread-event.c:
...
gdb compile failed, gdb.threads/clone-new-thread-event.c:46:1: error: \
static declaration of 'gettid' follows non-static declaration
46 | gettid (void)
| ^~~~~~
In file included from /usr/include/unistd.h:1170,
from gdb.threads/clone-new-thread-event.c:27:
/usr/include/bits/unistd_ext.h:34:16: note: previous declaration of 'gettid' \
was here
34 | extern __pid_t gettid (void) __THROW;
| ^~~~~~
...
Fix this by renaming the static gettid to local_gettid.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-07-14 Tom de Vries <tdevries@suse.de>
* gdb.threads/clone-new-thread-event.c (gettid): Rename to ...
(local_gettid): ... this.
(fn): Update.
|
|
When running the testsuite with clang, a number of testcases fail to
build with the following errors:
warning: control reaches end of non-void function [-Wreturn-type]
warning: control may reach end of non-void function [-Wreturn-type]
This prevents a number of testcases from executing. This commit fixes.
gdb/testsuite/ChangeLog:
* gdb.base/info-os.c (main): Add return statement.
* gdb.base/info_minsym.c (minsym_fun): Likewise.
* gdb.base/large-frame-2.c (func): Likewise.
* gdb.base/pr10179-a.c (foo1, bar1): Likewise.
* gdb.base/pr10179-b.c (foo2): Likewise.
* gdb.base/valgrind-disp-step.c (foo): Likewise.
* gdb.base/watch-cond.c (func): Likewise.
* gdb.multi/goodbye.c (verylongfun): Likewise.
* gdb.multi/hello.c (commonfun): Likewise.
* gdb.python/py-finish-breakpoint.c (call_longjmp): Likewise.
* gdb.threads/fork-plus-threads.c (thread_func): Likewise.
* gdb.threads/forking-threads-plus-breakpoint.c (thread_forks):
Likewise.
* gdb.threads/hand-call-new-thread.c (foo): Likewise.
* gdb.threads/interrupt-while-step-over.c (child_function):
Likewise.
* gdb.trace/actions-changed.c (end): Likewise.
|
|
gdb/stubs/ChangeLog:
2020-04-28 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* ia64vms-stub.c: Fix typo in comment (thead -> thread).
gdb/testsuite/ChangeLog:
2020-04-28 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* gdb.threads/stop-with-handle.exp: Fix typo in comment
(theads -> threads).
gdbsupport/ChangeLog:
2020-04-28 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* gdb-sigmask.h: Fix typo (pthead_sigmask -> pthread_sigmask).
|
|
Consider a test-case consisting of source file test.c:
...
extern int aaa;
int
main (void)
{
return 0;
}
...
and test-2.c:
...
int aaa = 33;
...
compiled with debug info only for test.c:
...
$ gcc -c test.c -g; gcc -c test2.c; gcc test.o test2.o -g
...
When trying to print aaa, we get:
...
$ gdb -batch a.out -ex "print aaa"
'aaa' has unknown type; cast it to its declared type
...
but with -readnow we have:
...
$ gdb -readnow -batch a.out -ex "print aaa"
$1 = 33
...
In the -readnow case, the symbol for aaa in the full symtab has
LOC_UNRESOLVED, and the symbol type is combined with the minimal symbol
address, to read the value and print it without cast.
Without the -readnow, we create partial symbols, but the aaa decl is missing
from the partial symtabs, so we find it only in the minimal symbols, resulting
in the cast request. If the aaa decl would have been in the partial symtabs,
it would have been found, and the full symtab would have been expanded, after
which things would be as with -readnow.
The function add_partial_symbol has a comment on the LOC_UNRESOLVED +
minimal symbol addres construct at DW_TAG_variable handling:
...
else if (pdi->is_external)
{
/* Global Variable.
Don't enter into the minimal symbol tables as there is
a minimal symbol table entry from the ELF symbols already.
Enter into partial symbol table if it has a location
descriptor or a type.
If the location descriptor is missing, new_symbol will create
a LOC_UNRESOLVED symbol, the address of the variable will then
be determined from the minimal symbol table whenever the variable
is referenced.
...
but it's not triggered due to this test in scan_partial_symbols:
...
case DW_TAG_variable:
...
if (!pdi->is_declaration)
{
add_partial_symbol (pdi, cu);
}
...
Fix this in scan_partial_symbols by allowing external variable decls to be
added to the partial symtabs.
Build and reg-tested on x86_64-linux.
The patch caused this regression:
...
(gdb) print a_thread_local^M
Cannot find thread-local storage for process 0, executable file tls/tls:^M
Cannot find thread-local variables on this target^M
(gdb) FAIL: gdb.threads/tls.exp: print a_thread_local
...
while without the patch we have:
...
(gdb) print a_thread_local^M
Cannot read `a_thread_local' without registers^M
(gdb) PASS: gdb.threads/tls.exp: print a_thread_local
...
However, without the patch but with -readnow we have the same FAIL as with the
patch (filed as PR25807). In other words, the patch has the effect that we
get the same result with and without -readnow.
This can be explained as follows. Without the patch, and without -readnow, we
have two a_thread_locals, the def and the decl:
...
$ gdb -batch outputs/gdb.threads/tls/tls \
-ex "maint expand-symtabs" \
-ex "print a_thread_local" \
-ex "maint print symbols" \
| grep "a_thread_local;"
Cannot read `a_thread_local' without registers
int a_thread_local; computed at runtime
int a_thread_local; unresolved
...
while without the patch and with -readnow, we have the opposite order:
...
$ gdb -readnow -batch outputs/gdb.threads/tls/tls \
-ex "maint expand-symtabs" \
-ex "print a_thread_local" \
-ex "maint print symbols" \
| grep "a_thread_local;"
Cannot find thread-local storage for process 0, executable file tls/tls:
Cannot find thread-local variables on this target
int a_thread_local; unresolved
int a_thread_local; computed at runtime
...
With the patch we have the same order with and without -readnow, but just a
different one than before without -readnow.
Mark the "Cannot find thread-local variables on this target" variant a PR25807
kfail.
gdb/ChangeLog:
2020-04-22 Tom de Vries <tdevries@suse.de>
PR symtab/25764
* dwarf2/read.c (scan_partial_symbols): Allow external variable decls
in psymtabs.
gdb/testsuite/ChangeLog:
2020-04-22 Tom de Vries <tdevries@suse.de>
PR symtab/25764
* gdb.base/psym-external-decl-2.c: New test.
* gdb.base/psym-external-decl.c: New test.
* gdb.base/psym-external-decl.exp: New file.
* gdb.threads/tls.exp: Add PR25807 kfail.
|
|
Consider the test-case from this patch, compiled with pthread support:
...
$ gcc gdb/testsuite/gdb.threads/killed-outside.c -lpthread -g
...
After running to all_started, we can print pid:
...
$ gdb a.out -ex "b all_started" -ex run -ex "delete 1" -ex "p pid"
...
Reading symbols from a.out...
Breakpoint 1 at 0x40072b: file killed-outside.c, line 29.
Starting program: /data/gdb_versions/devel/a.out
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
[New Thread 0x7ffff77fc700 (LWP 3155)]
Thread 1 "a.out" hit Breakpoint 1, all_started () at killed-outside.c:29
29 }
$1 = 3151
(gdb)
...
If we then kill the inferior using an external SIGKILL:
...
(gdb) shell kill -9 3151
...
and subsequently continue:
...
(gdb) c
Continuing.
Couldn't get registers: No such process.
Couldn't get registers: No such process.
(gdb) Couldn't get registers: No such process.
(gdb) Couldn't get registers: No such process.
(gdb) Couldn't get registers: No such process.
<repeat>
...
gdb hangs repeating the same warning. Typing control-C no longer helps,
and we have to kill gdb.
This is a regression since commit 873657b9e8 "Preserve selected thread in
all-stop w/ background execution". The commit adds a
scoped_restore_current_thread typed variable restore_thread to
fetch_inferior_event, and the hang is caused by the constructor throwing an
exception.
Fix this by catching the exception in the constructor.
Build and reg-tested on x86_64-linux.
gdb/ChangeLog:
2020-04-21 Tom de Vries <tdevries@suse.de>
PR gdb/25471
* thread.c
(scoped_restore_current_thread::scoped_restore_current_thread): Catch
exception in get_frame_id.
gdb/testsuite/ChangeLog:
2020-04-21 Tom de Vries <tdevries@suse.de>
PR gdb/25471
* gdb.threads/killed-outside.c: New test.
* gdb.threads/killed-outside.exp: New file.
|
|
When running test-case gdb.threads/omp-par-scope.exp, I get this XPASS:
...
XPASS: gdb.threads/omp-par-scope.exp: nested_parallel: outer_threads: \
outer stop: get valueof "num"
...
for test:
...
set thread_num [get_valueof "" "num" "unknown"]
...
The intention of the test is to get the value of local variable num, which
has been set to:
...
int num = omp_get_thread_num ();
...
but the actually printed value is 'num':
...
(gdb) print num^M
$76 = num^M
...
This is due to the fact that num is missing in the locals, so instead we find
the enum member 'num' of enum expression_operator in glibc/intl/plural-exp.h.
Fix this by getting the value using a new proc get_local_valueof, which uses
the "info locals" commands to get the value.
Tested on x86_64-linux, with gcc 7.5.0 (where the test xfails) and gcc
10.0.1 (where the test passes).
|
|
When running test-cases gdb.threads/step-over-lands-on-breakpoint.exp and
gdb.threads/step-over-trips-on-watchpoint.exp with target board
unix/-flto/-O0/-flto-partition=none/-ffat-lto-objects, we run into timeouts
due not being able to set a breakpoint and then trying to continue to that
breakpoint.
In total, we run into 186 timeouts, which roughly corresponds to half an hour:
...
$ grep "FAIL.*(timeout)" gdb.sum \
| awk '{print $2}' \
| sort \
| uniq -c
66 gdb.threads/step-over-lands-on-breakpoint.exp:
120 gdb.threads/step-over-trips-on-watchpoint.exp:
...
Fix this by bailing out if the first break fails.
Tested on x86_64-linux, both with native and with target board mentioned above.
gdb/testsuite/ChangeLog:
2020-03-20 Tom de Vries <tdevries@suse.de>
* gdb.threads/step-over-lands-on-breakpoint.exp (do_test): Bail out if
first break fails.
* gdb.threads/step-over-trips-on-watchpoint.exp: (do_test): Same.
|
|
When running test-case gdb.threads/attach-many-short-lived-threads.exp with
check-read1, I ran into:
...
FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 1: \
no new threads (timeout)
...
Fix this by rewriting the gdb_test_multiple call using -lbl and exp_continue.
Tested on x86_64-linux, with make targets check and check-read1.
gdb/testsuite/ChangeLog:
2020-03-14 Tom de Vries <tdevries@suse.de>
* gdb.threads/attach-many-short-lived-threads.exp: Read "info threads"
result in line-by-line fashion.
|
|
When running the gdb.threads/execl.exp test-case, we run into this FAIL:
...
(gdb) continue^M
Continuing.^M
^M
Thread 1 "execl" hit Breakpoint 2, __GI_execl (path=0x6024a0 \
"build/gdb/testsuite/outputs/gdb.threads/execl/execl1", \
arg=<optimized out>) at execl.c:51^M
51 if (execl (new_image, new_image, NULL) == -1) \
/* set breakpoint here */^M
(gdb) FAIL: gdb.threads/execl.exp: continue across exec
...
The fail is due to the continue command hitting a breakpoint in __GI_execl
rather than main.
This problem originates from where we execute the "b 51" command, and get two
breakpoint locations:
...
(gdb) run ^M
Starting program: build/gdb/testsuite/outputs/gdb.threads/execl/execl ^M
[Thread debugging using libthread_db enabled]^M
Using host libthread_db library "/lib64/libthread_db.so.1".^M
^M
Breakpoint 1, main (argc=1, argv=0x7fffffffd3f8) at gdb.threads/execl.c:44^M
44 pthread_create (&thread1, NULL, thread_function, NULL);^M
(gdb) b 51^M
Breakpoint 2 at 0x400787: gdb.threads/execl.c:51. (2 locations)^M
(gdb) PASS: gdb.threads/execl.exp: set breakpoint at execl
...
Adding a "info breakpoints" command, we can see the locations:
...
(gdb) info breakpoints^M
Num Type Disp Enb Address What^M
1 breakpoint keep y 0x00000000004006ee in main at \
gdb.threads/execl.c:44^M
breakpoint already hit 1 time^M
2 breakpoint keep y <MULTIPLE> ^M
2.1 y 0x0000000000400787 in main at \
gdb.threads/execl.c:51^M
2.2 y 0x00007ffff758d925 in __GI_execl at \
execl.c:51^M
(gdb) PASS: gdb.threads/execl.exp: info breakpoints
...
The fact that the __GI_execl breakpoint location is there, is a bug, filed as
PR25656. Without debug info for GLIBC though, the bug is not triggered.
Fix the FAIL by working around the bug, and deleting the breakpoint after
hitting the first breakpoint location.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-03-12 Tom de Vries <tdevries@suse.de>
* gdb.threads/execl.exp: Delete breakpoint after hitting it.
|
|
I ran into:
...
Thread 3.1 "watchpoint-fork" hit Breakpoint 3, marker () at \
watchpoint-fork-mt.c:42^M
42 }^M
(gdb) parent2: 1945^M
FAIL: gdb.threads/watchpoint-fork.exp: child: multithreaded: breakpoint (A) \
after the second fork (timeout)
...
The problem is that the FAILing gdb_test expects '(gdb) ' to be the last thing
printed, but the inferior prints something after that.
A similar FAIL is described in the sources in watchpoint-fork-parent.c:
...
printf ("child%d: %d\n", nr, (int) getpid ());
/* Delay to get both the "child%d" and "parent%d" message printed
without a race breaking expect by its endless wait on `$gdb_prompt$':
Breakpoint 3, marker () at watchpoint-fork.c:33
33 }
(gdb) parent2: 14223 */
i = sleep (1);
...
I noticed that while the executables print output, the output is not verified in
the test-case, so it's merely debug output.
Fix this by:
- guarding the prints in the executables (as well as related
sleep and setbuf calls) with #if DEBUG, and
- compiling by default with DEBUG=0.
gdb/testsuite/ChangeLog:
2020-01-29 Tom de Vries <tdevries@suse.de>
* gdb.threads/watchpoint-fork-child.c: Guard prints with #if DEBUG.
* gdb.threads/watchpoint-fork-mt.c: Same.
* gdb.threads/watchpoint-fork-parent.c: Same.
* gdb.threads/watchpoint-fork-st.c: Same.
* gdb.threads/watchpoint-fork.exp: Compile with DEBUG=0.
Change-Id: I63efd4c7771f96b5f5cd87ef2ab36795484ae2be
|
|
This commit extends the CLI a bit for multi-target, in three ways.
#1 - New "info connections" command.
This is a new command that lists the open connections (process_stratum
targets). For example, if you're debugging two remote connections, a
couple local/native processes, and a core dump, all at the same time,
you might see something like this:
(gdb) info connections
Num What Description
1 remote 192.168.0.1:9999 Remote serial target in gdb-specific protocol
2 remote 192.168.0.2:9998 Remote serial target in gdb-specific protocol
* 3 native Native process
4 core Local core dump file
#2 - New "info inferiors" "Connection" column
You'll also see a new matching "Connection" column in "info
inferiors", showing you which connection an inferior is bound to:
(gdb) info inferiors
Num Description Connection Executable
1 process 18526 1 (remote 192.168.0.1:9999) target:/tmp/a.out
2 process 18531 2 (remote 192.168.0.2:9998) target:/tmp/a.out
3 process 19115 3 (native) /tmp/prog1
4 process 6286 4 (core) myprogram
* 5 process 19122 3 (native) /bin/hello
#3 - Makes "add-inferior" show the inferior's target connection
"add-inferior" now shows you the connection you've just bound the
inferior to, which is the current process_stratum target:
(gdb) add-inferior
[New inferior 2]
Added inferior 2 on connection 1 (extended-remote localhost:2346)
gdb/ChangeLog:
2020-01-10 Pedro Alves <palves@redhat.com>
* Makefile.in (COMMON_SFILES): Add target-connection.c.
* inferior.c (uiout_field_connection): New function.
(print_inferior): Add new "connection-id" column.
(add_inferior_command): Show connection number/string of added
inferior.
* process-stratum-target.h
(process_stratum_target::connection_string): New virtual method.
(process_stratum_target::connection_number): New field.
* remote.c (remote_target::connection_string): New override.
* target-connection.c: New file.
* target-connection.h: New file.
* target.c (decref_target): Remove process_stratum targets from
the connection list.
(target_stack::push): Add process_stratum targets to the
connection list.
gdb/testsuite/ChangeLog:
2020-01-10 Pedro Alves <palves@redhat.com>
* gdb.base/kill-detach-inferiors-cmd.exp: Adjust expected output
of "add-inferior".
* gdb.base/quit-live.exp: Likewise.
* gdb.base/remote-exec-file.exp: Likewise.
* gdb.guile/scm-progspace.exp: Likewise.
* gdb.linespec/linespec.exp: Likewise.
* gdb.mi/new-ui-mi-sync.exp: Likewise.
* gdb.mi/user-selected-context-sync.exp: Likewise.
* gdb.multi/multi-target.exp (setup): Add "info connection" and
"info inferiors" tests.
* gdb.multi/remove-inferiors.exp: Adjust expected output of
"add-inferior".
* gdb.multi/watchpoint-multi.exp: Likewise.
* gdb.python/py-inferior.exp: Likewise.
* gdb.server/extended-remote-restart.exp: Likewise.
* gdb.threads/fork-plus-threads.exp: Adjust expected output of
"info inferiors".
* gdb.threads/forking-threads-plus-breakpoint.exp: Likewise.
* gdb.trace/report.exp: Likewise.
|
|
In non-stop mode, if you resume the program in the background (with
"continue&", for example), then gdb makes sure to not switch the
current thread behind your back. That means that you can be sure that
the commands you type apply to the thread you selected, even if some
other thread that was running in the background hits some event just
while you're typing.
In all-stop mode, however, if you resume the program in the
background, gdb let's the current thread switch behind your back.
This is bogus, of course. All-stop and non-stop background
resumptions should behave the same.
This patch fixes that, and adds a testcase that exposes the bad
behavior in current master.
The fork-running-state.exp changes are necessary because that
preexisting testcase was expecting the old behavior:
Before:
continue &
Continuing.
(gdb)
[Attaching after process 8199 fork to child process 8203]
[New inferior 2 (process 8203)]
info threads
Id Target Id Frame
1.1 process 8199 "fork-running-st" (running)
* 2.1 process 8203 "fork-running-st" (running)
(gdb)
After:
continue &
Continuing.
(gdb)
[Attaching after process 24660 fork to child process 24664]
[New inferior 2 (process 24664)]
info threads
Id Target Id Frame
* 1.1 process 24660 "fork-running-st" (running)
2.1 process 24664 "fork-running-st" (running)
(gdb)
Here we see that before this patch GDB switches current inferior to
the new inferior behind the user's back, as a side effect of handling
the fork.
The delete_exited_threads call in inferior_appeared is there to fix an
issue that Baris found in a previous version of this patch. The
fetch_inferior_event change increases the refcount of the current
thread, and in case the fetched inferior event denotes a thread exit,
the thread will not be deleted right away. A non-deleted but exited
thread stays in the inferior's thread list. This, in turn, causes the
"init_thread_list" call in inferior.c to be skipped. A consequence is
that the global thread ID counter is not restarted if the current
thread exits, and then the inferior is restarted:
(gdb) start
Temporary breakpoint 1 at 0x4004d6: file main.c, line 21.
Starting program: /tmp/main
Temporary breakpoint 1, main () at main.c:21
21 foo ();
(gdb) info threads -gid
Id GId Target Id Frame
* 1 1 process 16106 "main" main () at main.c:21
(gdb) c
Continuing.
[Inferior 1 (process 16106) exited normally]
(gdb) start
Temporary breakpoint 2 at 0x4004d6: file main.c, line 21.
Starting program: /tmp/main
Temporary breakpoint 2, main () at main.c:21
21 foo ();
(gdb) info threads -gid
Id GId Target Id Frame
* 1 2 process 16138 "main" main () at main.c:21
^^^
Notice that GId == 2 above. It should have been "1" instead.
The new tids-git-reset.exp testcase exercises the problem above.
gdb/ChangeLog:
2020-01-10 Pedro Alves <palves@redhat.com>
* gdbthread.h (scoped_restore_current_thread)
<dont_restore, restore, m_dont_restore>: Declare.
* thread.c (thread_alive): Add assertion. Return bool.
(switch_to_thread_if_alive): New.
(prune_threads): Switch inferior/thread.
(print_thread_info_1): Switch thread before calling target methods.
(scoped_restore_current_thread::restore): New, factored out from
...
(scoped_restore_current_thread::~scoped_restore_current_thread):
... this.
(scoped_restore_current_thread::scoped_restore_current_thread):
Add assertion.
(thread_apply_all_command, thread_select): Use
switch_to_thread_if_alive.
gdb/testsuite/ChangeLog:
2020-01-10 Pedro Alves <palves@redhat.com>
* gdb.base/fork-running-state.exp (do_test): Adjust expected
output.
* gdb.threads/async.c: New.
* gdb.threads/async.exp: New.
* gdb.multi/tids-gid-reset.c: New.
* gdb.multi/tids-gid-reset.exp: New.
|
|
gdb/ChangeLog:
Update copyright year range in all GDB files.
|
|
Add tests which check for accessibility of variables from within
various OpenMP parallel regions.
Tested on Fedora 27, 28, 29, 30, and 31. I also tested with my OpenMP
work on Fedora 30. The test has been annotated with setup_xfail and
setup_kfail statements so that there are no unexpected failures on any
of these platforms when using gcc. Better still, for my own testing
anyway, is that there are also no XPASSes or KPASSes either. So,
regardless of platform, when using gcc, and regardless of whether my
(not yet public) OpenMP work is used, seeing a FAIL indicates a real
problem.
Fedora 27 results:
# of expected passes 85
# of expected failures 65
(Note: I have not retested F27 since v1 of the patch; it's possible
that the numbers will be slightly different for v2.)
Fedora 28, 29, 30 results:
# of expected passes 131
# of expected failures 4
# of known failures 16
Fedora 30, 31 results w/ my OpenMP work:
# of expected passes 151
The above results all use gcc, either the system gcc or a development
gcc (when testing against my OpenMP work in GDB). I've also tested
with clang 9.0.0 and icc 19.0.5.281 20190815 on Fedora 31.
Fedora 31, clang:
FAIL: gdb.threads/omp-par-scope.exp: single_scope: first thread: print s1
FAIL: gdb.threads/omp-par-scope.exp: single_scope: first thread: print s3
FAIL: gdb.threads/omp-par-scope.exp: single_scope: first thread: print i1
FAIL: gdb.threads/omp-par-scope.exp: single_scope: first thread: print i3
FAIL: gdb.threads/omp-par-scope.exp: single_scope: second thread: print s1
FAIL: gdb.threads/omp-par-scope.exp: single_scope: second thread: print s3
FAIL: gdb.threads/omp-par-scope.exp: single_scope: second thread: print i1
FAIL: gdb.threads/omp-par-scope.exp: multi_scope: first thread: print i02
FAIL: gdb.threads/omp-par-scope.exp: multi_scope: first thread: print i11
FAIL: gdb.threads/omp-par-scope.exp: multi_scope: first thread: print i12
FAIL: gdb.threads/omp-par-scope.exp: multi_scope: first thread: print i22
FAIL: gdb.threads/omp-par-scope.exp: multi_scope: first thread: print file_scope_var
FAIL: gdb.threads/omp-par-scope.exp: multi_scope: second thread: print i11
FAIL: gdb.threads/omp-par-scope.exp: multi_scope: second thread: print file_scope_var
FAIL: gdb.threads/omp-par-scope.exp: multi_scope: after parallel: print file_scope_var
FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 1st stop: print file_scope_var
FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 1st stop: print num
FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 1st stop: print l
FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 1st stop: print k
FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 2nd stop: print file_scope_var
FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 2nd stop: print num
FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 3rd stop: print file_scope_var
FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 3rd stop: print num
FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 3rd stop: print l
FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 3rd stop: print k
FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 4th stop: print file_scope_var
FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 4th stop: print num
FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: outer_threads: outer stop: print file_scope_var
FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: outer_threads: outer stop: print i
FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: outer_threads: outer stop: print j
Fedora 31, icc:
FAIL: gdb.threads/omp-par-scope.exp: multi_scope: first thread: print i12
FAIL: gdb.threads/omp-par-scope.exp: multi_scope: first thread: print i22
FAIL: gdb.threads/omp-par-scope.exp: nested_func: 1st call: 1st thread: print s1
FAIL: gdb.threads/omp-par-scope.exp: nested_func: 1st call: 1st thread: print i
FAIL: gdb.threads/omp-par-scope.exp: nested_func: 1st call: 1st thread: print j
FAIL: gdb.threads/omp-par-scope.exp: nested_func: 1st call: 2nd thread: print s1
FAIL: gdb.threads/omp-par-scope.exp: nested_func: 1st call: 2nd thread: print i
FAIL: gdb.threads/omp-par-scope.exp: nested_func: 1st call: 2nd thread: print j
FAIL: gdb.threads/omp-par-scope.exp: nested_func: 1st call: 2nd thread: print k
FAIL: gdb.threads/omp-par-scope.exp: nested_func: 1st call: 2nd thread: print z
FAIL: gdb.threads/omp-par-scope.exp: nested_func: 2nd call: 1st thread: print s1
FAIL: gdb.threads/omp-par-scope.exp: nested_func: 2nd call: 1st thread: print i
FAIL: gdb.threads/omp-par-scope.exp: nested_func: 2nd call: 1st thread: print j
FAIL: gdb.threads/omp-par-scope.exp: nested_func: 2nd call: 2nd thread: print s1
FAIL: gdb.threads/omp-par-scope.exp: nested_func: 2nd call: 2nd thread: print i
FAIL: gdb.threads/omp-par-scope.exp: nested_func: 2nd call: 2nd thread: print j
FAIL: gdb.threads/omp-par-scope.exp: nested_func: 2nd call: 2nd thread: print k
FAIL: gdb.threads/omp-par-scope.exp: nested_func: 2nd call: 2nd thread: print z
FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 1st stop: print l
FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 1st stop: print k
FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 3rd stop: print l
FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 3rd stop: print k
For both clang and icc, it turns out that there are some problems with
the DWARF that these compilers generate. Of the two, icc does at
least nest the subprogram of the outlined function representing the
parallel region within the function that it's defined, but does not
handle inner scopes if they exist. clang places the subprogram for
the outlined function at the same level as the containing function, so
variables declared within the function aren't visible at all.
I could call setup_xfail to avoid FAILs for clang and icc also, but I don't
want to further complicate the test.
gdb/testsuite/ChangeLog:
* gdb.threads/omp-par-scope.c: New file.
* gdb/threads/omp-par-scope.exp: New file.
Change-Id: Icb9c991730d84ca7509380af817dfcc778e764ea
|
|
GDB crashes when doing:
(gdb) faas
Aborted
Do the needed check to avoid crashing.
gdb/ChangeLog
2019-12-06 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* stack.c (faas_command): Check a command is provided.
* thread.c (taas_command, tfaas_command): Likewise.
gdb/testsuite/ChangeLog
2019-12-06 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* gdb.threads/pthreads.exp: Test taas and tfaas without command.
* gdb.base/frameapply.exp: Test faas without command.
|
|
There's a pattern:
...
gdb_test <command> <pattern> <command>
...
that can be written shorter as:
...
gdb_test <command> <pattern>
...
Detect this pattern in proc gdb_test:
...
global gdb_prompt
upvar timeout timeout
if [llength $args]>2 then {
set message [lindex $args 2]
+ if { $message == [lindex $args 0] && [llength $args] == 3 } {
+ error "HERE"
+ }
} else {
set message [lindex $args 0]
}
...
and fix all occurrences in some gdb testsuite subdirs.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-10-31 Tom de Vries <tdevries@suse.de>
* gdb.arch/amd64-disp-step-avx.exp: Drop superfluous 3rd argument to
gdb_test.
* gdb.arch/amd64-disp-step.exp: Same.
* gdb.asm/asm-source.exp: Same.
* gdb.btrace/buffer-size.exp: Same.
* gdb.btrace/cpu.exp: Same.
* gdb.btrace/enable.exp: Same.
* gdb.dwarf2/count.exp: Same.
* gdb.dwarf2/dw2-ranges-func.exp: Same.
* gdb.dwarf2/dw2-ranges-psym.exp: Same.
* gdb.fortran/vla-datatypes.exp: Same.
* gdb.fortran/vla-history.exp: Same.
* gdb.fortran/vla-ptype.exp: Same.
* gdb.fortran/vla-value.exp: Same.
* gdb.fortran/whatis_type.exp: Same.
* gdb.guile/guile.exp: Same.
* gdb.multi/tids.exp: Same.
* gdb.python/py-finish-breakpoint.exp: Same.
* gdb.python/py-framefilter.exp: Same.
* gdb.python/py-pp-registration.exp: Same.
* gdb.python/py-xmethods.exp: Same.
* gdb.python/python.exp: Same.
* gdb.server/connect-with-no-symbol-file.exp: Same.
* gdb.server/no-thread-db.exp: Same.
* gdb.server/run-without-local-binary.exp: Same.
* gdb.stabs/weird.exp: Same.
* gdb.threads/attach-many-short-lived-threads.exp: Same.
* gdb.threads/thread-find.exp: Same.
* gdb.threads/tls-shared.exp: Same.
* gdb.threads/tls.exp: Same.
* gdb.threads/wp-replication.exp: Same.
* gdb.trace/ax.exp: Same.
* lib/gdb.exp (gdb_test_exact, help_test_raw): Same.
Change-Id: I2fa544c68f8c0099a77e03ff04ddc010eb2b6c7c
|
|
It was observed that in a multi-threaded application on GNU/Linux,
that if the user has set the SIGSTOP to be pass (using GDB's handle
command) then the inferior would hang upon hitting a breakpoint.
What happens is that when a thread hits the breakpoint GDB tries to
stop all of the other threads by sending them a SIGSTOP and setting
the stop_requested flag in the target_ops structure - this can be seen
in infrun.c:stop_all_threads.
GDB then waits for all of the other threads to stop.
When the SIGSTOP event arrives we eventually end up in
linux-nat.c:linux_nat_filter_event, which has the job of deciding if
the event we're looking at (the SIGSTOP arriving in this case) is
something that should be reported back to the core of GDB.
One of the final actions of this function is to check if we stopped
due to a signal, and if we did, and the signal has been set to 'pass'
by the user then we ignore the event and resume the thread.
This code already has some conditions in place that mean the event is
reported to GDB even if the signal is in the set of signals to be
passed to the inferior.
In this commit I extend this condition such that:
If the signal is a SIGSTOP, and the thread's stop_requested flag is
set (indicating we're waiting for the thread to stop with a SIGSTOP)
then we should report this SIGSTOP to GDB and not pass it to the
inferior.
With this change in place the test now passes. Regression tested on
x86-64 GNU/Linux with no regressions.
gdb/ChangeLog:
* linux-nat.c (linux_nat_filter_event): Don't ignore SIGSTOP if we
have just sent the thread a SIGSTOP and are waiting for it to
arrive.
gdb/testsuite/ChangeLog:
* gdb.threads/stop-with-handle.c: New file.
* gdb.threads/stop-with-handle.exp: New file.
|
|
With gdb.threads/fork-plus-threads.exp and check-run1 we get:
...
FAIL: gdb.threads/fork-plus-threads.exp: detach-on-fork=off: \
inferior 1 exited (timeout)
...
Fix this by calling exp_continue for new thread and thread exited messages.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-08-01 Tom de Vries <tdevries@suse.de>
PR testsuite/24863
* gdb.threads/fork-plus-threads.exp: Fix check-run1 timeout by
calling exp_continue for new thread and thread exited messages.
|
|
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.
|
|
When debugging any of the testcases added by this commit, which do a
vfork in a thread with "set follow-fork-mode child" + "set
detach-on-fork on", we run into this assertion:
...
src/gdb/nat/x86-linux-dregs.c:146: internal-error: \
void x86_linux_update_debug_registers(lwp_info*): \
Assertion `lwp_is_stopped (lwp)' failed.
...
The assert is caused by the following: the vfork-child exit or exec
event is handled by handle_vfork_child_exec_or_exit, which calls
target_detach to detach from the vfork parent. During target_detach
we call linux_nat_target::detach, which:
#1 - stops all the threads
#2 - waits for all the threads to be stopped
#3 - detaches all the threads
However, during the second step we run into this code in
stop_wait_callback:
...
/* If this is a vfork parent, bail out, it is not going to report
any SIGSTOP until the vfork is done with. */
if (inf->vfork_child != NULL)
return 0;
...
and we don't wait for the threads to be stopped, which results in this
assert in x86_linux_update_debug_registers triggering during the third
step:
...
gdb_assert (lwp_is_stopped (lwp));
...
The fix is to reset the vfork parent's vfork_child field before
calling target_detach in handle_vfork_child_exec_or_exit. There's
already similar code for the other paths handled by
handle_vfork_child_exec_or_exit, so this commit refactors the code a
bit so that all paths share the same code.
The new tests cover both a vfork child exiting, and a vfork child
execing, since both cases would trigger the assertion.
The new testcases also exercise following the vfork children with "set
detach-on-fork off", since it doesn't seem to be tested anywhere.
Tested on x86_64-linux, using native and native-gdbserver.
gdb/ChangeLog:
2019-04-18 Tom de Vries <tdevries@suse.de>
Pedro Alves <palves@redhat.com>
PR gdb/24454
* infrun.c (handle_vfork_child_exec_or_exit): Reset vfork parent's
vfork_child field before calling target_detach.
gdb/testsuite/ChangeLog:
2019-04-18 Tom de Vries <tdevries@suse.de>
Pedro Alves <palves@redhat.com>
PR gdb/24454
* gdb.threads/vfork-follow-child-exec.c: New file.
* gdb.threads/vfork-follow-child-exec.exp: New file.
* gdb.threads/vfork-follow-child-exit.c: New file.
* gdb.threads/vfork-follow-child-exit.exp: New file.
|
|
This patch fixes a problem on nios2-linux-gnu with stepping past the
kernel helper __kuser_cmpxchg, which was exposed by the testcase
gdb.threads/watchpoint-fork.exp. The kernel maps this function into
user space on an unwritable page. In this testcase, the cmpxchg
helper is invoked indirectly from the setbuf call in the test program.
Since this target lacks hardware breakpoint/watchpoint support, GDB
tries to single-step through the program by setting software
breakpoints, and was just giving an error when it reached the function
on the unwritable page.
The solution here is to always step over the call instead of stepping
into it; cmpxchg is supposed to be an atomic operation so this
behavior seems reasonable. The hook in nios2_get_next_pc is somewhat
generic, but at present cmpxchg is the only helper provided by the
Linux kernel that is invoked by an ordinary function call. (Signal
return trampolines also go through the unwritable page but not by a
function call.)
Fixing this issue also revealed that the testcase needs a much larger
timeout factor when software single-stepping is used. That has also
been fixed in this patch.
gdb/ChangeLog
2019-03-28 Sandra Loosemore <sandra@codesourcery.com>
* nios2-tdep.h (struct gdbarch_tdep): Add is_kernel_helper.
* nios2-tdep.c (nios2_get_next_pc): Skip over kernel helpers.
* nios2-linux-tdep.c (nios2_linux_is_kernel_helper): New.
(nios2_linux_init_abi): Install it.
gdb/testsuite/ChangeLog
2019-03-28 Sandra Loosemore <sandra@codesourcery.com>
* gdb.threads/watchpoint-fork.exp (test): Use large timeout
factor when no hardware watchpoint support.
|
|
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.
|
|
A failure that seems to cause a long/infinite time is the following:
For a not clear reason, tid-reuse.c spawner thread sometimes gets an error:
tid-reuse: /bd/home/philippe/gdb/git/build_moreaa/gdb/testsuite/../../../moreaa/gdb/testsuite/gdb.threads/tid-reuse.c:58: spawner_thread_func: Assertion `rc == 0' failed.
which causes a SIGABRT to be trapped by gdb, and tid-reuse does not reach the
after_count breakpoint:
Thread 2 "tid-reuse" received signal SIGABRT, Aborted.
[Switching to Thread 0x7ffff7518700 (LWP 10368)]
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
51 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) FAIL: gdb.threads/tid-reuse.exp: continue to breakpoint: after_count
After that, tid-reuse.exp gets the value of reuse_time, but this one kept its
initial value of -1 (as unsigned) :
print reuse_time
$1 = 4294967295
(gdb) PASS: gdb.threads/tid-reuse.exp: get reuse_time
tid-reuse then dies, and the .exp script continues (with some FAIL)
till it executes:
set timeout [expr $reuse_time * 2]
leading to the error:
(gdb) ERROR: integer value too large to represent as non-long integer
while executing
"expect {
-i exp8 -timeout 8589934590
-re ".*A problem internal to GDB has been detected" {
fail "$message (GDB internal error)"
gdb_intern..."
("uplevel" body line 1)
invoked from within
"uplevel $body" ARITH IOVERFLOW {integer value too large to represent as non-long integer} integer value too large to represent as non-long integer
ERROR: GDB process no longer exists
and then everything blocks.
This last 'GDB process no longer exists' is strange, as I still see the gdb
when this all blocks, e.g.
philippe 16058 31085 0 20:30 pts/15 00:00:00 /bin/bash -c rootme=`pwd`; export rootme; srcdir=../../../binutils-gdb/gdb/testsuite ; export srcdir ; EXPECT=`if [
philippe 16386 16058 0 20:30 pts/15 00:00:00 expect -- /usr/share/dejagnu/runtest.exp --status GDB_PARALLEL=yes --outdir=outputs/gdb.threads/tid-reuse gdb.thre
philippe 24848 16386 0 20:30 pts/20 00:00:00 /bd/home/philippe/gdb/git/build_binutils-gdb/gdb/testsuite/../../gdb/gdb -nw -nx -data-directory /bd/home/philip
This patch gives a default value of 60, so that if ever something wrong happens
in tid-reuse, then the value retrieved by the .exp script stays in a reasonable
range.
Simon verified the patch by:
"I replaced the pthread_create call with the value 1 to simulate a
failure, and the test succeeds to fail quickly with your patch applied.
Without your patch, I get the infinite hang that you describe."
Compared to V1:
As suggested by Pedro, this version checks the pthread calls return
code (in particular of pthread_create) and reports the failure reason,
instead of just aborting.
gdb/testsuite/ChangeLog
2018-12-09 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* gdb.threads/tid-reuse.c (REUSE_TIME_CAP): Declare as 60.
(reuse_time): Initialize to REUSE_TIME_CAP.
(check_rc): New function.
(main): Use REUSE_TIME_CAP instead of hardcoded 60.
Check pthread_create rc.
(spawner_thread_func): Check pthread_create and pthread_join rc.
|
|
In the 'info -q -t' patch series, I started a new test from
gdb.threads/threadapply.exp, that uses an obsolete way to do
runto_main.
This patch changes all occurrences of runto_main using gdb_suppress_tests
to use instead fail+return.
Note that there are still about 220 occurrences of gdb_suppress_tests
but unclear (to me) if these can be similarly trivially be replaced by a
fail+return. Further cleanup can be done in follow-up patches.
Tests run on Debian/x86_64.
gdb/testsuite/ChangeLog
2018-10-27 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* gdb.arch/altivec-regs.exp: Do not use gdb_suppress_tests in
runto_main, use fail + return instead.
gdb.arch/amd64-byte.exp: Likewise.
gdb.arch/amd64-dword.exp: Likewise.
gdb.arch/amd64-word.exp: Likewise.
gdb.arch/e500-abi.exp: Likewise.
gdb.arch/e500-regs.exp: Likewise.
gdb.arch/gdb1291.exp: Likewise.
gdb.arch/gdb1431.exp: Likewise.
gdb.arch/i386-avx.exp: Likewise.
gdb.arch/i386-byte.exp: Likewise.
gdb.arch/i386-prologue.exp: Likewise.
gdb.arch/i386-sse.exp: Likewise.
gdb.arch/i386-word.exp: Likewise.
gdb.arch/iwmmxt-regs.exp: Likewise.
gdb.arch/pa-nullify.exp: Likewise.
gdb.arch/powerpc-prologue.exp: Likewise.
gdb.arch/s390-tdbregs.exp: Likewise.
gdb.arch/vsx-regs.exp: Likewise.
gdb.asm/asm-source.exp: Likewise.
gdb.base/auxv.exp: Likewise.
gdb.base/bigcore.exp: Likewise.
gdb.base/overlays.exp: Likewise.
gdb.base/savedregs.exp: Likewise.
gdb.base/setshow.exp: Likewise.
gdb.base/sigaltstack.exp: Likewise.
gdb.base/sigbpt.exp: Likewise.
gdb.base/siginfo-addr.exp: Likewise.
gdb.base/siginfo-obj.exp: Likewise.
gdb.base/siginfo-thread.exp: Likewise.
gdb.base/siginfo.exp: Likewise.
gdb.base/signull.exp: Likewise.
gdb.base/sigrepeat.exp: Likewise.
gdb.base/structs2.exp: Likewise.
gdb.threads/threadapply.exp: Likewise.
gdb.threads/watchthreads.exp: Likewise.
gdb.threads/watchthreads2.exp: Likewise.
|
|
It is possible for the created thread to reach the breakpoint before
the main thread has set errno to 23.
Prevent this using a pthread barrier.
* gdb.threads/check-libthread-db.c (thread_routine): Use a
pthread barrier.
(main): Likewise.
|
|
Also, add prefixes to make some non unique tests unique.
gdb/testsuite/ChangeLog
2018-07-12 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* gdb.threads/pthreads.exp: Test qcs FLAG arguments.
Add some test prefixes to make tests unique.
|
|
It's long annoyed me that "info threads"'s columns are misaligned.
Particularly the "Target Id" column's content is usually longer than
the specified column width, so the table ends up with the "Frame"
column misaligned. For example, currently we get this:
(gdb) info threads
Id Target Id Frame
1 Thread 0x7ffff7fb5740 (LWP 9056) "threads" 0x00007ffff7bc28ad in __pthread_join (threadid=140737345763072, thread_return=0x7fffffffd3e8) at pthread_join.c:90
2 Thread 0x7ffff7803700 (LWP 9060) "function0" thread_function0 (arg=0x0) at threads.c:90
* 3 Thread 0x7ffff7002700 (LWP 9061) "threads" thread_function1 (arg=0x1) at threads.c:106
The fact that the "Frame" heading is in a weird spot is particularly
annoying.
This commit turns the above into into this:
(gdb) info threads
Id Target Id Frame
1 Thread 0x7ffff7fb5740 (LWP 7548) "threads" 0x00007ffff7bc28ad in __pthread_join (threadid=140737345763072, thread_return=0x7fffffffd3e8) at pthread_join.c:90
2 Thread 0x7ffff7803700 (LWP 7555) "function0" thread_function0 (arg=0x0) at threads.c:91
* 3 Thread 0x7ffff7002700 (LWP 7557) "threads" thread_function1 (arg=0x1) at threads.c:104
It does that by computing the max width of the "Target Id" column and
using that as column width when creating the table.
This results in calling target_pid_to_str / target_extra_thread_info /
target_thread_name twice for each thread, but I think that it doesn't
matter in practice performance-wise, because the remote target caches
the info, and with native targets it shouldn't be noticeable. It
could matter if we have many threads (say, thousands), but then "info
threads" is practically useless in such a scenario anyway -- better
thread filtering and aggregation would be necessary.
(Note: I have an old branch somewhere where I attempted at making
gdb's "info threads"-like tables follow a model/view design, so that a
general framework took care of issues like these, but it's incomplete
and a much bigger change. This patch doesn't prevent going in that
direction in the future, of course.)
gdb/ChangeLog:
2018-06-29 Pedro Alves <palves@redhat.com>
* thread.c (thread_target_id_str): New, factored out from ...
(print_thread_info_1): ... here. Use it to compute the max
"Target Id" column width.
gdb/testsuite/ChangeLog:
2018-06-29 Pedro Alves <palves@redhat.com>
* gdb.threads/names.exp: Adjust expected "info threads" output.
|
|
This patch fixes an issue where GDB would sometimes hang when
attaching to a multi-threaded process. This issue was especially
likely to trigger if the machine (running the inferior) was under
load.
In summary, the problem is an imbalance between two functions in
linux-nat.c, stop_callback and stop_wait_callback. In stop_callback
we send SIGSTOP to a thread, but _only_ if the thread is not already
stopped, and if it is not signalled, which means it should stop soon.
In stop_wait_callback we wait for the SIGSTOP to arrive, however, we
are aware that the thread might have been signalled for some other
reason, and so if a signal other than SIGSTOP causes the thread to
stop then we stash that signal away so it can be reported back later.
If we get a SIGSTOP then this is discarded, after all, this signal was
sent from stop_callback. Except that this might not be the case, it
could be that SIGSTOP was sent to a thread from elsewhere in GDB, in
which case we would not have sent another SIGSTOP from stop_callback
and the SIGSTOP received in stop_wait_callback should not be ignored.
Below I've laid out the exact sequence of events that I saw that lead
me to track down the above diagnosis.
After attaching to the inferior GDB sends a SIGSTOP to all of the
threads and then returns to the event loop waiting for interesting
things to happen.
Eventually the first target event is detected (this will be the first
SIGSTOP arriving) and GDB calls inferior_event_handler which calls
fetch_inferior_event. Inside fetch_inferior_event GDB calls
do_target_wait which calls target_wait to find a thread with an event.
The target_wait call ends up in linux_nat_wait_1, which first checks
to see if any threads already have stashed stop events to report, and
if there are none then we enter a loop fetching as many events as
possible out of the kernel. This event fetching is non-blocking, and
we give up once the kernel has no more events ready to give us.
All of the events from the kernel are passed through
linux_nat_filter_event which stashes the wait status for all of the
threads that reported a SIGSTOP, these will be returned by future
calls to linux_nat_wait_1.
Lets assume for a moment that we've attached to a multi-threaded
inferior, and that all but one thread has reported its stop during the
initial wait call in linux_nat_wait_1. The other thread will be
reporting a SIGSTOP, but the kernel has not yet managed to deliver
that signal to GDB before GDB gave up waiting and continued handling
the events it already had. GDB selects one of the threads that has
reported a SIGSTOP and passes this thread ID back to
fetch_inferior_event.
To handle the thread's SIGSTOP, GDB calls handle_signal_stop, which
calls stop_all_threads, this calls wait_one, which in turn calls
target_wait.
The first call to target_wait at this point will result in a stashed
wait status being returned, at which point we call setup_inferior.
The call to setup_inferior leads to a call into try_thread_db_load_1
which results in a call to linux_stop_and_wait_all_lwps. This in turn
calls stop_callback on each thread followed by stop_wait_callback on
each thread.
We're now ready to make the mistake. In stop_callback we see that our
problem thread is not stopped, but is signalled, so it should stop
soon. As a result we don't send another SIGSTOP.
We then enter stop_wait_callback, eventually the problem thread stops
with SIGSTOP which we _incorrectly_ assume came from stop_callback,
and we discard.
Once stop_wait_callback has done its damage we return from
linux_stop_and_wait_all_lwps, finish in try_thread_db_load_1, and
eventually unwind back to the call to setup_inferior in
stop_all_threads. GDB now loops around, and performs another
target_wait to get the next event from the inferior.
The target_wait calls causes us to once again reach linux_nat_wait_1,
and we pass through some code that calls resume_stopped_resumed_lwps.
This allows GDB to resume threads that are physically stopped, but
which GDB doesn't see any good reason for the thread to remain
stopped. In our case, the problem thread which had its SIGSTOP
discarded is stopped, but doesn't have a stashed wait status to
report, and so GDB sets the thread going again.
We are now stuck waiting for an event on the problem thread that might
never arrive.
When considering how to write a test for this bug I struggled. The
issue was only spotted _randomly_ when a machine was heavily loaded
with many multi-threaded applications, and GDB was being attached (by
script) to all of these applications in parallel. In one reproducer I
required around 5 applications each of 5 threads per machine core in
order to reproduce the bug 2 out of 3 times.
What we really want to do though is simulate the kernel being slow to
report events through waitpid during the initial attach. The solution
I came up with was to write an LD_PRELOAD library that intercepts
(some) waitpid calls and rate limits them to one per-second. Any more
than that simply return 0 indicating there's no event available.
Obviously this can only be applied to waitpid calls that have the
WNOHANG flag set.
Unfortunately, once you ignore a waitpid call GDB can get a bit stuck.
Usually, once the kernel has made a child status available to waitpid
GDB will be sent a SIGCHLD signal. However, if the kernel makes 5
child statuses available but, due to the preload library we only
collect one of them, then the kernel will not send any further SIGCHLD
signals, and so, when GDB, thinking that the remaining statuses have
not yet arrived sits waiting for a SIGCHLD it will be disappointed.
The solution, implemented within the preload library, is that, when we
hold back a waitpid result from GDB we spawn a new thread. This
thread delays for a short period, and then sends GDB a SIGCHLD. This
causes GDB to retry the waitpid, at which point sufficient time has
passed and our library allows the waitpid call to complete.
gdb/ChangeLog:
* linux-nat.c (stop_wait_callback): Don't discard SIGSTOP if it
was requested by GDB.
gdb/testsuite/ChangeLog:
* gdb.threads/attach-slow-waitpid.c: New file.
* gdb.threads/attach-slow-waitpid.exp: New file.
* gdb.threads/slow-waitpid.c: New file.
|
|
In PR22882 inferior functions are called on different threads while
scheduler-locking is turned on. This results in a hang. This was
discussed in this mailing list thread:
https://sourceware.org/ml/gdb/2017-10/msg00032.html
The problem is that when the thread is set running in order to execute
the inferior call, a call to target_async is made. If the target is
not already registered as 'target_async' then this will install the
async event handler, AND unconditionally mark the handler as having an
event pending.
However, if the target is already registered as target_async then the
event handler is not installed (its already installed) and the
handler is NOT marked as having an event pending.
If we try to set running a thread that already has a pending event,
then we do want to set target_async, however, there will not be an
external event incoming (the thread is already stopped) so we rely on
manually marking the event handler as having a pending event in order
to see the threads pending stop event. This is fine, if, at the point
where we call target_async, the target is not already marked as async.
But, if it is, then the event handler will not be marked as ready, and
the threads pending stop event will never be processed.
A similar pattern of code can be seen in linux_nat_target::resume,
where, when a thread has a pending event, the call to target_async is
followed by a call to async_file_mark to ensure that the pending
thread event will be processed, even if target_async was already set.
gdb/ChangeLog:
PR gdb/22882
* infrun.c (resume_1): Add call to mark_async_event_handler.
gdb/testsuite/ChangeLog:
* gdb.threads/multiple-successive-infcall.exp: Remove kfail case,
rewrite test to describe action performed, rather than possible
failure.
|
|
This commit adds two new commands which may be used to test thread
debugging libraries used by GDB:
* "maint check libthread-db" tests the thread debugging library GDB
is using for the current inferior.
* "maint set/show check-libthread-db" selects whether libthread_db
tests should be run automatically as libthread_db is auto-loaded.
The default is to not run tests automatically.
The test itself is a basic integrity check exercising all libthread_db
functions used by GDB on GNU/Linux systems. By extension this also
exercises the proc_service functions provided by GDB that libthread_db
uses.
This functionality is useful for NPTL developers and libthread_db
developers. It could also prove useful investigating bugs reported
against GDB where the thread debugging library or GDB's proc_service
layer is suspect.
gdb/ChangeLog:
* linux-thread-db.c (valprint.h): New include.
(struct check_thread_db_info): New structure.
(check_thread_db_on_load, tdb_testinfo): New static globals.
(check_thread_db, check_thread_db_callback): New functions.
(try_thread_db_load_1): Run integrity checks if requested.
(maintenance_check_libthread_db): New function.
(_initialize_thread_db): Register "maint check libthread-db"
and "maint set/show check-libthread-db".
* NEWS: Mention the above new commands.
gdb/doc/ChangeLog:
* gdb.texinfo (Maintenance Commands): Document "maint check
libthread-db" and "maint set/show check-libthread-db".
gdb/testsuite/ChangeLog:
* gdb.threads/check-libthread-db.exp: New file.
* gdb.threads/check-libthread-db.c: Likewise.
|
|
Complementing commit 280ca31f4d60 ("Add test for fetching TLS from
core file") extend gdb.threads/tls-core.exp with an OS-generated dump
where supported.
This verifies not only that our core dump interpreter is consistent
with our producer, but that it matches the OS verified as well,
avoiding a possible case where our interpreter would be bug-compatible
with our producer but not the OS and it would go unnoticed in testing.
This results in:
PASS: gdb.threads/tls-core.exp: native: load core file
PASS: gdb.threads/tls-core.exp: native: print thread-local storage variable
PASS: gdb.threads/tls-core.exp: gcore: load core file
PASS: gdb.threads/tls-core.exp: gcore: print thread-local storage variable
with local testing and:
UNSUPPORTED: gdb.threads/tls-core.exp: native: load core file
UNSUPPORTED: gdb.threads/tls-core.exp: native: print thread-local storage variable
PASS: gdb.threads/tls-core.exp: gcore: load core file
PASS: gdb.threads/tls-core.exp: gcore: print thread-local storage variable
with remote testing, or for testing on ports that don't supports
cores.
gdb/testsuite/ChangeLog:
2018-05-24 Maciej W. Rozycki <macro@mips.com>
Pedro Alves <palves@redhat.com>
* gdb.threads/tls-core.c: Include <stdlib.h>
(thread_proc): Call `abort'.
* gdb.threads/tls-core.exp: Generate a core with core_find too.
(tls_core_test): New procedure, bits factored out from ...
(top level): ... here. Test both native cores and gcore cores.
|
|
Since f67c0c917150 ("Enable 'set print inferior-events' and improve
detach/fork/kill/exit messages"), when detaching a remote process, we
get, for detach against a remote target:
(gdb) detach
Detaching from program: ...., process 5388
Ending remote debugging.
[Inferior 1 (Thread 5388.5388) detached]
^^^^^^^^^^^^^^^^
That is incorrect, for it is printing a thread id as string while we
should be printing the process id instead. I.e., either one of:
[Inferior 1 (process 5388) detached]
[Inferior 1 (Remote target) detached]
depending on remote stub support for the multi-process extensions.
Similarly, after killing a process, we're printing thread ids while we
should be printing process ids. E.g., on native GNU/Linux:
(gdb) k
Kill the program being debugged? (y or n) y
[Inferior 1 (Thread 0x7ffff7faa8c0 (LWP 30721)) has been killed]
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
while it should have been:
Kill the program being debugged? (y or n) y
[Inferior 1 (process 30721) has been killed]
^^^^^^^^^^^^^
There's a wording inconsistency between detach and kill:
[Inferior 1 (process 30721) has been killed]
[Inferior 1 (process 30721) detached]
Given we were already saying "detached" instead of "has been
detached", and we used to say just "exited", and given that the "has
been" doesn't really add any information, this commit changes the
message to just "killed":
[Inferior 1 (process 30721) killed]
gdb/ChangeLog:
2018-04-25 Pedro Alves <palves@redhat.com>
* infcmd.c (kill_command): Print the pid as string, not the whole
thread's ptid. Add comment. s/has been killed/killed/ in output
message.
* remote.c (remote_detach_1): Print the pid as string, not the
whole thread's ptid.
gdb/testsuite/ChangeLog:
2018-04-25 Pedro Alves <palves@redhat.com>
* gdb.base/hook-stop.exp: Expect "killed" instead of "has been
killed".
* gdb.base/kill-after-signal.exp: Likewise.
* gdb.threads/kill.exp: Likewise.
|
|
This patch aims to turn 'set print inferior-events' always on, and do
some cleanup on the messages printed by GDB when various inferior
events happen (attach, detach, fork, kill, exit).
To make sure that the patch is correct, I've tested it with a handful
of combinations of 'set follow-fork-mode', 'set detach-on-fork' and
'set print inferior-events'. In the end, I decided to make my
hand-made test into an official testcase. More on that below.
Using the following program as an example:
#include <unistd.h>
int main ()
{
fork ();
return 0;
}
We see the following outputs from the patched GDB:
- With 'set print inferior-events on':
(gdb) r
Starting program: a.out
[Detaching after fork from child process 27749]
[Inferior 1 (process 27745) exited normally]
(gdb)
- With 'set print inferior-events off':
(gdb) r
Starting program: a.out
[Inferior 1 (process 27823) exited normally]
(gdb)
Comparing this against an unpatched GDB:
- With 'set print inferior-events off' and 'set follow-fork-mode
child':
(gdb) r
Starting program: a.out
[Inferior 2 (process 5993) exited normally]
(gdb)
Compare this against an unpatched GDB:
(unpatched-gdb) r
Starting program: a.out
[New process 5702]
[Inferior 2 (process 5702) exited normally]
(unpatched-gdb)
It is possible to notice that, in this scenario, the patched GDB
will lose the '[New process %d]' message.
- With 'set print inferior-events on', 'set follow-fork-mode child'
and 'set detach-on-fork on':
(gdb) r
Starting program: a.out
[Attaching after process 27905 fork to child process 27909]
[New inferior 2 (process 27909)]
[Detaching after fork from parent process 27905]
[Inferior 1 (process 27905) detached]
[Inferior 2 (process 27909) exited normally]
(gdb)
Compare this output with an unpatched GDB, using the same settings:
(unpatched-gdb) r
Starting program: a.out
[New inferior 28033]
[Inferior 28029 detached]
[New process 28033]
[Inferior 2 (process 28033) exited normally]
[Inferior 28033 exited]
(unpatched-gdb)
As can be seen above, I've also made a few modifications to messages
that are printed when 'set print inferior-events' is on. For example,
a few of the messages did not contain the '[' and ']' as
prefix/suffix, which led to a few inconsistencies like:
Attaching after process 22995 fork to child process 22999.
[New inferior 22999]
Detaching after fork from child process 22999.
[Inferior 22995 detached]
[Inferior 2 (process 22999) exited normally]
So I took the opportunity and included the square brackets where
applicable. I have also made the existing messages more uniform, by
always printing "Inferior %d (process %d)..." where applicable. This
makes it easier to identify the inferior number and the PID number
from the messages.
As suggested by Pedro, the "[Inferior %d exited]" message from
'exit_inferior' has been removed, because it got duplicated when
'inferior-events' is on. I'm also using the
'add_{thread,inferior}_silent' versions (instead of their verbose
counterparts) on some locations, also to avoid duplicated messages.
For example, a patched GDB with 'set print inferior-events on', 'set
detach-on-fork on' and 'set follow-fork-mode child', but using
'add_thread', would print:
(gdb) run
Starting program: a.out
[Attaching after process 25088 fork to child process 25092.]
[New inferior 25092] <--- duplicated
[Detaching after fork from child process 25092.]
[Inferior 25088 detached]
[New process 25092] <--- duplicated
[Inferior 2 (process 25092) exited normally]
But if we use 'add_thread_silent' (with the same configuration as
before):
(gdb) run
Starting program: a.out
[Attaching after process 31606 fork to child process 31610]
[New inferior 2 (process 31610)]
[Detaching after fork from parent process 31606]
[Inferior 1 (process 31606) detached]
[Inferior 2 (process 31610) exited normally]
As for the tests, the configuration options being exercised are:
- follow-fork-mode: child/parent
- detach-on-fork: on/off
- print inferior-events: on/off
It was also necessary to perform adjustments on several testcases,
because the expected messages changed considerably.
Built and regtested on BuildBot, without regressions.
gdb/ChangeLog:
2018-04-24 Jan Kratochvil <jan.kratochvil@redhat.com>
Sergio Durigan Junior <sergiodj@redhat.com>
Pedro Alves <palves@redhat.com>
* infcmd.c (kill_command): Print message when inferior has
been killed.
* inferior.c (print_inferior_events): Remove 'static'. Set as
'1'.
(add_inferior): Improve message printed when
'print_inferior_events' is on.
(exit_inferior): Remove message printed when
'print_inferior_events' is on.
(detach_inferior): Improve message printed when
'print_inferior_events' is on.
(initialize_inferiors): Use 'add_inferior_silent' to set
'current_inferior_'.
* inferior.h (print_inferior_events): Declare here as
'extern'.
* infrun.c (follow_fork_inferior): Print '[Attaching...]' or
'[Detaching...]' messages when 'print_inferior_events' is on.
Use 'add_thread_silent' instead of 'add_thread'. Add '[' and ']'
as prefix/suffix for messages. Remove periods. Fix erroneous
'Detaching after fork from child...', replace it by '... from
parent...'.
(handle_vfork_child_exec_or_exit): Add '[' and ']' as
prefix/suffix when printing 'Detaching...' messages. Print
them when 'print_inferior_events' is on.
* remote.c (remote_detach_1): Print message when detaching
from inferior and '!is_fork_parent'.
gdb/testsuite/ChangeLog:
2018-04-24 Jan Kratochvil <jan.kratochvil@redhat.com>
Sergio Durigan Junior <sergiodj@redhat.com>
Pedro Alves <palves@redhat.com>
* gdb.base/attach-non-pgrp-leader.exp: Adjust 'Detaching...'
regexps to expect for '[Inferior ... detached]' as well.
* gdb.base/attach.exp: Likewise.
* gdb.base/catch-syscall.exp (check_for_program_end): Adjust
"gdb_continue_to_end".
(test_catch_syscall_with_wrong_args): Likewise.
* gdb.base/foll-fork.exp: Adjust regexps to match '[' and
']'. Don't set 'verbose' on.
* gdb.base/foll-vfork.exp: Likewise.
* gdb.base/fork-print-inferior-events.c: New file.
* gdb.base/fork-print-inferior-events.exp: New file.
* gdb.base/hook-stop.exp: Adjust regexps to expect for new
'[Inferior ... has been killed]' message.
* gdb.base/kill-after-signal.exp: Likewise.
* gdb.base/solib-overlap.exp: Adjust regexps to expect for new
detach message.
* gdb.threads/kill.exp: Adjust regexps to expect for new kill
message.
* gdb.threads/clone-attach-detach.exp: Adjust 'Detaching...'
regexps to expect for '[Inferior ... detached]' as well.
* gdb.threads/process-dies-while-detaching.exp: Likewise.
|
|
The hang occurs when GDB tries to call inferior functions on two
different threads with scheduler-locking turned on. The first call works
fine, with the call to infrun_async(1) causing the signal_handler to be
marked and the event to be handled, but then the event loop resets the
"ready" member to zero, while leaving infrun_is_async set to 1. As a
result, GDB hangs if the user switches to another thread and calls a
second function because calling infrun_async(1) a second time has no
effect, meaning the inferior call events are never handled.
The added test case provokes the above issue.
gdb/testsuite/ChangeLog:
* gdb.threads/multiple-successive-infcall.c: New test.
* gdb.threads/multiple-successive-infcall.exp: New file.
|
|
In the GDB test suite, there are still multiple invocations of
"target_info exists use_gdb_stub". However, the recommended way of
checking for use_gdb_stub is to call the convenience function of the same
name.
Replace these occurrences and just call "use_gdb_stub" instead.
gdb/testsuite/ChangeLog:
* gdb.ada/exec_changed.exp: Replace "target_info exists
use_gdb_stub" by "use_gdb_stub".
* gdb.ada/start.exp: Likewise.
* gdb.base/async-shell.exp: Likewise.
* gdb.base/attach-pie-misread.exp: Likewise.
* gdb.base/attach-wait-input.exp: Likewise.
* gdb.base/break-entry.exp: Likewise.
* gdb.base/break-interp.exp: Likewise.
* gdb.base/dprintf-detach.exp: Likewise.
* gdb.base/nostdlib.exp: Likewise.
* gdb.base/solib-nodir.exp: Likewise.
* gdb.base/statistics.exp: Likewise.
* gdb.base/testenv.exp: Likewise.
* gdb.mi/mi-exec-run.exp: Likewise.
* gdb.mi/mi-start.exp: Likewise.
* gdb.multi/dummy-frame-restore.exp: Likewise.
* gdb.multi/multi-arch-exec.exp: Likewise.
* gdb.multi/multi-arch.exp: Likewise.
* gdb.multi/tids.exp: Likewise.
* gdb.multi/watchpoint-multi.exp: Likewise.
* gdb.python/py-events.exp: Likewise.
* gdb.threads/attach-into-signal.exp: Likewise.
* gdb.threads/attach-stopped.exp: Likewise.
* gdb.threads/threadapply.exp: Likewise.
* lib/selftest-support.exp: Likewise.
|
|
gdb/ChangeLog:
Update copyright year range in all GDB files
|
|
I noticed [1] a test bug in gdb.threads/process-dies-while-detaching.exp.
Simplified, the test code in question looks somewhat like this:
~~~
# Detach from a process, and ensure that it exits after detaching.
# This relies on inferior I/O.
proc detach_and_expect_exit {test} {
gdb_test_multiple "detach" $test ....
set saw_prompt 0
set saw_inf_exit 0
while { !$saw_prompt && !$saw_inf_exit } {
gdb_test_multiple "" $test {
-re "exited, status=0" {
set saw_inf_exit 1
}
-re "$gdb_prompt " {
set saw_prompt 1
}
}
}
pass $test
}
~~~
The bug is in the while loop's condition. We want to make sure we see
both the inferior output and the prompt, so the loop's test should be:
- while { !$saw_prompt && !$saw_inf_exit } {
+ while { !$saw_prompt || !$saw_inf_exit } {
If we just fix that, the test starts failing though, because it
exposes a couple latent problems:
- When called from test_detach_killed_outside, the parent doesn't
print "exited, status=0", because in that case the child dies with a
signal, and so detach_and_expect_exit times out.
Fix it by making the parent print "signaled, sig=9" in that case,
and have the .exp expect it.
- When testing against --target_board=native-gdbserver, sometimes we'd
get this:
ERROR: Process no longer exists
ERROR: : spawn id exp9 not open
while executing
"expect {
-i exp8 -timeout 220
-i $server_spawn_id
eof {
pass $test
wait -i $server_spawn_id
unset server_spawn_id
}
timeout {
..."
("uplevel" body line 1)
invoked from within
"uplevel $body" NONE : spawn id exp9 not open
The problem is that:
- inferior_spawn_id and server_spawn_id are the same when testing
with gdbserver.
- gdbserver exits after "detach", so we get an eof for
$inferior_spawn_id in the loop in detach_and_expect_exit.
That's the first "ERROR: Process no longer exists".
- and then when we reach test_server_exit, server_spawn_id
is already closed (because server_spawn_id==inferior_spawn_id).
To handle this, make the loop in detach_and_expect_exit use an
indirect spawn id list and remove $inferior_spawn_id from the list
as soon as we got the inferior output we're expecting, so that the
"eof" is left unprocessed until we reach test_server_exit.
[1] I changed GDB in a way that should have made the test fail, but it
didn't.
gdb/testsuite/ChangeLog:
2017-12-03 Pedro Alves <palves@redhat.com>
* gdb.threads/process-dies-while-detaching.c: Include <errno.h>
and <string.h>.
(parent_function): Print distinct messages when waitpid fails, or
the child exits with a signal, or the child exits for an unhandled
reason.
* gdb.threads/process-dies-while-detaching.exp
(detach_and_expect_exit): New 'inf_output_re' parameter and use
it. Wait for both inferior output and GDB's prompt. Use an
indirect spawn id list.
(do_detach): New parameter 'child_exit'. Use it to compute
expected inferior output.
(test_detach, test_detach_watch, test_detach_killed_outside):
Adjust to pass down the expected child exit kind.
|
|
A correct PID is needed by `libthread_db' library supplied with
glibc repository revisions before commit c579f48edba8 ("Remove
cached PID/TID in clone") or versions before 2.25 release for
GDB to fetch value of TLS variable from core file. On MIPS
platforms it was omitted and fetching value of TLS variable was not
available.
This adds a new test in order to be sure if GDB on native platforms
can successfully fetch value of TLS variable.
gdb/testsuite:
* gdb.threads/tls-core.c: New file.
* gdb.threads/tls-core.exp: Likewise.
|
|
A previous patch removed one nesting level.
gdb/testsuite/ChangeLog:
2017-10-24 Pedro Alves <palves@redhat.com>
* gdb.threads/attach-into-signal.exp (corefunc): Reindent.
|
|
I noticed that the 'with_test_prefix "stoppedtry $stoppedtry"' prefix
in this testcase is unnecessary, because inside that block there are
no pass/fail calls. In fact the block includes a comment saying:
# No PASS message as we may be looping in multiple
# attempts.
but looking deeper at this I noticed a few odd things with this code
block:
1. This code is assuming that the second line in the /proc/PID/status
files is the "State:" line, which may have been true when this was
originally written, but is not true on my machine at least (Linux
4.8.13).
$ cat /proc/self/status
Name: cat
Umask: 0002
State: R (running)
So nowadays, that 'string match "*(stopped)*"' is running against
the "Umask:" line and thus always returns false, meaning the loop
always breaks on $stoppedtry == 0.
2. The loop seems to be waiting for the process to become "(stopped)",
but if so then that 'if {![string match]}' check is reversed, it
should be checking 'if {[string match]}' instead, because "string
match" returns true if the string matches, not 0.
3. But if we fixed all that, we'd still run into the simple fact that
nothing is actually stopping the test's inferior process before GDB
attaches... The top of the testcase says:
# This test was created by modifying attach-stopped.exp.
... and attach-stopped.exp does have:
# Stop the program
remote_exec build "kill -s STOP ${testpid}"
but then attach-stopped.exp doesn't have an equivalent
/proc/PID/status poll loop... (Maybe it could.)
So remove this whole loop as useless.
gdb/testsuite/ChangeLog:
2017-10-24 Pedro Alves <palves@redhat.com>
* gdb.threads/attach-into-signal.exp: Remove whole "stoppedtry"
loop.
|
|
Currently, if you diff testsuite/gdb.sum of two testsuite runs you'll
often see spurious hunks like these:
-PASS: gdb.threads/attach-into-signal.exp: nonthreaded: attempt 2: attach (pass 2), pending signal catch
+PASS: gdb.threads/attach-into-signal.exp: nonthreaded: attempt 1: attach (pass 2), pending signal catch
PASS: gdb.threads/attach-into-signal.exp: successfully compiled posix threads test case
PASS: gdb.threads/attach-into-signal.exp: threaded: handle SIGALRM stop print pass
-PASS: gdb.threads/attach-into-signal.exp: threaded: attempt 1: attach (pass 1), pending signal catch
-PASS: gdb.threads/attach-into-signal.exp: threaded: attempt 1: attach (pass 2), pending signal catch
+PASS: gdb.threads/attach-into-signal.exp: threaded: attempt 2: attach (pass 1), pending signal catch
+PASS: gdb.threads/attach-into-signal.exp: threaded: attempt 4: attach (pass 2), pending signal catch
Fix this by removing the "attempt $attempt" test prefix. The attempt
number can be retrieved from gdb.log instead, since the testcase is
already using "verbose -log" to that effect.
(The 'with_test_prefix "stoppedtry $stoppedtry"' prefix is unnecessary
too, because inside that block there are no pass/fail calls. In fact
the block includes a comment saying:
# No PASS message as we may be looping in multiple
# attempts.
but I'll drop that whole loop in the next patch instead.)
After this commit we'll show:
PASS: gdb.threads/attach-into-signal.exp: nonthreaded: handle SIGALRM stop print pass
PASS: gdb.threads/attach-into-signal.exp: nonthreaded: attach (pass 1), pending signal catch
PASS: gdb.threads/attach-into-signal.exp: nonthreaded: attach (pass 2), pending signal catch
PASS: gdb.threads/attach-into-signal.exp: successfully compiled posix threads test case
PASS: gdb.threads/attach-into-signal.exp: threaded: handle SIGALRM stop print pass
PASS: gdb.threads/attach-into-signal.exp: threaded: attach (pass 1), pending signal catch
PASS: gdb.threads/attach-into-signal.exp: threaded: attach (pass 2), pending signal catch
(I've avoided reindenting to make the patch easier to maintain/read.
I'll reindent the blocks after this is in.)
gdb/testsuite/ChangeLog:
2017-10-24 Pedro Alves <palves@redhat.com>
* gdb.threads/attach-into-signal.exp (corefunc): Remove "attach
$attempt" test prefix.
|
