Mail Archives: djgpp-workers/1996/06/13/08:25:23
On Thu, 13 Jun 1996, Robert Hoehne wrote:
> Because I want to integrate GDB in an other program (RHIDE), I needed
> the ability of GDB to restart the debugged program, without
> restarting GDB.
It will help (at least help me, if not the others) if you'd tell why did
you arrive to the conclusion that you need such an ability. What specific
problem do you need to solve in order to integrate RHIDE with GDB and why
do you think that being able to restart the debuggee under GDB is the
solution to that specific problem? It just might be that the problem you
are trying to solve has other solution(s). For example, saving the GDB
history, then having GDB to restore its state using that history might be
as good as restarting the debuggee, except that GDB already knows how to
do most of this, and it doesn't require to mess with the DPMI interface.
> 4) The main problem with unloading an image is in free the memory
> it used. The only solution I found for doing this is calling
> the function '_exit' of the image, which clears all the memory
> it used. Question: Can I assume, that every DJGPP V2 program
> has this function to do the correct cleanups?
`_exit' is defined on crt0.s which gets linked with every DJGPP program.
Both `exit' and `abort', as well as the default signal handlers call
it. I think it is safe to assume that it is present in every program.
> 6) What is, when the debugged program hooks some interrupts?
This is generally unrealiable under GDB also, so (IMHO) you might as well
leave it as a limitation, at least for the first release. I doubt that
anybody would try to debug such a program under RHIDE. Would you debug a
real-mode BC++ program that hooks hardware interrupts under Borland's
IDE and expect it to work reliably?
- Raw text -