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 10325 invoked from network); 30 Nov 2021 00:48:38 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 30 Nov 2021 00:48:38 -0000 Received: (qmail 5264 invoked by uid 550); 30 Nov 2021 00:48:37 -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 5232 invoked from network); 30 Nov 2021 00:48:36 -0000 Date: Mon, 29 Nov 2021 19:48:23 -0500 From: Rich Felker To: Norbert van Bolhuis Cc: musl@lists.openwall.com Message-ID: <20211130004822.GE7074@brightrain.aerifal.cx> References: <20211129173529.GC7074@brightrain.aerifal.cx> 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 Tue, Nov 30, 2021 at 12:15:59AM +0100, Norbert van Bolhuis wrote: > 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? The symbol there in 1.1.x didn't behave as needed to make 32-bit-off_t glibc code work. It just happened to be there as an alternate name for the 64-bit-off_t function __fxstat64 as a consequence of 32-bit archs not being special-cased. > 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? Right. Well, it might have 'worked' if it didn't actually inspect the fields of the structure, but since the 64-bit structure is larger than the object the caller provided, it was overflowing a buffer and probably clobbering other data. > 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? There's no way to support the 32-bit-off_t ABI with just a library, because the symbol names clash. It would require musl's dynamic linker to be specifically aware of foreign glibc libraries and remap their symbol references. This would be something of a cooperative project between musl and the folks working on gcompat to come up with a contract between them for making it all work -- something we've talked about as a vague future goal. Rich