From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22287 invoked by alias); 8 Mar 2004 14:19:34 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 22277 invoked from network); 8 Mar 2004 14:19:33 -0000 Received: from unknown (HELO cam-admin0.cambridge.arm.com) (193.131.176.58) by sources.redhat.com with SMTP; 8 Mar 2004 14:19:33 -0000 Received: from pc960.cambridge.arm.com (pc960.cambridge.arm.com [10.1.205.4]) by cam-admin0.cambridge.arm.com (8.12.10/8.12.10) with ESMTP id i28EJU23028832; Mon, 8 Mar 2004 14:19:30 GMT Received: from pc960.cambridge.arm.com (rearnsha@localhost) by pc960.cambridge.arm.com (8.11.6/8.9.3) with ESMTP id i28EJTH10164; Mon, 8 Mar 2004 14:19:29 GMT Message-ID: <200403081419.i28EJTH10164@pc960.cambridge.arm.com> X-Authentication-Warning: pc960.cambridge.arm.com: rearnsha owned process doing -bs To: Daniel Jacobowitz cc: Richard Earnshaw , gdb-patches@sources.redhat.com Reply-To: Richard Earnshaw Organization: ARM Ltd. X-Telephone: +44 1223 400569 (direct+voicemail), +44 1223 400400 (switchbd) X-Fax: +44 1223 400410 X-Address: ARM Ltd., 110 Fulbourn Road, Cherry Hinton, Cambridge CB1 9NJ. X-Url: http://www.arm.com/ Subject: Re: [rfa/arm] Handle bx and blx In-reply-to: Your message of "Mon, 08 Mar 2004 09:09:49 EST." <20040308140948.GA14686@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 08 Mar 2004 14:19:00 -0000 From: Richard Earnshaw X-SW-Source: 2004-03.o/txt/msg00152.txt Message-ID: <20040308141900.SYiCojaEqZzRaDyVmoEa31_iT_NKV1URqeH43FdixUY@z> > On Mon, Mar 08, 2004 at 10:17:53AM +0000, Richard Earnshaw wrote: > > > On Wed, Mar 03, 2004 at 04:01:55PM +0000, Richard Earnshaw wrote: > > > > > The software single-step implementation in GDB doesn't know either BX or > > > > > BLX. This results in losing control of the inferior when we single-step > > > > > over them. I based this on the ARM ARM, so I'm pretty sure I've got the > > > > > numbers correct. > > > > > > > > > > OK to check in? > > > > > > > > > > -- > > > > > Daniel Jacobowitz > > > > > MontaVista Software Debian GNU/Linux Developer > > > > > > > > > > 2004-02-28 Daniel Jacobowitz > > > > > > > > > > * arm-tdep.c (thumb_get_next_pc): Handle BX. > > > > > (arm_get_next_pc): Handle BX and BLX. > > > > > > > > Yikes! Yes, this is OK. However, Thumb has BLX (2 variants) as well. > > > > > > Right you are. I've checked in the above; if I'm reading > > > thumb_get_next_pc and the ARM correctly, then the below is all I need > > > for BLX. The first form is already handled since we don't check H. > > > The second form can be handled identically to BX by relaxing a test. > > > > > > OK? > > > > > > -- > > > Daniel Jacobowitz > > > MontaVista Software Debian GNU/Linux Developer > > > > > > 2004-03-07 Daniel Jacobowitz > > > > > > * arm-tdep.c (thumb_get_next_pc): Handle Thumb BLX. > > > > Very close, and possibly good enough for most purposes. But the ARM ARM > > says that in the blx(1) case, the resulting address should be masked with > > 0xfffffffc. That means that there are two theoretical encodings for each > > target ARM-state instruction. I think you need to add a test for H=01 and > > if so, to apply the mask to nextpc. > > Except it also says: > Bit[0] for BLX If H == 01, then bit[0] of the instruction must > be zero, or the instruction is UNDEFINED. > The offset calculation method described > in Usage above ensures that the offset > calculated for a BLX instruction is a > multiple of four, and that this > restriction is obeyed. > > So I think the mask really isn't needed, or am I reading that wrong? Ah, missed that bit. However, we could be starting with a pc value where pc[1] != 0, so we still need the mask. R.