ppoll with -D_TIME_BITS=64 and -D_FORTIFY_SOURCE

[Ola x Nilsson]

I've run into some problems when building programs using ppoll on a
32bit system with
-D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE -O

A C file containing a function call like

  int res = ppoll(fds, sizeof(fds)/sizeof(*fds), &timeout, NULL);

compiled without any of the above options will generate an ELF file with
an undefined symbol
ppoll@GLIBC_2.4

 $ objdump -wt ppoll-test | grep 'ppoll.*|GLIBC'
 00000000       F *UND*	00000000              ppoll@GLIBC_2.4

If it is compiled with 

-D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64

the ELF file will contain the undefined symbol __ppoll64@GLIBC_2.34

 $ objdump -wt ppoll-test-64bit | grep 'ppoll.*@GLIBC'
 00000000       F *UND*	00000000              __ppoll64@GLIBC_2.34

This is in line with how I interpret the sys/poll.h header file, if
__USE_TIME_BITS64 is defined, redirect ppoll to __ppoll64.


But if I build it with
-D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE -O
bits/poll2.h will add another redirect and the ELF file will again refer
to ppoll@GLIBC_2_4

 $ objdump -wt ppoll-test-64bit-fortified | grep 'ppoll.*@GLIBC'
 00000000       F *UND*	00000000              ppoll@GLIBC_2.4


I interpret this to mean that the actual system call will be resolved to
the 32-bit time version of ppoll.  But maybe I'm way off.

Can someone help me figure out what is going on here?

I've created a github repo with my test code here
https://github.com/snogge/glibc-ppoll-test .  I tested the build using
gcc-linaro-13.0.0-2022.11-x86_64_arm-linux-gnueabihf.tar.xz downloaded
from
https://snapshots.linaro.org/gnu-toolchain/13.0-2022.11-1/arm-linux-gnueabihf/
It uses glibc > 2.36.

/Ola