Date:	Sun, 21 Jan 2001 09:29:21 +0200 (IST)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	Martin Str|mberg <ams AT ludd DOT luth DOT se>
cc:	DJGPP-WORKERS <djgpp-workers AT delorie DOT com>
Subject:	Re: Debugging on 386
In-Reply-To:	<200101201906.UAA03921@father.ludd.luth.se>
Message-ID:	<Pine.SUN.3.91.1010121085318.13920K-100000@is>
MIME-Version:	1.0
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

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?

> 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?

> Starting program: f:/hackery/stat/new_stat/analyse_.exe
> 
> Program received signal SIGEMT, Emulation trap.
> 0x5535 in _control87 ()

What does "info handle SIGEMT" print?

> 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'.

> Ideas?

Try "handle SIGEMT nostop noprint".

> 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.

> 2. If I #define OFFS to 1024 in my program, it hangs (both on DOZE
> 6.22 and WINDOZE 98) after printing out the results from the first
> call to AX=0x7303 (and funny things start to appear at top of the
> screen). Isn't the transfer buffer at least 2kiB?

It's 2KB at least, and 16KB by default (you didn't stubedit your program 
to use a smaller transfer buffer, did you?).

> 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
is better:

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

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.

- Raw text -