From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x642.google.com (mail-ej1-x642.google.com [IPv6:2a00:1450:4864:20::642]) by sourceware.org (Postfix) with ESMTPS id 10FB13857C50 for ; Mon, 31 Aug 2020 08:04:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 10FB13857C50 Received: by mail-ej1-x642.google.com with SMTP id h4so5698432ejj.0 for ; Mon, 31 Aug 2020 01:04:38 -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=EI78O0g+gB/NPkfP8tp9wdB5MGaCfn/MRUEFoGZNF/k=; b=oGzFcJFAHoilxFHtNs21xewSxMPYOTFsJrJRgUmVeWC+OAAuJRAbEMGpMHxnELM4Pu +m0tnFwsCsLVXAUsQGE6XKCBoIBPqIe8VaGOGr6q/cLFE7jLSlySiximQwmODKkhqNT3 P8eLMmCxRJ85B4Nd/I1yN3x6nQyVTOguJAH4LrcwRMW+h6MutPVXNtQaLX0NxNneUJpd 9Tp6CSft283SwDbNRE7LtytGD8AWkT+1c69i1B3c8aUE2zTVHOzRBJ1cU9J+Mlw7nEYV Ba/tYSNQnsFdsI3ycRJ/uIIOqOc+JTV2WRbGnBZJfIqBnY8Txsdw7mOZVqIt5qEauyDi Ik3g== X-Gm-Message-State: AOAM531Qst6q+oZ4qL1QIZ9k+dhanhw5RXrL8HX61PvsyqwTPQzBtl/E Cy2cblfr+5DFrN8kFAv1tj6z5FEAgP/pHCgQhsg= X-Google-Smtp-Source: ABdhPJxGgTVD4N245wky+EnY25umacK0e4aFl4xVvFbMus0GPBgjb5EVGLcJRECUXq/dFvrK6sYQI5gPsT43yp9hmK8= X-Received: by 2002:a17:906:91d3:: with SMTP id b19mr15917ejx.235.1598861077139; Mon, 31 Aug 2020 01:04:37 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Richard Biener Date: Mon, 31 Aug 2020 10:04:26 +0200 Message-ID: Subject: Re: [PATCH v3] libgcc: Use `-fasynchronous-unwind-tables' for LIB2_DIVMOD_FUNCS To: Ramana Radhakrishnan Cc: "Maciej W. Rozycki" , Andrew Waterman , Kito Cheng , Andreas Schwab , GCC Patches Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, KAM_SHORT, 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: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2020 08:04:40 -0000 On Fri, Aug 28, 2020 at 5:47 PM Ramana Radhakrishnan wrote: > > On Wed, Aug 26, 2020 at 12:08 PM Richard Biener via Gcc-patches > wrote: > > > > On Tue, Aug 25, 2020 at 6:32 PM Maciej W. Rozycki wrote: > > > > > > Hi Kito, > > > > > > > I just found the mail thread about div mod with -fnon-call-exceptions, > > > > I think keeping the default LIB2_DIVMOD_EXCEPTION_FLAGS unchanged > > > > should be the best way to go. > > > > > > > > Non-call exceptions and libcalls > > > > https://gcc.gnu.org/legacy-ml/gcc/2001-06/msg01108.html > > > > > > > > Non-call exceptions and libcalls Part 2 > > > > https://gcc.gnu.org/legacy-ml/gcc/2001-07/msg00402.html > > > > > > Thank you for your input. I believe I had a look at these commits before > > > I posted my original proposal. Please note however that they both predate > > > the addition of `-fasynchronous-unwind-tables', so clearly the option > > > could not have been considered at the time the changes were accepted into > > > GCC. > > > > > > Please note that, as observed by Andreas and Richard here: > > > in no case we > > > want to have full exception handling here, so we clearly need no > > > `-fexceptions'; this libcall code won't itself ever call `throw'. > > > > > > Now it might be a bit unclear from documentation as to whether we want > > > `-fnon-call-exceptions' or `-fasynchronous-unwind-tables', as it says that > > > the former option makes GCC: > > > > > > " Generate code that allows trapping instructions to throw > > > exceptions. Note that this requires platform-specific runtime > > > support that does not exist everywhere. Moreover, it only allows > > > _trapping_ instructions to throw exceptions, i.e. memory references > > > or floating-point instructions. It does not allow exceptions to be > > > thrown from arbitrary signal handlers such as 'SIGALRM'." > > > > > > Note the observation that arbitrary signal handlers (invoked at more inner > > > a frame level, and necessarily built with `-fexceptions') are still not > > > allowed to throw exceptions. For that, as far as I understand it, you > > > actually need `-fasynchronous-unwind-tables', which makes GCC: > > > > > > " Generate unwind table in DWARF format, if supported by target > > > machine. The table is exact at each instruction boundary, so it > > > can be used for stack unwinding from asynchronous events (such as > > > debugger or garbage collector)." > > > > > > and therefore allows arbitrary signal handlers to throw exceptions, > > > effectively making the option a superset of `-fexceptions'. As libcall > > > code can generally be implicitly invoked everywhere, we want people not to > > > be restrained by it and let a exception thrown by e.g. a user-supplied > > > SIGALRM handler propagate through the relevant libcall's stack frame, > > > rather than just those exceptions the libcall itself might indirectly > > > cause. > > > > > > Maybe I am missing something here, especially as `-fexceptions' mentions > > > code generation, while `-fasynchronous-unwind-tables' only refers to > > > unwind table generation, but then what would be the option to allow > > > exceptions to be thrown from arbitrary signal handlers rather than those > > > for memory references or floating-point instructions (where by a special > > > provision integer division falls as well)? > > > > > > My understanding has been it is `-fasynchronous-unwind-tables', but I'll > > > be gladly straightened out otherwise. If I am indeed right, then perhaps > > > the documentation could be clarified and expanded a bit. > > > > > > Barring evidence to the contrary I maintain the change I have proposed is > > > correct, and not only removes the RISC-V `ld.so' build issue, but it fixes > > > the handling of asynchronous events arriving in the middle of the relevant > > > libcalls for all platforms as well. > > > > > > Please let me know if you have any further questions, comments or > > > concerns. > > > > You only need -fexceptions for that, then you can throw; from a signal handler > > for example. If you want to be able to catch the exception somewhere up > > the call chain all intermediate code needs to be compiled so that unwinding > > from asynchronous events is possible - -fasynchronous-unwind-tables. > > > > So -fasynchronous-unwind-tables is about unwinding. -f[non-call]-exceptions > > is about throw/catch. Clearly libgcc does neither throw nor catch but with > > async events we might need to unwind from inside it. > > > > Now I don't know about the arm situation but if arm cannot do async unwinding > > then even -fexceptions won't help it here - libgcc still does not throw. > > On Arm as in the AArch32 port, async unwinding will not work as those > can't be expressed in the EH format tables. And surely building libgcc with -fexceptions does not change that either. Richard. > regards > Ramana > > > > > Richard. > > > > > > > > Maciej