Hi Alan,
Thanks. This should now be fixed in mainline:
https://sourceware.org/ml/gdb-patches/2014-04/msg00436.html
Could you give it a try please?
On 03/26/2014 04:54 PM, Alan Lawrence wrote:
Following this patch, we're seeing an assertion failure of infrun.c:5192,
gdb_assert (!tp->control.trap_expected);
on the AArch64 platform. The testcase is that added in git commit
beb460e8d2ddf5327a6ab146055a6e6e9f552a4b, condbreak-call-false.{c,exp} - I've
tried this testcase both before and after your multiple step-over patch, and it
succeeds without the patch. I'm not very familiar with gdb internals and
stepwise comparing AArch64 against ARM (on which the test passes) sounds at best
laborious; hoping there may be some experts here who can help?
Against user mode qemu-aarch64:
Breakpoint 1, main () at testsuite/gdb.base/condbreak-call-false.c:37
37 foo ();
Breakpoint 2 at 0x400518: file testsuite/gdb.base/condbreak-call-false.c, line 25.
(gdb) c
Continuing.
infrun: clear_proceed_status_thread (Remote target)
infrun: proceed (addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT, step=0)
infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=1, current thread [Remote target] at 0x40052c
infrun: wait_for_inferior ()
infrun: target_wait (-1, status) =
infrun: 42000 [Remote target],
infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP
infrun: infwait_normal_state
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x400518
infrun: clear_proceed_status_thread (Remote target)
infrun: proceed (addr=0x400510, signal=GDB_SIGNAL_0, step=0)
infrun: resume (step=0, signal=GDB_SIGNAL_0), trap_expected=0, current thread [Remote target] at 0x400510
infrun: wait_for_inferior ()
infrun: target_wait (-1, status) =
infrun: 42000 [Remote target],
infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP
infrun: infwait_normal_state
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x4003b0
infrun: BPSTAT_WHAT_STOP_SILENT
infrun: stop_stepping
infrun: BPSTAT_WHAT_SINGLE
infrun: need to step-over [Remote target]
../../src/gdb/infrun.c:5200: internal-error: switch_back_to_stepped_thread: Assertion `!tp->control.trap_expected' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n)
The bug triggers if the thread trips on a breakpoint that needs stepping
over, just after stepping over another breakpoint. The condbreak-call-false.c
test involves an infcall, and therefore saving/restoring of trap_expected,
but that's not really necessary to trigger the bug.
On aarch64, the "foo" function ends up set on the function's first instruction:
(gdb) b foo if zero ()
Breakpoint 4 at 0x400518: file testsuite/gdb.base/condbreak-call-false.c, line 25.
(gdb) disassemble foo
Dump of assembler code for function foo:
0x0000000000400518 <+0>: mov w0, #0x17 // #23
0x000000000040051c <+4>: ret
While on x86_64, and most probably ARM too, it ends up set a couple
instructions further down:
(gdb) b foo if zero ()
Breakpoint 7 at 0x40054b: file ../../../src/gdb/testsuite/gdb.base/condbreak-call-false.c, line 25.
(gdb) disassemble foo
Dump of assembler code for function foo:
0x0000000000400547 <+0>: push %rbp
0x0000000000400548 <+1>: mov %rsp,%rbp
0x000000000040054b <+4>: mov $0x17,%eax
0x0000000000400550 <+9>: pop %rbp
0x0000000000400551 <+10>: retq
End of assembler dump.
So on aarch64, we hit the breakpoint at foo, which doesn't cause a stop,
just after stepping over the breakpoint at main.
The new gdb.base/consecutive-step-over.exp test added by the patch
linked above should trigger this issue, without infcalls, on all
platforms.
Thanks,