From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by sourceware.org (Postfix) with ESMTPS id 24DAC385C32E for ; Wed, 24 Aug 2022 12:53:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 24DAC385C32E Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.de Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id D92B2207C0; Wed, 24 Aug 2022 12:53:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1661345613; h=from:from:reply-to: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=og7pHlGfoYaEyo0H/QFnLKmJV0dTU4JaNSXsr2MP4EE=; b=JUBkai4fZZsIy2k9DuiJ5Ar9HX4zSdJvJBcHf+I2Al9+iuNo6UQPNnhsbUMQyhcEV4gKcB IvBeQ4SWy9pzogZ4yq4Xy3hzfZbJdCzi9W5wQC7uRXax1muX2XoFc8zVdLasisKDcm6RTw Vtk2pPw23Bh2Oo3x858eJE8UQj75oHE= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1661345613; h=from:from:reply-to: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=og7pHlGfoYaEyo0H/QFnLKmJV0dTU4JaNSXsr2MP4EE=; b=rsKCeY2WqSjrV4jIzXK+Szqo7+yJq+51B0DX9jbegS6OB6Pbl1EaBFh+Tmfc8HfPNXZSHY IEgdai4Khy4sEuDw== Received: from wotan.suse.de (wotan.suse.de [10.160.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id CD3702C141; Wed, 24 Aug 2022 12:53:33 +0000 (UTC) Received: by wotan.suse.de (Postfix, from userid 10510) id C09ED6633; Wed, 24 Aug 2022 12:53:33 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by wotan.suse.de (Postfix) with ESMTP id BEF7E661C; Wed, 24 Aug 2022 12:53:33 +0000 (UTC) Date: Wed, 24 Aug 2022 12:53:33 +0000 (UTC) From: Michael Matz To: Florian Weimer cc: binutils@sourceware.org, gcc@gcc.gnu.org, libc-alpha@sourceware.org Subject: Re: Counting static __cxa_atexit calls In-Reply-To: <87k06x7sme.fsf@oldenburg.str.redhat.com> Message-ID: References: <87fshn2mu1.fsf@oldenburg.str.redhat.com> <87k06x7sme.fsf@oldenburg.str.redhat.com> User-Agent: Alpine 2.20 (LSU 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-2.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hello, On Wed, 24 Aug 2022, Florian Weimer wrote: > > Isn't this merely moving the failure point from exception-at-ctor to > > dlopen-fails? > > Yes, and that is a soft error that can be handled (likewise for > pthread_create). Makes sense. Though that actually hints at a design problem with ELF static ctors/dtors: they should be able to soft-fail (leading to dlopen or pthread_create error returns). So, maybe the _best_ way to deal with this is to extend the definition of the various object-initionalization means in ELF to allow propagating failure. > > Probably a note section, which the link editor could either transform into > > a dynamic tag or leave as note(s) in the PT_NOTE segment. The latter > > wouldn't require any specific tooling support in the link editor. But the > > consumer would have to iterate through all the notes to add the > > individual counts together. Might be acceptable, though. > > I think we need some level of link editor support to avoid drastically > over-counting multiple static calls that get merged into one > implementation as the result of vague linkage. Not sure how to express > that at the ELF level? Hmm. The __cxa_atexit calls are coming from the per-file local static initialization_and_destruction routine which doesn't have vague linkage, so its contribution to the overall number of cxa_atexit calls doesn't change from .o to final-exe. Can you show an example of what you're worried about? A completely different way would be to not use cxa_atexit at all: allocate memory statically for the object and dtor addresses in .rodata (instead of in .text right now), and iterate over those at static_destruction time. (For the thread-local ones it would need to store arguments to __tls_get_addr). Doing that or defining failure modes for ELF init/fini seems a better design than hacking around the current limitation via counting static cxa_atexit calls. Ciao, Michael.