From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23477 invoked by alias); 29 Nov 2005 19:20:52 -0000 Received: (qmail 23463 invoked by uid 22791); 29 Nov 2005 19:20:52 -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; Tue, 29 Nov 2005 19:20:50 +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 jATJKmwF030552; Tue, 29 Nov 2005 14:20:48 -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 jATJKgV03146; Tue, 29 Nov 2005 14:20:42 -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 jATJKeSY027276; Tue, 29 Nov 2005 14:20:41 -0500 Message-ID: <438CA9FF.30706@redhat.com> Date: Wed, 30 Nov 2005 03:00:00 -0000 From: Michael Snyder User-Agent: Mozilla Thunderbird (X11/20050322) MIME-Version: 1.0 To: Eli Zaretskii CC: gdb-patches@sources.redhat.com, gdb@sources.redhat.com Subject: Re: [RFC] multi-process gdb (forks, checkpoints) References: <438B8B6F.6010706@redhat.com> In-Reply-To: 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/msg00502.txt.bz2 Eli Zaretskii wrote: >>Date: Mon, 28 Nov 2005 14:57:51 -0800 >>From: Michael Snyder >> >>This is, no kidding, gdb debugging multiple processes. > > > Wow! Thanks! > > >>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] > > > I'd prefer that we use ``process'' instead of ``fork'' here. That is, > > info processes > process [assuming n is a PID] Good idea. But , as written, is not a PID, it's a small counting number (analogous to a breakpoint id or thread id). I've added the command "process " since its semantics is different (and still useful). "info processes" is problematic, since there is already an "info proc" command.