[Pkg-sssd-devel] Bug#1086769: uid-wrapper FTBFS on hppa, powerpc and x32

[Simon Josefsson]

Helge Deller <deller at 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 at 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 at amdahl:~$ schroot -r -c $sessionid
(sid_armel-dchroot)jas at 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 at 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 at amdahl:~$ cc -o foo foo.c
(sid_armel-dchroot)jas at amdahl:~$ ./foo
size 8 8
(sid_armel-dchroot)jas at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 255 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-sssd-devel/attachments/20241106/8ebc0922/attachment.sig>