- Package:
- src:dietlibc
- Source:
- src:dietlibc
- Submitter:
- Sebastian Ramacher
- Date:
- 2024-07-06 16:06:05 UTC
- Severity:
- normal
- Tags:
Source: dietlibc Version: 0.34~cvs20160606-14 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) X-Debbugs-Cc: sramacher@debian.org https://buildd.debian.org/status/fetch.php?pkg=dietlibc&arch=armel&ver=0.34%7Ecvs20160606-14&stamp=1658293281&raw=0 RUN ERROR for debian/unittests/tc523086.c in variant pthreads (rc = 132), test output is: ------------------------------------------------------------ Illegal instruction ------------------------------------------------------------ RUN ERROR for debian/unittests/t-ascii1.c in variant pthreads (rc = 132), test output is: ------------------------------------------------------------ Illegal instruction ------------------------------------------------------------ RUN ERROR for debian/unittests/signal.c in variant pthreads (rc = 132), test output is: ------------------------------------------------------------ Illegal instruction ------------------------------------------------------------ RUN ERROR for debian/unittests/gettimeofday.c in variant pthreads (rc = 132), test output is: ------------------------------------------------------------ Illegal instruction ------------------------------------------------------------ RUN ERROR for debian/unittests/socketfns.c in variant pthreads (rc = 132), test output is: ------------------------------------------------------------ Illegal instruction ------------------------------------------------------------ RUN ERROR for test/bsearch.c in variant pthreads (rc = 132), test output is: ------------------------------------------------------------ Illegal instruction ------------------------------------------------------------ RUN ERROR for test/fadvise.c in variant pthreads (rc = 132), test output is: ------------------------------------------------------------ Illegal instruction ------------------------------------------------------------ RUN ERROR for test/mmap_test.c in variant pthreads (rc = 132), test output is: ------------------------------------------------------------ Illegal instruction ------------------------------------------------------------ RUN ERROR for test/stdarg.c in variant pthreads (rc = 132), test output is: ------------------------------------------------------------ Illegal instruction ------------------------------------------------------------ RUN ERROR for test/ungetc.c in variant pthreads (rc = 132), test output is: ------------------------------------------------------------ Illegal instruction ------------------------------------------------------------ RUN ERROR for test/utime.c in variant pthreads (rc = 132), test output is: ------------------------------------------------------------ Illegal instruction ------------------------------------------------------------ RUN ERROR for test/waitpid.c in variant pthreads (rc = 132), test output is: ------------------------------------------------------------ Illegal instruction ------------------------------------------------------------ RUN ERROR for test/dirent/opendir-tst1.c in variant pthreads (rc = 132), test output is: ------------------------------------------------------------ Illegal instruction ------------------------------------------------------------ RUN ERROR for test/stdlib/tst-calloc.c in variant pthreads (rc = 132), test output is: ------------------------------------------------------------ Illegal instruction ------------------------------------------------------------ make[1]: *** [debian/rules:105: override_dh_auto_test-arch] Error 1 make[1]: Leaving directory '/<<PKGBUILDDIR>>' Cheers
Control: found -1 0.34~cvs20160606-12 Control: tags -1 sid bookworm This is already an issue with 0.34~cvs20160606-12. Cheers
Sebastian Ramacher dixit: It’s an incompatible toolchain change that broke this package. I’m trying to find out why, but the ARM porters are not helpful. bye, //mirabilos
Arnd Bergmann dixit: Is my expectation that, for any given platform (armel, armhf, arm64), that a default invocation of the system compiler adds the correct flags not good? Sounds like a bug in gcc-11 instead then? (Why has this then not hit more packages?) debian/rules inspects DEB_HOST_ARCH and passes MYARCH to the upstream Makefile so this ought to DTRT…ish — arm64 is passed as aarch64, and all other *arm* are passed as arm (though we don’t carry armeb or the pre-EABI arm any more so that’s probably also fine). Note that #1017537 (on armel) and #1017538 (on armhf) probably are, if not the same thing, at least related. bye, //mirabilos No, the only way I've seen them sold is for $40 with a free OpenBSD CD. -- Haroon Khalid and Steve Shockley in gmane.os.openbsd.misc
outcome 1017537 fails on porterbox/bullseye as well, suspect 64-bit host to be an issue tags 1017537 + help thanks In contrast to armhf, which works fine on the porterbox (amdahl; abel, which I normally use, is currently down) for me, this one also fails, but it ALSO fails in a bullseye chroot, so this is possibly not related to a toolchain change. I think I’ll have to track down a 32-bit ARM machine and test-build it there. I recently got gifted a Raspbery Pi v1.2 so that’d be running armel anyway, so I guess it’s installing Debian on that thing for me now. bye, //mirabilos
(gdb) r Starting program: /home/tg/dietlibc-0.34~cvs20160606-el-11/debian/unittests/ttt Program received signal SIGILL, Illegal instruction. __testandset () at arm/__testandset.S:7 7 swp r0, r1, [r2] (gdb) bt #0 __testandset () at arm/__testandset.S:7 #1 0x000113d4 in __pthread_lock (lock=lock@entry=0x25054 <_main_thread+20>) at libpthread/pthread_spinlock.c:84 #2 0x0001052c in __thread_find_ (pid=<optimized out>) at libpthread/pthread_internal.c:98 #3 0x00010578 in __thread_self () at libpthread/pthread_internal.c:127 #4 0x00010280 in malloc (size=32) at libpthread/pthread_sys_alloc.c:20 #5 0x00010124 in main () (gdb) info r r0 0x25054 151636 r1 0x1 1 r2 0x25054 151636 r3 0x0 0 r4 0x0 0 r5 0x25054 151636 r6 0x0 0 r7 0x1e8481 2000001 r8 0x10 16 r9 0xfffef684 4294899332 r10 0xfffef68c 4294899340 r11 0xfffef67c 4294899324 r12 0x14 20 sp 0xfffef3c0 0xfffef3c0 lr 0x113d4 70612 pc 0x11480 0x11480 <__testandset+8> cpsr 0x60000010 1610612752 fpscr 0x0 0 (gdb) disas Dump of assembler code for function __testandset: 0x00011478 <+0>: mov r2, r0 0x0001147c <+4>: mov r1, #1 => 0x00011480 <+8>: swp r0, r1, [r2] 0x00011484 <+12>: bx lr End of assembler dump.
Dixi quod… Code looks right enough (with an explanation of why this only fails on armel but not on armhf which is perfectly fine): $ cat arm/__testandset.S #include "arm-features.h" FUNC_START __testandset mov r2, r0 mov r1, #1 # if __ARM_ARCH__ < 6 swp r0, r1, [r2] # else 1: ldrex r0, [r2] strex r3, r1, [r2] cmp r3, #0 bne 1b # endif RET FUNC_END __testandset bye, //mirabilos
outlook 1017537 some armel buildds are misconfigured and lack SWP emulation thanks Dixi quod… And this, after some research, is it. This is needed for armel, which is v5. Apparently, Linux has SWP emulation for v7/v8 hosts, but at least one buildd listed does not have this enabled, breaking the armel ABI. Please ensure that only hosts with working SWP emulation run armel. (Can I reassign this bugreport to the buildd? Does it have a virtual package in debbugs?) Until then, I guess I’ll keep giveback’ing dietlibc on armel until it builds… bye, //mirabilos
outlook 1017537 some armel buildds are misconfigured and lack SWP emulation thanks Dixi quod… And this, after some research, is it. This is needed for armel, which is v5. Apparently, Linux has SWP emulation for v7/v8 hosts, but at least one buildd listed does not have this enabled, breaking the armel ABI. Please ensure that only hosts with working SWP emulation run armel. (Can I reassign this bugreport to the buildd? Does it have a virtual package in debbugs?) Until then, I guess I’ll keep giveback’ing dietlibc on armel until it builds… bye, //mirabilos
retitle 1017537 dietlibc: may FTBFS on armel due to buildd misconfiguration severity 1017537 normal thanks Just givebacking until it ends up on a working buildd helps. Keeping this open until the buildd maintainers report it fixed.
For reference, the instruction is not avaialable on Armv7 but is emulated
on 32-bit kernels whenever CONFIG_SWP_EMULATE is enabled,
this is defined as:
config SWP_EMULATE
bool "Emulate SWP/SWPB instructions" if !SMP
depends on CPU_V7
default y if SMP
select HAVE_PROC_CPU if PROC_FS
so this is enabled on all SMP-enabled kernels but can be disabled
on uniprocessor Armv7 builds, which would be broken here.
On 64-bit kernels, the same option is not enabled by default
in mainline kernels, so the kernel config needs to contain
CONFIG_COMPAT=y, ARMV8_DEPRECATED=y, and
CONFIG_SWP_EMULATION=y. This also has to be enabled
at runtime using the "abi.swp=1" sysctl, see
https://www.kernel.org/doc/Documentation/arm64/legacy_instructions.rst
Most likely, the buildd is running a default debian kernel and has
the compile-time options enabled, but has it disabled at runtime.
Can you find out if /proc/sys/abi/swp exists on the system, and
what its contents are? If it does not exist, fixing this requires
a change to the kernel configuration, if it exists but contains
'0', then running binaries with the swp instruction just requires
changing the local sysctl.conf for any armel buildd.
For reference, the instruction is not avaialable on Armv7 but is emulated
on 32-bit kernels whenever CONFIG_SWP_EMULATE is enabled,
this is defined as:
config SWP_EMULATE
bool "Emulate SWP/SWPB instructions" if !SMP
depends on CPU_V7
default y if SMP
select HAVE_PROC_CPU if PROC_FS
so this is enabled on all SMP-enabled kernels but can be disabled
on uniprocessor Armv7 builds, which would be broken here.
On 64-bit kernels, the same option is not enabled by default
in mainline kernels, so the kernel config needs to contain
CONFIG_COMPAT=y, ARMV8_DEPRECATED=y, and
CONFIG_SWP_EMULATION=y. This also has to be enabled
at runtime using the "abi.swp=1" sysctl, see
https://www.kernel.org/doc/Documentation/arm64/legacy_instructions.rst
Most likely, the buildd is running a default debian kernel and has
the compile-time options enabled, but has it disabled at runtime.
Can you find out if /proc/sys/abi/swp exists on the system, and
what its contents are? If it does not exist, fixing this requires
a change to the kernel configuration, if it exists but contains
'0', then running binaries with the swp instruction just requires
changing the local sysctl.conf for any armel buildd.
Arnd Bergmann dixit:
I guess the buildds would be running some kind of stock Debian
kernel from, probably, stable or oldstable. (The latter may be
problematic but I’ve seen it.) Or, at least, I hope they do.
Only on the porterbox amdahl; it exists and is 0.
The same would then be valid for porterboxen: for it to be a viable
armel porterbox, this must be set to 1.
Do you think it would be worth compiling a VERY tiny program from
execute_before_dh-auto-build that just runs an swp instruction, and
if that fails, issue a message pointing to your message? I’m doing
something similar for mksh wrt. the existence of /dev/{tty,pts,ptmx}
but here it can obviously only be done if not cross-compiling (but
that’s not a problem because the tests can only run then either).
Thanks,
//mirabilos
Arnd Bergmann dixit:
I guess the buildds would be running some kind of stock Debian
kernel from, probably, stable or oldstable. (The latter may be
problematic but I’ve seen it.) Or, at least, I hope they do.
Only on the porterbox amdahl; it exists and is 0.
The same would then be valid for porterboxen: for it to be a viable
armel porterbox, this must be set to 1.
Do you think it would be worth compiling a VERY tiny program from
execute_before_dh-auto-build that just runs an swp instruction, and
if that fails, issue a message pointing to your message? I’m doing
something similar for mksh wrt. the existence of /dev/{tty,pts,ptmx}
but here it can obviously only be done if not cross-compiling (but
that’s not a problem because the tests can only run then either).
Thanks,
//mirabilos
Yes, that sounds reasonable in principle. I've tried to come up with a
minimal test case like
echo 'int main(void) { static int a, b, c; return
__atomic_exchange_n(&a, b, 0); }' | \
gcc -S -xc - -O2 -o testswp
However, this does not actually use the swp instruction but calls
the correct libgcc function __sync_val_compare_and_swap_4(),
which in turn uses a VDSO helper provided by the kernel to
do this in a portable way using either swp or ldrex/strex depending
on the running CPU.
So an even better way to handle this would be to use the gcc
builtins in place of the assembler implementation, or copy
the portable code from musl, which uses the VSDO version
explicitly:
#define a_cas a_cas
static inline int a_cas(volatile int *p, int t, int s)
{
for (;;) {
register int r0 __asm__("r0") = t;
register int r1 __asm__("r1") = s;
register volatile int *r2 __asm__("r2") = p;
register uintptr_t r3 __asm__("r3") = __a_cas_ptr;
int old;
__asm__ __volatile__ (
BLX " r3"
: "+r"(r0), "+r"(r3) : "r"(r1), "r"(r2)
: "memory", "lr", "ip", "cc" );
if (!r0) return t;
if ((old=*p)!=t) return old;
}
}
Yes, that sounds reasonable in principle. I've tried to come up with a
minimal test case like
echo 'int main(void) { static int a, b, c; return
__atomic_exchange_n(&a, b, 0); }' | \
gcc -S -xc - -O2 -o testswp
However, this does not actually use the swp instruction but calls
the correct libgcc function __sync_val_compare_and_swap_4(),
which in turn uses a VDSO helper provided by the kernel to
do this in a portable way using either swp or ldrex/strex depending
on the running CPU.
So an even better way to handle this would be to use the gcc
builtins in place of the assembler implementation, or copy
the portable code from musl, which uses the VSDO version
explicitly:
#define a_cas a_cas
static inline int a_cas(volatile int *p, int t, int s)
{
for (;;) {
register int r0 __asm__("r0") = t;
register int r1 __asm__("r1") = s;
register volatile int *r2 __asm__("r2") = p;
register uintptr_t r3 __asm__("r3") = __a_cas_ptr;
int old;
__asm__ __volatile__ (
BLX " r3"
: "+r"(r0), "+r"(r3) : "r"(r1), "r"(r2)
: "memory", "lr", "ip", "cc" );
if (!r0) return t;
if ((old=*p)!=t) return old;
}
}
Arnd Bergmann dixit: OK, good. I’ll do that then when I’m caught up with dayjob work. Meh, I’m just going to write a main.s ;-) I like assembly. Also, less surprises there. GCC is… bye, //mirabilos
We believe that the bug you reported is fixed in the latest version of
dietlibc, which is due to be installed in the Debian FTP archive.
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to 1017537@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Thorsten Glaser <tg@mirbsd.de> (supplier of updated dietlibc package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Fri, 05 Jul 2024 00:20:35 +0200
Source: dietlibc
Architecture: source
Version: 0.34~cvs20160606-14exp1
Distribution: experimental
Urgency: high
Maintainer: Christian Seiler <christian@iwakd.de>
Changed-By: Thorsten Glaser <tg@mirbsd.de>
Closes: 974690 1017537 1030998 1069365 1074910
Changes:
dietlibc (0.34~cvs20160606-14exp1) experimental; urgency=high
.
[ Debian Janitor, lintian-brush ]
* fix d/copyright, d/watch, Homepage, UMEGAYA and d/changelog
* bump debhelper and S-V
.
[ Bastian Germann ]
* d/watch: Scan for other compression formats
.
[ Helge Deller ]
* Update hppa defs (Closes: #974690) (Closes: #1030998)
.
[ Thorsten Glaser ]
* avoid rmdir failing with ENOENT
* add -ffreestanding to libc builds (Closes: #1069365)
* test swp instruction for armel builds (Closes: #1017537)
* B-D on GCC 14 and fix FTBFS with it (Closes: #1074910)
uploading to experimental for that
* Unbreak building on architectures with LFS/t64 in dpkg-buildflags
* More fixing of the stack protector, pthreads, etc.
* Apply lintian fixes
Checksums-Sha1:
970c1a81ac5653506639c28398ac5fb4ad7763b8 2438 dietlibc_0.34~cvs20160606-14exp1.dsc
fa21c22c60a629e19684a65a60f02b5de59eb2ab 51640 dietlibc_0.34~cvs20160606-14exp1.debian.tar.xz
Checksums-Sha256:
dc6bfdc86c8a6702bf8f52408b7d500223422779292ed4f23cf6a0f64c0f0dac 2438 dietlibc_0.34~cvs20160606-14exp1.dsc
15cd1a8b58b61d0025f2d044ad9d6dffa71d4f92f893f67ed0b9e9141bc0e8a7 51640 dietlibc_0.34~cvs20160606-14exp1.debian.tar.xz
Files:
31f77780ae4219e450760b74654ac2f4 2438 devel optional dietlibc_0.34~cvs20160606-14exp1.dsc
45c01f77014e8b3d70e4ead4be09628b 51640 devel optional dietlibc_0.34~cvs20160606-14exp1.debian.tar.xz
iQIcBAEBCQAGBQJmhzLNAAoJEHa1NLLpkAfg4SYQAJWRgKzXWxtosvmhkvw68j68
QNcUxdCRVOWCkc9k6u+LGitw5mDqpEU4h9Q/HoG3RxYRlMkKMOAQDejG9aH2K3sI
DOI4YQ9hhwy4i+4Pt1gO2+1Km+2610kOFZsi7kIhgOT/QFLsFVCo3/9Y7lTERr2S
6doqKrlotzj3duMjLajHdJ7oovGFbxRg8mQOAdRjerYOTUC8zsmanobwFaQkaG3A
B3ZNqrplFg+qXjY+pi2So+OPfOKQWwMY0D0LuRM/gXhlWhFXaaNQN85YnGuawltC
GlusgYPUMzKXM2Nd3bT++yKYchDcns6fNJeBFT0MqiFmmITa7tdnQxgndkkhOTVX
cHI2vMMOhW539o2R8GuEAskvDFl+6zuxCKYo/wP8vlwB7Cz0vZfIzvwWt57Y9e/E
LVVWOrbgJV4LJYPuHpjSSCrQWMSnpbzb3RK0i8Xh/KK3DBpvnJ2CT/DcMRg7nnXj
kE4D8I4k2KlKi7Wemijy7LWCSRdJNcEgCqJLFzwTo2Ia+Xrqeotpbrpj4yJFZn03
RzaUIawgLw+PniNgeT4hJMGlzQJBXFngfQP+iiWnN5t02i6J7Y2nMexqpIBv0oEP
By6mA59L+O53fHWH5TgKd49yTJzyxjVvz2cSs9cv+ZP59fywO/6uFTsP9U4DSjwx
Hpc3M2lngawxRhVAcULW
=DWr8
-----END PGP SIGNATURE-----
We believe that the bug you reported is fixed in the latest version of
dietlibc, which is due to be installed in the Debian FTP archive.
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to 1017537@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Thorsten Glaser <tg@mirbsd.de> (supplier of updated dietlibc package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Sat, 06 Jul 2024 17:28:41 +0200
Source: dietlibc
Architecture: source
Version: 0.34~cvs20160606-15
Distribution: unstable
Urgency: medium
Maintainer: Christian Seiler <christian@iwakd.de>
Changed-By: Thorsten Glaser <tg@mirbsd.de>
Closes: 974690 1017537 1030998 1069365 1074910
Changes:
dietlibc (0.34~cvs20160606-15) unstable; urgency=medium
.
* upload to unstable reverting GCC 14 test B-D
* d/copyright: complete licence review, entirely new
(cf. #1067946)
* update description and patch headers
* un-mark fadvise test as expect-fail on ARM (works now)
* mark socketfns test as expect-fail on parisc (hppa),
as qemu-user needs to be updated to match changed Linux kernel
.
dietlibc (0.34~cvs20160606-14exp1) experimental; urgency=high
.
[ Debian Janitor, lintian-brush ]
* fix d/copyright, d/watch, Homepage, UMEGAYA and d/changelog
* bump debhelper and S-V
.
[ Bastian Germann ]
* d/watch: Scan for other compression formats
.
[ Helge Deller ]
* Update hppa defs (Closes: #974690) (Closes: #1030998)
.
[ Thorsten Glaser ]
* avoid rmdir failing with ENOENT
* add -ffreestanding to libc builds (Closes: #1069365)
* test swp instruction for armel builds (Closes: #1017537)
* B-D on GCC 14 and fix FTBFS with it (Closes: #1074910)
uploading to experimental for that
* Unbreak building on architectures with LFS/t64 in dpkg-buildflags
* More fixing of the stack protector, pthreads, etc.
* Apply lintian fixes
Checksums-Sha1:
5119389b4c7d61fda5002a44f62bae252256b542 2392 dietlibc_0.34~cvs20160606-15.dsc
81b2cf66c7d5976904b602beeddced0ba94f095d 53916 dietlibc_0.34~cvs20160606-15.debian.tar.xz
Checksums-Sha256:
d9b7f5f0e36e2104c32fab5947036d4421880845e62dcbf6b92fbde7bd95ed08 2392 dietlibc_0.34~cvs20160606-15.dsc
4e662d7e68de19a66bb73ddd8a31bb3211164d27667338c22712632b7bc292e4 53916 dietlibc_0.34~cvs20160606-15.debian.tar.xz
Files:
e8c8ada8133ce36aff69ee9e94d814b8 2392 devel optional dietlibc_0.34~cvs20160606-15.dsc
f470cf075c394b85e2709b60b33f2143 53916 devel optional dietlibc_0.34~cvs20160606-15.debian.tar.xz
iQIcBAEBCQAGBQJmiWTnAAoJEHa1NLLpkAfgcC0P/0nydZ0tcB4s5D5ySO45XoQT
/Xw0s+0bvUSld3LrHIw7Nj4gHKRLZOSOeImuTgY1ScN8ztmihqPU2oHwZEC0fhgW
fnwIk/gmpRkqUA/Ko+FFC7aLUi6u7mStZFJ8BjWllZZyRs45EfNKA5I/9IUoqDp3
XQstu5Gix16Xqi3zogQo8oYcOKnBYRqdVs7kbfYkODGeuTmNyPPOQxWSOx1ZslWW
QBCcuquRwtHPdRmcCeCWNGyu4ULQis7Zvirn39OEtGi5HrrcKhF0yleWakFct3DB
a6swdUNQCB6S8ZrhPydsil8HriXeRNluEpa/Uod/ebqUGWxKF1xnEmFSxFIxbL9z
dJ8FUtOsA0S5hd5DfJXR93YKTY3ZwtRusuBBSut6Y16+m9pxfvacB1kdXMuJzZpm
i530fA3Wv7ta4npKBYosmbBCjhPrjQ0SPvR7OJxFz57o/lwnLUoI3XMFD6voYREI
YW76KNpJVdbUaf5RAocdsihhHtpIVLg87TovnSp2Y3l331LAl0aJCMdpb7WHMtSx
PhbPFi4VQkuS44rIGI2RiOK3MHgjewWrAXm3VzVegL9c3DfDibkT1b9xr+6U8SOQ
IMaUwl3pC0qcT+eCfbysDmYR88ygH+rCxkw2O1kbtyttNXxDG8AQcCEc+yFuhJeb
wFOzpGvSQtQPWr0z5d6y
=8zzS
-----END PGP SIGNATURE-----