Date: Sat, 20 May 2000 17:05:43 -0400 (EDT) Message-Id: <200005202105.RAA25437@indy.delorie.com> From: Eli Zaretskii To: "Barry" CC: djgpp AT delorie DOT com In-reply-to: (barryem AT yahoo DOT com) Subject: Re: Using allegro in RHIDE References: Reply-To: djgpp AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk > From: "Barry" > Date: Sat, 20 May 2000 14:47:08 -0500 > > I've found that if I run the program in rhide with ctrl F9 and have > no breakpoints, the program runs to completion and all is well. > > But, if I put a breakpoint on the first executable line in main and > run it I get the following error: > Program has received a signal: SIGFPE, Arithmetic exception. [snip] > I'm doing this on an old 486sx laptop and of course there is no > FPU. Ouch! That's a crucial piece of info; I wish you had said that earlier (or did I miss it?). Debugging FP programs on FPU-less machines does not work 100% yet; this is explained in section 12.10 of the FAQ, which see. The problems look like you describe: a program runs to completion unless you set a breakpoint. In my testing, the program hits the breakpoint all-right, but then crashes when you resume it. It looks like you describe a similar, but slightly different phenomenon. You need to understand that getting to the point where a program which uses FP emulation to run under a debugger is no small feat in itself: each FP instruction triggers a processor exception (because there's no FPU), which gets caught by the DJGPP debug support routines. Those support routines then get to decide whether the exception happened in the debuggee or in the debugger's own code, and route the execution thread accordingly. When the exception happens in the debuggee, the debug support routines need to deliver the exception back to the debuggee, in effect causing an exception in another process, something that is not really easy on DOS! This didn't work at all in versions of DJGPP before 2.03; now it semi-works. More work is required to make it better, but the priority of this is low since most machines have FPUs these days. One possible work-around is to use the alternative emulator WMEMU (download and install v2misc/wmemu21b.zip). I'm not sure this will solve your problems completely, though.