This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: bounds checking and traps
- From: "Jan Beulich" <JBeulich at novell dot com>
- To: <zack at codesourcery dot com>
- Cc: <gcc at gcc dot gnu dot org>
- Date: Fri, 13 Aug 2004 12:06:15 +0200
- Subject: Re: bounds checking and traps
>GCC expects that the "trap" insn will unconditionally cause a hardware
>fault which (unless the program takes action to intercept it) will
>terminate the process. Which hardware fault it is doesn't matter -
Hmm, I can't agree here. It doesn't matter only if the app isn't expected to try to catch this or other instances of the same exception/signal. Otherwise, since you can tell one from the other (on Linux and perhaps several other Unix-es through trapno, on Windows through the originally communicated exception number [since they don't fold many exception types into one]), attempting to handle one or both may cause all sorts of confusion to the handler.
How I really came to this is not because I want another OS to work with this (at least not at this point), but I'm rather trying to understand why Linux sets the 5th IDT gate to a dpl of 3 rather than 0 (and I'm trying to evaluate the consequences changing this oddity would have) * and I found the only viable explanation for this in the gcc sources. This in turn originates from porting a kernel debugger from another OS to Linux, and this other OS as well as the debugger expect vector 5 to only be activated through #BR (most importantly so continuing without adjusting anything would re-raise the fault, which isn't the case for a software INT 05).
Jan