Message ID | 20230307102935.2882450-1-arsen@gentoo.org |
---|---|
State | New |
Headers | show |
Series | [v3,1/2] elf,nptl: Add -z lazy to some more tests | expand |
* Arsen Arsenović: > Some toolchains, such as that used on Gentoo Hardened, set -z now out of > the box. This trips up a couple of tests. > --- > Hi, > > This is re-roll of the following patch series: > https://inbox.sourceware.org/libc-alpha/20230307003222.2810662-1-arsen@aarsen.me/ > https://inbox.sourceware.org/libc-alpha/20230302112519.914641-1-arsen@gentoo.org/ > > Changes from v2: > - Split off the +$(objpfx)resolvfail.out: $(objpfx)testobj1.so change > into its own commit. > > Changes from v1: > - Dropped -z norelro. This turned out to be unnecessary after > Adhemervals removal of --with-default-link and linker script > machinery: > https://patchwork.sourceware.org/project/glibc/list/?series=17843 > See: https://inbox.sourceware.org/libc-alpha/86fsakz5mr.fsf@gentoo.org > for an explanation of what caused the need for norelro. That fix was > misguided, due to a previous error on my part, too. > I applied this patch on top of that patchset and it would appear to > resolve all related failures. > The above is not applied to Git yet, but should be before this patch > is. > > elf/Makefile | 19 +++++++++++++++++++ > 1 file changed, 19 insertions(+) > elf/Makefile | 19 +++++++++++++++++++ > 1 file changed, 19 insertions(+) The patches look okay to me, but would you please resend them with Signed-off-by: (to mark this as a contribution under DCO)? I had the FSF records checked, and they don't have a glibc copyright assignment from you, as far as we can tell. Sorry for the hassle! Thanks, Florian
Florian Weimer <fweimer@redhat.com> writes: > * Arsen Arsenović: > >> Some toolchains, such as that used on Gentoo Hardened, set -z now out of >> the box. This trips up a couple of tests. >> --- >> Hi, >> >> This is re-roll of the following patch series: >> https://inbox.sourceware.org/libc-alpha/20230307003222.2810662-1-arsen@aarsen.me/ >> https://inbox.sourceware.org/libc-alpha/20230302112519.914641-1-arsen@gentoo.org/ >> >> Changes from v2: >> - Split off the +$(objpfx)resolvfail.out: $(objpfx)testobj1.so change >> into its own commit. >> >> Changes from v1: >> - Dropped -z norelro. This turned out to be unnecessary after >> Adhemervals removal of --with-default-link and linker script >> machinery: >> https://patchwork.sourceware.org/project/glibc/list/?series=17843 >> See: https://inbox.sourceware.org/libc-alpha/86fsakz5mr.fsf@gentoo.org >> for an explanation of what caused the need for norelro. That fix was >> misguided, due to a previous error on my part, too. >> I applied this patch on top of that patchset and it would appear to >> resolve all related failures. >> The above is not applied to Git yet, but should be before this patch >> is. >> >> elf/Makefile | 19 +++++++++++++++++++ >> 1 file changed, 19 insertions(+) >> elf/Makefile | 19 +++++++++++++++++++ >> 1 file changed, 19 insertions(+) > > The patches look okay to me, but would you please resend them with > Signed-off-by: (to mark this as a contribution under DCO)? I had the > FSF records checked, and they don't have a glibc copyright assignment > from you, as far as we can tell. Sorry for the hassle! Yes, I never signed the copyright papers for the libc. I intended to undergo that process, which is why I didn't add signoffs initially (since they'd indicate that I don't intend to sign over copyright when I do), so I figured I should wait for advice. How should I proceed? Thanks in advance. PS: I noticed that I forgot to drop `,nptl' from the subject line. The NPTL bits of this patch are gone now. > > Thanks, > Florian
* Arsen Arsenović: > Yes, I never signed the copyright papers for the libc. > > I intended to undergo that process, which is why I didn't add signoffs > initially (since they'd indicate that I don't intend to sign over > copyright when I do), so I figured I should wait for advice. > > How should I proceed? It's up to you. You can try the FSF paperwork process, it should be fully digital nowadays. And we can apply the patch as a regular FSF contribution once the paperwork is complete. Or we can take a DCO contribution from you today. We don't need the assignment paperwork anymore. > PS: I noticed that I forgot to drop `,nptl' from the subject line. The > NPTL bits of this patch are gone now. Ah, okay. Thanks, Florian
Florian Weimer <fweimer@redhat.com> writes: > * Arsen Arsenović: > >> Yes, I never signed the copyright papers for the libc. >> >> I intended to undergo that process, which is why I didn't add signoffs >> initially (since they'd indicate that I don't intend to sign over >> copyright when I do), so I figured I should wait for advice. >> >> How should I proceed? > > It's up to you. You can try the FSF paperwork process, it should be > fully digital nowadays. And we can apply the patch as a regular FSF > contribution once the paperwork is complete. My previous experiences were rather prompt (usually done by the time I'm done with a patchset - not the case here due to the triviality, of course). Is https://git.savannah.gnu.org/cgit/gnulib.git/plain/doc/Copyright/request-assign.future the right form? This is the one I've used for gcc et al, to cover current and future changes of any nature. > Or we can take a DCO contribution from you today. We don't need the > assignment paperwork anymore. > >> PS: I noticed that I forgot to drop `,nptl' from the subject line. The >> NPTL bits of this patch are gone now. > > Ah, okay. > > Thanks, > Florian
* Arsen Arsenović: > Florian Weimer <fweimer@redhat.com> writes: > >> * Arsen Arsenović: >> >>> Yes, I never signed the copyright papers for the libc. >>> >>> I intended to undergo that process, which is why I didn't add signoffs >>> initially (since they'd indicate that I don't intend to sign over >>> copyright when I do), so I figured I should wait for advice. >>> >>> How should I proceed? >> >> It's up to you. You can try the FSF paperwork process, it should be >> fully digital nowadays. And we can apply the patch as a regular FSF >> contribution once the paperwork is complete. > > My previous experiences were rather prompt (usually done by the time I'm > done with a patchset - not the case here due to the triviality, of > course). Is > https://git.savannah.gnu.org/cgit/gnulib.git/plain/doc/Copyright/request-assign.future > the right form? This is the one I've used for gcc et al, to cover > current and future changes of any nature. <https://sourceware.org/glibc/wiki/CopyrightFSF> also links to this form, so I think it's the right one. Thanks, Florian
Florian Weimer <fweimer@redhat.com> writes: > <https://sourceware.org/glibc/wiki/CopyrightFSF> also links to this > form, so I think it's the right one. I sent this form earlier today. Will keep you posted. Thanks, have a lovely night. > Thanks, > Florian
* Arsen Arsenović: > PS: I noticed that I forgot to drop `,nptl' from the subject line. The > NPTL bits of this patch are gone now. I received word that the FSF has completed the paperwork, so I fixed that and pushed your two patches. Thanks, Florian
Florian Weimer <fweimer@redhat.com> writes: > * Arsen Arsenović: > >> PS: I noticed that I forgot to drop `,nptl' from the subject line. The >> NPTL bits of this patch are gone now. > > I received word that the FSF has completed the paperwork, so I fixed > that and pushed your two patches. Lovely, thanks! Have a great day. > Thanks, > Florian
diff --git a/elf/Makefile b/elf/Makefile index dcdfd0af87..b9c77604b5 100644 --- a/elf/Makefile +++ b/elf/Makefile @@ -1176,6 +1176,11 @@ postclean-generated += $(objpfx)/dso-sort-tests-2.generated-makefile \ ifeq (yes,$(have-tunables)) $(eval $(call include_dsosort_tests,dso-sort-tests-1.def)) $(eval $(call include_dsosort_tests,dso-sort-tests-2.def)) + +# BZ15311 is intentionally underlinked. +LDFLAGS-tst-bz15311-b.so += -Wl,-z,lazy +LDFLAGS-tst-bz15311-c.so += -Wl,-z,lazy +LDFLAGS-tst-bz15311-d.so += -Wl,-z,lazy endif check-abi: $(objpfx)check-abi-ld.out \ @@ -1498,6 +1503,20 @@ LDFLAGS-tst-initorderb2.so = -Wl,--no-as-needed LDFLAGS-tst-tlsmod5.so = -nostdlib -Wl,--no-as-needed LDFLAGS-tst-tlsmod6.so = -nostdlib -Wl,--no-as-needed +# The following tests are underlinked, and rely on late loading. On toolchains +# that set -z now by default, this leads to failures to load or fix up the +# executables being tested. +LDFLAGS-circlemod2.so = -Wl,-z,lazy +LDFLAGS-tst-tls20mod-bad.so = -Wl,-z,lazy +LDFLAGS-reldep6mod1.so += -Wl,-z,lazy +LDFLAGS-constload2.so = -Wl,-z,lazy +LDFLAGS-constload3.so = -Wl,-z,lazy +LDFLAGS-dblloadmod3.so = -Wl,-z,lazy +LDFLAGS-ifuncmod6.so = -Wl,-z,lazy +LDFLAGS-ltglobmod2.so = -Wl,-z,lazy +LDFLAGS-testobj1.so = -Wl,-z,lazy +LDFLAGS-testobj6.so = -Wl,-z,lazy + testobj1.so-no-z-defs = yes testobj3.so-no-z-defs = yes testobj4.so-no-z-defs = yes