From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12943 invoked by alias); 16 Nov 2005 08:01:33 -0000 Received: (qmail 12922 invoked by uid 22791); 16 Nov 2005 08:01:29 -0000 Received: from main.gmane.org (HELO ciao.gmane.org) (80.91.229.2) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Wed, 16 Nov 2005 08:01:29 +0000 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1EcID1-0007SM-F3 for gdb@sources.redhat.com; Wed, 16 Nov 2005 08:59:59 +0100 Received: from zigzag.lvk.cs.msu.su ([158.250.17.23]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 16 Nov 2005 08:59:59 +0100 Received: from ghost by zigzag.lvk.cs.msu.su with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 16 Nov 2005 08:59:59 +0100 To: gdb@sources.redhat.com From: Vladimir Prus Subject: Re: libGDB and gdbserver questions Date: Wed, 16 Nov 2005 08:01:00 -0000 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit User-Agent: KNode/0.8.2 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2005-11/txt/msg00316.txt.bz2 Donny Kurniawan wrote: >> > "master UI controller" (that controls GDBs). >> >> I'm not sure what you mean about "master UI controller". The biggest > > What I mean is the UI that is presented to the user, which manages > breakpoints, execution, stepping etc. for multiple processes. Well, UI has to deal with 1000 threads of executions anyway, be it processes, threads, or anything. It's not trivial, but independent of the number of gdb instances, IMO. >> However, it's not likely that you have 1000 different programs. If you >> have > > It is only one single program being run for 1000 times (1000 processes). Not MPI, per chance? Actually, I always though it's a good idea to add multi-process debugging (including MPI) to KDevelop (http://kdevelop.org). Maybe, we can team up for that? >> two programs, and each one is run on 500 machines, you can start two >> copies of gdb. >> >> Then each copy of gdb would connect to a "redirector" you can write, that >> will basically forward all packets to invididual instances of gdbserver. >> But it will present those 500 instances as 500 threads, and gdb can work >> with threads more or less fine. > > Hmmm.... I'm curious with this approach. I did write a "proxy" > redirector between gdbserver and gdb. But it only connects one > gdbserver to one gdb. > > So basically with this approach (many gdbservers to one gdb), we > present processes as threads to gdb? How about debugging multi-thread > (!) program with many processes then? How do we present threads to > gdb? Heh, that's problem of your "master UI controller". I'd extend the remote protocol to allow UI to query which real process and real thread each gdb-visible thread corresponds to. > It seems to me, this approach is a clean hack, but not the way it's > supposed to be. Unfortunately, I don't know better way. Refactoring gdb to support several connections to remote targets and to add an explicit notion of "process" might be very hard. - Volodya