From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10838 invoked by alias); 21 Sep 2011 06:09:05 -0000 Received: (qmail 10819 invoked by uid 22791); 21 Sep 2011 06:09:03 -0000 X-SWARE-Spam-Status: No, hits=-1.6 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 21 Sep 2011 06:08:48 +0000 Received: from nat-jpt.mentorg.com ([192.94.33.2] helo=PR1-MAIL.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1R6FzD-0007F8-O4 from Yao_Qi@mentor.com ; Tue, 20 Sep 2011 23:08:47 -0700 Received: from [127.0.0.1] ([172.16.63.104]) by PR1-MAIL.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Sep 2011 15:08:46 +0900 Subject: Re: Displaced stepping not always working as expected From: Yao Qi To: Marc Khouzam Cc: "'gdb@sourceware.org'" In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Date: Wed, 21 Sep 2011 06:09:00 -0000 Message-ID: <1316585323.4150.25.camel@yaolp> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2011-09/txt/msg00077.txt.bz2 On Tue, 2011-09-20 at 15:54 -0400, Marc Khouzam wrote: > Can someone let me know where in GDB I can look to see why a displaced > instruction is not being executed? Or maybe other debug logs to enable? > Usually, I use 'set debug displaced 1' and 'set debug infrun 1' together. Looks you have used them. I don't know extra debug log to turn on. > ^^^^^^^^ > 'next' operation stuck at line 9 of my program: > ============================================== > (gdb) n > infrun: clear_proceed_status_thread (Thread 0x40b21940 (LWP 763)) > infrun: proceed (addr=0xffffffffffffffff, signal=144, step=1) > infrun: resume (step=1, signal=0), trap_expected=1 > displaced: stepping Thread 0x40b21940 (LWP 763) now > displaced: saved 0x4006d2: 49 89 d1 5e 48 89 e2 48 83 e4 f0 50 54 49 c7 c0 > displaced: copy 0x40083e->0x4006d2: 83 6d fc 01 8b 75 fc bf 8c 09 40 00 b8 00 00 00 > displaced: displaced pc to 0x4006d2 > displaced: run 0x4006d2: 83 6d fc 01 > infrun: target_wait (-1, status) = > infrun: 760 [Thread 0x40b21940 (LWP 763)], > infrun: status->kind = stopped, signal = SIGTRAP > infrun: Switching context from Thread 0x40b21940 (LWP 763) to Thread 0x40b21940 (LWP 763) The line of log looks strange to me. Why LWP 763 switch to itself? Usually, what I saw here is "from Thread A to Thread B", while A != B. In this case, I know current displaced stepping infrastructure doesn't handle "thread context switch during displaced stepping". That is, when some insns are copied to scratch pad and executed in thread A, but thread B gets an event first. Then gdb will forget that Thread A is displaced stepping after handle event for Thread B. This problem is quite similar to context switch during software-single-step. I don't think this is the same problem you asked here. I had drafted a patch for this problem I described above, but still need some time.