From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com [IPv6:2607:f8b0:4864:20::62b]) by sourceware.org (Postfix) with ESMTPS id D4E5D3858D39 for ; Tue, 12 Mar 2024 12:06:40 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D4E5D3858D39 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linaro.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org D4E5D3858D39 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::62b ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1710245203; cv=none; b=XDTR7EcSaDlTRtjy6EzsfRUW+2qkNvgiG1yEXdrt3tQ20SOb3J/aMYVP05lmDvzXA8BbBQIARKVyqj4WLjfsuRX9Rc7B5dToauoRNzBiliE1o23gf123hFvfB/FoTgg005wfAqjSg5sigbodi8w/KbXBLm1id2H4LA+Iq4doDco= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1710245203; c=relaxed/simple; bh=fXpyCDD/71glAqK19Gn9KITvpnFleElN/aYQhz1Vo40=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=W64jo4N8xPunL1wa2fWNhH0PZ/BtncEHU1e/JNAqjAfcPvuX6FgXndCwwQl0C7dPnEgLWiv7pWPvNt4JwfQBJVR0ZwAlC6rwMGy+XA5tRog4ITUMtByjUH096Wjaj6peCppS1zMBxm/lx9B5TjBJ4r+R3SbDFzrywXjT8qSn4ZI= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-pl1-x62b.google.com with SMTP id d9443c01a7336-1ddc5a8d0f2so842785ad.1 for ; Tue, 12 Mar 2024 05:06:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1710245200; x=1710850000; darn=sourceware.org; h=content-transfer-encoding:in-reply-to:organization:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:from:to:cc:subject:date:message-id:reply-to; bh=Pkns7N7OuXavtu5iO/2DP6S0mePgQf87OV4oVWXFnn8=; b=Pr6uJUDMvqcJtN3aL2b3q/tkp4Wi/S+qPZVy9LcBsBvrPV4RXZzyMAa6vyKunE4wXX 76KdW6W4Ic3vBqSzXGKRl/AOWKa9WYohf2eCacggJjNP36zXdGsuLSvOBjN0kwGbsiDa x/4tmKRyEIhvl8tuSySF0AE6iiNwMmigv+UA7wRzDS3EPs7eICz/0ErD4Yla7vpn8d8c UTY2FZlUIiH0BXCfuaHoKLAS96jF/GmVkmKlyHoAvhaG5/MQrAKmsmBPUJBFDLEPxmrg vDtgk2ee5Bsqtyl5NZi3yVU98+IoxvFdGbLEcqB+TpUfphM0sbwD+bsXK1donKIGyUfK mhVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710245200; x=1710850000; h=content-transfer-encoding:in-reply-to:organization:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Pkns7N7OuXavtu5iO/2DP6S0mePgQf87OV4oVWXFnn8=; b=sQYE7Shf9yEC0D511oYwDXh7rRJbwNBoJ4e6/llgvCVVhEFP4r3TE8Y94R4bvtfgac p3LBIzyJ8zZjF444nUWNJ1Bl+/x6qGnOG23oPSiAzoFnFxzIdw+9j5xNc69sBTTT1qYM SwOADzlb+HfavJ0hfaJmjv+PqLc93drAr3sQjRLGqqsbuEoRBqz4ibB/v60RlHn8DJ8K rM+ixooMMHKWCrlvO2CHhsz8wc1GMO0HPXygDqgxeIt6RpD0iB0RQfP1RBbWWzaDSMvs DGotHL6Uf//zFGRgq2wIXsdqO9sqp6kl37tvmBWgeDfa/0Z4scZ30BmlwW4AJpooOeEj hcrw== X-Gm-Message-State: AOJu0Yzr3967iM/YQzXeSk0idMNoHli1+d7+Nnjqi133BIOG1mNh4lvb 5lhPS4AsE4rMZy2LFPZ2f4zUnZGccYOMN6gNj3kD5Dp3RdO6zIpOPfC6pftTw+g= X-Google-Smtp-Source: AGHT+IFwJQXDWfZqIMhOyBbqLAzkDna7CUQdIMipX8Cb1Qm2GyavudWbluDFjVPJWoZfHA9Zzks3Pg== X-Received: by 2002:a17:902:f813:b0:1db:d13d:6bf3 with SMTP id ix19-20020a170902f81300b001dbd13d6bf3mr91223plb.62.1710245199755; Tue, 12 Mar 2024 05:06:39 -0700 (PDT) Received: from ?IPV6:2804:1b3:a7c2:8dfd:c57b:a149:38c:3b3e? ([2804:1b3:a7c2:8dfd:c57b:a149:38c:3b3e]) by smtp.gmail.com with ESMTPSA id b10-20020a170902d50a00b001dd54c4320esm3785752plg.256.2024.03.12.05.06.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 12 Mar 2024 05:06:38 -0700 (PDT) Message-ID: <33041603-e847-473e-908d-a0778eee10c7@linaro.org> Date: Tue, 12 Mar 2024 09:06:36 -0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Seeking advise on most portable way to detect 64-bit off_t Content-Language: en-US To: Aliaksey Kandratsenka Cc: libc-help@sourceware.org References: From: Adhemerval Zanella Netto Organization: Linaro In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-5.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,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: On 07/03/24 15:31, Aliaksey Kandratsenka wrote: > 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=64 and _FILE_OFFSET_BITS=64 at any point? Asking because it would break my code (thankfully, it won't be silent breaking, but still). It was on my plan when I we started to effectively work on 64 bit time_t, but we decided this would case too much potential breakage (as debian is finding out recently). So I think it is unlikely that we will even change it. > > Should I consider something else to make my code more robust ? > > On Mon, Mar 4, 2024 at 7:04 AM Adhemerval Zanella Netto > 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 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 + > > 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 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. > > [1] https://github.com/llvm/llvm-project/blob/main/compiler-rt/lib/sanitizer_common/sanitizer_platform_limits_posix.cpp#L15 >