Hi, Here is the fixed version of the patch. Ok for trunk? -----Original Message----- From: Sandra Loosemore [mailto:sandra@codesourcery.com] Sent: Tuesday, May 10, 2016 11:02 PM To: Koval, Julia ; gcc-patches@gcc.gnu.org Cc: Lu, Hongjiu ; vaalfreja@gmail.com; ubizjak@gmail.com; law@redhat.com; Zamyatin, Igor Subject: Re: [PATCH] x86 interrupt attribute patch [2/2] On 04/20/2016 07:42 AM, Koval, Julia wrote: > diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi index > a5a8b23..82de5bf 100644 > --- a/gcc/doc/extend.texi > +++ b/gcc/doc/extend.texi > @@ -5263,6 +5263,83 @@ On x86-32 targets, the @code{stdcall} attribute > causes the compiler to assume that the called function pops off the > stack space used to pass arguments, unless it takes a variable number of arguments. > > +@item no_caller_saved_registers > +@cindex @code{no_caller_saved_registers} function attribute, x86 Use > +this attribute to indicate that the specified function has no > +caller-saved registers. That is, all registers are callee-saved. > +The compiler generates proper function entry and exit sequences to > +save and restore any modified registers, except for the EFLAGS > +register. If the compiler generates MPX, SSE, MMX or x87 > +instructions in a function with @code{no_caller_saved_registers} > +attribute or functions called from a function with > +@code{no_caller_saved_registers} attribute may contain MPX, SSE, MMX > +or x87 instructions, the compiler must save and restore the corresponding state. I cannot parse the last sentence in this paragraph. How can the compiler know whether called functions may contain those instructions? Plus, talking about what the compiler must do seems too implementor-speaky for user documentation. Maybe you mean something like "The compiler also saves and restores state associated with MPX, SSE, MMX, and x87 instructions." ? I also think the documentation needs to give some hint about why a user would want to put this attribute on a function. > + > +@item interrupt > +@cindex @code{interrupt} function attribute, x86 Use this attribute > +to indicate that the specified function 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 > +@code{IRET} instruction, instead of the @code{RET} instruction, is > +used to return from interrupt handlers. All registers, except for > +the EFLAGS register which is restored by the @code{IRET} instruction, > +are preserved by the compiler. If the compiler generates MPX, SSE, > +MMX or x87 instructions in an interrupt handler, or functions called > +from an interrupt handler may contain MPX, SSE, MMX or x87 > +instructions, the compiler must save and restore the corresponding > +state. Similar problems here. From the further discussion that follows, it appears that you can use the "interrupt" attribute on exception handlers as well, but the paragraph above only mentions interrupt handlers. > + > +Since the direction flag in the FLAGS register in interrupt handlers > +is undetermined, cld instruction must be emitted in function prologue > +if rep string instructions are used in interrupt handler or interrupt > +handler isn't a leaf function. Again, this sounds like implementor-speak, and there are grammatical errors (noun/verb disagreement, missing articles). Do users of this attribute need to know what instructions the compiler is emitting? We already say above that it causes GCC to generate suitable entry and exit sequences. > + > +Any interruptible-without-stack-switch code must be compiled with > +@option{-mno-red-zone} since interrupt handlers can and will, because > +of the hardware design, touch the red zone. > + > +An interrupt handler must be declared with a mandatory pointer > +argument: > + > +@smallexample > +struct interrupt_frame; > + > +__attribute__ ((interrupt)) > +void > +f (struct interrupt_frame *frame) > +@{ > +@} > +@end smallexample > + > +and user must properly define the structure the pointer pointing to. "user" == "you" in the GCC user manual. How do you "properly define" this structure, or is that a stupid question? (I know very little about x86, maybe this is obvious to experts.) > + > +The exception handler is very similar to the interrupt handler with > +a different mandatory function signature: > + > +@smallexample > +#ifdef __x86_64__ > +typedef unsigned long long int uword_t; > +#else > +typedef unsigned int uword_t; > +#endif > + > +struct interrupt_frame; > + > +__attribute__ ((interrupt)) > +void > +f (struct interrupt_frame *frame, uword_t error_code) > +@{ > + ... > +@} > +@end smallexample > + > +and compiler pops the error code off the stack before the @code{IRET} > +instruction. > + > +The exception handler should only be used for exceptions which push an > +error code and all other exceptions must use the interrupt handler. > +The system will crash if the wrong handler is used. I think you need to move this information above the examples, and explain from the start that there are two flavors of handlers that have different information pushed on the stack by the hardware. > + > @item target (@var{options}) > @cindex @code{target} function attribute > As discussed in @ref{Common Function Attributes}, this attribute -Sandra