From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11332 invoked by alias); 21 Jun 2008 14:14:55 -0000 Received: (qmail 11317 invoked by uid 22791); 21 Jun 2008 14:14:54 -0000 X-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 21 Jun 2008 14:14:29 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id m5LEERpM002008 for ; Sat, 21 Jun 2008 10:14:27 -0400 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [10.11.255.20]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m5LEEQa0005884 for ; Sat, 21 Jun 2008 10:14:27 -0400 Received: from [127.0.0.1] (sebastian-int.corp.redhat.com [172.16.52.221]) by pobox.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m5LEEQQt025078 for ; Sat, 21 Jun 2008 10:14:26 -0400 Message-ID: <485D0CD1.9010602@redhat.com> Date: Sat, 21 Jun 2008 14:18:00 -0000 From: Andrew Cagney User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: frysk Subject: notes from 2008-06-18 - vfork and debuginfo Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.58 on 172.16.52.254 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/msg00113.txt.bz2 debuginfo: bauerman, live from the gcc summit, gave an update of the debug-info presentation. While nothing was immediately resolved, there was a good consensus that the problems with debug-info quality from GCC needed to be addressed, more in the future. One key highlight was general recognition that GCC would need to locally check test the quality of its debug info. vfork: pmuldoon and cagney had a lively (at least for them :-) discussion on vfork. pmuldoon identified the essential issue being that after a vfork, the vchild (so you don't get confused with a fork's child, groan :-) and parent share a common address space; more specifically that common address space contains breakpoints from both the parent and the vchild. This in turn means: -> the vchild can hit any parent breakpoint (since they are still inserted in memory) -> the parent could hit any vchild breakpoint (unless they are removed after the vchild execs/exits) Comparing the existing fork and clone models, the discussion concluded that vfork is closer to clone in that the parent and vchild share a common: -> memory address spaces In particular the LogicalMemoryBuffer and AddressSpaceByteBuffer which ensures that, to the user, the inserted breakpoints are not visible. This relying on ... -> breakpoint tables The combination of BreakpointAddresses and Breakpoint that tracks where breakpoints are inserted, and which Task[s] each belongs to. which is on par with parent/clone. This leads to the aproach: -> at the vfork Like for clone, vchild's process shares the parent's memory-address-space and breakpoint-table (a.k.a. BreakpointAddresses?) (not a clone or copy). This ensures that any breakpoints inserted for the vchild are reflected in the parent's breakpoint table / memory. And similarly, when a parent breakpoint is hit by the vchild's thread[s] the breakpoint logic can recognize this. -> at the exec/exit The vchild creates a new breakpoint-table and memory-address-space, while also telling the parent's breakpoint-table to remove any breakpoints belonging to the vchild Notes: - an aternative, to model more like fork, would be to pull all breakpoints at the vfork, and then re-instate them when the vchild exits/execs (assuming there isn't a race with the parent), but conversely ... - the above approach could perhaps be applied to simple fork, instead of pulling all breakpoints in the child, leave them in place and ignore them - less i/o :-) - an example of a vchild breakpoint is during a "next" where a temporary per-thread breakpoint is inserted; of course an easier example is to explicitly insert a breakpoint :-)