From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31942 invoked by alias); 20 Dec 2010 07:50:31 -0000 Received: (qmail 31932 invoked by uid 22791); 20 Dec 2010 07:50:30 -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 07:50:24 +0000 Received: (qmail 25712 invoked from network); 20 Dec 2010 07:50:22 -0000 Received: from unknown (HELO ?192.168.0.101?) (yao@127.0.0.2) by mail.codesourcery.com with ESMTPA; 20 Dec 2010 07:50:22 -0000 Message-ID: <4D0F0ABA.9010506@codesourcery.com> Date: Mon, 20 Dec 2010 07:50: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: [rfa] Update PC without side effect in displaced stepping Content-Type: multipart/mixed; boundary="------------050000070908090708010204" 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/msg00364.txt.bz2 This is a multi-part message in MIME format. --------------050000070908090708010204 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Content-length: 1182 During preparation of displaced stepping (in displaced_step_prepare), regcache_write_pc is called to update PC to the address of copy area, and gdbarch_write_pc is called subsequently. However, gdbarch_write_pc has some side effects besides updating PC values. As far as I know on updating PC in displaced_step_prepare, what we need here is to force program to execute one or some instructions in copy area, and get the *same* effect of single-step one instruction on original place, so we should update PC without any side effect. Current approach may have some drawbacks in some cases. For example, on ARM, system library is compiled in Thumb mode, and application is compiled in ARM mode. The copy area for displaced stepping is in thumb mode. During displaced stepping, GDB copies that ARM instruction to copy area, and using regcache_write_pc to update PC to the new address of this instruction. Due to the side effect of arm_write_pc, the T bit is set in status register, so one 32-bit ARM instruction is interpreted as two 16-bit thumb instructions by mistake. This patch is to fix this problem. Regression tested on x86_64-linux. OK for mainline? -- Yao (齐尧) --------------050000070908090708010204 Content-Type: text/x-patch; name="displaced_step_prepare.1220.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="displaced_step_prepare.1220.patch" Content-length: 836 2010-12-20 Yao Qi * infrun.c (displaced_step_prepare): Replace regcache_write_pc by regcache_cooked_write_unsigned to update PC without side effect. diff --git a/gdb/infrun.c b/gdb/infrun.c index 1bc00a4..2711e19 100644 --- a/gdb/infrun.c +++ b/gdb/infrun.c @@ -1304,8 +1304,13 @@ displaced_step_prepare (ptid_t ptid) make_cleanup (displaced_step_clear_cleanup, displaced); - /* Resume execution at the copy. */ - regcache_write_pc (regcache, copy); + /* Resume execution at the copy. Update PC without any side effects. */ + if (gdbarch_pc_regnum (gdbarch) >= 0) + regcache_cooked_write_unsigned (regcache, + gdbarch_pc_regnum (gdbarch), copy); + else + internal_error (__FILE__, __LINE__, + _("displaced: Unable to update PC")); discard_cleanups (ignore_cleanups); --------------050000070908090708010204--