From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20668 invoked by alias); 29 Apr 2014 11:02:18 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 20638 invoked by uid 89); 29 Apr 2014 11:02:16 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: service87.mimecast.com Received: from service87.mimecast.com (HELO service87.mimecast.com) (91.220.42.44) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 29 Apr 2014 11:02:13 +0000 Received: from cam-owa2.Emea.Arm.com (fw-tnat.cambridge.arm.com [217.140.96.21]) by service87.mimecast.com; Tue, 29 Apr 2014 12:02:10 +0100 Received: from [10.1.209.51] ([10.1.255.212]) by cam-owa2.Emea.Arm.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 29 Apr 2014 12:02:22 +0100 Message-ID: <535F86AE.5000406@arm.com> Date: Tue, 29 Apr 2014 11:02:00 -0000 From: Alan Lawrence User-Agent: Thunderbird 2.0.0.24 (X11/20101213) MIME-Version: 1.0 To: Pedro Alves CC: "gdb-patches@sourceware.org" Subject: Re: [PATCH 5/6] Handle multiple step-overs References: <53330643.4040402@arm.com> <5356B823.3090409@redhat.com> In-Reply-To: <5356B823.3090409@redhat.com> X-MC-Unique: 114042912021007601 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2014-04/txt/msg00608.txt.bz2 Hi Pedro, Sorry for the delay in replying, I've been away a few days lately. I can co= nfirm=20 this does indeed appear to be fixed now. Thanks! :) --Alan Pedro Alves wrote: > Hi Alan, >=20 > Thanks. This should now be fixed in mainline: >=20 > https://sourceware.org/ml/gdb-patches/2014-04/msg00436.html >=20 > Could you give it a try please? >=20 > 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=20 >> beb460e8d2ddf5327a6ab146055a6e6e9f552a4b, condbreak-call-false.{c,exp} -= I've=20 >> tried this testcase both before and after your multiple step-over patch,= and it=20 >> succeeds without the patch. I'm not very familiar with gdb internals and= =20 >> stepwise comparing AArch64 against ARM (on which the test passes) sounds= at best=20 >> laborious; hoping there may be some experts here who can help? >=20 > Against user mode qemu-aarch64: >=20 > 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=3D0xffffffffffffffff, signal=3DGDB_SIGNAL_DEFAULT, = step=3D0) > infrun: resume (step=3D1, signal=3DGDB_SIGNAL_0), trap_expected=3D1, curr= ent thread [Remote target] at 0x40052c > infrun: wait_for_inferior () > infrun: target_wait (-1, status) =3D > infrun: 42000 [Remote target], > infrun: status->kind =3D stopped, signal =3D GDB_SIGNAL_TRAP > infrun: infwait_normal_state > infrun: TARGET_WAITKIND_STOPPED > infrun: stop_pc =3D 0x400518 > infrun: clear_proceed_status_thread (Remote target) > infrun: proceed (addr=3D0x400510, signal=3DGDB_SIGNAL_0, step=3D0) > infrun: resume (step=3D0, signal=3DGDB_SIGNAL_0), trap_expected=3D0, curr= ent thread [Remote target] at 0x400510 > infrun: wait_for_inferior () > infrun: target_wait (-1, status) =3D > infrun: 42000 [Remote target], > infrun: status->kind =3D stopped, signal =3D GDB_SIGNAL_TRAP > infrun: infwait_normal_state > infrun: TARGET_WAITKIND_STOPPED > infrun: stop_pc =3D 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_threa= d: 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) >=20 > The bug triggers if the thread trips on a breakpoint that needs stepping > over, just after stepping over another breakpoint. The condbreak-call-fa= lse.c > test involves an infcall, and therefore saving/restoring of trap_expected, > but that's not really necessary to trigger the bug. >=20 > On aarch64, the "foo" function ends up set on the function's first instru= ction: >=20 > (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 >=20 > While on x86_64, and most probably ARM too, it ends up set a couple > instructions further down: >=20 > (gdb) b foo if zero () > Breakpoint 7 at 0x40054b: file ../../../src/gdb/testsuite/gdb.base/condb= reak-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. >=20 > So on aarch64, we hit the breakpoint at foo, which doesn't cause a stop, > just after stepping over the breakpoint at main. >=20 > The new gdb.base/consecutive-step-over.exp test added by the patch > linked above should trigger this issue, without infcalls, on all > platforms. >=20 > Thanks,