From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2.axis.com (smtp2.axis.com [195.60.68.18]) by sourceware.org (Postfix) with ESMTPS id 584BE3858D20 for ; Wed, 9 Nov 2022 10:57:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 584BE3858D20 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=axis.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=axis.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=axis.com; q=dns/txt; s=axis-central1; t=1667991436; x=1699527436; h=from:to:subject:date:message-id:mime-version; bh=CT9/BlcIEp/v3SuC7L8FWC9hBkZusQh9Jp/bBII6+aA=; b=YNkts0QiJXxgU4kgKVBQfvoOxdbzVEZrY2hdV60T3LZoTqkbMz/Sb3hW 8qcaovnJ89aJT+h5fjWHFgQC9BMUFi2cyGXF0QmKO0j9mDSDhmAafDLNb oZqPtkkpSto6X4EGIefbLObm4BriPKkFHh5rBS1iJOVmpYxHAFtvuN2Ia GKwnlCEdqn9DP1NIi4X6FqBjcQ3mWErP7YLdCyk1+niKW7P5yLkWzjY15 9z8acw0i9NmYrz5MYv5L0St2wwSrEq44GJdMwvZQHM4U1aGveWPrh5w0m JhC1rL7hsPJe0sZTF8gbhMZN6pcPTSP89fwcIRA6oycR3KePLfmmcuZch Q==; User-agent: mu4e 1.8.9; emacs 29.0.50 From: Ola x Nilsson To: Subject: ppoll with -D_TIME_BITS=64 and -D_FORTIFY_SOURCE Date: Wed, 9 Nov 2022 09:31:21 +0100 Organization: Axis Communications AB Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-3.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: 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