From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1030326AbWGaTAl (ORCPT ); Mon, 31 Jul 2006 15:00:41 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1030328AbWGaTAk (ORCPT ); Mon, 31 Jul 2006 15:00:40 -0400 Received: from nevyn.them.org ([66.93.172.17]:31688 "EHLO nevyn.them.org") by vger.kernel.org with ESMTP id S1030326AbWGaTAj (ORCPT ); Mon, 31 Jul 2006 15:00:39 -0400 Date: Mon, 31 Jul 2006 15:00:18 -0400 From: Daniel Jacobowitz To: Albert Cahalan Cc: torvalds@osdl.org, alan@lxorguk.ukuu.org.uk, ak@suse.de, mingo@elte.hu, arjan@infradead.org, akpm@osdl.org, linux-kernel@vger.kernel.org, roland@redhat.com Subject: Re: ptrace bugs and related problems Message-ID: <20060731190018.GA13735@nevyn.them.org> Mail-Followup-To: Albert Cahalan , torvalds@osdl.org, alan@lxorguk.ukuu.org.uk, ak@suse.de, mingo@elte.hu, arjan@infradead.org, akpm@osdl.org, linux-kernel@vger.kernel.org, roland@redhat.com References: <787b0d920607262355x3f669f0ap544e3166be2dca21@mail.gmail.com> <20060727203128.GA26390@nevyn.them.org> <787b0d920607271817u4978d2bdiac261d916971c1b3@mail.gmail.com> <20060728034741.GA3372@nevyn.them.org> <787b0d920607281528w56472db2u81268aad523d5c72@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <787b0d920607281528w56472db2u81268aad523d5c72@mail.gmail.com> User-Agent: Mutt/1.5.11+cvs20060403 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jul 28, 2006 at 06:28:34PM -0400, Albert Cahalan wrote: > I was using the data to look up which task just got split away > from the parent. Judging by Chuck Ebbert's email, I'm not the > only person to expect the data to be valid. So it seems! It seems a reasonable addition if anyone wants to submit it. > >Or just present things as if the leader task did the execve, which is > >effectively what happens, and what I thought would happen for ptrace > >too. > > That makes things even weirder. A successful execve done in one > thread appears to be done by another (which might not be > traced if the debugger was a bit odd), while a failing execve > appears... where? Not at all, unless you're doing syscall tracing, I don't think. The exec notification is after the mm is replaced. > >The interface was never designed to handle unsharing. I don't really > >think it should be extended to; whoever needs this functionality should > >design something cleaner for utrace. > > I'm not sure utrace will be accepted. (many ptrace alternatives > have been born and died over the years) Even if utrace does get > accepted, initially we only get: > > 1. a clean-up that provides hope for the future > 2. a hopefully-compatible ptrace on top of utrace > 3. some sort of demo interface > > That alone won't replace ptrace. That's why I suggested someone design a cleaner debugging interface to be implemented on top of utrace - which is how it's supposed to be used. Like David, I am confident that this is the future direction of Linux debugging. > >> PTRACE_GETSIGINFO has 0x0605 as si_code when a process exits. > >> This is not defined anywhere. > > > >It's garbage. PTRACE_GETSIGINFO is only valid after the process stops > >with a signal. > > The process does indeed stop with a signal. It gets SIGTRAP > as part of sending the ptrace event. Sure, but you must know what I meant. PTRACE_GETSIGINFO is only valid when there is a real signal, i.e. generated by something other than ptrace. Which is true whenever wait reports a signal without any of the special event bits set (except for the legacy SIGTRAP on execve). -- Daniel Jacobowitz CodeSourcery