From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) by sourceware.org (Postfix) with ESMTPS id A4144385480E for ; Thu, 18 Mar 2021 13:03:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org A4144385480E Received: by mail-lf1-x12d.google.com with SMTP id q29so4420479lfb.4 for ; Thu, 18 Mar 2021 06:03:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7CC2knxQFkyKtB2eS96VkDNCQJeN5KGZyNR3HTQRBVw=; b=HOLbvSFEmnsOWC9EW542Tu4ECpSpx7LAcPuSZ1RoguC00Eu4Rhp3oAGipXpDudplQW wO16xoaR+5HQ7o/8X8qEPZUDMQ5nk+THbZV/SiqUhEeq1oyK+HGrEkKosVLGKvvdRhm6 N1ux9VnuYlFOwfW6VDUgk1hGlHY2iB4sEQhR1QRt/hbAichV6FnLm0QRqmyRJW9EI9Pf 2v57lg9sk/76BzkSGDRYV3WyRJmjqFCPcpCKQvcwBThn8cL6sEtcPcfJOIhHN8FjCYEe uW+rWpSmzl+Q/gv4nH4nrvZhKBsF6NKGa7OmMYPeDWHtmHd6zoGoIZ62oeQMBZBiASEA OAsA== X-Gm-Message-State: AOAM530YDR1lZf0zAYGvbx9xFZTDjhUvn0i7iRJ7jP/stbxDgsjwUnAq pZwaHG47MTKY1AgSZtauLU0uCZmIPopdVw5duxw= X-Google-Smtp-Source: ABdhPJx6s6KZ60U/JJIqtc2CbuK/s61phXHLxtWLYomCcWIAjyJURgMEAof93At0A5MNR+kpYex8HwzmEPjuc6zgN08= X-Received: by 2002:a05:6512:2097:: with SMTP id t23mr5079872lfr.21.1616072582118; Thu, 18 Mar 2021 06:03:02 -0700 (PDT) MIME-Version: 1.0 References: <41f234be-0fbe-0ae1-74be-084bab59bef6@linaro.org> In-Reply-To: <41f234be-0fbe-0ae1-74be-084bab59bef6@linaro.org> From: Fengkai Sun Date: Thu, 18 Mar 2021 21:02:48 +0800 Message-ID: Subject: Re: why don't setjmp save MXCSR register and x87 control word? To: Adhemerval Zanella Cc: libc-help@sourceware.org X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM, HTML_MESSAGE, 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 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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:03:05 -0000 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? I still have one question here: On Thu, Mar 18, 2021 at 2:59 AM Adhemerval Zanella < adhemerval.zanella@linaro.org> 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. Much appreciated, Fengkai