From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29162 invoked by alias); 21 Feb 2011 20:09:33 -0000 Received: (qmail 29144 invoked by uid 22791); 21 Feb 2011 20:09:31 -0000 X-SWARE-Spam-Status: No, hits=-1.3 required=5.0 tests=AWL,BAYES_00,MSGID_FROM_MTA_HEADER,SPF_SOFTFAIL,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mtagate3.uk.ibm.com (HELO mtagate3.uk.ibm.com) (194.196.100.163) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 21 Feb 2011 20:09:27 +0000 Received: from d06nrmr1507.portsmouth.uk.ibm.com (d06nrmr1507.portsmouth.uk.ibm.com [9.149.38.233]) by mtagate3.uk.ibm.com (8.13.1/8.13.1) with ESMTP id p1LK9OUw022914 for ; Mon, 21 Feb 2011 20:09:24 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 p1LK9WSX983196 for ; Mon, 21 Feb 2011 20:09:32 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 p1LK9NjY019155 for ; Mon, 21 Feb 2011 13:09:23 -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 p1LK9MEC019152; Mon, 21 Feb 2011 13:09:22 -0700 Message-Id: <201102212009.p1LK9MEC019152@d06av02.portsmouth.uk.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Mon, 21 Feb 2011 21:09:22 +0100 Subject: Re: [patch 2/3] Displaced stepping for 16-bit Thumb instructions To: yao@codesourcery.com (Yao Qi) Date: Mon, 21 Feb 2011 20:14:00 -0000 From: "Ulrich Weigand" Cc: gdb-patches@sourceware.org In-Reply-To: <4D6206C4.7030405@codesourcery.com> from "Yao Qi" at Feb 21, 2011 02:31:32 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-02/txt/msg00563.txt.bz2 Yao Qi wrote: > Yes. If I understand you correctly, modinsn is a 'unsigned long' array. > * ARM instruction occupies one slot with flag `ARM', > * Thumb 16 bit instruction occupies one slot with flag `Thumb' > * Thumb 32-bit instruction occupies *two* slots with flag `Thumb', > That works, I think. Yes, that's what I suggested. > I just recall one extra benefit of my original approach is about sharing > some copy_* routines for Thumb 32-bit instructions and ARM instructions. > In ARM manual, I noticed that some encodings of 32-bit Thumb-2 > instructions are the same ARM counterparts (such as preload preload_reg, > and svc_copro), so that their copy routines can be shared. Huh. Sharing copy routines seems a bit dangerous, because it only works if the copy routine only looks at those bits that are identical between the ARM and Thumb encoding (e.g. even for all the NEON instuctions, the position of the U bit is different), *and* the copy routine always only copies instructions in the correct format into the output buffer. While this may happen to work in certain cases (e.g. if we look only at a couple of bits and then do copy_unmodified), it seems a bit fragile as errors may be easily introduced by future changes. Having clearly separate copy routines for ARM and Thumb seems preferable to me, therefore; even if it leads to small amount of duplication. (If we're talking *large* amounts of duplicated code here, it might be possible to factor out some commonalities into helpers ...) Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com