Message ID | cover.1639515239.git.fweimer@redhat.com |
---|---|
Headers |
Return-Path: <libc-alpha-bounces+patchwork=sourceware.org@sourceware.org> X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id A856F385841C for <patchwork@sourceware.org>; Tue, 14 Dec 2021 21:02:25 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org A856F385841C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1639515745; bh=1/AJwMMulVCe4QTD0nuuGrrFeydDruleFcOLf9puR2s=; h=To:Subject:Date:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:From; b=eg27eB4PmJUvAsvipOu9ltHUtGi8hDnaEpbjaxjzq3S+INBTfzWNRECzpiZi6/19f APd/MZ19qJvuNND5fRs3tKiw43PvNaX6Uz7Mqwp+GTHNllRagefpx3O1JihYjnO+W8 4jJMo9vU0Gu6mCL14oh9bAxoHDQzNok50y1bhmdQ= X-Original-To: libc-alpha@sourceware.org Delivered-To: libc-alpha@sourceware.org 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 7DBBE3858D28 for <libc-alpha@sourceware.org>; Tue, 14 Dec 2021 21:02:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7DBBE3858D28 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-474-GGv4emjPNra3rrHC9zrjjg-1; Tue, 14 Dec 2021 16:02:01 -0500 X-MC-Unique: GGv4emjPNra3rrHC9zrjjg-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 140AF5120 for <libc-alpha@sourceware.org>; Tue, 14 Dec 2021 21:02:01 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.2.17.223]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 6D992A0F87 for <libc-alpha@sourceware.org>; Tue, 14 Dec 2021 21:02:00 +0000 (UTC) To: libc-alpha@sourceware.org Subject: [PATCH 0/2] Predictable ELF destructor ordering X-From-Line: dc8b3c5769667256401da0a949f91194b1e0653f Mon Sep 17 00:00:00 2001 Message-Id: <cover.1639515239.git.fweimer@redhat.com> Date: Tue, 14 Dec 2021 22:01:57 +0100 User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 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 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_LOW, RCVD_IN_MSPIKE_H2, 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 <libc-alpha.sourceware.org> List-Unsubscribe: <https://sourceware.org/mailman/options/libc-alpha>, <mailto:libc-alpha-request@sourceware.org?subject=unsubscribe> List-Archive: <https://sourceware.org/pipermail/libc-alpha/> List-Post: <mailto:libc-alpha@sourceware.org> List-Help: <mailto:libc-alpha-request@sourceware.org?subject=help> List-Subscribe: <https://sourceware.org/mailman/listinfo/libc-alpha>, <mailto:libc-alpha-request@sourceware.org?subject=subscribe> From: Florian Weimer via Libc-alpha <libc-alpha@sourceware.org> Reply-To: Florian Weimer <fweimer@redhat.com> Errors-To: libc-alpha-bounces+patchwork=sourceware.org@sourceware.org Sender: "Libc-alpha" <libc-alpha-bounces+patchwork=sourceware.org@sourceware.org> |
Series |
Predictable ELF destructor ordering
|
|
Message
Florian Weimer
Dec. 14, 2021, 9:01 p.m. UTC
These patches remove the dependency sorting from dlclose and process shutdown, so that destructor order is the reverse of constructor order in more cases (always if the process does not call dlclose). Tested on i686-linux-gnu and x86_64-linux-gnu. I would like to include this in glibc 2.35 if possible, among the other dependency sorting changes. I believe this fixes bugs 15311 and 15903. Florian Weimer (2): elf: Do not rely on relocation dependencies for destructor sorting elf: Always call destructors in reverse constructor order elf/dl-close.c | 130 +++++++++++++--------- elf/dl-deps.c | 3 +- elf/dl-fini.c | 216 ++++++++++++++----------------------- elf/dl-init.c | 14 +++ elf/dl-sort-maps.c | 105 ++---------------- elf/dso-sort-tests-1.def | 6 +- include/link.h | 4 + sysdeps/generic/ldsodefs.h | 6 +- 8 files changed, 194 insertions(+), 290 deletions(-) base-commit: 0884724a95b60452ad483dbe086d237d02ba624d
Comments
On Tue, Dec 14, 2021 at 10:01:57PM +0100, Florian Weimer via Libc-alpha wrote: > These patches remove the dependency sorting from dlclose and process > shutdown, so that destructor order is the reverse of constructor order > in more cases (always if the process does not call dlclose). > > Tested on i686-linux-gnu and x86_64-linux-gnu. > > I would like to include this in glibc 2.35 if possible, among the other > dependency sorting changes. > > I believe this fixes bugs 15311 and 15903. > > Florian Weimer (2): > elf: Do not rely on relocation dependencies for destructor sorting > elf: Always call destructors in reverse constructor order > > elf/dl-close.c | 130 +++++++++++++--------- > elf/dl-deps.c | 3 +- > elf/dl-fini.c | 216 ++++++++++++++----------------------- > elf/dl-init.c | 14 +++ > elf/dl-sort-maps.c | 105 ++---------------- > elf/dso-sort-tests-1.def | 6 +- > include/link.h | 4 + > sysdeps/generic/ldsodefs.h | 6 +- > 8 files changed, 194 insertions(+), 290 deletions(-) Hi Florian, This does seem to fix an issue for me in the OpenRISC port. Discussed [1] in the OpenRISC port thread. It fixes: elf/tst-bz15311 Failure details in tst-bz15311.out (fixed with these patches) [2]. However this also seems to break: elf/tst-glibc-hwcaps-prepend-cache I am not able to get much detail from the failure other than a SIGDEGV in fork, I then bisected it to these patches I have on my branch to fix elf/tst-bz15311. Let me know if I can help. -Stafford [1] https://sourceware.org/pipermail/libc-alpha/2021-December/134184.html [2] https://gist.github.com/5a5dacaeef1eac1f2f5d89701d14c0ad
* Stafford Horne: > On Tue, Dec 14, 2021 at 10:01:57PM +0100, Florian Weimer via Libc-alpha wrote: >> These patches remove the dependency sorting from dlclose and process >> shutdown, so that destructor order is the reverse of constructor order >> in more cases (always if the process does not call dlclose). >> >> Tested on i686-linux-gnu and x86_64-linux-gnu. >> >> I would like to include this in glibc 2.35 if possible, among the other >> dependency sorting changes. >> >> I believe this fixes bugs 15311 and 15903. >> >> Florian Weimer (2): >> elf: Do not rely on relocation dependencies for destructor sorting >> elf: Always call destructors in reverse constructor order >> >> elf/dl-close.c | 130 +++++++++++++--------- >> elf/dl-deps.c | 3 +- >> elf/dl-fini.c | 216 ++++++++++++++----------------------- >> elf/dl-init.c | 14 +++ >> elf/dl-sort-maps.c | 105 ++---------------- >> elf/dso-sort-tests-1.def | 6 +- >> include/link.h | 4 + >> sysdeps/generic/ldsodefs.h | 6 +- >> 8 files changed, 194 insertions(+), 290 deletions(-) > > Hi Florian, > > This does seem to fix an issue for me in the OpenRISC port. Discussed [1] in > the OpenRISC port thread. It fixes: > > elf/tst-bz15311 > > Failure details in tst-bz15311.out (fixed with these patches) [2]. > > However this also seems to break: > > elf/tst-glibc-hwcaps-prepend-cache > > I am not able to get much detail from the failure other than a SIGDEGV > in fork, I then bisected it to these patches I have on my branch to > fix elf/tst-bz15311. Let me know if I can help. What are the DT_NEEDED entries on the shared objects, and the run-time relocations? I suspect you must have some unexpected dependency which confuses the old sorting code. The elf/tst-glibc-hwcaps-prepend-cache failure is very suspicious, it really should not happen. Would you be able to debug it further? Thanks, Florian
On Mon, Dec 20, 2021, 10:20 PM Florian Weimer <fweimer@redhat.com> wrote: > * Stafford Horne: > > > On Tue, Dec 14, 2021 at 10:01:57PM +0100, Florian Weimer via Libc-alpha > wrote: > >> These patches remove the dependency sorting from dlclose and process > >> shutdown, so that destructor order is the reverse of constructor order > >> in more cases (always if the process does not call dlclose). > >> > >> Tested on i686-linux-gnu and x86_64-linux-gnu. > >> > >> I would like to include this in glibc 2.35 if possible, among the other > >> dependency sorting changes. > >> > >> I believe this fixes bugs 15311 and 15903. > >> > >> Florian Weimer (2): > >> elf: Do not rely on relocation dependencies for destructor sorting > >> elf: Always call destructors in reverse constructor order > >> > >> elf/dl-close.c | 130 +++++++++++++--------- > >> elf/dl-deps.c | 3 +- > >> elf/dl-fini.c | 216 ++++++++++++++----------------------- > >> elf/dl-init.c | 14 +++ > >> elf/dl-sort-maps.c | 105 ++---------------- > >> elf/dso-sort-tests-1.def | 6 +- > >> include/link.h | 4 + > >> sysdeps/generic/ldsodefs.h | 6 +- > >> 8 files changed, 194 insertions(+), 290 deletions(-) > > > > Hi Florian, > > > > This does seem to fix an issue for me in the OpenRISC port. Discussed > [1] in > > the OpenRISC port thread. It fixes: > > > > elf/tst-bz15311 > > > > Failure details in tst-bz15311.out (fixed with these patches) [2]. > > > > However this also seems to break: > > > > elf/tst-glibc-hwcaps-prepend-cache > > > > I am not able to get much detail from the failure other than a SIGDEGV > > in fork, I then bisected it to these patches I have on my branch to > > fix elf/tst-bz15311. Let me know if I can help. > > What are the DT_NEEDED entries on the shared objects, and the run-time > relocations? I suspect you must have some unexpected dependency which > confuses the old sorting code. > > The elf/tst-glibc-hwcaps-prepend-cache failure is very suspicious, it > really should not happen. Would you be able to debug it further? > Hi Florian After further debugging I found i cannot reproduce this after a full toolchain rebuild. I will leave this to a bad environment setup on my side. Sorry for the noise -Stafford