[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <dffe8309-6a9c-149d-ceb2-24ea285712bc@ev-box.com>
Date: Tue, 30 Nov 2021 00:15:59 +0100
From: Norbert van Bolhuis <norbert.vanbolhuis@...ox.com>
To: Rich Felker <dalias@...c.org>,
Norbert van Bolhuis <norbert.vanbolhuis@...ox.com>
Cc: musl@...ts.openwall.com
Subject: Re: 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 <sys/stat.h>
>>
>> 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
>
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
