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=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 22695 invoked from network); 29 Nov 2021 17:35:46 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 29 Nov 2021 17:35:46 -0000 Received: (qmail 1123 invoked by uid 550); 29 Nov 2021 17:35: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 1090 invoked from network); 29 Nov 2021 17:35:43 -0000 Date: Mon, 29 Nov 2021 12:35:30 -0500 From: Rich Felker To: Norbert van Bolhuis Cc: musl@lists.openwall.com Message-ID: <20211129173529.GC7074@brightrain.aerifal.cx> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] no 32bit timestamp compatible stat/lstat/fstat? 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