From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30077 invoked by alias); 22 Apr 2014 18:42:52 -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 30067 invoked by uid 89); 22 Apr 2014 18:42:52 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 22 Apr 2014 18:42:51 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s3MIgkJI011193 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 22 Apr 2014 14:42:47 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s3MIghNI005423; Tue, 22 Apr 2014 14:42:45 -0400 Message-ID: <5356B823.3090409@redhat.com> Date: Tue, 22 Apr 2014 18:42:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: Alan Lawrence CC: gdb-patches@sourceware.org Subject: Re: [PATCH 5/6] Handle multiple step-overs References: <53330643.4040402@arm.com> In-Reply-To: <53330643.4040402@arm.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2014-04/txt/msg00437.txt.bz2 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