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.129.124]) by sourceware.org (Postfix) with ESMTPS id CDBB8385843A for ; Thu, 18 Nov 2021 13:43:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org CDBB8385843A Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-297-A9cqs3hzNwe-E2oomudI8w-1; Thu, 18 Nov 2021 08:43:08 -0500 X-MC-Unique: A9cqs3hzNwe-E2oomudI8w-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 4EA19100C609; Thu, 18 Nov 2021 13:43:07 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.192.54]) by smtp.corp.redhat.com (Postfix) with ESMTPS id D9C0060657; Thu, 18 Nov 2021 13:43:06 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.16.1/8.16.1) with ESMTPS id 1AIDh4RW2646660 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Thu, 18 Nov 2021 14:43:04 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.16.1/8.16.1/Submit) id 1AIDh3oo2646659; Thu, 18 Nov 2021 14:43:03 +0100 Date: Thu, 18 Nov 2021 14:43:03 +0100 From: Jakub Jelinek To: Florian Weimer Cc: libc-alpha@sourceware.org, gcc-patches@gcc.gnu.org, Jason Merrill Subject: Re: [PATCH 3/3] elf: Add _dl_find_eh_frame function Message-ID: <20211118134303.GB2646553@tucnak> Reply-To: Jakub Jelinek References: MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 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=-5.7 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Nov 2021 13:43:11 -0000 On Wed, Nov 03, 2021 at 05:28:02PM +0100, Florian Weimer wrote: > This function is similar to __gnu_Unwind_Find_exidx as used on arm. > It can be used to speed up the libgcc unwinder. I'm little bit worried that this trades the speed of exceptions for speed of dlopen/dlclose and extra memory use in each process. I admit I haven't been paying close attention to how many shared libraries apps typically link against and how many dlopen/dlclose calls they do in the last decade and half, but I'd think more applications don't use exceptions compared to apps that do use them, and of many of those that do use them don't use them for really exceptional cases, so speeding those is a good thing. So, I'd wonder, could this overhead be added lazily, when _dl_find_eh_frame is called for the first time just take the rtld lock, prepare anything you populate right now already from the process start up and every dlopen/dlclose before the first _dl_find_eh_frame call and only since then keep it updated on dlopen/dlclose? Thus, for the expected majority of apps that aren't using exceptions at all nothing would change for dlopen/dlclose overhead, while all but the first _dl_find_eh_frame would be faster and with no locking? Jakub