From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) by sourceware.org (Postfix) with ESMTPS id 068203858D35 for ; Fri, 1 Mar 2024 21:07:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 068203858D35 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 068203858D35 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::230 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1709327229; cv=none; b=s8cXfdl0aRUEKS7D/kTA9T5XGED/G7u92QPMdQEdf3hq7EI1Ke006uIe7MIh1Ht7jC/PyA5QxHKpR3GesdAGPSVq4TU5lkmHaiAjKJkrSZlO35+1eXi/UJJ1YgykJ3P3MeigDa4LfCWDwsVuYIVYqiuQC2XyrO8j5FFx71qkvyo= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1709327229; c=relaxed/simple; bh=ZsK76iuMujiC6HUYCXld7hruHsb7FSSiRrqDnQQ2fNY=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=YEflFm+WO7C5894sYn8IFslTIufdVomSeVIUGXEbQcYxpZf3+l/bgEA3wDKthYLM93SUKUWdiVZmPSjtVJ8tVixqpnyPwsyWc4ff/2nQBsLBsb6OkRrufrtBCA80EtcY3vpNdFdykDCT6+os8cXR8X+zOUFPUMTZ16xkvMNvPeE= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-lj1-x230.google.com with SMTP id 38308e7fff4ca-2d28051376eso32599131fa.0 for ; Fri, 01 Mar 2024 13:07:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1709327225; x=1709932025; darn=sourceware.org; h=cc:to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=ZsK76iuMujiC6HUYCXld7hruHsb7FSSiRrqDnQQ2fNY=; b=K1BaEmAeYmMigoJOHLbFniDw0a5hoDkqV+naXuZD4A7T2INdijQNetd25pXugfLa7U PmRcspVRyEVWq9CEeKoBlW77LQfnV8ymvfXssGlntMogAReMUif5MYzq5Fz2BQSQ0xAj ahNf//8SYCvLtQE27KtJZLAiDzh597GldnwEvs0snaz2nIGoEYll4tg+w3/WfZQv85mG 5ZD8r3dqQznmcxm5qZY3nU0SCSPzwbBDt01UskVKCw2xcIryJzaq6bXaOqrG31zqyETu EbwW3J81weyOfYFpvZxhfJxpRVQ8s2P7Toe491mCs5vs/YS6ebdXomqhS2pwxy0nAwFv 28VA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709327225; x=1709932025; h=cc:to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=ZsK76iuMujiC6HUYCXld7hruHsb7FSSiRrqDnQQ2fNY=; b=ahbBQrnc6om5n87qJyyjq3IuEuGiLiiUfy1ZxF9J8tJliOjdON6y5oZ4xYbsBSevD/ G8Euu0VwyXX2OWN2OMPNFtwnAeoRbE0ufFdN6nKEnVTwsGmz2A1BF347G9Ei6biqftVQ 89LaZJMRkwScqkuAgh5BxwXDkIripdkRcnW5kOuiFQUJ+7Qpv6J0IEEXdC8rRdHWMgZB P5ZRGa/Y5pLWtT9dTX6TwFOvF3lepfxZnlqaibFula6htcaeoGgfL9zFlJk0Im48S4iF 6gOZIrBCcVqYnBtfiitewBD2u4Y3PfK3MvuFQQu1pqtsQ7mZAfuDghlMoR0HG3Lzwhr9 booQ== X-Gm-Message-State: AOJu0YxqvipYQyPNTb/7B8XbWsI9gPXNS2biYlJiKiMWcM8+thkXvoE2 68uBMnxHxWj99xAhexlW5MDiLOJ9Xs2VB+/YgTbWPeEOK0PeQKrYqfrIRz6VgyD+/YQr1DTjyow zaf7ds/gxUabrCrXdqslBJIhRLw5vNSIJysI= X-Google-Smtp-Source: AGHT+IGdmqtoTr106uRS2n9qoUx3NfXLaz+FdCu3E+o5NvD//owW8Zl7rjmdAUM4s//2v/S4NqeI5Lg+vCvdri4+nx0= X-Received: by 2002:a2e:a7c2:0:b0:2d3:4b07:9140 with SMTP id x2-20020a2ea7c2000000b002d34b079140mr1812794ljp.47.1709327224831; Fri, 01 Mar 2024 13:07:04 -0800 (PST) MIME-Version: 1.0 From: Aliaksey Kandratsenka Date: Fri, 1 Mar 2024 16:06:53 -0500 Message-ID: Subject: Seeking advise on most portable way to detect 64-bit off_t To: libc-help@sourceware.org Cc: Aliaksiej Kandracienka Content-Type: multipart/alternative; boundary="0000000000000a85c106129fc2b5" X-Spam-Status: No, score=0.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE 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: --0000000000000a85c106129fc2b5 Content-Type: text/plain; charset="UTF-8" Hi. In gperftools we have the feature to hook mmap calls which works by interposing over glibc's mmap. So it has to deal with off_t complexities. We don't use that offset argument, other than just passing it to real mmap implementation. I am also trying to support different Linux libc-s just for completeness. And musl being new enough and wise enough has always had 64-bit off_t (bionic hasn't and there is really no excuse...) So with that I need some means to detect 32-bit off_t that works across multiple libcs and has the highest hope of working in the future. By looking around, I choose to detect 32-bit-ness of off_t by looking at semi-obscure define _POSIX_V7_ILP32_OFF32: https://github.com/gperftools/gperftools/blob/37b59a206e36b405dcb2ac09d502875dd629a80b/src/mmap_hook.cc#L275 It does seem to do the right thing across implementations I checked. Well mostly. These days, Debian folk are doing a massive 64-bit time_t transition (which also includes mass-enabling 64-bit off_t, at last) and they're rebuilding everything with _FILE_OFFSET_BITS=64. And my "approach" fails. https://buildd.debian.org/status/fetch.php?pkg=google-perftools&arch=armel&ver=2.15-1.1&stamp=1709166723&file=log Glibc doesn't adjust _POSIX_V7_ILP32_{BIGOFF,OFF32} defines based on _FILE_OFFSET_BITS. Perhaps rightly so. But with that situation I need some other, and hopefully more robust means to detect off_t width. I am thinking of 3 options: * Keep _POSIX_V7 thingy but also add a check for _FILE_OFFSET_BITS == 64. And then behave as if off_t is 32-bit. * #undef _FILE_OFFSET_BITS at the first line in mmap_hooks.cc. It will cause glibc on those legacy 32-bit off_t systems to define 32-bit off_t and give me right defines and my code will define mmap symbol with 32-bit offset arg and mmap64 symbol with 64-bit offset. And thus matching glibc. * just manually hardcode knowledge that glibc + {i386,arm{el,hf},mips32,ppc32} has 32-bit off_t. But that leaves the question of how to deal with e.g. bionic (well, I could in principle say, bionic already being broken enough is only supported for 64-bit systems, which is where android systems are moving anyways) I am looking for any comments or suggestions. Particularly I'd like my fix to be robust w.r.t. any further glibc evolution. --0000000000000a85c106129fc2b5--