[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 29 Nov 2021 12:35:30 -0500
From: Rich Felker <dalias@...c.org>
To: Norbert van Bolhuis <norbert.vanbolhuis@...ox.com>
Cc: musl@...ts.openwall.com
Subject: Re: 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 <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.
