From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com [IPv6:2607:f8b0:4864:20::72a]) by sourceware.org (Postfix) with ESMTPS id 91CDD385781F for ; Thu, 18 Mar 2021 13:25:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 91CDD385781F Received: by mail-qk1-x72a.google.com with SMTP id x10so1901514qkm.8 for ; Thu, 18 Mar 2021 06:25:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:cc:references:from:subject:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=GhTyC4AxBRRPOwtz5gIi8B6Nd65g+GZ49M/YajoOEJU=; b=cWgq+KgzpnO240S5jPrTWFo/yT2Y5jDRa1gz4p9qa0qIQDvjdBu5Fp9I4QO1bVOIME tB0DSj8D6vsgRcoGzZKJBSGuvZHNWcqOi6lBnaOkxpFzRLQ/F5RB+pAs8eiTJnvHBg20 eQBpkUsbqkRZFp+M00UxBICSUKIvyLsq4s0othfNxRXRb3vVqJY4HP87ZrLunhndwAIr Tne2n/IP2vNnj5MMkahIZcQ381kyx5GOeWs893GywtksO49t7BR9E7Xhq6KC2fqvnrZ4 P3eTMwfX/6SnvpeLxlPYtteHi0wMRThgcgCszM1Qx9cP2V7xc8MK0CbVYdOpX1EjHCx/ ykaA== X-Gm-Message-State: AOAM53126YTZqB8uJCbfXgXO6XSkt74pnUu9uN/a8YwPJC6Qi0Z8f0j3 QOUJJJG4Z5/bVf/qqFS70qIkCmQN7DXVD+Pi X-Google-Smtp-Source: ABdhPJxLVLpj6fWaeG/smGxJMO36TgzKVWYbnoNC+nncIjhgYpF9qqxFUiAjl2ii4c5j5Etf1mG4OQ== X-Received: by 2002:a05:620a:120d:: with SMTP id u13mr4206056qkj.248.1616073914896; Thu, 18 Mar 2021 06:25:14 -0700 (PDT) Received: from [192.168.1.4] ([177.194.48.209]) by smtp.googlemail.com with ESMTPSA id e96sm1378207qtb.60.2021.03.18.06.25.13 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 18 Mar 2021 06:25:14 -0700 (PDT) To: Fengkai Sun Cc: libc-help@sourceware.org References: <41f234be-0fbe-0ae1-74be-084bab59bef6@linaro.org> From: Adhemerval Zanella Subject: Re: why don't setjmp save MXCSR register and x87 control word? Message-ID: Date: Thu, 18 Mar 2021 10:25:11 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-7.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-help@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-help mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2021 13:25:16 -0000 On 18/03/2021 10:02, Fengkai Sun wrote: > Hello Adhemerval, > > Thank you very much for your informative reply! > > I think I've figured it out: setjmp and longjmp, though look like function call  > and return, are actually not. Thus their behavior should be defined by standard >  instead of calling conventions, is that correct? The C standard defines its semantic, it is up to the compiler plus the ABI to actually define its calling convention (gcc for instance handles internal the concept that setjmp returns more than once). > > I still have one question here: > > On Thu, Mar 18, 2021 at 2:59 AM Adhemerval Zanella > wrote: > >   Note that standards don't require longjmp to restore either control >   word, and none of Linux, MacOS X 10.3 and earlier, NetBSD, OpenBSD, >   or Solaris do it. However, it is historical FreeBSD behavior, and >   bde points out that it is needed to make longjmping out of a signal >   handler work properly, given the way FreeBSD clobbers the FPU state >   on signal handler entry. > >   > Does this mean that on FreeBSD, after longjmp to the saved context, the FPU >  state will be restored to what it was right after setjmp, while on other OSs it's not?  > Because the situation I think of is that, the call stack between setjmp and longjmp >  may have operations modifying FPU state, but longjmp does not restore it on  > most OSs. > No idea about FreeBSD, I am just quoting its setjmp commit history (I haven't checked FreeBSB source or did any experiment to attest it). And yes, you can't count that the FP state will be saved/restored over different implementations.