From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 76E5D3858413 for ; Mon, 21 Nov 2022 11:48:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 76E5D3858413 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1669031323; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references; bh=2NtNKx/IYyGZEjoCLzdxKNO9l0kK2oci2jaDHmmsZxY=; b=S+Cdqn8lXPntmbiS6KvCEZJFyfwKQvVoXwjlVxJEMElv2Pk7EGtNE1UrXH6tDXTL1re2CX Yxwmpe9jgITLB/wuIJaQwRtuR1WcycekciGyhCerBG4Gp+xnNyefuaJnCffw81jcPh2VOs bjT6xTM0grwaFvL2XdcNLPmTxMHotyA= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-434-rAl6O827PZSlCRPcFP2THw-1; Mon, 21 Nov 2022 06:48:40 -0500 X-MC-Unique: rAl6O827PZSlCRPcFP2THw-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id C145986C051; Mon, 21 Nov 2022 11:48:39 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.194.202]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 7FD452166B26; Mon, 21 Nov 2022 11:48:39 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.17.1/8.17.1) with ESMTPS id 2ALBmYek028057 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Mon, 21 Nov 2022 12:48:34 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 2ALBmSib028056; Mon, 21 Nov 2022 12:48:28 +0100 Date: Mon, 21 Nov 2022 12:48:28 +0100 From: Jakub Jelinek To: Thomas Neumann Cc: Tamar Christina , "gcc-patches@gcc.gnu.org" , Jason Merrill , Florian Weimer , Jonathan Wakely Subject: Re: [PATCH v4] eliminate mutex in fast path of __register_frame Message-ID: Reply-To: Jakub Jelinek References: <2a4776b9-9271-bb3c-a626-d5ec22dae6f3@in.tum.de> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 3.1 on 10.11.54.6 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-3.5 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_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Mon, Nov 21, 2022 at 12:22:32PM +0100, Thomas Neumann via Gcc-patches wrote: > > When dynamically linking a fast enough machine hides the latency, but when > > Statically linking or on slower devices this change caused a 5x increase in > > Instruction count and 2x increase in cycle count before getting to main. > > > > This has been quite noticeable on smaller devices. Is there a reason the btree > > can't be initialized lazily? It seems a bit harsh to pay the cost of unwinding at > > startup even when you don't throw exceptions.. > > we cannot easily do that lazily because otherwise we need a mutex for lazy > initialization, which is exactly what we wanted to get rid of. > > Having said that, I am surprised that you saw a noticeable difference. On > most platforms there should not be dynamic frame registration at all, as the > regular frames are directly read from the ELF data. > > Can you please send me an precise description on how to reproduce the issue? > (Platform, tools, a VM if you have one would be great). I will then debug > this to improve the startup time. I can see it being called as well for -static linked binaries. -static links in crtbeginT.o which is libgcc/crtstuff.c built with CRTSTUFFT_O macro being defined among other things, and that disables USE_PT_GNU_EH_FRAME: #if defined(OBJECT_FORMAT_ELF) \ && !defined(OBJECT_FORMAT_FLAT) \ && defined(HAVE_LD_EH_FRAME_HDR) \ && !defined(inhibit_libc) && !defined(CRTSTUFFT_O) \ && defined(__GLIBC__) && __GLIBC__ >= 2 #include /* uClibc pretends to be glibc 2.2 and DT_CONFIG is defined in its link.h. But it doesn't use PT_GNU_EH_FRAME ELF segment currently. */ # if !defined(__UCLIBC__) \ && (__GLIBC__ > 2 || (__GLIBC__ == 2 && __GLIBC_MINOR__ > 2) \ || (__GLIBC__ == 2 && __GLIBC_MINOR__ == 2 && defined(DT_CONFIG))) # define USE_PT_GNU_EH_FRAME # endif #endif I think .eh_frame_hdr was never used for statically linked programs, see already https://gcc.gnu.org/legacy-ml/gcc-patches/2001-12/msg01383.html We don't pass --eh-frame-hdr when linking statically and dl_iterate_phdr doesn't handle those. Now, if -static -Wl,--eh-frame-hdr is passed when linking to the driver, .eh_frame_hdr section is created and __GNU_EH_FRAME_HDR symbol points to the start of that section, so at least that section could be found if something in the crt files and libgcc is adjusted. But e.g. i?86, nios2, frv and bfin we also need to find the got. Also, would it work even for static PIEs? Jakub