Message-Id: <200007080630.JAA17055@mailgw1.netvision.net.il>
Date: Sat, 08 Jul 2000 09:31:14 +0200
To: Jonathan Brogdon <brogdon AT austin DOT rr DOT com>
X-Mailer: Emacs 20.6 (via feedmail 8.2.emacs20_6 I) and Blat ver 1.8.5b
From: "Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>
CC: djgpp AT delorie DOT com
In-reply-to: <39669600.896FFBB6@austin.rr.com> (message from Jonathan & Sylvia
	Brogdon on Sat, 08 Jul 2000 02:29:33 GMT)
Subject: Re: ANNOUNCE: GDB stub for remote debugging of DJGPP targets
References:  <39669600 DOT 896FFBB6 AT austin DOT rr DOT com>
Reply-To: djgpp AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

> From: Jonathan & Sylvia Brogdon <brogdon AT austin DOT rr DOT com>
> Newsgroups: comp.os.msdos.djgpp
> Date: Sat, 08 Jul 2000 02:29:33 GMT
> 
> This message is to announce the release of a GDB stub port for DJGPP.
> The GDB stub may be used to debug remote DJGPP targets over a serial
> line with GDB.

Thanks for making this happen!

Hmm...  Browsing through the sources, it looks like the implementation
doesn't use the DJGPP debug support routines (in libdbg.a from
djdev203.zip) at all, and instead does everything on its own.  Is that
true?

If so, perhaps it would be better either to use libdbg.a functions, at
least those in dbgcom.c which load the debuggee and allow it to run,
or borrow some of the code from there.  The code in dbgcom.c has
several useful features that might make sense in the stub case, such
as true exception handling, hardware breakpoints/watchpoints support,
the ability to restart the debuggee without exiting the debugging
session, support for FP registers, etc.

Also, I see that the debugged program needs to be linked with
libgdb.a.  Why is this required?  libgdb.a is quite a large library,
so this would make for a very large executable, I think, whereas
remote debugging is supposed to keep the target part lean and mean...