Re: [PATCH 5/6] Handle multiple step-overs

[Pedro Alves <palves at redhat dot com>]

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,
-- 
Pedro Alves