[CommandLine][Linux] Don't read argv from /proc/self/cmdline.

[al45tair]

Instead of reading from /proc/self/cmdline, take advantage of the fact that the initial stack layout is ABI specified, and that we already have a pointer into it (environ). This lets us walk up the stack until we find argc, at which point we also know where argv is.

We do this from a static initializer because a setenv() or putenv() can change environ (if you add a new environment variable), and it's even permissible to just outright change environ yourself too. It seems reasonable to suggest to people that they shouldn't be doing those things from a static initializer, and as long as they don't, they won't run before we've had a chance to find argv.

Just in case someone does do this, we also check that environ points into the stack. If it doesn't, they won't get any arguments, so if that happens, that's a clue that they're messing with environ too early.

This works around a problem (#69658) with Docker Desktop 4.25.0 and Rosetta, wherein we end up with an extra argument visible in /proc/self/cmdline, and also avoids allocating memory for the command line arguments.

rdar://117963394

[kateinoigakukun]

Can we just save argv/argc passed to main entrypoint by emit a runtime function call at the main? This is only for Linux, so introducing a new ABI function wouldn't be a big deal, I think.

For the record, Rust takes this saving-at-entry approach for some platforms including Linux. (but for Linux + glibc, they use the fact that glibc passes argv/argc/envp to init_array functions)

[al45tair]

Can we just save argv/argc passed to main entrypoint by emit a runtime function call at the main? This is only for Linux, so introducing a new ABI function wouldn't be a big deal, I think.

The problem with that is that the command line would only be available after main has started. Library code may want it before then, and indeed it looks like that would work just fine on Darwin, Windows, FreeBSD, OpenBSD and indeed WASI. It just wouldn't work on Linux.

Ideally, Swift should behave the same way everywhere.

[kateinoigakukun]

The problem with that is that the command line would only be available after main has started. Library code may want it before then

Ah, I see... Then it makes sense to depend on initial stack layout as libc-independent approach on Linux.

[al45tair]

For the record, Rust takes this saving-at-entry approach for some platforms including Linux. (but for Linux + glibc, they use the fact that glibc passes argv/argc/envp to init_array functions)

Yes. I'd be in favour of the save-at-entry approach if I was doing something like this from scratch, I think, because that's completely portable, whereas with this we're dependent on platform specifics.

As for the init_array behaviour, if every Linux libc did that, that would be the way to go. I think glibc and Bionic both do, but musl doesn't, sadly :-(

[al45tair]

@swift-ci Please smoke test Linux platform

[al45tair]

@swift-ci Please smoke test Linux platform

[al45tair]

@swift-ci Please smoke test Windows platform

[al45tair]

@swift-ci Please smoke test macOS platform

[mikeash]

huh

[Catfish-Man]

This is awful (laudatory)