Date: Thu, 13 Jun 1996 15:22:47 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To: Robert Hoehne <robert DOT hoehne AT mathematik DOT tu-chemnitz DOT de>
Cc: DJGPP workers <djgpp-workers AT delorie DOT com>
Subject: Re: Improvements for GDB
In-Reply-To: <Pine.HPP.3.91.960613125047.18256F-100000@newton.mathematik.tu-chemnitz.de>
Message-Id: <Pine.SUN.3.91.960613150240.8974A-100000@is>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII


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?