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

[Alan Lawrence <alan.lawrence@arm.com>]

Hi Pedro,

Sorry for the delay in replying, I've been away a few days lately. I can confirm 
this does indeed appear to be fixed now. Thanks! :)

--Alan

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