From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8931 invoked by alias); 10 Apr 2003 19:50:32 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 8901 invoked from network); 10 Apr 2003 19:50:31 -0000 Received: from unknown (HELO hub.ott.qnx.com) (209.226.137.76) by sources.redhat.com with SMTP; 10 Apr 2003 19:50:31 -0000 Received: from smtp.ott.qnx.com (smtp.ott.qnx.com [10.0.2.158]) by hub.ott.qnx.com (8.9.3p2/8.9.3) with ESMTP id PAA16717; Thu, 10 Apr 2003 15:50:10 -0400 Received: from catdog ([10.4.2.2]) by smtp.ott.qnx.com (8.8.8/8.6.12) with SMTP id PAA08432; Thu, 10 Apr 2003 15:50:30 -0400 Message-ID: <034201c2ff9a$731c5bc0$0202040a@catdog> From: "Kris Warkentin" To: "Daniel Jacobowitz" Cc: References: <032e01c2ff95$cf069400$0202040a@catdog> <20030410192626.GA18362@nevyn.them.org> Subject: Re: gdbserver implementation Date: Thu, 10 Apr 2003 19:50:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-SW-Source: 2003-04/txt/msg00099.txt.bz2 > After that, well, there's the beginnings of a target abstraction layer > but it suffers from a lack of targets. Feel free to change anything > you want outside of the platform-specific code if you think it's an > improvement, or drop me a line if there's something you want it to do. > > I haven't had a lot of time for gdbserver recently, but I still have > hopes of making it do things like support limited file transfer/daemon > mode.... Not enough round tuits. Thanks Daniel. We have a pretty full featured remote debug agent in our pdebug. It runs as a daemon on a com or network port plus it runs from inetd. It supports upload/download and spawning of processes on the remote, listing of remote pids, attaching, etc. It also supports threads and everything else you would expect such as memory/register reads, solib loading, etc. Multiple gdbs SHOULD be able to talk to a single pdebug. You can set the targets environment to inherit from either the host or target. We support a console so you can interact with the remote processes stdin/stdout, etc. We also can print meminfo on the process that shows how the process and its libs are mapped into the address space. There are a few problems with it though. On an unreliable connection with a very fast host and slow target, there are occasionally issues with syncronization that can cause lockups (extremely rare). The protocol is not full duplex which exacerbates this problem. The console channels are only two way so stdout and stderr are merged. I've never used gdbserver before. How does its feature set compare to this? We wanted to see how well gdbserver worked for us and were considering migrating to get away from the pdebug protocol issues. cheers, Kris