From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31814 invoked by alias); 31 Jan 2011 15:39:08 -0000 Received: (qmail 31803 invoked by uid 22791); 31 Jan 2011 15:39:07 -0000 X-SWARE-Spam-Status: No, hits=-0.4 required=5.0 tests=AWL,BAYES_20,MSGID_FROM_MTA_HEADER,SPF_SOFTFAIL,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mtagate4.uk.ibm.com (HELO mtagate4.uk.ibm.com) (194.196.100.164) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 31 Jan 2011 15:39:02 +0000 Received: from d06nrmr1507.portsmouth.uk.ibm.com (d06nrmr1507.portsmouth.uk.ibm.com [9.149.38.233]) by mtagate4.uk.ibm.com (8.13.1/8.13.1) with ESMTP id p0VFcxOC005067 for ; Mon, 31 Jan 2011 15:38:59 GMT Received: from d06av02.portsmouth.uk.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1507.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p0VFd22Q1404942 for ; Mon, 31 Jan 2011 15:39:02 GMT Received: from d06av02.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av02.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p0VFcx7b019563 for ; Mon, 31 Jan 2011 08:38:59 -0700 Received: from tuxmaker.boeblingen.de.ibm.com (tuxmaker.boeblingen.de.ibm.com [9.152.85.9]) by d06av02.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with SMTP id p0VFcwIn019533; Mon, 31 Jan 2011 08:38:58 -0700 Message-Id: <201101311538.p0VFcwIn019533@d06av02.portsmouth.uk.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Mon, 31 Jan 2011 16:38:58 +0100 Subject: Re: [try 3rd] arm_pc_is_thumb takes displaced stepping into account To: yao@codesourcery.com (Yao Qi) Date: Mon, 31 Jan 2011 15:40:00 -0000 From: "Ulrich Weigand" Cc: gdb-patches@sourceware.org In-Reply-To: <4D2D27F2.7050303@codesourcery.com> from "Yao Qi" at Jan 11, 2011 10:02:58 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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: 2011-01/txt/msg00586.txt.bz2 Yao Qi wrote: > This time, instead of exposing displaced_step_inferior_state to tdep, we > return displaced_step_closure, which is defined by each tdep, instance > to tdep appropriately. Hmmm. I see one problem with this approach: > +/* If inferior is in displaced stepping, and ADDR equals to starting address > + of copy area, return corresponding displaced_step_closure. Otherwise, > + return NULL. */ What if the copy area contains more than a single instruction, and we need to find out the mode of the PC corresponding to the second of them? Your get_displaced_step_closure_by_addr routine would not find the closure in this case, because the PC doesn't match the start address. I had originally suggested to create a function that would recognize any PC within the copy area. But it seems this cannot be implemented in common code, since common code does not actually know the length of the copy area. Matthew suggested to keep another list of copy areas in target-dependent code instead. While I don't really like to keep duplicated data, it would appear that this approach is able to handle the above situation. Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com