From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19109 invoked by alias); 17 Jan 2004 04:58:44 -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 19102 invoked from network); 17 Jan 2004 04:58:43 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 17 Jan 2004 04:58:43 -0000 Received: from drow by nevyn.them.org with local (Exim 4.30 #1 (Debian)) id 1AhiXj-00088A-CZ for ; Fri, 16 Jan 2004 23:58:43 -0500 Date: Sat, 17 Jan 2004 04:58:00 -0000 From: Daniel Jacobowitz To: gdb-patches@sources.redhat.com Subject: Re: RFA/ARM: Switch mode when setting PC Message-ID: <20040117045843.GA31115@nevyn.them.org> Mail-Followup-To: gdb-patches@sources.redhat.com References: <200401161727.i0GHRxt24387@pc960.cambridge.arm.com> <40083792.7020102@gnu.org> <20040116035402.GA3215@nevyn.them.org> <40077A12.5040306@gnu.org> <20040116141040.GA8134@nevyn.them.org> <20040116173235.GA7498@nevyn.them.org> <40083424.1000102@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40083792.7020102@gnu.org> <40083424.1000102@gnu.org> User-Agent: Mutt/1.5.1i X-SW-Source: 2004-01/txt/msg00431.txt.bz2 On Fri, Jan 16, 2004 at 02:12:18PM -0500, Andrew Cagney wrote: > Or a lack of design, Arm needs to ensure that it doesn't define PC_REGNUM. OK, I'll keep that in mind. > >In the past we've tried to distinguish R15 from PC. This was especially > >useful in the legacy 26-bit mode where the CPSR bits *were* in R15. Perhaps, in that case, we should have the PC as a pseudoregister. That would simplify a lot of arm-tdep.c. Is it possible to use the existing ARM compiler and simulator (and newlib) in 26-bit mode without a lot of hassle, or would it be the work of months to make it happen? I'm reluctant to dig my fingers in too deeply if I can't test both code paths. > >This would probably all have been much simpler if I'd been able to > >complete my code for handling the banked register; sadly I never got far > >enough, and I think the code is probably too bit-rotten to be worth trying > >to resurrect directly at this point. > > If there's an explicit "set_resume_address", separate to write_pc, this > should happen: > > (gdb) set $r15 = 0x123 > - target sees: > $r15=0x123 > (gdb) call foo() OR (gdb) jump foo > - target, via "set_resume_address", sees: > $r15=&foo > $ps&|= > > and significantly no other write_pc calls. And at this point, is write_pc used for anything besides DECR_PC_AFTER_BREAK? I would prefer to add an adjust_pc_after_break, and then possibly rename the existing write_pc. Most of the write_pc implementations we have currently are really set-resume-address semantics. On Fri, Jan 16, 2004 at 01:57:40PM -0500, Andrew Cagney wrote: > >On Fri, Jan 16, 2004 at 09:10:40AM -0500, Daniel Jacobowitz wrote: > >Is this patch OK (write_pc isn't deprecated yet!)? Cleaning up the > >existing DECR_PC_AFTER_BREAK handling is going to be a touchy job, and > >I don't really want to try it today :) I'll try to look into it later, > >though. > I was suggesting "two methods so that it's clear that this case only > applies when doing a jump". This won't involve anything like > deprecating /removing decr_pc_after_break _+ write_pc but will involve > the addition of a new method like: > set_resume_address (arch, targ or tpid or regs) > that could somehow default to a legacy call to write_pc. Significantly, > this will avoid making the changes conditional on the elimination of > decr-pc (your concern). > > Why is this better? It clearly separates the [apparently] legetimate > resume case from the decr-pc case. This in turn opens the way for the > deprecate / delete decr-pc "write_pc" code while at the same time > ensuring that the work can't break the arm. Sorry, but you did not answer my question. My question was, are you specifically objecting to this patch pending the, IMO tangentially related, architectural cleanup? I understand your suggested change and your reasoning for it, I just don't understand your answer to my question. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer