Message-Id: <200007081225.PAA23074@alpha.netvision.net.il>
Date: Sat, 08 Jul 2000 15:26:26 +0200
To: 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: <3966CFBC.3686882B@austin.rr.com> (message from Brogdon on Sat,
	08 Jul 2000 01:52:44 -0500)
Subject: Re: ANNOUNCE: GDB stub for remote debugging of DJGPP targets
References: <39669600 DOT 896FFBB6 AT austin DOT rr DOT com> <200007080630 DOT JAA17055 AT mailgw1 DOT netvision DOT net DOT il> <3966CFBC DOT 3686882B 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

> Date: Sat, 08 Jul 2000 01:52:44 -0500
> From: Brogdon <brogdon AT austin DOT rr DOT com>
> 
> I didn't use the libdbg.a library, mainly because I didn't have any
> information to understand how this code worked (other than digging through
> it).  Perhaps, this information exists, but I didn't know where to find it.

The latest DJGPP release v2.03 includes the docs of these functions as
part of libc.info.  Type "info libc functional debug" from the command
prompt and read there.

> > 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...
> 
> The libgdb.a really only contains 2 objects:  i386-stub.o (the stub
> functionality called out by the GDB manual) and i386-supp.o (the support
> functions which the user must provide for the stub).

Oh, sorry, I didn't look close enough: I thought you are referring to
libgdb.a that is built as part of the GDB build process.

In that case, I suggest to rename your library to some name other than
libgdb.a, to prevent conflicts.