Initially filed in https://gcc.gnu.org/PR113991, but it looks like a glibc bug to me. vsftpd for some strange reason does: int ret = clone(NULL, NULL, CLONE_NEWPID | CLONE_NEWIPC | SIGCHLD, NULL); My reading of glibc sources is that this results always in -1/EINVAL without invoking the syscall. Anyway, since https://sourceware.org/git/?p=glibc.git;a=commit;h=e57d8fc97b90127de4ed3e3a9cdf663667580935 if the first or second clone argument is NULL, it will return -1/EINVAL, but clobber the call-saved %r7 register. I think error: label should either lm{,g} %r6,%7 or l{,g} %r7.
Introduced in commit e57d8fc97b.
Yes, you are right, this is broken. I'll take care of it. Thanks for figuring out and reporting to me.
Patch under review: https://patchwork.sourceware.org/project/glibc/patch/20240221161307.2821102-1-stli@linux.ibm.com/
Committed to master: "S390: Do not clobber r7 in clone [BZ #31402]" https://sourceware.org/git/?p=glibc.git;a=commit;h=02782fd12849b6673cb5c2728cb750e8ec295aa3 I will backport this commit to the release branches and will then close this bugzilla.
Also backported to release-branches: - release/2.37/master: https://sourceware.org/git/?p=glibc.git;a=commit;h=9a1bdd7df731a4bc60f72dbdc1b849e02cfa9c34 - release/2.38/master: https://sourceware.org/git/?p=glibc.git;a=commit;h=ee4806e978467d705b26ccb7dfddb9e0a710f8e4 - release/2.39/master: https://sourceware.org/git/?p=glibc.git;a=commit;h=e0910f1d3278f05439fb434ee528fc9be1b6bd5e