From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14258 invoked by alias); 17 Jan 2004 16:12:50 -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 14248 invoked from network); 17 Jan 2004 16:12:47 -0000 Received: from unknown (HELO localhost.redhat.com) (65.49.4.239) by sources.redhat.com with SMTP; 17 Jan 2004 16:12:47 -0000 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 635BB2B92; Sat, 17 Jan 2004 11:12:45 -0500 (EST) Message-ID: <40095EFD.4030609@gnu.org> Date: Sat, 17 Jan 2004 16:12:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030820 MIME-Version: 1.0 To: Daniel Jacobowitz Cc: gdb-patches@sources.redhat.com Subject: Re: RFA/ARM: Switch mode when setting PC 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> <20040117045843.GA31115@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-01/txt/msg00436.txt.bz2 >> 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? Hopefully not (well ignoring -tdep files). > 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. The change wouldn't be tested, and would be more work. > 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? What ever. Andrew