Date:	Thu, 9 Nov 2000 08:42:20 +0200 (IST)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	djgpp AT delorie DOT com
Subject:	Re: My program hangs under RHIDE's debugger
In-Reply-To:	<8ucv1j$nff$1@nnrp1.deja.com>
Message-ID:	<Pine.SUN.3.91.1001109084112.16891F-100000@is>
MIME-Version:	1.0
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

On Thu, 9 Nov 2000 dcasale AT my-deja DOT com wrote:

> Okay, I'm back with a slightly different problem.

Welcome back ;-)

> I tried experimenting around with Nate Eldredge's YAMD (Yet Another
> Malloc Debugger), but my program hung almost right at the beginning,
> and didn't even get close to where the original crash occurs.

Did you try this on plain DOS or on Windows?  If the former, did you
use CWSDPMI as your DPMI host?  YAMD will not work except with CWSDPMI
or DPMI 1.0 host.

>     // Check to see if the INT 13 HD extensions are present...
>     if( ( (regs.x.flags & 1) == 0 ) && ( regs.x.bx == 0xAA55 ) )
>     {
>         regs.h.ah = 0x48;
>         regs.h.dl = PhysicalDriveNumber;
>         regs.x.si = __tb & 0x0f ;
>         regs.x.es = regs.x.ds = __tb >> 4 ;
>         pINT13DP->BufferSize = 0x1A;
>         dosmemput(pINT13DP,sizeof(*pINT13DP),__tb);

What is sizeof(*pINT13DP)?  How many bytes did you mean to copy to the
transfer buffer?

> 	asm volatile ("pushf" : : );
>         __dpmi_int (0x13, &regs);  /* call BIOS  */  <--- hangs here
> 	asm volatile ("popf" : : );

Why did you insert PUSHF and POPF?  They are not needed for __dpmi_int 
calls; I suggest to remove them.

> I'm guessing that RHIDE's debugger might be using the transfer buffer
> itself, thus overwriting what I just put there.

No, this guess is wrong: the DJGPP debug support arranges for the
debuggee to have a separate transfer buffer, to avoid problems with
stepping through system calls.  This is done in the function that
loads the debugged program and prepares it for execution, effectively
replacing the stub loader; see the source of the function v2loadimage
in djlsr203.zip.

> Any ideas?

The Interrupt List says something about specific BIOSes which fail to
handle this function correctly if the flag word at DS:[SI+2] is not
0000h on entry.  Are you sure you zero that word?

- Raw text -