From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-4.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, MAILING_LIST_MULTI,NICE_REPLY_A,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 8624 invoked from network); 30 Nov 2021 00:33:45 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 30 Nov 2021 00:33:45 -0000 Received: (qmail 31953 invoked by uid 550); 30 Nov 2021 00:33:43 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 5850 invoked from network); 29 Nov 2021 23:16:12 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evbox-com.20210112.gappssmtp.com; s=20210112; h=from:subject:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=jf2iMgDkFIth5SwsBPYiygU+GXsCtCu5atZ+tQdqw+o=; b=wPaxXAhaH2K64DswLi19hdz2yt3EWZT4VUTOfvwXm7kW2FLSycVXgcJdFpuFWWQDsB exWJFPPp2RfyDDIUwFc1WAzspRvB0ggwXpItoFUBOLNXrBgksAjqIqkvuBbwS1huD1nU f08JdbfUQRtCYgUTYrpI8To2vU0QzqOCtm8ukkaY63Rtv6LcTNoDbKQ6rH44FlBfBOms GNu8n92Kl1dtWpdzG04IEcoIfIB3iR/HpA3wJWMjcnSKAFI1opsLrNI+GV37pn6bSz6K T1XiNEEExHcXBMwvmT55CKMP3+n9p2H4x7j7DVXI9TkdCHmSL3ydmf8q1sXBB7TPfblN iEnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:subject:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=jf2iMgDkFIth5SwsBPYiygU+GXsCtCu5atZ+tQdqw+o=; b=d/7srd8/8OGTos1XZ+oiQ9OpTjGoY3rtUjymWNnOzAtOFjFka0SJnf7Lwt4cYDoB7S hvZiWCTNxea1A0vItSHGwKpb557kEf7zqInsgPKiunULnmvD9T9lqFuU73H+8YO+eNh+ M+xNbAD4hNFliC3nu6AS3UeT++Uq2B9IgH5IkScdrMnlW/LeGj4nc5hzZzCpkyb9DsUu 0lH2uHlJaNbr+UgUqkp/yeZhqQXj7Rkrtl3M+ssgGrvNCOIx3uNkUGX3CPwfc1Paxm0Q CmX0TDsY/GiTKyd5WfkQwgCVMn5cAY0DQK8lsI6BBwrdPEthlrnMLD0tS9nB90rOBOSp jhVQ== X-Gm-Message-State: AOAM531vR8wSAOYcbKMUFdvEOCSHutNJtFnqZnwcAjJAKMqLPMGUrfql pJiBhqweb063m04qwpmKiHZAPg== X-Google-Smtp-Source: ABdhPJw/zS4Yjbqlq+QrCztnw2QbojMplmYTpzGzj+BfzCPJW2pyq8DANfkifX2hsTfuY+8uSz2VUQ== X-Received: by 2002:a05:6402:1292:: with SMTP id w18mr77951266edv.46.1638227761345; Mon, 29 Nov 2021 15:16:01 -0800 (PST) From: Norbert van Bolhuis X-Google-Original-From: Norbert van Bolhuis To: Rich Felker , Norbert van Bolhuis Cc: musl@lists.openwall.com References: <20211129173529.GC7074@brightrain.aerifal.cx> Message-ID: Date: Tue, 30 Nov 2021 00:15:59 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: <20211129173529.GC7074@brightrain.aerifal.cx> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [musl] no 32bit timestamp compatible stat/lstat/fstat? Hi Rich, Thanks for your answer! Ah, it's about 32-bit off_t compatibility, but then why does musl-1.1.24 (and the corresponding libc6-compat package on Alpine 3.12) provide this (ancient) __fxstat function? So this can never work properly and the reason why it worked with Alpine 3.12 (musl-1.1.24) is that the 3rd-party binary never really used __fxstat (because there is no way the 64-bit structure is compatible with the 32-bit one), right? Glibc does provide the ancient 32-bit variant, see: nm -D --defined-only /lib/arm-linux-gnueabihf/libc.so.6 | grep __fxstat 00093e68 T __fxstat 00093fdc T __fxstat64 000942a4 T __fxstatat 00094320 T __fxstatat64 I would expect musl libc6-compat package to provide it, why it doesn't? Anyway, I'll certainly ask the provider of the 3rd-party binary to recompile with -D_FILE_OFFSET_BITS=64. I may lookup this ancient 32-bit 'struct stat' and write a shim, another short-term "solution" is to simply return EOVERFLOW. This will tell me if __fxstat is called anywayr. Right now I have no idea, it sure looks like we don't need it for our use-case since we never had an issue with musl-1.1.x. Regards, Norbert On 11/29/21 6:35 PM, Rich Felker wrote: > On Mon, Nov 29, 2021 at 02:11:47PM +0100, Norbert van Bolhuis wrote: >> Hi All, >> >> Why does musl-1.2.x not offer the 32bit timestamp compatible stat/lstat/fstat? >> >> We're using a 3rd-party binary (compiled against glibc) on an arm32v7 platform >> which fails to execute ever since we jumped from musl v1.1.x to 1.2.x, see: >> >> / # wl >> Error relocating /usr/sbin/wl: __fxstat: symbol not found > > This is not the glibc symbol for 32-bit time_t but for 32-bit off_t, a > very bad legacy ABI that musl has never supported and that shouldn't > be used. Since it was not compiled with -D_FILE_OFFSET_BITS=64, any > calls from this code to functions that take off_t, or structures > containing off_t, will be wrong. If the only such functions are the > stat family, you can probably make shims to convert and make it work. > If it has calls to other functions like lseek, etc., then you may need > to also patch the binary to call shims for those. > > Of course the best and easiest solution if possible would be to get > the provider of this library to recompile it properly with > -D_FILE_OFFSET_BITS=64, since without that it cannot handle large > files or filesystems where inode numbers may not fit in 32 bits. This > problem has nothing to do with musl; it's already a problem if you're > using their code on glibc. > >> The arm32v7 glibc-2.3x (working with 64bit timestamps) does provide them. >> >> Looking at: https://www.openwall.com/lists/musl/2019/08/01/1 >> it seems this is a known limitation. > > No, this was resolved, and it's a different issue: allowing > glibc-built code to call the "lfs64" (_FILE_OFFSET_BITS=64) glibc > names for the 64-bit off_t functions rather than their unadorned names > (which is what musl uses natively since off_t is always 64-bit). > >> >> Any plans on fixing this? >> >> I solved my case by preloading a shared library for which the source is: >> >> >> #include >> >> extern int __fxstat64(int ver, int fd, struct stat32 *buf); >> >> int __fxstat(int ver, int fd, struct stat32 *buf) >> { >> return __fxstat64(ver, fd, buf); >> } > > That's insufficient because __fxstat is not expected to write the > version of the structure __fxstat64 would write. It's expected to > write some ancient legacy version of the sturcture (from the 1990s) > where the offset and inode fields are only 32-bit. A working shim > would require looking up (in the glibc headers) what that format is, > and writing the code to convert on success. > > Rich >