www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/2000/05/20/17:05:50

Date: Sat, 20 May 2000 17:05:43 -0400 (EDT)
Message-Id: <200005202105.RAA25437@indy.delorie.com>
From: Eli Zaretskii <eliz AT delorie DOT com>
To: "Barry" <barryem AT yahoo DOT com>
CC: djgpp AT delorie DOT com
In-reply-to: <wZBV4.247732$AT6.345504@dfw-read.news.verio.net>
(barryem AT yahoo DOT com)
Subject: Re: Using allegro in RHIDE
References: <wZBV4.247732$AT6 DOT 345504 AT dfw-read DOT news DOT verio DOT net>
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

> From: "Barry" <barryem AT yahoo DOT com>
> 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.

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019