From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2510 invoked by alias); 18 Jul 2008 23:13:32 -0000 Received: (qmail 2393 invoked by uid 22791); 18 Jul 2008 23:13:31 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 18 Jul 2008 23:13:13 +0000 Received: (qmail 20011 invoked from network); 18 Jul 2008 23:13:11 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 18 Jul 2008 23:13:11 -0000 From: Pedro Alves To: gdb@sourceware.org Subject: Re: Towards multiprocess GDB Date: Sat, 19 Jul 2008 03:53:00 -0000 User-Agent: KMail/1.9.9 Cc: Stan Shebs , Mark Kettenis References: <4880FFA8.3080600@earthlink.net> <200807182141.m6ILfBcf014252@brahms.sibelius.xs4all.nl> <488118EE.90508@codesourcery.com> In-Reply-To: <488118EE.90508@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200807190013.24604.pedro@codesourcery.com> X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2008-07/txt/msg00219.txt.bz2 A Friday 18 July 2008 23:27:58, Stan Shebs wrote: > I'm not sure it's going to be that big of a change actually. Once > behavior has been directed to the right objects internally, they will do > what they're doing now. Most symbol handling is objfile-relative for > instance, adding a new set of objfiles for a different exec isn't going > to affect that code. You seem to be thinking of the symbol handling code only. The thing I see requiring architecting, is the target stack. Currently, it's only layed out for the single executable + single process case. For starters, I'll try to give a simple example. Imagine you're debugging simultaneously these cases below: 1) Linux native non-threaded app. The current target is a squashed view of: linux-nat process_stratum exec file_stratum 2) Linux native multi-threaded app, loads libthread_db for the thread support. The current target is a squashed view of: linux-thread-db thread_stratum linux-nat process_stratum exec file_stratum 3) Linux native threaded app, but loads another thread support lib. linux-other-thread-db thread_stratum linux-nat process_stratum exec file_stratum 4) Linux native non-threaded app, doing reverse debugging. record record_stratum linux-nat process_stratum exec file_stratum (There are OSs where this is more common.) It seems to me that each process should have its own target stack instance. We could split target_ops in two and share the ops part between instances, but still the target_ops rw data needs to be per-process. Note that I'm not even considering multi-process,multi-exec,single remote target connection, where things get even dirtier, or even native process + remote process debugging simultaneously. There are other issues around the target stack that need resolution, but this issue above seems crucial to have in mind first. -- Pedro Alves