From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3706 invoked by alias); 21 Feb 2006 15:36:10 -0000 Received: (qmail 3697 invoked by uid 22791); 21 Feb 2006 15:36:10 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Tue, 21 Feb 2006 15:36:04 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1FBZYX-0005Y6-Tm; Tue, 21 Feb 2006 10:36:01 -0500 Date: Tue, 21 Feb 2006 16:10:00 -0000 From: Daniel Jacobowitz To: Richard Earnshaw Cc: gdb-patches@sourceware.org, Shaun Jackman Subject: Re: RFC: Use the ARM CPSR as a fallback to determine ARM/Thumb Message-ID: <20060221153601.GA21183@nevyn.them.org> Mail-Followup-To: Richard Earnshaw , gdb-patches@sourceware.org, Shaun Jackman References: <20060220214918.GA28798@nevyn.them.org> <1140519913.27380.29.camel@pc960.cambridge.arm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1140519913.27380.29.camel@pc960.cambridge.arm.com> User-Agent: Mutt/1.5.8i X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-02/txt/msg00393.txt.bz2 On Tue, Feb 21, 2006 at 11:05:13AM +0000, Richard Earnshaw wrote: > I can sympathise... :-) Also note that for a lot of ARM users, > defaulting to ARM is exactly the wrong choice, since all their code is > Thumb (with the possible exception of some start-up code and other small > trampolines). I think that guessing based on the current CPSR is a > better guess than just ARM, if you can sort out the 'what we guessed > last time we looked at this address problem...'. OK, I will fix up the patch. > > Maybe there should be a "set" option for the default when no symbol is > > found, allowing the user to throttle this back to ARM-only if that works > > better for them? > > I certainly think we need a set option, but it's more complex than that, > since I think it needs probably four states: > > arm - force to ARM mode even if things look otherwise. > thumb - force to Thumb mode even if things look otherwise. > auto-arm - Try to work it out, but guess ARM if unknown > auto-thumb - Try to work it out, but guess Thumb if unknown > > Another approach would be some augmentation to a memory-region type > command, something like > > add code-region [arm|thumb|auto-arm|auto-thumb] [+|] What I had in mind for this was: set arm fallback-mode [arm|thumb|auto] That is, continue to honor symbol information, but change the fallback when we don't have symbols to arm, thumb, or current cpsr. And maybe augment that with: set arm force-mode [arm|thumb|auto] This would also override symbol information. This is basically the same as your first option, but spread out over two variables. How does that sound? I'd rather avoid regions here; they're complicated, and not a very useful way to describe arm/thumb mixing. Hmm, software single step probably gets very confused over mode changes; not going to touch that right now though. -- Daniel Jacobowitz CodeSourcery