From patchwork Mon Jul 28 11:30:56 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Yao Qi X-Patchwork-Id: 2194 Received: (qmail 32179 invoked by alias); 28 Jul 2014 11:34:41 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 32166 invoked by uid 89); 28 Jul 2014 11:34:40 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=AWL, BAYES_00, KAM_STOCKGEN autolearn=no version=3.3.2 X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 28 Jul 2014 11:34:39 +0000 Received: from svr-orw-fem-01.mgc.mentorg.com ([147.34.98.93]) by relay1.mentorg.com with esmtp id 1XBjCO-00033f-5z from Yao_Qi@mentor.com for gdb-patches@sourceware.org; Mon, 28 Jul 2014 04:34:36 -0700 Received: from SVR-ORW-FEM-05.mgc.mentorg.com ([147.34.97.43]) by svr-orw-fem-01.mgc.mentorg.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 28 Jul 2014 04:34:36 -0700 Received: from localhost.localdomain (147.34.91.1) by svr-orw-fem-05.mgc.mentorg.com (147.34.97.43) with Microsoft SMTP Server id 14.2.247.3; Mon, 28 Jul 2014 04:34:35 -0700 From: Yao Qi To: Subject: [PATCH] Fix PR 17206 Date: Mon, 28 Jul 2014 19:30:56 +0800 Message-ID: <1406547056-22541-1-git-send-email-yao@codesourcery.com> MIME-Version: 1.0 X-IsSubscribed: yes As reported in PR 17206, an internal error is triggered when command until is executed. In infcmd.c:until_next_command, step_range_end is set to 'pc', if (!func) { struct bound_minimal_symbol msymbol = lookup_minimal_symbol_by_pc (pc); if (msymbol.minsym == NULL) error (_("Execution is not within a known function.")); tp->control.step_range_start = BMSYMBOL_VALUE_ADDRESS (msymbol); tp->control.step_range_end = pc; } and later in infrun.c:resume, the assert below is triggered in PR 17206. if (tp->control.may_range_step) { /* If we're resuming a thread with the PC out of the step range, then we're doing some nested/finer run control operation, like stepping the thread out of the dynamic linker or the displaced stepping scratch pad. We shouldn't have allowed a range step then. */ gdb_assert (pc_in_thread_step_range (pc, tp)); } In until_next_command, we set step range to [XXX, pc), so pc isn't within the range. pc_in_thread_step_range returns false and the assert is triggered. AFAICS, the range we want in until_next_command is [XXX, pc] instead of [XXX, pc), because we want to program step until greater than pc. This patch is to set step_range_end to 'pc + 1'. Regression tested on x86_64-linux, both native and gdbserver. gdb: 2014-07-28 Yao Qi PR gdb/17206 * infcmd.c (until_next_command): Set step_range_end to PC + 1. --- gdb/infcmd.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/gdb/infcmd.c b/gdb/infcmd.c index 76ec560..50cc04b 100644 --- a/gdb/infcmd.c +++ b/gdb/infcmd.c @@ -1359,7 +1359,9 @@ until_next_command (int from_tty) error (_("Execution is not within a known function.")); tp->control.step_range_start = BMSYMBOL_VALUE_ADDRESS (msymbol); - tp->control.step_range_end = pc; + /* The upper-bound of step_range is exclusive. In order to make PC + within the range, set the step_range_end with PC + 1. */ + tp->control.step_range_end = pc + 1; } else {