From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15446 invoked by alias); 28 Feb 2012 13:55:49 -0000 Received: (qmail 15437 invoked by uid 22791); 28 Feb 2012 13:55:47 -0000 X-SWARE-Spam-Status: No, hits=-1.5 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; Tue, 28 Feb 2012 13:55:33 +0000 Received: from svr-orw-fem-01.mgc.mentorg.com ([147.34.98.93]) by relay1.mentorg.com with esmtp id 1S2NWe-00027s-Kv from Yao_Qi@mentor.com ; Tue, 28 Feb 2012 05:55:32 -0800 Received: from SVR-ORW-FEM-05.mgc.mentorg.com ([147.34.97.43]) by svr-orw-fem-01.mgc.mentorg.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 28 Feb 2012 05:55:32 -0800 Received: from [127.0.0.1] (147.34.91.1) by svr-orw-fem-05.mgc.mentorg.com (147.34.97.43) with Microsoft SMTP Server id 14.1.289.1; Tue, 28 Feb 2012 05:55:31 -0800 Message-ID: <4F4CDCD0.7020906@codesourcery.com> Date: Tue, 28 Feb 2012 14:57:00 -0000 From: Yao Qi User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Jan Kratochvil CC: Subject: Re: [patch] Fix disp-step-syscall.exp on some i386 targets References: <20120227192228.GA15792@host2.jankratochvil.net> <4F4C874E.7060203@codesourcery.com> <20120228084050.GA1296@host2.jankratochvil.net> <4F4CA669.7040209@codesourcery.com> <20120228134241.GA24390@host2.jankratochvil.net> In-Reply-To: <20120228134241.GA24390@host2.jankratochvil.net> 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: 2012-02/txt/msg00652.txt.bz2 On 02/28/2012 09:42 PM, Jan Kratochvil wrote: > +/* Linux kernel shows PC value after the 'int $0x80' instruction even if > + inferior is still inside the syscall. On next PTRACE_SINGLESTEP it will > + finish the syscall but PC will not change. > + > + Some vDSOs contain 'int $0x80; ret' and during stepping out of the syscall > + i386_displaced_step_fixup would keep PC at the displaced pad location. > + As PC is pointing to the 'ret' instruction before the step > + i386_displaced_step_fixup would expect inferior has just executed that 'ret' > + and PC should not be adjusted. In reality it finished syscall instead and > + PC should get relocated back to its vDSO address. Hide the 'ret' > + instruction by 'nop' so that i386_displaced_step_fixup is not confused. > + > + It is not fully correct as the bytes in struct displaced_step_closure will > + not match the inferior code. But we would need some new flag in > + displaced_step_closure otherwise to keep the state that syscall is finishing > + for the later i386_displaced_step_fixup execution as the syscall execution > + is already no longer detectable there. The new flag field would mean > + i386-linux-tdep.c needs to wrap all the displacement methods of i386-tdep.c > + which does not seem worth it. The same effect is achieved by patching that > + 'nop' instruction there instead. */ These comments are clear. I like them :) -- Yao (齐尧)