From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) by sourceware.org (Postfix) with ESMTPS id 1CBBA3858C36 for ; Thu, 7 Mar 2024 18:31:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 1CBBA3858C36 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 1CBBA3858C36 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::12b ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1709836316; cv=none; b=Jxi3cCBL1NiOxIE3uvlXStSMFvw6G7P5B0kQM0a8d1PRdYRG6e/fUcM2A3ijbH/oeJlXFe8NrswH50IVIlzRKzIwoT0WkrkwB7M5/Zd9cGRuQuaihWDhEnw1xKRSfsyduG4p1VlaGOcYQ1jvLkopMO4wvHy9C8m4z7T9SfTyJ2s= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1709836316; c=relaxed/simple; bh=SqILgr0Mz+1afW2iQHQOXrcMqgpHf58/SjvVH/LDNVo=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=qZjVRUb9HYrN1EtwKiXM1gYCAyueDgU3p72D5IHqvr2/URHD1ebSdp0qysm4/HatkbS2wE3C8zML7Lxn6XxvfXEi5RuiTKn5nSRiXeUBJXkDx5f3kZ6foQGjX9w9VirJNPQlcorsH6otdsc1vB72NNQ4vvkxkqzRCgUkTdOf4Rk= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-lf1-x12b.google.com with SMTP id 2adb3069b0e04-513181719easo1011995e87.3 for ; Thu, 07 Mar 2024 10:31:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1709836312; x=1710441112; darn=sourceware.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=IZ0m1etqMLIfHswU6xXfDeWUsKUn8SDLgZHYOHIK0kM=; b=NdW+b+utIfZljltFWokwS/sBpiUW3cMThimlhrjZsIB4/S6NVRhD8jI+O8hVbS1QFl rJ8eKhLZLPt0Ncxc2HGMoaVvgu0f3C4ep1qhVrV7boCTAqFsOvZSzOFEZojE4uknRX97 YCYbVq5jkPFPSBYqD6G6vSVtyqPbUE7bP1vCYGxGTNI33OcSnWo22t7DuUMcYfet8e7k 9HLwLVKR10ud0m8L+Fg2tXJGa/Ahq043shCgeJH4KjBsZJoUOjBxnU5U7RgNNgKblwx8 Fbh4K/jh1upUUPXAlazrBUUDdObvdmCnSfJqMTyH62Oz6pjut5HlY6yh+JgP4DT7SJD/ tDNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709836312; x=1710441112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=IZ0m1etqMLIfHswU6xXfDeWUsKUn8SDLgZHYOHIK0kM=; b=S6HQEOIuyYkuZBHeknJDHJ0gvU741uH61NHzdtVSEYt9ZtobquDCK/Kiysh2E1uUeI QTJetIA9JqbhkTPRBYiDFhHKRPMME/Wl85MMd9BFErW8OTSSujiScMNbs2Ai47VF7N2G t38zOnqKiXnCCFI3OoXgcYJ7dp2SvJoKNcEUWQa9BJseLCERiRMKOL2kGQ6qcaIJK2qh Ek1LF8OAEOLKTxxm5d2SfsPNSGGF84/XZ7jl1Yk2F2be0JQuT4NOrceQAH3NqUQK19OJ rpthnipYf6E6KOTaR3ALmIzDIgFV1nN/QTo8r9xZW92wsxtg9Cb10v3qstJ/zPbQqy+g Lkdg== X-Gm-Message-State: AOJu0YxzMiYFdCNapzKLb3vNj7i+NrkUMf+6PhcJnFgcrdw5/sG5kcXY t0xvT4gjmPoBNBIzJcWVfxI5a8f3BU7JWL/UOSH5DKfqTPNoMePOakvdKmQ0PmDfX4W/NFKdAuS P1iJG3UQRwR7vJne4u8Mqu8peA9xk4T9F X-Google-Smtp-Source: AGHT+IEzwWcux64/hvyUwajfU63GypV19k2/HpSrtEMtAQ+Jmvq6U9EfcK242bZuI5of7wTXO+bGjYsIjbWUN3oeluA= X-Received: by 2002:ac2:464c:0:b0:513:226c:6535 with SMTP id s12-20020ac2464c000000b00513226c6535mr2227056lfo.33.1709836312032; Thu, 07 Mar 2024 10:31:52 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Aliaksey Kandratsenka Date: Thu, 7 Mar 2024 13:31:41 -0500 Message-ID: Subject: Re: Seeking advise on most portable way to detect 64-bit off_t To: Adhemerval Zanella Netto Cc: libc-help@sourceware.org Content-Type: multipart/alternative; boundary="00000000000000bf360613164a22" 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: --00000000000000bf360613164a22 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks. So it turns out I also needed to undef _TIME_BITS. Since glibc errors whenever _TIME_BITS are set and _FILE_OFFSET_BITS aren't. No complaints. IMHO it is a very reasonable thing that glibc does there. But it makes things slightly riskier on our end. I have a question about a potentially longer term future. Do you guys plan to, say, default to _TIME_BITS=3D64 and _FILE_OFFSET_BITS=3D64 at any point? Asking because it would break my code (thankfully, it won't be silent breaking, but still). Should I consider something else to make my code more robust ? On Mon, Mar 4, 2024 at 7:04=E2=80=AFAM Adhemerval Zanella Netto < adhemerval.zanella@linaro.org> wrote: > > > On 01/03/24 18:06, Aliaksey Kandratsenka via Libc-help wrote: > > 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 complexitie= s. > > 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/37b59a206e36b405dcb2ac09d50= 2875dd629a80b/src/mmap_hook.cc#L275 > > > > It does seem to do the right thing across implementations I checked. We= ll > > 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 rebuildi= ng > > everything with _FILE_OFFSET_BITS=3D64. And my "approach" fails. > > > https://buildd.debian.org/status/fetch.php?pkg=3Dgoogle-perftools&arch=3D= armel&ver=3D2.15-1.1&stamp=3D1709166723&file=3Dlog > > > > 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 =3D= =3D 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 glib= c. > > * just manually hardcode knowledge that glibc + > > You need to undefine _FILE_OFFSET_BITS to get the expected types for > off_t and off64_t on the mmap_hook.cc TU, since the whole idea is to > override the symbol. You can also try to poke on glibc internals and > use __off_t and __off64_t, which would not be redefined depending the > the preprocessor (but tying to internal implementation is always a bad > idea). > > So I would recommend this option, which seems to what you did and it is > what sanitizers do also [1]. > > > {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 sa= y, > > 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. > > [1] > https://github.com/llvm/llvm-project/blob/main/compiler-rt/lib/sanitizer_= common/sanitizer_platform_limits_posix.cpp#L15 > --00000000000000bf360613164a22--