From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18034 invoked by alias); 21 Dec 2010 16:19:15 -0000 Received: (qmail 18021 invoked by uid 22791); 21 Dec 2010 16:19:13 -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; Tue, 21 Dec 2010 16:19:07 +0000 Received: (qmail 26995 invoked from network); 21 Dec 2010 16:19:05 -0000 Received: from unknown (HELO ?192.168.0.101?) (yao@127.0.0.2) by mail.codesourcery.com with ESMTPA; 21 Dec 2010 16:19:05 -0000 Message-ID: <4D10D377.8080100@codesourcery.com> Date: Tue, 21 Dec 2010 16:19: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: 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> <4D0F5D36.2040909@codesourcery.com> In-Reply-To: <4D0F5D36.2040909@codesourcery.com> 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/msg00379.txt.bz2 On 12/20/2010 09:42 PM, Yao Qi wrote: > 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. When writing the new patch, I re-consider this problem again. GDB doesn't support displaced stepping on sparc and hppa, so it is not harmful to sparc and hppa when regcache_write_pc is replaced by regcache_cooked_write_unsigned. Currently, GDB supports displaced stepping on s390, rs6000 (including ppc-linux, aix), i386, amd64 and arm. AFAICS, this replacement in my original patch is not harmful to these targets. >> 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? My new patch is drafted in this way, but it looks not better than my original one, because in my new patch, some state of displaced stepping has to be exposed to arm-tdep.c in order to return the correct mode (ARM or Thumb) according to the address of copy area. Unless we make some refactor to extract displaced stepping from infrun, this approach makes code looks ugly. Given my original patch is clean, and not harmful to existing targets support displaced stepping, please consider my original patch again. Comments on promising directions/approaches are welcome. -- Yao (齐尧)