Message ID | cover.1621347402.git.fweimer@redhat.com |
---|---|
Headers |
Return-Path: <libc-alpha-bounces@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 CCC4A3844023; Tue, 18 May 2021 14:25:04 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org CCC4A3844023 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1621347904; bh=vkNjEjEi6OQzPiMjT6dXV7lGkMJKgx1LNWD5Rtv3MdA=; h=To:Subject:Date:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:From; b=LY+TnfdfFXKKL/iMYHQxRWHDPgxLE5IGMAdFNk8wJCp3tbr7HMExqifmA4UUSOW4L Xu1YktuobriBwXWatAfsARlprcquIO+ULMECpQzdzKuCE/7Y1Hjxmtlkvu1yYYWoQZ YFjb32Gp4PRWEy2/RjpUcATX+hcLlhlYjTTuDuTI= 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 ESMTP id 648D63853831 for <libc-alpha@sourceware.org>; Tue, 18 May 2021 14:25:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 648D63853831 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-504-pKUK8cMRP3yE_5Ki1tscCA-1; Tue, 18 May 2021 10:24:58 -0400 X-MC-Unique: pKUK8cMRP3yE_5Ki1tscCA-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 81C8B10074CE for <libc-alpha@sourceware.org>; Tue, 18 May 2021 14:24:47 +0000 (UTC) Received: from oldenburg.str.redhat.com (ovpn-112-137.ams2.redhat.com [10.36.112.137]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 0AB5A105C817 for <libc-alpha@sourceware.org>; Tue, 18 May 2021 14:24:45 +0000 (UTC) To: libc-alpha@sourceware.org Subject: [PATCH 00/10] nptl: Complete libpthread removal X-From-Line: 82b3610549a7413177855880b89798745bf3931c Mon Sep 17 00:00:00 2001 Message-Id: <cover.1621347402.git.fweimer@redhat.com> Date: Tue, 18 May 2021 16:24:43 +0200 User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-6.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_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) 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@sourceware.org Sender: "Libc-alpha" <libc-alpha-bounces@sourceware.org> |
Series |
nptl: Complete libpthread removal
|
|
Message
Florian Weimer
May 18, 2021, 2:24 p.m. UTC
This series finally removes libpthread for Linux/NPTL. The first patch supersedes “nptl: Introduce __nptl_deferred_init”. I think doing cancel initialization on pthread_cancel is not an improvement because we would have to use another flag to avoid the extra system calls. The next two patches were posted previous; Adhemerval already reviewed them. One test had to be adjusted because it use libpthread as the canonical NODELETE object. We need to provide libpthread.so.0 stub object for use with memusagestat, otherwise a system libpthread.so.0 might leak into the link. Not loading libpthread.so.0 is hacked directly into the dynamic loader. For some reason, pthread debugging still works even without libpthread loaded. I didn't have to add the fake libpthread.so.0 link map to trigger loading of libthread_db in GDB. Testing with systemtap and dyninst will happen once we get this into Fedora rawhide. I have built and tested various intermediate steps (i686-linux-gnu, x86_64-linux-gnu, build-many-glibcs.py). In particular, the placeholder symbols in the code-less libpthread match the abilist files. Thanks, Florian Florian Weimer (10): nptl: Perform signal initialization upon pthread_create nptl: Eliminate the __static_tls_size, __static_tls_align_m1 variables nptl: Move semi-public __pthread_get_minstack symbol into libc elf: Use custom NODELETE DSO for tst-dlopenfail, tst-dlopenfail-2 nptl: Move pthread_create, thrd_create into libc nptl: Remove unused __libc_pthread_init function nptl: Remove remaining code from libpthread elf: Do not load libpthread for PTHREAD_IN_LIBC elf: Add facility to create stub DSOs in elf/stub-dsos nptl: Stop building libpthread Makeconfig | 13 +- elf/Makefile | 29 ++- elf/dl-load.c | 19 +- elf/dl-tls.c | 5 +- elf/dl-version.c | 9 + nptl/version.c => elf/lib-stub.S | 31 +-- elf/tst-dlopenfail-2.c | 5 +- elf/tst-dlopenfail.c | 44 ++--- elf/tst-dlopenfailmod2.c | 6 +- .../tst-dlopenfailnodelmod.c | 24 +-- include/libc-internal.h | 6 +- nptl/Makefile | 77 +------- nptl/Versions | 33 ++-- nptl/allocatestack.c | 25 +-- nptl/libpthread-compat.c | 112 ----------- nptl/libpthread-stub.S | 1 + nptl/nptl-init.c | 180 ------------------ nptl/nptl-stack.c | 17 ++ nptl/nptl-stack.h | 11 +- nptl/pt-crti.S | 50 ----- nptl/pt-interp.c | 1 - nptl/pthreadP.h | 18 +- nptl/pthread_cancel.c | 88 ++++++++- nptl/pthread_create.c | 60 +++++- nptl/pthread_getattr_default_np.c | 6 +- nptl_db/Makefile | 2 +- nptl_db/structs.def | 10 +- sysdeps/arm/nptl-aeabi_unwind_cpp_pr1.c | 1 - sysdeps/arm/nptl/Makefile | 3 - sysdeps/ia64/nptl/Makefile | 5 - sysdeps/mips/Makefile | 5 - sysdeps/mips/nptl/Makefile | 5 - sysdeps/mips/nptl/nptl-sysdep.S | 2 - sysdeps/nptl/Makeconfig | 7 +- sysdeps/nptl/Makefile | 4 - sysdeps/nptl/pthread_early_init.h | 28 +++ sysdeps/nptl/thrd_create.c | 2 - sysdeps/pthread/Makefile | 3 +- sysdeps/pthread/thrd_create.c | 11 +- sysdeps/riscv/nptl/Makefile | 5 - sysdeps/riscv/nptl/nptl-sysdep.S | 2 - sysdeps/s390/nptl/Makefile | 5 - sysdeps/sparc/Makefile | 4 - sysdeps/sparc/nptl/Makefile | 5 - sysdeps/unix/sysv/linux/aarch64/libc.abilist | 4 + .../sysv/linux/aarch64/libpthread.abilist | 6 - sysdeps/unix/sysv/linux/alpha/Makefile | 6 - sysdeps/unix/sysv/linux/alpha/libc.abilist | 5 + .../unix/sysv/linux/alpha/libpthread.abilist | 18 -- sysdeps/unix/sysv/linux/arc/libc.abilist | 4 + .../unix/sysv/linux/arc/libpthread.abilist | 3 - sysdeps/unix/sysv/linux/arm/Makefile | 5 - sysdeps/unix/sysv/linux/arm/be/libc.abilist | 4 + .../unix/sysv/linux/arm/be/libpthread.abilist | 9 - sysdeps/unix/sysv/linux/arm/le/libc.abilist | 4 + .../unix/sysv/linux/arm/le/libpthread.abilist | 9 - sysdeps/unix/sysv/linux/csky/libc.abilist | 4 + .../unix/sysv/linux/csky/libpthread.abilist | 5 - sysdeps/unix/sysv/linux/hppa/libc.abilist | 4 + .../unix/sysv/linux/hppa/libpthread.abilist | 14 -- sysdeps/unix/sysv/linux/i386/Makefile | 11 -- sysdeps/unix/sysv/linux/i386/libc.abilist | 5 + .../unix/sysv/linux/i386/libpthread.abilist | 18 -- sysdeps/unix/sysv/linux/ia64/libc.abilist | 4 + .../unix/sysv/linux/ia64/libpthread.abilist | 14 -- .../sysv/linux/m68k/coldfire/libc.abilist | 4 + .../linux/m68k/coldfire/libpthread.abilist | 9 - .../unix/sysv/linux/m68k/m680x0/libc.abilist | 5 + .../sysv/linux/m68k/m680x0/libpthread.abilist | 18 -- sysdeps/unix/sysv/linux/microblaze/Makefile | 6 - .../sysv/linux/microblaze/be/libc.abilist | 4 + .../linux/microblaze/be/libpthread.abilist | 5 - .../sysv/linux/microblaze/le/libc.abilist | 4 + .../linux/microblaze/le/libpthread.abilist | 5 - .../sysv/linux/mips/mips32/fpu/libc.abilist | 5 + .../sysv/linux/mips/mips32/libpthread.abilist | 15 -- .../sysv/linux/mips/mips32/nofpu/libc.abilist | 5 + .../sysv/linux/mips/mips64/libpthread.abilist | 15 -- .../sysv/linux/mips/mips64/n32/libc.abilist | 5 + .../sysv/linux/mips/mips64/n64/libc.abilist | 5 + sysdeps/unix/sysv/linux/nios2/libc.abilist | 4 + .../unix/sysv/linux/nios2/libpthread.abilist | 5 - sysdeps/unix/sysv/linux/powerpc/Makefile | 5 - .../linux/powerpc/powerpc32/fpu/libc.abilist | 5 + .../powerpc/powerpc32/libpthread.abilist | 19 -- .../powerpc/powerpc32/nofpu/libc.abilist | 5 + .../linux/powerpc/powerpc64/be/libc.abilist | 4 + .../powerpc/powerpc64/be/libpthread.abilist | 13 -- .../linux/powerpc/powerpc64/le/libc.abilist | 4 + .../powerpc/powerpc64/le/libpthread.abilist | 6 - .../unix/sysv/linux/riscv/rv32/libc.abilist | 4 + .../sysv/linux/riscv/rv32/libpthread.abilist | 3 - .../unix/sysv/linux/riscv/rv64/libc.abilist | 4 + .../sysv/linux/riscv/rv64/libpthread.abilist | 5 - .../unix/sysv/linux/s390/s390-32/libc.abilist | 5 + .../linux/s390/s390-32/libpthread.abilist | 19 -- .../unix/sysv/linux/s390/s390-64/libc.abilist | 4 + .../linux/s390/s390-64/libpthread.abilist | 15 -- sysdeps/unix/sysv/linux/sh/be/libc.abilist | 4 + .../unix/sysv/linux/sh/be/libpthread.abilist | 14 -- sysdeps/unix/sysv/linux/sh/le/libc.abilist | 4 + .../unix/sysv/linux/sh/le/libpthread.abilist | 14 -- sysdeps/unix/sysv/linux/sparc/Makefile | 6 - .../sysv/linux/sparc/sparc32/libc.abilist | 5 + .../linux/sparc/sparc32/libpthread.abilist | 18 -- .../sysv/linux/sparc/sparc64/libc.abilist | 4 + .../linux/sparc/sparc64/libpthread.abilist | 14 -- .../unix/sysv/linux/x86_64/64/libc.abilist | 4 + .../sysv/linux/x86_64/64/libpthread.abilist | 13 -- .../unix/sysv/linux/x86_64/x32/libc.abilist | 4 + .../sysv/linux/x86_64/x32/libpthread.abilist | 6 - 111 files changed, 510 insertions(+), 974 deletions(-) rename nptl/version.c => elf/lib-stub.S (51%) rename nptl/libc_pthread_init.c => elf/tst-dlopenfailnodelmod.c (61%) delete mode 100644 nptl/libpthread-compat.c create mode 100644 nptl/libpthread-stub.S delete mode 100644 nptl/nptl-init.c delete mode 100644 nptl/pt-crti.S delete mode 100644 nptl/pt-interp.c delete mode 100644 sysdeps/arm/nptl-aeabi_unwind_cpp_pr1.c delete mode 100644 sysdeps/mips/nptl/nptl-sysdep.S delete mode 100644 sysdeps/nptl/thrd_create.c delete mode 100644 sysdeps/riscv/nptl/nptl-sysdep.S delete mode 100644 sysdeps/unix/sysv/linux/aarch64/libpthread.abilist delete mode 100644 sysdeps/unix/sysv/linux/alpha/libpthread.abilist delete mode 100644 sysdeps/unix/sysv/linux/arc/libpthread.abilist delete mode 100644 sysdeps/unix/sysv/linux/arm/be/libpthread.abilist delete mode 100644 sysdeps/unix/sysv/linux/arm/le/libpthread.abilist delete mode 100644 sysdeps/unix/sysv/linux/csky/libpthread.abilist delete mode 100644 sysdeps/unix/sysv/linux/hppa/libpthread.abilist delete mode 100644 sysdeps/unix/sysv/linux/i386/libpthread.abilist delete mode 100644 sysdeps/unix/sysv/linux/ia64/libpthread.abilist delete mode 100644 sysdeps/unix/sysv/linux/m68k/coldfire/libpthread.abilist delete mode 100644 sysdeps/unix/sysv/linux/m68k/m680x0/libpthread.abilist delete mode 100644 sysdeps/unix/sysv/linux/microblaze/be/libpthread.abilist delete mode 100644 sysdeps/unix/sysv/linux/microblaze/le/libpthread.abilist delete mode 100644 sysdeps/unix/sysv/linux/mips/mips32/libpthread.abilist delete mode 100644 sysdeps/unix/sysv/linux/mips/mips64/libpthread.abilist delete mode 100644 sysdeps/unix/sysv/linux/nios2/libpthread.abilist delete mode 100644 sysdeps/unix/sysv/linux/powerpc/powerpc32/libpthread.abilist delete mode 100644 sysdeps/unix/sysv/linux/powerpc/powerpc64/be/libpthread.abilist delete mode 100644 sysdeps/unix/sysv/linux/powerpc/powerpc64/le/libpthread.abilist delete mode 100644 sysdeps/unix/sysv/linux/riscv/rv32/libpthread.abilist delete mode 100644 sysdeps/unix/sysv/linux/riscv/rv64/libpthread.abilist delete mode 100644 sysdeps/unix/sysv/linux/s390/s390-32/libpthread.abilist delete mode 100644 sysdeps/unix/sysv/linux/s390/s390-64/libpthread.abilist delete mode 100644 sysdeps/unix/sysv/linux/sh/be/libpthread.abilist delete mode 100644 sysdeps/unix/sysv/linux/sh/le/libpthread.abilist delete mode 100644 sysdeps/unix/sysv/linux/sparc/sparc32/libpthread.abilist delete mode 100644 sysdeps/unix/sysv/linux/sparc/sparc64/libpthread.abilist delete mode 100644 sysdeps/unix/sysv/linux/x86_64/64/libpthread.abilist delete mode 100644 sysdeps/unix/sysv/linux/x86_64/x32/libpthread.abilist
Comments
On Mai 18 2021, Florian Weimer via Libc-alpha wrote: > We need to provide libpthread.so.0 stub object for use with > memusagestat, otherwise a system libpthread.so.0 might leak into the > link. Not loading libpthread.so.0 is hacked directly into the dynamic > loader. What would happen if the lpthread stub would be loaded? Andreas.
* Andreas Schwab: > On Mai 18 2021, Florian Weimer via Libc-alpha wrote: > >> We need to provide libpthread.so.0 stub object for use with >> memusagestat, otherwise a system libpthread.so.0 might leak into the >> link. Not loading libpthread.so.0 is hacked directly into the dynamic >> loader. > > What would happen if the lpthread stub would be loaded? I made sure that it crashes: /* Produce an invalid init function, so that loading the stub crashes. */ .section .init_array,"a",%init_array .dc.a 4096 I tried adding an undefined symbol, but that make the stub unusable as a stub, too. Neither binutils nor glibc currently support DF_1_STUB, so that's not an option. Thanks, Florian
On Mai 18 2021, Florian Weimer wrote: > * Andreas Schwab: > >> On Mai 18 2021, Florian Weimer via Libc-alpha wrote: >> >>> We need to provide libpthread.so.0 stub object for use with >>> memusagestat, otherwise a system libpthread.so.0 might leak into the >>> link. Not loading libpthread.so.0 is hacked directly into the dynamic >>> loader. >> >> What would happen if the lpthread stub would be loaded? > > I made sure that it crashes: What's wrong with providing an empty libpthread.so.0, and a no-op libpthread.{so,a}? Andreas.
* Andreas Schwab: > On Mai 18 2021, Florian Weimer wrote: > >> * Andreas Schwab: >> >>> On Mai 18 2021, Florian Weimer via Libc-alpha wrote: >>> >>>> We need to provide libpthread.so.0 stub object for use with >>>> memusagestat, otherwise a system libpthread.so.0 might leak into the >>>> link. Not loading libpthread.so.0 is hacked directly into the dynamic >>>> loader. >>> >>> What would happen if the lpthread stub would be loaded? >> >> I made sure that it crashes: > > What's wrong with providing an empty libpthread.so.0, and a no-op > libpthread.{so,a}? I'm already adding a no-op libpthread.a, so that -lpthread keeps working. As far as I can tell, a libpthread.so.0 is not needed because it's not an error for ld if it is missing despite a DT_NEEDED reference. (The stub is not installed, it's only needed because non-cross builds pick up libpng et al. from the system environment.) Thanks, Florian
On Mai 18 2021, Florian Weimer wrote: > I'm already adding a no-op libpthread.a, so that -lpthread keeps > working. As far as I can tell, a libpthread.so.0 is not needed because > it's not an error for ld if it is missing despite a DT_NEEDED reference. Though you will get an annoying warning. Andreas.
* Andreas Schwab: > On Mai 18 2021, Florian Weimer wrote: > >> I'm already adding a no-op libpthread.a, so that -lpthread keeps >> working. As far as I can tell, a libpthread.so.0 is not needed because >> it's not an error for ld if it is missing despite a DT_NEEDED reference. > > Though you will get an annoying warning. I don't think we can do anything about that. The libpthread.so linker script won't suppress it because it's not loaded implicitly, and as soon we load libpthread.so.0 explicitly during the link, we also end up with a DT_NEEDED reference, which I don't think we want. Thanks, Florian
On Mai 18 2021, Florian Weimer wrote: > I don't think we can do anything about that. The libpthread.so linker > script won't suppress it because it's not loaded implicitly, and as soon > we load libpthread.so.0 explicitly during the link, we also end up with > a DT_NEEDED reference, which I don't think we want. I don't think that would be such a bad thing. It will vanish over time when libraries are relinked. Andreas.
The 05/18/2021 16:24, Florian Weimer via Libc-alpha wrote:
> This series finally removes libpthread for Linux/NPTL.
sorry i don't know when this started but in libc.a
now i see
cnd_wait.o:
0000000000000000 T __cnd_wait
0000000000000000 W cnd_wait
U __pthread_cond_wait
and __pthread_cond_wait is not defined anywhere.
(only a 3 _ prefix version)
(in cnd_wait.os i see
U __GI___pthread_cond_wait
which is a hidden symbol in libc.so now)
so now static linking code with cnd_wait fails.
* Szabolcs Nagy: > The 05/18/2021 16:24, Florian Weimer via Libc-alpha wrote: >> This series finally removes libpthread for Linux/NPTL. > > sorry i don't know when this started but in libc.a > now i see > > cnd_wait.o: > 0000000000000000 T __cnd_wait > 0000000000000000 W cnd_wait > U __pthread_cond_wait > > and __pthread_cond_wait is not defined anywhere. > (only a 3 _ prefix version) > > (in cnd_wait.os i see > U __GI___pthread_cond_wait > which is a hidden symbol in libc.so now) > > so now static linking code with cnd_wait fails. Ugh, I thought the linknamespace tests would cover that. This is a generic issue related to how libc_hidden_ver is defined: It does not create an alias as one might expect for the static libc, but actually expands to nothing. I hacked around this with an explicit strong_alias in some places, but it looks like I missed a few cases. Should we try to change the definition of libc_hidden_ver, or add more strong_alias directives? Thanks, Florian
The 05/19/2021 14:35, Florian Weimer wrote: > * Szabolcs Nagy: > > The 05/18/2021 16:24, Florian Weimer via Libc-alpha wrote: > >> This series finally removes libpthread for Linux/NPTL. > > > > sorry i don't know when this started but in libc.a > > now i see > > > > cnd_wait.o: > > 0000000000000000 T __cnd_wait > > 0000000000000000 W cnd_wait > > U __pthread_cond_wait > > > > and __pthread_cond_wait is not defined anywhere. > > (only a 3 _ prefix version) > > > > (in cnd_wait.os i see > > U __GI___pthread_cond_wait > > which is a hidden symbol in libc.so now) > > > > so now static linking code with cnd_wait fails. > > Ugh, I thought the linknamespace tests would cover that. > > This is a generic issue related to how libc_hidden_ver is defined: It > does not create an alias as one might expect for the static libc, but > actually expands to nothing. I hacked around this with an explicit > strong_alias in some places, but it looks like I missed a few cases. > > Should we try to change the definition of libc_hidden_ver, or add more > strong_alias directives? there are quite a few libc_hidden_ver uses and i assume now exists many some_alias (foo, bar) libc_hidden_ver (foo, bar) even in target specific code, which has to be changed and tested if libc_hidden_ver is changed. but if we always want libc_hidden_ver to create an alias for static linking then it would be nice to fix at some point.
* Andreas Schwab: > On Mai 18 2021, Florian Weimer wrote: > >> I don't think we can do anything about that. The libpthread.so linker >> script won't suppress it because it's not loaded implicitly, and as soon >> we load libpthread.so.0 explicitly during the link, we also end up with >> a DT_NEEDED reference, which I don't think we want. > > I don't think that would be such a bad thing. It will vanish over time > when libraries are relinked. Coming back to this, should we stop loading libpthread at all? That is, keep libpthread.so.0 around indefinitely (with the placeholder symbols and symbol versions), and just wait until more and more binaries are linked with the empty libpthread.a and no longer have a DT_NEEDED dependency on libpthread.so.0? Thanks, Florian
On Mai 20 2021, Florian Weimer wrote: > That is, keep libpthread.so.0 around indefinitely (with the > placeholder symbols and symbol versions), and just wait until more and > more binaries are linked with the empty libpthread.a and no longer > have a DT_NEEDED dependency on libpthread.so.0? I don't see any downsides with this approach. Andreas.
* Andreas Schwab: > On Mai 20 2021, Florian Weimer wrote: > >> That is, keep libpthread.so.0 around indefinitely (with the >> placeholder symbols and symbol versions), and just wait until more and >> more binaries are linked with the empty libpthread.a and no longer >> have a DT_NEEDED dependency on libpthread.so.0? > > I don't see any downsides with this approach. There's a slight additional run-time overhead due to the loaded object. But I don't feel strongly about this. Do you think it's okay if we ship libpthread.a only, or should we install a no-op libpthread.so as well? -lpthread will use the .a file for static and dynamic links, so I think that's sufficient. Thanks, Florian
On Mai 20 2021, Florian Weimer wrote: > Do you think it's okay if we ship libpthread.a only, or should we > install a no-op libpthread.so as well? I don't see any need for libpthread.so. Andreas.
On Thu, May 20, 2021 at 8:06 AM Florian Weimer via Libc-alpha <libc-alpha@sourceware.org> wrote: > > * Andreas Schwab: > > > On Mai 20 2021, Florian Weimer wrote: > > > >> That is, keep libpthread.so.0 around indefinitely (with the > >> placeholder symbols and symbol versions), and just wait until more and > >> more binaries are linked with the empty libpthread.a and no longer > >> have a DT_NEEDED dependency on libpthread.so.0? > > > > I don't see any downsides with this approach. > > There's a slight additional run-time overhead due to the loaded object. > But I don't feel strongly about this. > > Do you think it's okay if we ship libpthread.a only, or should we > install a no-op libpthread.so as well? -lpthread will use the .a file > for static and dynamic links, so I think that's sufficient. Can we ship a dummy linker script for libpthread.so to just satisfy -lpthread at link-time?
* H. J. Lu: > On Thu, May 20, 2021 at 8:06 AM Florian Weimer via Libc-alpha > <libc-alpha@sourceware.org> wrote: >> >> * Andreas Schwab: >> >> > On Mai 20 2021, Florian Weimer wrote: >> > >> >> That is, keep libpthread.so.0 around indefinitely (with the >> >> placeholder symbols and symbol versions), and just wait until more and >> >> more binaries are linked with the empty libpthread.a and no longer >> >> have a DT_NEEDED dependency on libpthread.so.0? >> > >> > I don't see any downsides with this approach. >> >> There's a slight additional run-time overhead due to the loaded object. >> But I don't feel strongly about this. >> >> Do you think it's okay if we ship libpthread.a only, or should we >> install a no-op libpthread.so as well? -lpthread will use the .a file >> for static and dynamic links, so I think that's sufficient. > > Can we ship a dummy linker script for libpthread.so to just > satisfy -lpthread at link-time? An empty libpthread.a already does that. Thanks, Florian
On Mai 20 2021, H.J. Lu wrote: > Can we ship a dummy linker script for libpthread.so to just > satisfy -lpthread at link-time? -lpthread will be satisfied by libpthread.a. Andreas.
On Thu, May 20, 2021 at 8:17 AM Andreas Schwab <schwab@linux-m68k.org> wrote: > > On Mai 20 2021, H.J. Lu wrote: > > > Can we ship a dummy linker script for libpthread.so to just > > satisfy -lpthread at link-time? > > -lpthread will be satisfied by libpthread.a. > > Andreas. > What is the problem then? We have to keep libpthread.so.0 for existing binaries. We just don't link against it for new binaries.
* H. J. Lu: > On Thu, May 20, 2021 at 8:17 AM Andreas Schwab <schwab@linux-m68k.org> wrote: >> >> On Mai 20 2021, H.J. Lu wrote: >> >> > Can we ship a dummy linker script for libpthread.so to just >> > satisfy -lpthread at link-time? >> >> -lpthread will be satisfied by libpthread.a. >> >> Andreas. >> > > What is the problem then? We have to keep libpthread.so.0 for existing > binaries. We just don't link against it for new binaries. I was a bit creative and patched the dynamic loader not to load libpthread.so.0 ever (treating it as a reference to libc.so.6). If we don't want to do that (and the consensus is moving in that direction), then we need to keep the DSO around as an actual file. Thanks, Florian
On Thu, May 20, 2021 at 8:39 AM Florian Weimer <fweimer@redhat.com> wrote: > > * H. J. Lu: > > > On Thu, May 20, 2021 at 8:17 AM Andreas Schwab <schwab@linux-m68k.org> wrote: > >> > >> On Mai 20 2021, H.J. Lu wrote: > >> > >> > Can we ship a dummy linker script for libpthread.so to just > >> > satisfy -lpthread at link-time? > >> > >> -lpthread will be satisfied by libpthread.a. > >> > >> Andreas. > >> > > > > What is the problem then? We have to keep libpthread.so.0 for existing > > binaries. We just don't link against it for new binaries. > > I was a bit creative and patched the dynamic loader not to load > libpthread.so.0 ever (treating it as a reference to libc.so.6). If we > don't want to do that (and the consensus is moving in that direction), > then we need to keep the DSO around as an actual file. I think we should keep it as an actual DSO.