From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3675 invoked by alias); 10 May 2016 20:02:32 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 3664 invoked by uid 89); 10 May 2016 20:02:31 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=sandra, Sandra X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Tue, 10 May 2016 20:02:28 +0000 Received: from svr-orw-fem-04.mgc.mentorg.com ([147.34.97.41]) by relay1.mentorg.com with esmtp id 1b0DrM-0001tF-JC from Sandra_Loosemore@mentor.com ; Tue, 10 May 2016 13:02:24 -0700 Received: from [127.0.0.1] (147.34.91.1) by svr-orw-fem-04.mgc.mentorg.com (147.34.97.41) with Microsoft SMTP Server id 14.3.224.2; Tue, 10 May 2016 13:02:24 -0700 Subject: Re: [PATCH] x86 interrupt attribute patch [2/2] To: "Koval, Julia" , "gcc-patches@gcc.gnu.org" References: <4E89A029A0F8D443B436A5167BA3C53F03CFFF3B@CDSMSX101.ccr.corp.intel.com> CC: "Lu, Hongjiu" , "vaalfreja@gmail.com" , "ubizjak@gmail.com" , "law@redhat.com" , "Zamyatin, Igor" From: Sandra Loosemore Message-ID: <57323E4F.8060309@codesourcery.com> Date: Tue, 10 May 2016 20:02:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <4E89A029A0F8D443B436A5167BA3C53F03CFFF3B@CDSMSX101.ccr.corp.intel.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2016-05/txt/msg00756.txt.bz2 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