Helge Deller <del...@gmx.de> writes: > Hi Simon, > > On 11/6/24 09:26, Simon Josefsson wrote: >> Hi. The uid-wrapper autopkgtest fails on armel and armhf: >> >> https://tracker.debian.org/pkg/uid-wrapper >> https://ci.debian.net/packages/u/uid-wrapper/testing/armel/54125843/ >> https://ci.debian.net/packages/u/uid-wrapper/testing/armhf/54125865/ >> >> The C flags are hidden, and I am working on unhiding them via >> -DCMAKE_VERBOSE_MAKEFILE=ON but it doesn't look like the self-tests are >> built with -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64, unless that comes >> from config.h: https://salsa.debian.org/jas/uid-wrapper/-/jobs/6543041 >> >> The failing code here is uid-wrapper/tests/test_syscall.c line 53: >> >> assert_int_equal(tv1.tv_sec, tv2.tv_sec); >> >> Maybe the previous arm32 patch is still relevant? > > No, the previous arm32 patch was just a hack and is completely wrong. > > This is the error reported: > [ ERROR ] --- 0x672a9fe1 != 0xf2839672a9fe1 > 0xf2839672a9fe1 is the value which is stored in tv2.tv_sec. > That number is a 64-bit value (you need more than 32bits to store that value). > So, "-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64" was definitively set in your > build, > otherwise tv2.tv_sec would not be 64-bits wide.
I think time_t and timeval's tv_sec are 64-bit on 32-bit architectures now: https://wiki.debian.org/ReleaseGoals/64bit-time The following may confirms this, although amdahl is running a 64-bit kernel so maybe this isn't correct anyway. Is there any real 32-bit armel/armhf porter box to test things on? jas@amdahl:~$ sessionid=$(schroot -b -c sid_armel-dchroot) I: 00check: Untarring chroot environment. This might take a minute or two. I: 99porterbox-extra-sources: o To install build dependencies run I: 99porterbox-extra-sources: dd-schroot-cmd -c sid_armel-dchroot-6d957f01-d2d5-424e-8367-94b5ba7473eb apt-get update I: 99porterbox-extra-sources: followed by build-dep/install as appropriate in the host system. I: 99porterbox-extra-sources: o If you started this session with schroot -b, please do not forget to run I: 99porterbox-extra-sources: schroot --end-session -c sid_armel-dchroot-6d957f01-d2d5-424e-8367-94b5ba7473eb I: 99porterbox-extra-sources: when you no longer need this environment. jas@amdahl:~$ schroot -r -c $sessionid (sid_armel-dchroot)jas@amdahl:~$ uname -a Linux amdahl 6.1.0-26-arm64 #1 SMP Debian 6.1.112-1 (2024-09-30) armv8l GNU/Linux (sid_armel-dchroot)jas@amdahl:~$ cat>foo.c #include <stdio.h> #include <time.h> #include <sys/time.h> int main (void) { struct timeval tv; printf ("size %d %d\n", sizeof (tv.tv_sec), sizeof (time_t)); } (sid_armel-dchroot)jas@amdahl:~$ cc -o foo foo.c (sid_armel-dchroot)jas@amdahl:~$ ./foo size 8 8 (sid_armel-dchroot)jas@amdahl:~$ Is the problem that the SYS_gettimeofday call assumes 32-bit int's, but is passed and compared with a 64-bit struct, which causes the problem? It should have used a SYS_gettimeofday64 syscall to use 64-bit int's but there is no such syscall. There are for many other 64-bit syscalls like SYS_fstat64 and SYS_clock_gettime64 but nothing for SYS_gettimeofday64. >> uid-wrapper generally: the self test checks gettimeofday vs >> SYS_gettimeofday, but uid-wrapper never does anything related to >> gettimeofday. > > Right. Perhaps we can get upstream to use another syscall to test things here. Is there some harmless syscall we could use instead? That doesn't have 32-bit vs 64-bit alignment issues... >> As discussed in >> https://gitlab.com/cwrap/uid_wrapper/-/issues/1 one fix would be to use >> a SYS_gettimeofday64 call instead, but that doesn't seem to exist. > > Right. There is no such syscall. > Instead glibc uses clock_gettime() to provide a 64-bit time on 32-bit > platforms. > So, there is no need for uid-wrapper to emulate such a call. Okay, that also suggests test_syscall.c shouldn't use gettimeofday() for test purposes since it is not trivial. /Simon
signature.asc
Description: PGP signature
