Date:	Sun, 21 Jan 2001 18:52:17 +0200
From:	"Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>
Sender:	halo1 AT zahav DOT net DOT il
To:	Martin Str|mberg <ams AT ludd DOT luth DOT se>
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

> From: Martin Str|mberg <ams AT ludd DOT luth DOT se>
> 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.

- Raw text -