Date: Sun, 21 Jan 2001 18:52:17 +0200 From: "Eli Zaretskii" Sender: halo1 AT zahav DOT net DOT il To: Martin Str|mberg Message-Id: <2110-Sun21Jan2001185217+0200-eliz@is.elta.co.il> X-Mailer: Emacs 20.6 (via feedmail 8.3.emacs20_6 I) and Blat ver 1.8.6 CC: djgpp-workers AT delorie DOT com In-reply-to: <200101211544.QAA10016@father.ludd.luth.se> (message from Martin Str|mberg on Sun, 21 Jan 2001 16:44:45 +0100 (MET)) Subject: Re: Debugging on 386 References: <200101211544 DOT QAA10016 AT father DOT ludd DOT luth DOT se> 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 > From: Martin Str|mberg > Date: Sun, 21 Jan 2001 16:44:45 +0100 (MET) > > Yes, as far as I can see. Where do SIGFPE come from? I'm guessing that they come from GDB's own code which saves and restores the (emulated) FPU state. More accurately, GDB calls a function on dbgcom.c which does that. But I don't see why doesn't this DTRT, since dbgcom.c seems to hook and unhook SIGNOFP correctly... Hm. Well, this code was only tested on a machine with an FPU, by forcing the emulation with "set 387=n", so it might be buggy. If you can rebuild GDB, perhaps you could add some debugging print-outs to the functions hook_dpmi, unhook_dpmi, and dbgsig, and see what exactly happens there when those SIGEMTs hit. > (And SIGEMT?) SIGEMT is the GDB translation of our SIGNOFP, or, more accurately, anything that triggers exception 7 (as opposed to Int 75h usually triggered by an FP exception, such as sqrt of a negative number). SIGNOFP is a non-standard name that GDB doesn't support, and I didn't want to lose the ability to catch SIGNOFP in the debugger, because it is needed for debugging FP emulators. SIGEMT was available and close enough to SIGNOFP's meaning, so I used it. > > > Starting program: f:/hackery/stat/new_stat/analyse_.exe > > > > > > Program received signal SIGEMT, Emulation trap. > > > 0x5535 in _control87 () Btw, what does "bt" say at this point? > > What does "info handle SIGEMT" print? > > It says "Yes" on everything. Probably not a good idea on an FPU-less machine, since each FP operation will stop the debuggee. I'll try to see if it's possible to automatically set it to nostop noprint if there's no FPU. > > As an aside, I'd suggest not to use printf in a function that manipulates > > the transfer buffer, since printf itself puts things into the transfer > > buffer. The resultant bugs can drive you crazy. I usually switch to > > cprintf in such cases: better be safe than sorry. > > But I have to use sprintf() to construct the string to _put_path(). sprintf is okay, since it doesn't use the transfer buffer (it doesn't call DOS). > Anyway in this case it should be safe as I zero out the buffer after > sprintf(). I didn't say your code had any bugs in that area. It's just all too easy to hit such bugs, so I thought I'd warn you where I had problems in the past.