Non-LFS functions on 32-bit platforms

[vt-alt]

As of 1.58.1 rustc compiles with non-LFS functions on 32-bit platforms.

Linux kernel have special 64-bit versions of some important syscalls that 32-bit programs could use if they want to access large files. In C (and glibc) there is transparent function & syscall replacement if program is compiled with -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64.
Example list of functions that should not be used and replaced with their 64-bit versions if LFS is enabled: fallocate fcntl fopen fstat fstatfs ftruncate getrlimit glob globfree lseek lstat mkstemp mmap open openat posix_fadvise posix_fallocate pread pwrite readdir setrlimit stat statfs. For example, instead of openat should be used openat64.

There are related issues:

• std: use more LFS functions on Linux #31668
• std: Use Android LFS off64_t, ftruncate64, and lseek64 #31805

But their solutions are seems incomplete.

Simplest reproducer:

$ cat main.rs
fn main() {}
$ rustc main.rs
$ nm main |grep 'U open'
         U open64@GLIBC_2.1
         U open@GLIBC_2.0

As you can see there is open present which mean that there is still non-LFS compliant usage.

[mochaaP]

This currently breaks musl libc builds at the linking stage.

https://github.com/bminor/musl/blob/f47a8cdd250d9163fcfb39bf4e9d813957c0b187/include/sys/mman.h#L144-L147

Please consider target_env = "musl" when using LFS functions.

[workingjubilee]

See also:

• Rust binding to LFS64 ABI-compat symbols rather than public names on musl libc libc#2934
• Alias all LFS64 symbols to their non-LFS64 counterparts on musl libc#2935

[workingjubilee]

Before:

nm hello | grep 'mmap'
                 U mmap64@GLIBC_2.2.5
                 U mmap@GLIBC_2.2.5

After #113176:

nm hello | grep 'mmap'
                 U mmap64@GLIBC_2.2.5

That PR brings in rust-lang/backtrace-rs#501 which should be the last subject of concern for Rust binaries, as it should have the correct fix for both glibc and musl. The libc alias shim should serve for addressing the immediate problem for code we emit as part of our bindings, and we can address how we want to update to move with any future libc changes as a separate subject.

Please let me know if we are actually secretly missing something, or reopen this issue if for some reason that PR fails.

[workingjubilee]

Also as a remark on possible false positives: we will likely still include a reference to open and not open64 on glibc because the getrandom crate, one of our dependencies in std, decided that use of the 32-bit version was acceptable because they only use it to interact with pulling bytes out of a device file and never seek inside it. This neatly solves any issues for musl. If this is mistaken for some other reason it should be opened as a separate issue, likely against their repo.