ppoll with -D_TIME_BITS=64 and -D_FORTIFY_SOURCE
Ola x Nilsson
ola.x.nilsson@axis.com
Wed Nov 9 08:31:21 GMT 2022
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
More information about the Libc-help
mailing list