From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10714 invoked by alias); 9 Feb 2007 15:35:37 -0000 Received: (qmail 10705 invoked by uid 22791); 9 Feb 2007 15:35:37 -0000 X-Spam-Check-By: sourceware.org Received: from exprod8og53.obsmtp.com (HELO exprod8og53.obsmtp.com) (64.18.3.88) by sourceware.org (qpsmtpd/0.31) with SMTP; Fri, 09 Feb 2007 15:35:29 +0000 Received: from source ([12.110.134.31]) by exprod8ob53.obsmtp.com ([64.18.7.12]) with SMTP; Fri, 09 Feb 2007 07:35:16 PST Received: from pkoning.equallogic.com ([172.16.1.128]) by M31.equallogic.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Feb 2007 10:31:54 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17868.37865.32814.683925@gargle.gargle.HOWL> Date: Fri, 09 Feb 2007 15:35:00 -0000 From: Paul Koning To: veenu_khanna@yahoo.com Cc: gdb@sourceware.org Subject: Re: GDB Stub & GPL question References: <123982.25433.qm@web53807.mail.yahoo.com> X-Mailer: VM 7.17 under 21.4 (patch 19) "Constant Variable" XEmacs Lucid 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: 2007-02/txt/msg00056.txt.bz2 >>>>> "veenu" == veenu khanna writes: veenu> HI Daniel, I am still unclear. :( You mean to say that if we veenu> implement our own stub for gdb then it HAS to be a serial veenu> connection. It can not be IP based. I don't think that's what Daniel said. One of the forms of the "set target remote" command takes an IP address and port number as argument. If you use that form, GDB will speak Telnet to that address. One way to use this is to have a target whose stub talks to a serial port, and plug a Telnet terminal server into that port. This is a handy scenario for embedded devices where a serial port is readily available. Another way is to have a target that speaks TCP/IP itself, and accepts data in Telnet form on that port. Gdbserver is an example. You could also write your own stub to work that way. >From the point of view of GDB, these two cases are the same. veenu> I have another question as well. We are pondering over the veenu> idea to implement a gdb & gdbserver/stub solution for our veenu> proprietary OS (embedded arch) And I have few doubts about the veenu> viability. It seems that multiple instances of gdbserver veenu> needs to be launched to connect it to multiple processes. Is veenu> there a way to debug multiple processes with single gdbserver veenu> instance ? Say we write our own command in gdb to list all veenu> the processes in our OS. And then we do an attach from gdb veenu> like attach . I've tried such a thing in a kernel debug environment (where I can tell the debugger to attach to any of the user processes). It can be made to work to some extent. GDB works on a single executable image with a single set of shared libraries. It took a lot of hammering to be able to switch from one executable to another, and one set of libraries to another (or the same library at a different base address, which amounts to the same issue). I got it to work somewhat, but not very well. Fortunately it wasn't a critical need. Gdbserver is very small, and of course much of it is shareable. The simple answer is to run multiple instances, and connect one instance of GDB to each Gdbserver. That works perfectly. The overhead is trivial. Why make it harder than it needs to be? paul