On 11/6/24 17:00, Simon Josefsson wrote:
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:~$
I agree, I see size=8 as well. This comes from here:
/usr/include/arm-linux-gnueabihf/bits/types/struct_timeval.h
struct timeval
{
#ifdef __USE_TIME64_REDIRECTS
__time64_t tv_sec; /* Seconds. */
__suseconds64_t tv_usec; /* Microseconds. */
#else
__time_t tv_sec; /* Seconds. */
__suseconds_t tv_usec; /* Microseconds. */
#endif
};
So, when using "cc -o foo foo.c", __USE_TIME64_REDIRECTS is somehow
automatically set.
Running "cc --dumpspecs" shows that there are default values:
*distro_defaults_cpp:
%{!m16:%{!m64:%{!D_DISTRO_EVADE_TIME_BITS:%{!D_TIME_BITS=*:%{!U_TIME_BITS:-D_TIME_BITS=64%{!D_FILE_OFFSET_BITS=*:%{!U_FILE_OFFSET_BITS:
-D_FILE_OFFSET_BITS=64}}}}}}}
So, you need to use "-U" to undefine the defines and try again.
gcc -U_TIME_BITS -U_FILE_OFFSET_BITS foo.c
Note, that "DEB_BUILD_MAINT_OPTIONS = abi=-time64" does exactly this.
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?
Yes.
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.
Yes, maybe.
Helge
