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

[Helge Deller]

On 11/6/24 17:00, Simon Josefsson wrote:
> 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:~$

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