Date: Sun, 25 May 1997 14:09:56 +0300 (IDT) From: Eli Zaretskii To: Paul Derbyshire cc: djgpp AT delorie DOT com Subject: Re: Windows NT In-Reply-To: <5m8quk$nm4@freenet-news.carleton.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk 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.