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 5AAB63858D37 for ; Tue, 24 Oct 2023 10:57:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5AAB63858D37 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 5AAB63858D37 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1698145079; cv=none; b=Dih/zXD91SKWkCAl67zeVhc5THK5aPQ4OkCgNmkKhakmz4DM1k18j/XDefyhjksNs9qv7vQA6O77y65GCntqkrGEizqPS77Mkuxomy8jG0nNxm073+chZsVqdXtvpYhIZbveIwwj2UTrMsm2ckCL5eKLoro7PS1whwahITMwVU4= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1698145079; c=relaxed/simple; bh=MN4tf+lffrWReFkqWTS2QyUslRKUVrx600sRhPXCJ6E=; h=DKIM-Signature:Message-ID:Date:MIME-Version:To:From:Subject; b=Zo52NM9QW3Eat1lJtbS9DAO+bCODHsD9ALXOSIPsz0DGsTyeL2UcAUyqkhH1uYaPRy/vrV+TNjK39vniIap6kbIDhcdJsEzRYWoHQzgMcGwBUQP/M/kEXeugjdZKmVc8r3zkiw8epc3qt2Sit4STWtS8k46Qy6HOuAeDSlDWCjE= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1698145074; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=qcTBFE8RR3YXv9XkDl9qy0k+QHIlN5TSI5J6Uh52IGk=; b=hjfOOgtCuNy/4DZx/loog3OXypwz70HtyYVPawBxdKJ7rE380gvSvGuQAvA/j/ZEus9G0j lr/Cta9DAhk9BdTFGshgPvVOJqYeKh+XeM8KkgaogEOpNjZVOgHXTwKO85gzEWywAIfHnh 4Gy2KSizm8Dtuoosc9lBDMfpo7Y0Q3M= Received: from mail-qv1-f69.google.com (mail-qv1-f69.google.com [209.85.219.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-608-Q5q-2dg-Op-InRZgTgAPqg-1; Tue, 24 Oct 2023 06:57:41 -0400 X-MC-Unique: Q5q-2dg-Op-InRZgTgAPqg-1 Received: by mail-qv1-f69.google.com with SMTP id 6a1803df08f44-668f04867deso62570056d6.2 for ; Tue, 24 Oct 2023 03:57:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698145060; x=1698749860; h=content-transfer-encoding:organization:subject:from:to :content-language:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=qcTBFE8RR3YXv9XkDl9qy0k+QHIlN5TSI5J6Uh52IGk=; b=TRzkYVU+Mfc68EYgyX2ayTcHkRJEF9LX7+hqvv0g7s0BIsIeLPrVOg7SLMINF6o7V8 JIFvUpGF1c76ea1itNT/IHECHnhf/XLJr6dN4C1+ajEznuOTlaZGk0RnwwIfrCt5zpLH UchJBpXV3w/S2yB5uqkTMSXABWIjUEgoCW9iW9yto+PEHm8r8RXrQTtqQiaGCwsKeztt pI47G3bKRWT8jYWRmH8c8+EqRmDqsj9g0humlp3RIv8yozr0v+EVrftEtQSnfhiQfzC/ EIDUMD0P2kvNedGFbRNDVsvEJdrvyHVmlR20DL636ldexU1tK/F/UtvekgFz1NDCAZRc pGXw== X-Gm-Message-State: AOJu0YyF9D7L7WMsH4L64tMlOiShiXfE+JnQeo1JvIPQvhUZVVOfAvr1 yW2Hf5vIiyC5Np5xNqZ62q0JCteOqOPvE1cOV+xmQJJvWaSHSmsFZvdSS4n7Xdq0+YfB/LuLIIu NGBnRM3nsun/yrLL1geQUV8qdF6Og X-Received: by 2002:ad4:5bce:0:b0:66d:212b:32ab with SMTP id t14-20020ad45bce000000b0066d212b32abmr12675815qvt.47.1698145060442; Tue, 24 Oct 2023 03:57:40 -0700 (PDT) X-Google-Smtp-Source: AGHT+IEcmtZWfUHSn3ndW3a5KBjOqkeoDEkXOdSfZOyJJgNU6BILEc6SOYkPIVNRW0/gJfZmfYswpA== X-Received: by 2002:ad4:5bce:0:b0:66d:212b:32ab with SMTP id t14-20020ad45bce000000b0066d212b32abmr12675809qvt.47.1698145060146; Tue, 24 Oct 2023 03:57:40 -0700 (PDT) Received: from [192.168.0.241] ([198.48.244.52]) by smtp.gmail.com with ESMTPSA id bu7-20020ad455e7000000b0065b1bcd0d33sm3550255qvb.93.2023.10.24.03.57.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 24 Oct 2023 03:57:39 -0700 (PDT) Message-ID: Date: Tue, 24 Oct 2023 06:57:38 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 To: Florian Weimer , libc-alpha From: Carlos O'Donell Subject: Failing fast: Revert "elf: Always call destructors in reverse constructor order (bug 30785)" Organization: Red Hat X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.5 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,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: Florian, I want to thank you for all of the work that you put into the ELF destructor and constructor ordering changes. Even if we have had to revert the change we connected the solution directly to users to learn if it would work. You used our downstream connections to test the changes in a broader context with distribution builds and users in that ecosystem (where we saw some compatibility issues). Along the way there were several bugs to resolve and overall the implementation is better because of the attempt. I specifically want to call out the exceptional "Reason for revert" message which documents exactly why you did the revert. Reason for revert: The commit changes the order of ELF destructor calls too much relative to what applications expect or can handle. In particular, during process exit and _dl_fini, after the revert commit, we no longer call the destructors of the main program first; that only happens after some dlopen'ed objects have been destructed. This robs applications of an opportunity to influence destructor order by calling dlclose explicitly from the main program's ELF destructors. A couple of different approaches involving reverse constructor order were tried, and none of them worked really well. It seems we need to keep the dependency sorting in _dl_fini. There is also an ambiguity regarding nested dlopen calls from ELF constructors: Should those destructors run before or after the object that called dlopen? Commit 6985865bc3ad5b2314 used reverse order of the start of ELF constructor calls for destructors, but arguably using completion of constructors is more correct. However, that alone is not sufficient to address application compatibility issues (it does not change _dl_fini ordering at all). Thank you for attempting to address this issue, and even if we failed and reverted it, the outcome is that we've discovered a lot of other implicit dependencies. I would be keenly interested in seeing a post-mortem blog or presentation or discussion here where you lay out these topics and more details regarding your thoughts on the ordering and the C++ language requirements, on application expectations, and what we might do to simplify what we have today. In my mind these reverts are an excellent example of failing fast: * Attempting a valuable change that has risk. - Simplify ordering. * Connecting directly to our users to see if it works. - Deploy directly into Fedora. * Changing the direction of the work as required within a release. - Revert. - Focus on dlclose() issues. Thank you for working on these difficult problems :-) -- Cheers, Carlos.