From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S261416AbUEJTiQ (ORCPT ); Mon, 10 May 2004 15:38:16 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261418AbUEJTiQ (ORCPT ); Mon, 10 May 2004 15:38:16 -0400 Received: from x35.xmailserver.org ([69.30.125.51]:55443 "EHLO x35.xmailserver.org") by vger.kernel.org with ESMTP id S261416AbUEJTiG (ORCPT ); Mon, 10 May 2004 15:38:06 -0400 X-AuthUser: davidel@xmailserver.org Date: Mon, 10 May 2004 12:37:48 -0700 (PDT) From: Davide Libenzi X-X-Sender: davide@bigblue.dev.mdolabs.com To: Andi Kleen cc: Fabiano Ramos , Linux Kernel Mailing List Subject: Re: ptrace in 2.6.5 In-Reply-To: Message-ID: References: <1UlcA-6lq-9@gated-at.bofh.it> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 10 May 2004, Andi Kleen wrote: > Fabiano Ramos writes: > > > Hi All. > > > > Is ptrace(), in singlestep mode, required to stop after a int 0x80? > > When tracing a sequence like > > > > mov ... > > int 0x80 > > mov .... > > > > ptrace would notify the tracer after the two movs, but not after the > > int 0x80. I want to know if it is a bug or the expected behaviour. > > What happens is that after the int 0x80 the CPU is in ring 0 (you > don't get an trace event in that mode unless you use a kernel debugger). > Then when the kernel returns the last instruction executed before it is an > IRET. But the IRET is also executed still in ring 0 and you should not get > an event for it (you can not even access its code from user space). > > So it's expected behaviour. IIRC, it's the "int" instruction that automatically clears the TF bit from flags. The next "iret" will restore the caller flags and re-enable the TF bit. - Davide