From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [205.139.110.120]) by sourceware.org (Postfix) with ESMTP id 7865238930ED for ; Mon, 11 May 2020 14:23:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 7865238930ED Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-492-ShS2eSb2M0Oc2RLEdQpTQA-1; Mon, 11 May 2020 10:22:47 -0400 X-MC-Unique: ShS2eSb2M0Oc2RLEdQpTQA-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 9BFA9872FE0; Mon, 11 May 2020 14:22:46 +0000 (UTC) Received: from oldenburg2.str.redhat.com (ovpn-114-54.ams2.redhat.com [10.36.114.54]) by smtp.corp.redhat.com (Postfix) with ESMTPS id E72A36C777; Mon, 11 May 2020 14:22:45 +0000 (UTC) From: Florian Weimer To: Thomas Neumann Cc: Gcc Subject: Re: performance of exception handling References: <0bbdaab7-c083-e14e-6227-27713dab9657@users.sourceforge.net> <874ksmg3fb.fsf@oldenburg2.str.redhat.com> <929cc727-20c6-480c-3412-d3f7a08f7544@users.sourceforge.net> Date: Mon, 11 May 2020 16:22:39 +0200 In-Reply-To: <929cc727-20c6-480c-3412-d3f7a08f7544@users.sourceforge.net> (Thomas Neumann's message of "Mon, 11 May 2020 15:59:16 +0200") Message-ID: <87wo5id00g.fsf@oldenburg2.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-9.4 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_SHORT, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, 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@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2020 14:23:09 -0000 * Thomas Neumann: >> Link: >> >> I'm not sure if your summary is correct. > > I was referring to Section 3.2, where Herb says: > > "We must remove all technical reasons for a C++ project to disable > exception handling (e.g., by compiler switch) or ban use of exceptions, > in all or part of their project." Ah, but I think his other papers make it clear that he wants a unified error handling mechanism for C++, but something that is not based on exceptions with stack unwinding. Or has he changed his mind? > In a way I am disagreeing with the paper, of course, in that I propose > to make the existing exception mechanism faster instead of inventing a > new exception mechanism. But what I agree on with P0709 is that it is > unfortunate that many projects disable exceptions due to performance > concerns. And I think the performance problems can be solved. Yes, I think we agree. >> My current preferred solution is something that moves the entire code >> that locates the relevant FDE table into glibc. > > That is indeed an option, but I have two concerns there. First, it will > lead to code duplication, as libgcc will have to continue to provide its > on implementation on systems with "old" glibcs lacking > __dl_ehframe_find. That's true for any approach with backwards compatibility. > And second, libgcc has a second lookup mechanism for > __register_frame_info_bases etc., which is needed to JITed code anyway. > And it seems to be attractive to handle that in the same data structure > that also covers the code from executables and shared libraries. That would still need dynamic linker changes because currently, it is not possible to report failure from an ELF constructor, and registration may fail due to the memory allocations. > Of course one could move that part to glibc, too. But the code > duplication problems will persist for a long time, as gcc cannot rely > upon the system glibc being new enough to provide __dl_ehframe_find. Sure. I'm not too worried about the explicitly registration code. We can optimize that independently, with a fast path for the common case that no frames have been registered using this mechanism. Thanks, Florian