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

Joerg Sonnenberger via cfe-dev cfe-dev at lists.llvm.org
Tue Sep 22 06:58:20 PDT 2015

On Tue, Sep 22, 2015 at 09:41:16AM +0100, David Chisnall via cfe-dev wrote:
> On 21 Sep 2015, at 21:45, H.J. Lu via cfe-dev <cfe-dev at lists.llvm.org> wrote:
> > 
> > The main purpose of x86 interrupt attribute is to allow programmers
> > to write x86 interrupt/exception handlers in C WITHOUT assembly
> > stubs to avoid extra branch from assembly stubs to C functions.  I
> > want to keep the number of new intrinsics to minimum without sacrificing
> > handler performance. I leave faking error code in interrupt handler to
> > the programmer.
> The assembly stubs have to come from somewhere.  You either put them
> in an assembly file (most people doing embedded x86 stuff steal the
> ones from NetBSD), or you put them in the compiler where they can be
> inlined.  In terms of user interface, there’s not much difference in
> complexity.  Having written this kind of code in the past, I can
> honestly say that using the assembly stubs was the least difficult part
> of getting them right.

There are some more things to consider. What is the environment your
interrupt / exception handler is to be provided? Do you use %fs or %gs
for kernel state? Do you expect to point %es or %ds to valid registers?
What kind of interrupt vector are you using? All this and more are often
highly kernel specific and certainly nowhere generic.

> In terms of compiler complexity, there’s a big difference: in one case
> the compiler contains nothing, in the other it contains something
> special for a single use case.  In terms of performance, the compiler
> version has the potential to be faster, but if we’re going to pay for
> the complexity then I think that we’d need to see some strong evidence
> that someone else is getting a noticeable benefit.

To further extend this a bit. Most kernels I know explicitly disable SSE
and friends for general use. They are neither saved nor changed outside
the context switching code. The potential advantage for a compiler is
therefore to save a limited set of the general purpose registers. That's
between 8 and 16 registers, so not such a big potential, not even
counting normal psABI preservation in.


More information about the cfe-dev mailing list