Mail Archives: djgpp/2000/07/08/02:52:07
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
- Raw text -