Re: armel buildd misconfiguration (was Re: Bug#1017537: dietlibc: FTBFS on armel)
On Mon, Aug 22, 2022 at 3:08 AM Thorsten Glaser wrote: > > outlook 1017537 some armel buildds are misconfigured and lack SWP emulation > thanks > > Dixi quod… > > ># if __ARM_ARCH__ < 6 > > swp r0, r1, [r2] > ># else > > 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?) 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.
armel buildd misconfiguration (was Re: Bug#1017537: dietlibc: FTBFS on armel)
outlook 1017537 some armel buildds are misconfigured and lack SWP emulation thanks Dixi quod… ># if __ARM_ARCH__ < 6 > swp r0, r1, [r2] ># else 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 -- den AGP stecker anfeilen, damit er in den slot aufm 440BX board passt… oder netzteile, an die man auch den monitor angeschlossen hat und die dann für ein elektrisch aufgeladenes gehäuse gesorgt haben […] für lacher gut auf jeder LAN party │ damals, als der pizzateig noch auf dem monior "gegangen" ist
Re: Bug#1017537: dietlibc: FTBFS on armel
Dixi quod… >In case this makes anyone immediately think of whatever it is: 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 -- When he found out that the m68k port was in a pretty bad shape, he did not, like many before him, shrug and move on; instead, he took it upon himself to start compiling things, just so he could compile his shell. How's that for dedication. -- Wouter, about my Debian/m68k revival
Re: Bug#1017537: dietlibc: FTBFS on armel
>but it ALSO fails in a bullseye chroot, so this is possibly not related In case this makes anyone immediately think of whatever it is: (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=) 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 0x1e8481201 r8 0x1016 r9 0xfffef684 4294899332 r100xfffef68c 4294899340 r110xfffef67c 4294899324 r120x1420 sp 0xfffef3c0 0xfffef3c0 lr 0x113d4 70612 pc 0x11480 0x11480 <__testandset+8> cpsr 0x6010 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.
Bug#1017537: dietlibc: FTBFS on armel
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 -- 22:20⎜ The crazy that persists in his craziness becomes a master 22:21⎜ And the distance between the craziness and geniality is only measured by the success 18:35⎜ "Psychotics are consistently inconsistent. The essence of sanity is to be inconsistently inconsistent
