Mail Archives: djgpp-workers/2001/01/21/10:44:55
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
- Raw text -