Message-ID: <3966CFBC.3686882B@austin.rr.com> Date: Sat, 08 Jul 2000 01:52:44 -0500 From: Brogdon X-Mailer: Mozilla 4.05 [en] (Win95; U) MIME-Version: 1.0 To: Eli Zaretskii CC: djgpp AT delorie DOT com 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> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: djgpp AT delorie DOT com Eli: > 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? > 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. > 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. > I would be interested in understanding how this works. Point me to more information, and I will look at converting to this. > 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). That's it. Creating the library was my idea. I don't believe that the GDB distrubution will cause a library to be built for this. This may not be the most efficient code (actually, I can think of at least one thing that I could have done to cut down on register copies and updates--always room for improvement), but it is not a lot of code. Regards, Jon