From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30410 invoked by alias); 11 Aug 2012 07:45:53 -0000 Received: (qmail 30402 invoked by uid 22791); 11 Aug 2012 07:45:51 -0000 X-SWARE-Spam-Status: No, hits=-4.3 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,TW_BL,TW_XT X-Spam-Check-By: sourceware.org Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 11 Aug 2012 07:45:37 +0000 Received: from svr-orw-exc-10.mgc.mentorg.com ([147.34.98.58]) by relay1.mentorg.com with esmtp id 1T06O8-0000E0-CF from Yao_Qi@mentor.com for gdb-patches@sourceware.org; Sat, 11 Aug 2012 00:45:36 -0700 Received: from SVR-ORW-FEM-04.mgc.mentorg.com ([147.34.97.41]) by SVR-ORW-EXC-10.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 11 Aug 2012 00:45:36 -0700 Received: from [127.0.0.1] (147.34.91.1) by svr-orw-fem-04.mgc.mentorg.com (147.34.97.41) with Microsoft SMTP Server id 14.1.289.1; Sat, 11 Aug 2012 00:45:35 -0700 Message-ID: <50260D91.5070000@codesourcery.com> Date: Sat, 11 Aug 2012 07:45:00 -0000 From: Yao Qi User-Agent: Mozilla/5.0 (X11; Linux i686; rv:13.0) Gecko/20120601 Thunderbird/13.0 MIME-Version: 1.0 To: "Joseph S. Myers" CC: Subject: Re: Fix ARM stepping over Thumb-mode "bx pc" or "blx pc" References: In-Reply-To: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-IsSubscribed: yes 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 X-SW-Source: 2012-08/txt/msg00332.txt.bz2 On 08/11/2012 01:06 AM, Joseph S. Myers wrote: > arm-tdep.c has code to determine the next instruction for use in > single stepping. This code fails to handle a Thumb-mode "bx pc" or > "blx pc" correctly; it acts as if the branch target (four bytes after > the current instruction) should be in Thumb mode, when actually these Yes, as we can see, at the beginning of thumb_get_next_pc_raw, the 'pc_val' is converted to THUMB_ADDR, static CORE_ADDR thumb_get_next_pc_raw (struct frame_info *frame, CORE_ADDR pc) { [...] pc_val = MAKE_THUMB_ADDR (pc_val) > Index: gdb/arm-tdep.c > =================================================================== > RCS file: /cvs/src/src/gdb/arm-tdep.c,v > retrieving revision 1.365 > diff -u -r1.365 arm-tdep.c > --- gdb/arm-tdep.c 25 Jun 2012 12:32:45 -0000 1.365 > +++ gdb/arm-tdep.c 10 Aug 2012 15:18:37 -0000 > @@ -4541,7 +4541,7 @@ > else if ((inst1 & 0xff00) == 0x4700) /* bx REG, blx REG */ > { > if (bits (inst1, 3, 6) == 0x0f) > - nextpc = pc_val; > + nextpc = pc_val & 0xfffffffc; > else > nextpc = get_frame_register_unsigned (frame, bits (inst1, 3, 6)); > } I don't have any preference on clearing either the last one bit in address or the last two bits. Looks like two ways coexist in arm-tdep.c nowadays. As 'pc_val' is set by MAKE_THUMB_ADDR at the beginning, it is better to revert its change by using UNMAKE_THUMB_ADDR (which only clears the last one bit of address). -- Yao (齐尧)