After fixing gdb.base/disp-step-syscall.exp to properly test what it tests it has revealed: stepi Program terminated with signal SIGILL, Illegal instruction. The program no longer exists. (gdb) PASS: gdb.base/disp-step-syscall.exp: vfork: single step over vfork Child terminated with signal = 0x4 (SIGILL) GDBserver exiting print /x $pc No registers. (gdb) FAIL: gdb.base/disp-step-syscall.exp: vfork: get hexadecimal valueof "$pc" (timeout) It works with linux-nat so it seems like a gdbserver (and not kernel) issue.
CVSROOT: /cvs/src Module name: src Changes by: jkratoch@sourceware.org 2012-03-03 06:58:16 Modified files: gdb/testsuite : ChangeLog gdb/testsuite/gdb.base: disp-step-syscall.exp Log message: gdb/testsuite/ Setup KFAIL for PR server/13796. * gdb.base/disp-step-syscall.exp (single step over vfork): Setup KFAIL. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/testsuite/ChangeLog.diff?cvsroot=src&r1=1.3115&r2=1.3116 http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/testsuite/gdb.base/disp-step-syscall.exp.diff?cvsroot=src&r1=1.6&r2=1.7
The test displace-steps over a vfork syscall. In the special case of displace-stepping over a (v)fork, GDB needs to adjust both the parent and the child back from the displace stepping scratchpad. Since GDBserver doesn't support following (v)forks yet, gdb is never informed about the child, and so the child ends up continuing freely, unadjusted, from the scratchpad, and crashes.
Actually, I just found my note that says: "We miss adjusting the child, and then the parent gets corrupted, and crashes." which makes a bit more sense, given we see the crash with vfork.
The master branch has been updated by Yao Qi <qiyao@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=2d5189bd3a6e2014b9b42a4bcb0df410eff1c2e1 commit 2d5189bd3a6e2014b9b42a4bcb0df410eff1c2e1 Author: Yao Qi <yao.qi@linaro.org> Date: Thu Feb 18 13:02:12 2016 +0000 Remove setup_kfail server/13796 in disp-step-syscall.exp This patch series add fork support in target remote, [PATCH v2 0/3] Target remote mode fork and exec support https://sourceware.org/ml/gdb-patches/2015-12/msg00144.html so GDB can be informed about the child, and adjust child correctly in displaced stepping. The PR server/13796 was fixed by this patch series actually. Test results on buildbot show this KFAIL->KPASS change https://sourceware.org/ml/gdb-testers/2015-q4/msg10128.html gdb/testsuite: 2016-02-18 Yao Qi <yao.qi@linaro.org> * gdb.base/disp-step-syscall.exp (disp_step_cross_syscall): Don't call setup_kfail.
This bug was fixed by this patch series, [PATCH v2 0/3] Target remote mode fork and exec support https://sourceware.org/ml/gdb-patches/2015-12/msg00144.html Close it.