Message ID | cover.1621347402.git.fweimer@redhat.com |
---|---|
Headers | show |
Series | nptl: Complete libpthread removal | expand |
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.