Date:	Sun, 25 May 1997 14:09:56 +0300 (IDT)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To:	Paul Derbyshire <ao950 AT FreeNet DOT Carleton DOT CA>
cc:	djgpp AT delorie DOT com
Subject:	Re: Windows NT
In-Reply-To:	<5m8quk$nm4@freenet-news.carleton.ca>
Message-ID:	<Pine.SUN.3.91.970525140438.4960Y-100000@is>
MIME-Version:	1.0

On 25 May 1997, Paul Derbyshire wrote:

> The control-break handler must have an error that causes sigsegv under
> less forgiving DPMI hosts...:P

Actually, most NT-related problems that people cared to hunt down were 
traced to bugs in the NT built-in DPMI host.  So I'd guess this is 
another such case, until proven otherwise.

> I noticed that if a DJGPP program pukes under WIndows 95 in a DOS box, you
> don't get a symifyable stack trace, which is a serious problem. Is thee a
> way, for instance, to turn this:
> 
> Fault location
> 00A7:2FB8B
> 
> into this:
> 
> _foobar()+19 (foo.c: line 218)

You need to know that this address is in the DJGPP program's address 
space (as opposed to some Windows code), and you cannot do that without 
the register dump.

Anyway, if you need to try, you can use the disassemble command of any 
debugger to see what's going on around that address.  GDB (and RHIDE) 
will show you the function, if any, which includes this address.

> This is obviously a segment/offset type deal. I need to know how to turn
> these unfriendly non-PM-type addresses into locations in my code...

How do you know it's non-PM?  Intel processors are segmented in both RM 
and PM, you just can forget about the segments in DJGPP since their value 
never changes as long as your code runs.  But when you call DOS or the 
DPMI host, the segments *do* change.

- Raw text -