[cfe-dev] RFC: Support x86 interrupt and exception handlers

[John Criswell via cfe-dev]

On 9/21/15 12:27 PM, H.J. Lu via cfe-dev wrote:
> On Thu, Sep 17, 2015 at 12:26 PM, H.J. Lu <hjl.tools at gmail.com> wrote:
>> On Tue, Sep 15, 2015 at 1:11 PM, H.J. Lu <hjl.tools at gmail.com> wrote:
>>>> To implement interrupt and exception handlers for x86 processors, a
>>>> compiler should support:
>>>>
>>>> 1. void * __builtin_ia32_interrupt_data (void)
>>> I got a feedback on the name of this builtin function.  Since
>>> it also works for 64-bit,  we should avoid ia32 in its name.
>>> We'd like to change it to
>>>
>>> void * __builtin_interrupt_data (void)
>>>
>> Here is the updated spec.
>>
> This updated spec adds
>
>     unsigned int __builtin_exception_error (void)
>     unsigned long long int __builtin_exception_error (void)
>
> This function returns the exception error code pushed onto the stack by
> processor.  Its return value is 64 bits in 64-bit mode and 32 bits in
> 32-bit mode.  This function can only be used in exception handler.

Exception handlers can, in general, call regular functions which, in 
turn, might want to access the error code.  Given that operating system 
kernels are always entered via an interrupt, trap, or system call, there 
should always be an error code available (on x86, non-error-code 
interrupts can just make up an error code).

>
> It also changes the definition of
>
> void * __builtin_interrupt_data (void)
>
> so that it returns a pointer to the data layout pushed onto stack
> by processor for both interrupt and exception handlers.
>
>

You might want to have a look at Secure Virtual Architecture (SVA). One 
of the things we discovered is that commodity operating systems access 
the most recently used interrupt data (which SVA calls an "interrupt 
context").  Over the years, we figured out that it's better to provide 
intrinsics (i.e., builtins) that implicitly access the top-most 
interrupt context.  We also found that we could limit the operations 
performed on interrupt contexts so that we could safely implement signal 
handlers and exception recovery without letting the operating system 
kernel have pointers to the interrupt context which would need to be 
checked.  In short, despite common belief, the OS does not need to do 
whatever it wants with interrupted program state.

I recommend you take a look at Appendix A of my dissertation 
(https://www.ideals.illinois.edu/handle/2142/50547).  It describes the 
SVA-OS instructions used to abstract away the hardware details. You'll 
also notice that the design is pretty processor transparent (MMU 
notwithstanding), so designing your builtins based on SVA may make them 
more portable if you decide to use another processor later on.  Chapter 
2 describes some of the rationale behind the design, though it's for the 
first version of SVA (Appendix A is the final instruction set after 4 
papers).

If the implementation is useful, SVA is publicly available at 
https://github.com/jtcriswell/SVA.

Finally, to echo Joerg's concerns, it's not clear that having 
exception/interrupt handlers declared as a special type is really 
helpful.  It's not immediately obvious that you get a benefit from doing 
that vs. doing what most system software does (having assembly code that 
saves processor state and calls a C function).  I think you should do 
some experiments to demonstrate the benefit that one can get with your 
method to see if it is worth adding complexity to the compiler.

Regards,

John Criswell

-- 
John Criswell
Assistant Professor
Department of Computer Science, University of Rochester
http://www.cs.rochester.edu/u/criswell