This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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 <> wrote:
On Tue, Sep 15, 2015 at 1:11 PM, H.J. Lu <> 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 ( 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

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.


John Criswell

John Criswell
Assistant Professor
Department of Computer Science, University of Rochester

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]