From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-return-31957-listarch-gdb=sources.redhat.com@sourceware.org>
Received: (qmail 29998 invoked by alias); 29 May 2008 17:58:25 -0000
Received: (qmail 29972 invoked by uid 22791); 29 May 2008 17:58:24 -0000
X-Spam-Check-By: sourceware.org
Received: from bluesmobile.specifix.com (HELO bluesmobile.specifix.com) (216.129.118.140)     by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 29 May 2008 17:58:07 +0000
Received: from [127.0.0.1] (bluesmobile.specifix.com [216.129.118.140]) 	by bluesmobile.specifix.com (Postfix) with ESMTP id D418F3C26F; 	Thu, 29 May 2008 10:58:05 -0700 (PDT)
Subject: Re: multi-process remote protocol extensions
From: Michael Snyder <msnyder@specifix.com>
To: Pedro Alves <pedro@codesourcery.com>
Cc: gdb@sourceware.org
In-Reply-To: <200805272233.24078.pedro@codesourcery.com>
References: <200805272233.24078.pedro@codesourcery.com>
Content-Type: text/plain
Date: Fri, 30 May 2008 13:15:00 -0000
Message-Id: <1212083885.3601.179.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Evolution 2.10.3 (2.10.3-7.fc7)
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes
Mailing-List: contact gdb-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gdb.sourceware.org>
List-Subscribe: <mailto:gdb-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb/>
List-Post: <mailto:gdb@sourceware.org>
List-Help: <mailto:gdb-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-owner@sourceware.org
X-SW-Source: 2008-05/txt/msg00175.txt.bz2


Hi Pedro, 

I'd like to throw out some thoughts *before* I read your 
somewhat long but apparently well-thought-out proposal.
I'll be brief.

Forgive me if what I toss out has already been covered.

Have you considered the cross-over between the general
case of debugging multiple processes, and the more restricted
case of debugging forks of the same process?  With forks,
(and excluding exec for the moment), you actually have 
several processes with separate address spaces but one
common symbol table.

I'm thinking that the support for fork debugging that we
already have might serve as a stepping-off point for what
you propose.

Maybe an incremental step would be to extend the fork
debugging functionality into the remote protocol and
get it to work with gdbserver?

I'll just go off and actually read what you wrote now...
;-)
Michael