From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 516 invoked by alias); 28 Nov 2005 22:58:04 -0000 Received: (qmail 502 invoked by uid 22791); 28 Nov 2005 22:58:03 -0000 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; Mon, 28 Nov 2005 22:58:02 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id jASMvxB2027445; Mon, 28 Nov 2005 17:58:00 -0500 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id jASMvsV08320; Mon, 28 Nov 2005 17:57:54 -0500 Received: from [172.16.24.50] (bluegiant.sfbay.redhat.com [172.16.24.50]) by potter.sfbay.redhat.com (8.12.8/8.12.8) with ESMTP id jASMvpSY027029; Mon, 28 Nov 2005 17:57:52 -0500 Message-ID: <438B8B6F.6010706@redhat.com> Date: Tue, 29 Nov 2005 04:41:00 -0000 From: Michael Snyder User-Agent: Mozilla Thunderbird (X11/20050322) MIME-Version: 1.0 To: GDB Patches , gdb@sources.redhat.com, drow@false.org, Eli Zaretskii Subject: [RFC] multi-process gdb (forks, checkpoints) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2005-11/txt/msg00494.txt.bz2 Folks, I'm pretty close to actually submitting this for approval; this is (knock on wood) my last request for pre-review. Instead of attaching a patch, I've checked this in on a branch: msnyder-fork-checkpoint-branch. This is, no kidding, gdb debugging multiple processes. I've adapted it to work with the existing "follow-fork" infrastructure, so that when a process forks, instead of being forced to choose between debugging the parent or the child, we can now debug both. The user sets a mode flag, and rather than detaching from one of the forks, gdb will set it aside (in a ptrace-stopped state), and let you return to debugging it later, switching back and forth at will. Daniel, it handles quit, kill, and inferior exit. If one process exits and there's another available, it just switches automatically (as it would with threads). I've added a testcase, gdb.base/multi-forks.exp, which serves to demonstrate the debugging of 16 forks at a time. And of course checkpoint and restart are in there too. Eli, I'll be working on documentation. For the mean time, the user interface looks like this: set/show detach-on-fork (on/off) [default on] info forks fork [analogous to thread ] detach-fork delete-fork [and kill] checkpoint restart info checkpoints delete-checkpoint detach-checkpoint [well...]