Mail Archives: djgpp/1996/07/03/07:46:23
Xref: | news2.mv.net comp.os.msdos.djgpp:5609
|
From: | krecik AT hp20 DOT lri DOT fr (Grzegorz Nowakowski)
|
Newsgroups: | comp.os.msdos.djgpp
|
Subject: | Core files under DJGPP.
|
Date: | 03 Jul 1996 10:38:37 GMT
|
Organization: | Laboratoire de Recherche en Informatique, UPS/CNRS, Orsay,FRANCE
|
Lines: | 21
|
Message-ID: | <KRECIK.96Jul3123837@hp20.lri.fr>
|
NNTP-Posting-Host: | hp20.lri.fr
|
To: | djgpp AT delorie DOT com
|
DJ-Gateway: | from newsgroup comp.os.msdos.djgpp
|
Hi
Does anybody thought about writing core images when program gets some
signals (like in unix) ? I dont't know if it't easy or difficult because
I have no experience with digging into DJGPP. However, I had experience
with digging into core and I know how it's useful. Of course, if the trouble
is caused by bad control structure, stack traceback and symify.exe is sufficient.
But when you have wild pointer jumping over multi-linked allocated data, it's
not enough.
Answering on some questions:
- core should be dumped when program is bad, not operting system; when someone
screws DOS it even can't flash num-lock light, we don't care writing images;
- writing cores should be at user option, not everyone wants to have them;
- gdb need not to create subprocess, it has only to look at dead program's state:
local and global variables, dynamic data and unlucky instruction, then it needn't
to restore full state of program - only memory;
- I think it would be also useful to bind one keystroke (say Ctl-Alt-Brk) to force
program to dump core and terminate.
Please, forgive me if I wrote stupid things. Just idea.
- Raw text -