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.
Reading that self-test makes me wonder if it really support
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64. The code is low-level so
shouldn't it have internal magic for the 32-bit vs 64-bit case?
This library should do no magic.
It should simply emulate the original syscalls correctly.
uid-wrapper generally: the self test checks gettimeofday vs
SYS_gettimeofday, but uid-wrapper never does anything related to
gettimeofday.
Right.
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.
Maybe the purpose of this self-test is to merely test the syscall
facility, and that they happened to pick gettimeofday which used to be
an uncomplicated interface but lately haven't been?
Yes, I think so.
As an example, the x32 build currently fails because the syscall isn't executed.
Thoughts? Maybe just add back Draw's patch?
No.
Helge
