From: sandmann AT clio DOT rice DOT edu (Charles Sandmann) Message-Id: <9606131941.AA13864@clio.rice.edu> Subject: Re: Improvements for GDB To: robert DOT hoehne AT mathematik DOT tu-chemnitz DOT de (Robert Hoehne) Date: Thu, 13 Jun 1996 14:41:41 -0600 (CDT) Cc: djgpp-workers AT delorie DOT com In-Reply-To: from "Robert Hoehne" at Jun 13, 96 01:05:23 pm Content-Type: text Content-Length: 2875 > 1) I modified the the file 'v2load.c' in the way, that I can access > the variables, which hold the allocated selectors and DOS > memory from outside the function. This is actually all available either directly or indirectly in the structure which is returned (how else would the stub know how to do it's business if stuff was missing?) I have made a few changes to v2load.c, but all of them were more implicit inputs, so you could allow the stack to be 0xdeadbeef'ed for example. I suppose I ought to post em. > 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? You need to pass through the exit code to allow it to clean up the memory handles and selectors. If you don't want to do this, you would need to hook more of the I31 dpmi calls, keep track of what's outstanding, then free what you knew was outstanding if needed. If you are running a non-symboled image, you don't know where _exit is, so the only fix for everything is the monitor int 31 approach. DBGCOM.c already monitors int 31 for some events, and the stack usage code that I sent to Eli monitors int 31 for cleanup events, so there are a couple of examples around. If you are going to do it, make it generic, put it in dbgcom.c (which already hooks), add a cleanup call. Then all the debuggers (EDEBUG32/FSDB/LDBG/GDB) can all use it if desired. See why I didn't implement restart? :-) Exit + uparrow was MUCH easier. > 6) What is, when the debugged program hooks some interrupts? The debuggers currently disallow hooking any hardware interrupts, since this could prevent the debugger from reading the input, and there are all sorts of scenarios with HW interrupts and debuggers and locking I didn't even want to start to handle. This could eventually be fixed in dbgcom.c, but I doubt I'll ever have the time nor energy to do so. > If you exit gdb before exiting the program, and the program is using > non-moving sbrk, do we leak selectors, or are they cleaned up > automatically when the last program exits? The only problem I know of leaking selectors or memory is when a dpmi child process exits while the parent is still active. Since all debuggers actually run in the same process, when GDB exits all should get cleaned up. If you ran GDB from emacs or somesuch, then you could potentially have problems, yes. But this is only under some providers, and if it's linked in you have the problem with ALL DPMI providers. > Or is there an other solution like loading the GDB object files as > DXE's or like something? The only problem I see with linking it in is making sure everything gets cleaned up.