Date: Thu, 22 Mar 2001 10:20:49 +0200 (IST) From: Eli Zaretskii X-Sender: eliz AT is To: "Nimrod A. Abing" cc: djgpp-workers AT delorie DOT com, sandmann AT clio DOT rice DOT edu Subject: Re: Core dumping for DJGPP programs In-Reply-To: <3.0.1.32.20010322141215.00706d80@wingate> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp-workers AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk On Thu, 22 Mar 2001, Nimrod A. Abing wrote: > if (__djgpp_exception_state == fake_exception > && __djgpp_exception_state -> __cs == _my_cs() > && (unsigned)__djgpp_exception_state -> __ebp > >= __djgpp_exception_state -> __esp > && (unsigned *)__djgpp_exception_state -> __ebp >= &end > && (unsigned *)__djgpp_exception_state -> __ebp > < (unsigned *)__djgpp_selector_limit) > _writei4 (corefile, *((unsigned *)__djgpp_exception_state -> __ebp + 1)); > else > _writei4 (corefile, __djgpp_exception_state -> __eip); > > which is basically what the code in dpmiexcp does, except the value of eip > is written to an open file. The eip is correctly written for signals other > than the fake signal SIGABRT (well for SIGSEGV anyway, eip is correctly > written). I also noticed discrepancies in the values of the registers eax, > ecx, edx, esi, edi, ebp, and esp. There's a big difference between the ones > generated by the traceback and the ones stored in the core file, this > apparently happens for fake signal SIGABRT, doesn't seem to happen for > SIGSEGV. IIRC, SIGABRT doesn't bother to save the registers at the point of abort()'s invocation. If that's true, there's no surprise that you get different register values. For true exceptions, such as SIGSEGV, the exception handler saves the registers on the stack and then copies them into the __djgpp_exception_state struct. But I don't think anything similar is done for fake exceptions. Perhaps the simple-minded way of hacking together the fake_exception variable can be changed to do it better. In any case, since a call to abort() is a voluntary action by the program's code, I doubt that the registers' values would be of great importance. You need the registers to find out which variable had invalid value (e.g., a garbled pointer which caused SIGSEGV), but that problem is irrelevant for a code which called abort(). A good debugger, such as GDB, should be able to find the registers saved on the stack, and doing so involves lots of non-trivial code that I don't think should be put into a core dumper. (For an idea what's involved, see the function i386_frame_init_saved_regs on i386-tdep.c in the GDB distribution.) > Again, if you need the sources, I'll be more than happy to send them to you. I suggest that you upload the code to the /incoming directory on DJ's server, so that it could be put in some beta directory on the ftp server where people could download it.