std::env::args_os always returns an empty iterator in a musl+gcompat environment

[rjsberry]

I tried this code in Alpine Linux cross compiled to x86_64-unknown-linux-gnu:

use std::env;

fn main() {
    println!("{:?}", env::args_os().collect::<Vec<_>>());
}

For reference I ran this in a container on an M1 Macbook:

$ docker run --rm -it --platform linux/amd64 alpine
# apk add gcompat libgcc

I always see [] printed, even when I pass the program arguments.

I'm not sure this is an issue with the environment as the following C program works as expected:

#include <stdio.h>

int main(int argc, char **argv) {
    for (int i = 0; i < argc; i++) {
        printf("%d: %s\n", i, argv[i]);
    }
}

Meta

rustc +nightly --version --verbose:

rustc 1.79.0-nightly (becebb315 2024-04-17)
binary: rustc
commit-hash: becebb3158149a115cad8a402612e25436a7e37b
commit-date: 2024-04-17
host: aarch64-apple-darwin
release: 1.79.0-nightly
LLVM version: 18.1.3

[workingjubilee]

uh.

[workingjubilee]

@rjsberry Could you clarify: Does this problem arise with code ran on an ordinary gnu system? Say, a Debian container? Or x86_64-unknown-linux-musl itself?

[ChrisDenton]

I can take a guess at why this happens. For glibc targets we assume that the arguments can be retrieved without needing to store argc and argv. However if this musl compatibility layer doesn't use the .init_array then we can't retrieve them.

[workingjubilee]

Ah yeah, it seems that behavior is a GNU extension that Rich Felker doesn't want to support?

[workingjubilee]

Does env::args() just not work at all on musl if we're a cdylib, then?

[bjorn3]

Correct. When libstd's start function isn't used, env::args() only works on Windows, macOS and Linux with Glibc. On any other target it returns an empty list.

[workingjubilee]

Apparently we already have this comment:

rust/library/std/src/sys/pal/unix/args.rs

Lines 101 to 107 in 07d0d7c

	pub unsafe fn init(_argc: isize, _argv: *const *const u8) {
	// On Linux-GNU, we rely on `ARGV_INIT_ARRAY` below to initialize
	// `ARGC` and `ARGV`. But in Miri that does not actually happen so we
	// still initialize here.
	#[cfg(any(miri, not(all(target_os = "linux", target_env = "gnu"))))]
	really_init(_argc, _argv);
	}

In other words, we are already hacking around this issue for the miri emulator, and not using the fact that we are still given argv "naturally" via execve.

We should probably just unconditionally call really_init.

[bjorn3]

We should probably just unconditionally call really_init.

That would fix rust-lang/rustc_codegen_cranelift#1048 on Linux + glibc too.

[ChrisDenton]

Note that this was intentionally done #66547 but there have been other issues #105999

[workingjubilee]

@ChrisDenton I still think we can consider #105999 to still be fixed, as we just get our char **argv and it will be the same thing, even if the char*s behind the char** have been rearranged, right? So we'll set the atomics twice to the same value, which sounds very Working As Intended.

[workingjubilee]

One other thought: if we initialize arguments this way, we don't also need to initialize them in our main function in binaries. Can you compile out that code on linux-gnu?

— @joshtriplett in #66547 (review)

Well, given the remarks here seem to position this as a "wouldn't it be nice if we didn't do extra work?" and that this seems to be non-resilient in practice, as it has caused more than one open issue, I think we should be unafraid of doing a bit of extra computation.

[ChrisDenton]

I more meant that the fact that libraries mess about with (what should be) immutable memory is a safety issue so ideally we would parse it at the point where it's least likely that the are multiple threads. But people would probably complain about doing unnecessary allocating and extra work pre-main.

Just storing argc and argv should be cheap though so I'm definitely not arguing against that.

[workingjubilee]

the dilemma: strictly conforming posix programs shouldn't mutate argc and argv, but strictly conforming posix programs also shouldn't be aware of argc and argv if if they're dylibs, eh?

[joshtriplett]

Could we check, first, whether we've already had these initialized, and only call this in the unusual case where they're not initialized? That would avoid the extra work in the common case, and do the work in the unusual case.

[workingjubilee]

@joshtriplett I don't know what you mean? We aren't doing substantial extra work. The thing that costs the most in runtime startup, I expect, is having the static initializer at all, which we then don't get to make choices about whether its called. It simply is or isn't.

[joshtriplett]

@workingjubilee Nevermind: #124447 (comment) ; forgot that really_init was just saving off the values and not doing anything with them.