From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30410 invoked by alias); 9 Jul 2015 10:38:31 -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 29574 invoked by uid 89); 9 Jul 2015 10:38:30 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=no 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 (AES256-GCM-SHA384 encrypted) ESMTPS; Thu, 09 Jul 2015 10:38:30 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id C9E77BC8FC; Thu, 9 Jul 2015 10:38:28 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t69AcRdm018835; Thu, 9 Jul 2015 06:38:28 -0400 Message-ID: <559E4F22.6040500@redhat.com> Date: Thu, 09 Jul 2015 10:38:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Markus Metzger CC: gdb-patches@sourceware.org Subject: Re: [PATCH v2 1/2] record: set stop_pc in "record goto" command References: <1436422132-8936-1-git-send-email-markus.t.metzger@intel.com> In-Reply-To: <1436422132-8936-1-git-send-email-markus.t.metzger@intel.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2015-07/txt/msg00272.txt.bz2 Thanks. On 07/09/2015 07:08 AM, Markus Metzger wrote: > When navigating in the recorded execution trace via "record goto", we do not > set stop_pc. This may trigger an internal error in infrun.c when stepping > from that location. Set it. > > (gdb) rec full > (gdb) c > Continuing. > > Breakpoint 1, foo (void) at foo.c:42 > 42 x = y > (gdb) rn > foo (void) > at foo.c:41 > 41 y = x > (gdb) rec go end > Go forward to insn number 98724 > at foo.c:42 > 42 x = y > (gdb) n > infrun.c:2382: internal-error: resume: Assertion `sig != GDB_SIGNAL_0' failed. > A problem internal to GDB has been detected, > further debugging may prove unreliable. > Quit this debugging session? (y or n) I realized that we had context in our minds from the private chats that might be missing from the archives/logs. I think we should extend the commit log a bit to connect the dots between "stop_pc not set" <-> "internal error". E.g.,: ~~~ This happens because there's a breakpoint at PC when the "next" is issued, so that breapoint should be immediately stepped over. That should have been detected/done by proceed, here: if (addr == (CORE_ADDR) -1) { if (pc == stop_pc && breakpoint_here_p (aspace, pc) == ordinary_breakpoint_here && execution_direction != EXEC_REVERSE) /* There is a breakpoint at the address we will resume at, step one instruction before inserting breakpoints so that we do not stop right away (and report a second hit at this breakpoint). Note, we don't do this in reverse, because we won't actually be executing the breakpoint insn anyway. We'll be (un-)executing the previous instruction. */ tp->stepping_over_breakpoint = 1; But since stop_pc was stale, the pc == stop_pc check failed, and left the breakpont at PC inserted. ~~~~~~ > +set bp [gdb_get_line_number "fun4.3" $srcfile] > +gdb_breakpoint $srcfile:$bp > + > +# record the execution until we hit a breakpoint > +gdb_test_no_output "record btrace" > +gdb_continue_to_breakpoint "cont to $bp" ".*$srcfile:$bp.*" > + Seems like these put line number in the test message in gdb.sum. Please tweak the messages to avoid that, so that if the test lines change in the future, the test messages remain stable. > +# reverse-step, then jump to the end of the trace > +gdb_test "reverse-next" ".*fun4\.2.*" > +gdb_test "record goto end" ".*fun4\.3.*" > + > +# test that we can continue stepping Please mention the breakpoint here. E.g.,: # test that we can continue stepping, even though # there's a breakpoint at PC. > +gdb_test "next" ".*fun4\.4.*" Fix these and you're good to go. Please push. Thanks, Pedro Alves