From: Martin Str|mberg <ams AT ludd DOT luth DOT se>
Message-Id: <200101211544.QAA10016@father.ludd.luth.se>
Subject: Re: Debugging on 386
In-Reply-To: <Pine.SUN.3.91.1010121085318.13920K-100000@is> from Eli Zaretskii at "Jan 21, 2001 09:29:21 am"
To: djgpp-workers AT delorie DOT com
Date: Sun, 21 Jan 2001 16:44:45 +0100 (MET)
X-Mailer: ELM [version 2.4ME+ PL54 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
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

According to Eli Zaretskii:
> On Sat, 20 Jan 2001, Martin Str|mberg wrote:
> > 1. While hacking on a program to check which of the INT21 calls are
> > supported, I needed to debug it on my 386 (as it hangs on it). The
> > program do not use any floating point (as far as I can tell). However
> > there are floating points signals delivered while running in
> > gdb. Perhaps gdb is using floating point and is confused? Or why are
> > floating point signals coming in?
> 
> I'm not sure I understand what your evidence is.  Are the messages about 
> SIGEMT you posted the ones you refer to above as the signs of FP signals 
> being delivered?

Yes... But SIGFPE definitely!

> > Earlier it was said that debugging floating point program on a
> > 387-less platform wasn't doable. Now the FAQ says (section 12.10) it
> > should work. Alas it doesn't.
> 
> I'm confused: didn't you tell that the program does NOT use FP math?

Yes, as far as I can see. Where do SIGFPE come from? (And SIGEMT?)
That's a (one of them) mystery to me.

> > Starting program: f:/hackery/stat/new_stat/analyse_.exe
> > 
> > Program received signal SIGEMT, Emulation trap.
> > 0x5535 in _control87 ()
> 
> What does "info handle SIGEMT" print?

It says "Yes" on everything.

> > Breakpoint 1...
> > -> n
> > Exiting due to signal SIGFPE
> > Coprocessor Error at eip=00001a64, x87 status=
> > Program received signal SIGEMT, Emulation trap.
> 
> This is a known problem: breakpoints sometimes cause programs that are 
> debugged under an FP emulator to crash.  Note that the FAQ still has this 
> caveat in section 12.10:
> 
>    Some problems still remain, though, even in v2.03: if you use the 
>    stock `emu387.dxe' FP emulator while debugging floating-point programs or
>    debug programs that call `alarm' or `setitimer' library functions, the 
>    program will sometimes crash with `SIGSEGV'.

But it isn't a floating-point program...

> > Another little bug: N.B. the line after SIGFPE where "status=". I
> > suspect the line "00c1" after my last "c" is supposed to be output
> > earlier.
> 
> That's because the status is retrieved by a call to _status87, which 
> triggers a no-coprocessor exception.  When an exception is triggered, 
> GDB gets control and prints whatever it has to say; the result of the
> call to _status87 is not printed until the debuggee is resumed.
> 
> So I don't think this is a bug.

Ah! Ok.

> > Or is there some other bug somewhere that I don't see?
> 
> Probably ;-)
> 
> > #define OFFS (270)
> >   sprintf( tmp_path, "%c:/", drive );
> >   _put_path( tmp_path );
> >   _farsetsel( _dos_ds );
> >   for( i = 0; i < 0x100; i++ )
> >   {
> >     _farnspokeb( OFFS + i, 0 );
> >   }
> 
> This last loop writes over 0x100 bytes of DOS memory, starting at the 
> address 0:OFFS.  You probably meant to write to _tb_segment:OFFS instead, 
> as overwriting low DOS memory sounds like a bad idea ;-)  I'd say this

Ooops! Yes it's not the best thing I can do.

> is better:
> 
>   for (i = 0; i < 0x100; i++)
>   {
>     __farnspokeb (_tb_segment*16 + OFFS + i, 0);
>   }

Thanks!

> 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(). Anyway in this case it should be safe as I zero out the
buffer after sprintf().


Right,

						MartinS