From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10128 invoked by alias); 20 Dec 2010 13:42:29 -0000 Received: (qmail 10114 invoked by uid 22791); 20 Dec 2010 13:42:28 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 20 Dec 2010 13:42:23 +0000 Received: (qmail 20080 invoked from network); 20 Dec 2010 13:42:21 -0000 Received: from unknown (HELO ?192.168.0.101?) (yao@127.0.0.2) by mail.codesourcery.com with ESMTPA; 20 Dec 2010 13:42:21 -0000 Message-ID: <4D0F5D36.2040909@codesourcery.com> Date: Mon, 20 Dec 2010 13:42:00 -0000 From: Yao Qi User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: Mark Kettenis CC: gdb-patches@sourceware.org Subject: Re: [rfa] Update PC without side effect in displaced stepping References: <4D0F0ABA.9010506@codesourcery.com> <201012200804.oBK84oPu005379@glazunov.sibelius.xs4all.nl> In-Reply-To: <201012200804.oBK84oPu005379@glazunov.sibelius.xs4all.nl> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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-12/txt/msg00366.txt.bz2 On 12/20/2010 04:04 PM, Mark Kettenis wrote: > > Sorry, no this isn't right. On sparc and hppa for example, the > effects of write_pc() are needed here, since both the pc and the "next > pc" registers need to be updated to make sure all instructions in the > copy area get executed. > I know very little on sparc and hppa. Thanks for your explanation. > I think you'll have to make sure that if the displaced instructions > are Thumb instructions, the copy area gets properly marked as Thumb > such that write_pc() can do the right thing on arm as well. That works. If we do so, given an address of an instruction, we have to return the mode of original instruction in displaced stepping, and return real mode there otherwise. However, current GDB dose not provide interfaces to target-dependent parts to query the state of displaced stepping. Shall we refactor infrun.c a little bit to move some code to displace_step.[c|h], and expose them to target-dependent part? -- Yao (齐尧)