[Pkg-sssd-devel] Bug#1069425: uid-wrapper: FTBFS on armhf: 15: [ LINE ] --- ./tests/test_syscall.c:53: error: Failure!

[Drew Parsons]

Source: uid-wrapper
Followup-For: Bug #1069425
Control: tags -1 ftbfs

Debugging a little on porterbox, the problem is that tv2 is set by the
system call SYS_gettimeofday,
   rc = syscall(SYS_gettimeofday, &tv2, NULL);
   
which gets tv2.tv_sec=0 on arm-32.
So the test fails since tv1 has a non-zero value, tv2 gets 0.

SYS_gettimeofday is an alias to __NR_gettimeofday, if defined,
set in /usr/include/*/bits/syscall.h (l.687)

On amd64 (x86_64-linux-gnu), 32-bit __NR_gettimeofday is defined in
/usr/include/x86_64-linux-gnu/asm/unistd_32.h
as syscall 78.  The 64-bit bit syscall is 96 (in unistd_64.h).

on armel (arm-linux-gnueabi),
/usr/include/arm-linux-gnueabi/asm/unistd_32.h does not contain a
definition for __NR_gettimeofday.  I presume this is the problem.
There no such syscall on 32-bit arm, to SYS_gettimeofday returns a
null (0) results.

If that's the case, if arm-32 simply does not have this syscall, then
of course the test can't pass and therefore should be skipped.

The complicating point is that there is an alternative definition in 
/usr/include/arm-linux-gnueabi/asm/unistd-oabi.h l.67
  #define __NR_gettimeofday (__NR_SYSCALL_BASE + 78)
likewise unistd-eabi.h l.61
I guess this is the definition that arm-32 is supposed to be using.

The equivalent alternative definition on amd64 is in
unistd_x32.h l.89:
  #define __NR_gettimeofday (__X32_SYSCALL_BIT + 96)

bits/syscall.h should not be used directly, rather sys/syscall.h
should be used. On amd64 sys/syscall.h includes asm/unistd.h which
includes asm/unistd_32.h for __i386__, asm/unistd_x32.h for __ILP32__,
else asm/unistd_64.h

On armel, asm/unistd.h uses
unistd-eabi.h for __ARM_EABI__, otherwise unistd-oabi.h
So arm-32 should have __NR_gettimeofday defined either way.

Does it mean the syscall is defined but not implemented on arm-32
(just returns 0 time)?