Mail Archives: djgpp-workers/1996/06/13/16:01:35
> 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.
- Raw text -