From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10200 invoked by alias); 20 Aug 2010 08:38:34 -0000 Received: (qmail 10188 invoked by uid 22791); 20 Aug 2010 08:38:33 -0000 X-SWARE-Spam-Status: No, hits=-1.6 required=5.0 tests=AWL,BAYES_00,TW_GJ,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from cam-admin0.cambridge.arm.com (HELO cam-admin0.cambridge.arm.com) (217.140.96.50) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 20 Aug 2010 08:38:29 +0000 Received: from cam-owa2.Emea.Arm.com (cam-owa2.emea.arm.com [10.1.105.18]) by cam-admin0.cambridge.arm.com (8.12.6/8.12.6) with ESMTP id o7K8bJF9025507; Fri, 20 Aug 2010 09:37:19 +0100 (BST) Received: from [10.1.77.63] ([10.1.255.212]) by cam-owa2.Emea.Arm.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 20 Aug 2010 09:38:23 +0100 Subject: Re: [rfc] Strip Thumb bit from PC returned by arm_get_longjmp_target From: Matthew Gretton-Dann To: Ulrich Weigand Cc: gdb-patches@sourceware.org In-Reply-To: <201008190849.o7J8nEkP025126@d12av02.megacenter.de.ibm.com> References: <201008190849.o7J8nEkP025126@d12av02.megacenter.de.ibm.com> Content-Type: text/plain; charset="ISO-8859-1" Date: Fri, 20 Aug 2010 08:38:00 -0000 Message-ID: <1282293503.7290.8.camel@e102319-lin.cambridge.arm.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit 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: 2010-08/txt/msg00364.txt.bz2 On Thu, 2010-08-19 at 10:49 +0200, Ulrich Weigand wrote: > > Matthew Gretton-Dann wrote: > > > > > The problem with the patch is it removes what may be the only way we > > > have of telling the instruction state of the longjmp target. If you > > > have debugging information (mapping symbols at the very least) > > > everything is fine, but if you don't then how do you tell what the state > > > is? arm_pc_is_thumb does use this bit to detect the instruction state > > > (and arm_breakpoint_from_pc then uses this result to determine the > > > breakpoint type). > > > > Ah, I see. I was confused about just where the Thumb bit was supposed > > to be present and where not, sorry ... > > > > > In the case above I think the correct fix is to make > > > arm_adjust_breakpoint_address not strip out the address bits (which it > > > does when trying to work out whether we are single stepping through an > > > IT block). > > > > Does the patch below seem reasonable to you? > > Actually, it turns out this new patch doesn't work. It leads to: > > Breakpoint 4 at 0x84ec: file ../../../gdb-head/gdb/testsuite/gdb.threads/threxit-hop-specific.c, line 47.^M > (gdb) next^M > ^M > Program received signal SIGTRAP, Trace/breakpoint trap.^M > > This happens because GDB now no longer recognizes the PC address > when the breakpoint trap arrives. The PC is compared against > the breakpoint location's loc->address value -- which now has the > Thumb bit set, but the PC doesn't. > > Note that while the Thumb bit gets removes in arm_breakpoint_from_pc, > this affects only loc->placed_address, not loc->address. > > This seems to indicate that in fact, breakpoint addresses must > *not* have the Thumb bit set ... > > Do you have a case where this works for you? I don't have a case. I think this means that the original patch is the correct one for the moment - but I'm not a maintainer so this isn't an approval. Also, looking at the code in arm_adjust_breakpoint_address I think there are other cases that may cause the failure you are seeing above (for instance when using Thumb-2 in the absence of mapping symbols and setting the breakpoint on 0x8001). We still need to come up with a way to be able to better pass the instruction set state around with the PC (I'll respond to your earlier email with some of my thoughts). Thanks, Matt -- Matthew Gretton-Dann Principal Engineer - PDSW Tools ARM Ltd