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

[H.J. Lu via cfe-dev]

On Tue, Sep 15, 2015 at 2:45 PM, Matthew Fortune
<Matthew.Fortune at imgtec.com> wrote:
> H.J. Lu <hjl.tools at gmail.com> writes:
>> On Thu, Sep 3, 2015 at 10:37 AM, H.J. Lu <hjl.tools at gmail.com> wrote:
>> > The interrupt and exception handlers are called by x86 processors.  X86
>> > hardware puts information on stack and calls the handler.  The
>> > requirements are
>> >
>> > 1. Both interrupt and exception handlers must use the 'IRET' instruction,
>> > instead of the 'RET' instruction, to return from the handlers.
>> > 2. All registers are callee-saved in interrupt and exception handlers.
>> > 3. The difference between interrupt and exception handlers is the
>> > exception handler must pop 'ERROR_CODE' off the stack before the 'IRET'
>> > instruction.
>> >
>> > The design goals of interrupt and exception handlers for x86 processors
>> > are:
>> >
>> > 1. No new calling convention in compiler.
>> > 2. Support both 32-bit and 64-bit modes.
>> > 3. Flexible for compilers to optimize.
>> > 4. Easy to use by programmers.
>> >
>> > 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)
>>
>> Any comments?
>
> For what it's worth, this seems like a good plan to me. I don't know x86
> but how many variations of interrupt and exception handling mechanisms
> are there? If there are lots then you may want to make it clear which
> subset of them you intend to support. I just added a few more variations
> of interrupt handlers to MIPS and it got complicated quite quickly.
>
> I think I remember someone asking about interrupt handler support for
> x86 some time ago and the answer then was that there were too many
> variants to make it useful.

In my proposal, there are only 2 handlers: interrupt and exception.
__builtin_interrupt_data is provided to programmers to implement
different variants of those handlers.

>
>>
>> > This function returns a pointer to interrupt or exception data pushed
>> > onto the stack by processor.
>> >
>> > The __builtin_frame_address builtin isn't suitable for interrupt and
>> > exception handlers since it returns the stack frame address on the
>> > callee side and compiler may generate a new stack frame for stack
>> > alignment.
>> >
>> > 2. 'interrupt' attribute
>> >
>> > Use this attribute to indicate that the specified void function without
>> > arguments is an interrupt handler.  The compiler generates function entry
>> > and exit sequences suitable for use in an interrupt handler when this
>> > attribute is present.  The 'IRET' instruction, instead of the
>> > 'RET' instruction, is used to return from interrupt handlers.  All
>> > registers, except for the EFLAGS register which is restored by the
>> > 'IRET' instruction, are preserved by the compiler.  The red zone
>> > isn't supported in an interrupt handler; that is an interrupt
>> > handler can't access stack beyond the current stack pointer.
>> >
>> > You can use the builtin '__builtin_ia32_interrupt_data' function to access
>> > data pushed onto the stack by processor:
>> >
>> > void
>> > f () __attribute__ ((interrupt))
>> > {
>> >   void *p = __builtin_ia32_interrupt_data ();
>> >   ...
>> > }
>> >
>> > 3. 'exception' attribute
>> >
>> > Use 'exception' instead of 'interrupt' for handlers intended to be
>> > used for 'exception' (i.e. those that must pop 'ERROR_CODE' off the
>> > stack before the 'IRET' instruction):
>> >
>> > void
>> > f () __attribute__ ((exception))
>> > {
>> >   void *p = __builtin_ia32_interrupt_data ();
>> >   ...
>> > }
>> >
>> > Any comments, suggestions?
>> >
>> > Thanks.
>> >
>> >
>> > --
>> > H.J.
>>
>>
>>
>> --
>> H.J.



-- 
H.J.