From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28802 invoked by alias); 30 Apr 2008 03:06:21 -0000 Received: (qmail 28793 invoked by uid 22791); 30 Apr 2008 03:06:20 -0000 X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,BAYES_50,SPF_FAIL X-Spam-Check-By: sourceware.org Received: from qmta03.emeryville.ca.mail.comcast.net (HELO QMTA03.emeryville.ca.mail.comcast.net) (76.96.30.32) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 30 Apr 2008 03:05:58 +0000 Received: from OMTA13.emeryville.ca.mail.comcast.net ([76.96.30.52]) by QMTA03.emeryville.ca.mail.comcast.net with comcast id KTV11Z00B17UAYkA30qc00; Wed, 30 Apr 2008 03:02:50 +0000 Received: from gateway.sf.frob.com ([76.102.158.52]) by OMTA13.emeryville.ca.mail.comcast.net with comcast id Kf5v1Z00318718U8Z00000; Wed, 30 Apr 2008 03:05:56 +0000 X-Authority-Analysis: v=1.0 c=1 a=RYFLW6ebtpNBegQnzZ7X4w==:17 a=c_EW-QtJYu3skDYv0A0A:9 a=4ZioxB9QnJN3ZcCcRDYA:7 a=CMQuxndcavNE3N0oS2kP_fuqNJ8A:4 a=MxZ3bB5I4kYA:10 Received: from magilla.localdomain (magilla.sf.frob.com [198.49.250.228]) by gateway.sf.frob.com (Postfix) with ESMTP id 6895D357B; Tue, 29 Apr 2008 20:05:54 -0700 (PDT) Received: by magilla.localdomain (Postfix, from userid 5281) id 7A2E426FA24; Tue, 29 Apr 2008 20:05:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roland McGrath To: Mark Wielaard Cc: frysk Subject: Re: Reset breakpoints on fork In-Reply-To: Mark Wielaard's message of Tuesday, 22 April 2008 18:52:02 +0200 <1208883122.3426.18.camel@dijkstra.wildebeest.org> References: <1208883122.3426.18.camel@dijkstra.wildebeest.org> X-Shopping-List: (1) Organic circumcisions (2) Prodigious chowder (3) Televised esoteric dogs (4) Embryonic erroneous pronunciations (5) Biochemical colliders Message-Id: <20080430030523.7A2E426FA24@magilla.localdomain> Date: Thu, 01 May 2008 22:49:00 -0000 X-IsSubscribed: yes Mailing-List: contact frysk-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: frysk-owner@sourceware.org X-SW-Source: 2008-q2/txt/msg00068.txt.bz2 > Roland, I CCed you in the hope that you could maybe point out some nice > way now or in the future to do this. There is no great magic to offer here, but I will be sure to keep this wrinkle of the problem in mind for the future. > This of course isn't very efficient since I assume the kernel could help > us out here since it know the pages we touched through ptrace poke to > set the breakpoints in the first place. In fact, it doesn't really. There is no trail of this per se any more than there is a trail of what memory writes the process itself made. The breakpoints normally go in read-only text pages, which did get COW'd when you wrote them via ptrace. It's probably possible to grovel around in the VM data structures and figure out which read-only pages are COW copies. But nothing distinguishes your pokes from the process itself doing mprotect, then write to cause COW of a file-backed page, then mprotect back to read-only. For example, RELRO areas will always look that same way. > If there was some way to have an event from the kernel where we got the > forking and forked tasks in a quiescent state (at the same time) and then > could inspect both and tell the kernel whether or not to copy the > modified or original code pages that would be much better. Sorry, quiescent does not include "half-created". When the child exists, its address space has been populated. fork is an atomic operation. Consider thread A in the parent running along while thread B forks a child; then A calls munmap, etc. The fork happens either before or after anything A did. > Bonus points for having advanced knowledge of a pending exec event, which > would wipe away any changes we do anyway (although I don't see how this > would be possible). It's a mere matter of interpreting the machine code from the PC on, solving the halting problem, etc. ;-) For advanced knowledge that an exec is likely, there is knowing that it was a vfork. Then an exec or an exit is inevitably entailed before the parent runs again. That's it. Back at the dawn of time, one big idea was that fancy new VM tricks would be the bee's knees for breakpoints. VM tricks have great sex appeal, but will be much deep voodoo to implement, and probably at least slightly mind-bending to use (maybe true of sex appeal in general ;->). The original thinking was to rely on this for breakpoints vs threads, but that was before we clued in to the instruction-copying technique. It might still be in the cards one day and a big win for e.g. per-thread breakpoints, but it remains to be seen and is certainly a long way off (after most of the rest of anything else anticipated for new kernel features). Much of that sex appeal is how clean and nice it can be for issues like the one you are concerned with here. But we'll be admiring it from afar for a long time to come. Thanks, Roland