From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS31976 209.132.180.0/23 X-Spam-Status: No, score=-4.1 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_EF,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 85EB61F461 for ; Wed, 3 Jul 2019 10:05:26 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:from:to:cc:subject:references:date:in-reply-to :message-id:mime-version:content-type:content-transfer-encoding; q=dns; s=default; b=jlW5+5hYm4pLaVz7uXE+pevYklLRjijXMhbZl5VSckV RVvLsCSFnfnXD8vLvWYYSZ/ocqFf8HZA9iBaIl7IlBR2JGSDugxbE79QmMy7jDKi EscaECgk4E8yjmTdVRhx091kQUn5/icouavceT4pbrprkA34liky/QbAT9m+nC74 = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:from:to:cc:subject:references:date:in-reply-to :message-id:mime-version:content-type:content-transfer-encoding; s=default; bh=uN5g87+091crrtNtZYNlGqtxjHQ=; b=mSoKlP2BOav6864jy tpJSwIEu5IICYwlNaF0nf6Kv6CaNlWctitRZZmH67OGEGzEkEi6bZamnL++ggKJ4 qZKnbK19EJxXMt5mYsIAJ+4Gs/C2IUAbAf2s3Sjw6fihzMIAxn0Ps06PO1sy/yMo Lr2l8twfOhgw59PgEjWUdR7RgM= Received: (qmail 104962 invoked by alias); 3 Jul 2019 10:05:24 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 104947 invoked by uid 89); 3 Jul 2019 10:05:23 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: mx1.redhat.com From: Florian Weimer To: Adhemerval Zanella Cc: libc-alpha@sourceware.org Subject: Re: [RFC] stdlib: Make atexit to not act as __cxa_atexit References: <20190701205904.22287-1-adhemerval.zanella@linaro.org> <87k1d098yo.fsf@oldenburg2.str.redhat.com> <44d11528-a60b-47de-5e2d-61f5769755c5@linaro.org> <878stg36xv.fsf@oldenburg2.str.redhat.com> <9a349438-34f9-4552-ed82-f3d8607c5b2c@linaro.org> Date: Wed, 03 Jul 2019 12:05:19 +0200 In-Reply-To: <9a349438-34f9-4552-ed82-f3d8607c5b2c@linaro.org> (Adhemerval Zanella's message of "Tue, 2 Jul 2019 13:56:05 -0300") Message-ID: <87wogztov4.fsf@oldenburg2.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable * Adhemerval Zanella: >>> We need __cxa_finalize because it is called by __do_global_dtors_aux >>> from initfini callbacks. >>=20 >> (Note: The comment is about crtbeginS.o built from libgcc sources.) >>=20 >> If all versions of the ELF constructor in crtbeginS.o call >> __cxa_finalize as their first action, then we can turn __cxa_finalize >> into a NOP and have the dynamic linker perform the original actions of >> __cxa_finalize directly, before running the ELF destructors for this >> object. > > In fact I though about it and one issue I found is __cxa_finalize uses > __dso_handle and it is a hidden symbol for each DSO. So, at _dl_fini > we will need to resolve __cxa_finalize from libc.so (or potentially > other function that handles the exit handlers), then resolve the > __dso_handle from the referenced object (with potentially a hack to > lookup for local objects), and finally call __cxa_finalize with > __dso_handler as argument. Not sure it is really a better design. So =E2=80=A6 what I was implying but didn't say explicitly is that at one p= oint, we will have to map (the address of) __dso_handle to a link map using _dl_find_dso_for_object. I need to submit my patch to speed up _dl_find_dso_for_object substantially. Then it shouldn't be a problem at all to call it in response to each call to atexit, and put new entries on both the global linked list and the per-DSO list. Not sure to what extend we'd need to avoid quadratic-time algorithms here. >>> Also making the loader itself handler atexit >>> is not the best option IMHO: we will either to call a private symbol on= =20 >>> libc (which might require an additional lookup) or export the internal= =20 >>> data so loader can implement the callback issuing itself. >>=20 >> Anything would be better than this pointless indirection through libgcc. >> We have accumlated lots of cruft in the crt* objects which serve no >> purpose at all for current binaries, and eventually, we will have to >> clean this up. >>=20 >> I think crtbegin*.o could completely go away if we turn __cxa_finalize >> into a NOP on the glibc side. > > I think if __dso_handle was exported as a global symbol it could > simplify the indirection by a bit. I don't see how this is possible. It would trigger interposition, and we need a unique address for each DSO, to identify it. Now the __dso_handle interface is fairly broken and probably predates the tight integration of libc and the dynamic linker. We could easily cache something that allows to quickly locate the actual linkmap in a variable link __dso_handle, but we do not. > One idea is to change the order atexit handlers are handled slightly: > > - atexit handlers are not registered through __cxa_atexit, a new > symbol __atexit adds a new entry as ef_at (similar to my proposal). > > - __cxa_finalize is changed to handle ef_at similar to ef_cxa by > calling the function pointer and setting it as ef_free. dlclose > will issue atexit as expected. > > - __run_exit_handlers, used on both exit and quick_exit, will issue > atexit handler (ef_at) first and then handle on_exit (ef_on), and > __cxa_atexit (ef_cxa). This keeps the expected order or atexit > handlers, however the order regarding ef_cxa will change. > > - It will required some changes internally to handle atexit and > __cxa_atexit differently regarding lock acquisition since before > ef_cxa handler we can't get newly added ef_at ones. I think you also need to do something on dlclose to deallocate atexit handlers that have run, to avoid a memory leak. Setting them to ef_free is not sufficient. Thanks, Florian