From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: far call
Date: Wed, 20 Oct 1999 13:19:42 +0200
Organization: NetVision Israel	
Lines: 38
Message-ID: <Pine.SUN.3.91.991020130944.22660F-100000@is>
References: <Pine DOT UW2 DOT 3 DOT 95 DOT 991019185402 DOT 20452B-100000 AT bryggen DOT bgnett DOT no> <7uim9q$14k AT acp3bf DOT knirsch DOT de>
NNTP-Posting-Host: is.elta.co.il
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Trace: news.netvision.net.il 940418303 19631 199.203.121.2 (20 Oct 1999 11:18:23 GMT)
X-Complaints-To: abuse AT netvision DOT net DOT il
NNTP-Posting-Date: 20 Oct 1999 11:18:23 GMT
X-Sender: eliz AT is
In-Reply-To: <7uim9q$14k@acp3bf.knirsch.de>
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk


On 19 Oct 1999, Hans-Bernhard Broeker wrote:

> Gisle Vanem (giva AT bryggen DOT bgnett DOT no) wrote:
> > Eli Zaretskii <eliz AT is DOT elta DOT co DOT il> said:
> > > > Exiting due to signal SIGSEGV
> > > > General Protection Fault at eip=00001dcc, error=01d4
> 
> > > So in this case, you are trying to use a selector 0x1d4, which is indeed
> > > invalid (it's not ring-3 selector).
> >  
> > OTOH, the error code doesn't include the ring-level.
> 
> It does. You just don't see it because you don't know where to look
> --- the 2 lowest bits of the descriptor are the ring-level. Your
> descriptor is 0x1d4 ==> lowest bits are 00 ==> Ring-0 was requested.

Btw, as long as we are talking about this, here's an idea for a useful 
project: add code to SYMIFY that would analyze the crash message and 
print human-readable hints, expressed in small words, as to possible 
causes.  Examples include possible NULL pointer dereference in case of 
Page Fault, invalid selector in case of GPF with an error code, stack 
overrun if EBP looks funny, etc.  You could even get ambitious enough to 
disassemble the code at the  EIP shown by the traceback (EDEBUG32 and 
FSDB include ready disassembly code), find the register with the garbled 
data, and maybe even determine what C variable is loaded into that 
register.

The list of possible problems and their symptoms in section 12.2 of 
the FAQ should be the starting point.  Browsing through the DJGPP 
archives should provide enough examples to test the code.  If that's not 
enough, I can add some really weird cases from my private collection ;-)

As a bonus (besides the infinite gratitude of every newbie around here, 
that is), whoever does this will learn A LOT about protected mode and 
DPMI.  That's a promise.

Well, any takers?