Fix CG_CLIF_JIT_ARGS on Linux, macOS and Windows

[bjorn3]

On Linux since 5c6bf83, the arguments passed to libstd by glibc when dlopening it are used, which are the arguments of the rustc process, not those in CG_CLIF_JIT_ARGS.

[bjorn3]

The same problem seems to exist on macOS and Windows. On macOS libstd uses _NSGetArgv. On Windows libstd uses GetCommandLineW.

[workingjubilee]

Hrm, can you explain this issue in more detail?

[bjorn3]

When in JIT mode, the CG_CLIF_JIT_ARGS env var is used to specify which arguments to pass to the main function of the jitted program. On most targets this will be reflected in the std::env::args() of the jitted program, however on Linux + glibc, macOS and Windows, libstd instead directly requests the arguments from the OS/libc, thus causing the arguments passed to rustc to be returned by std::env::args() instead. One potential fix would be to always respect the arguments passed to main and only request them from the OS/libc as fallback. This would result in slightly bigger programs however.

[workingjubilee]

Ah, thank you!

Yes, it will result in slightly bigger programs, but I think it is fine.

The test case then would be running rustc with the cranelift backend enabled and CG_CLIF_JIT_ARGS set and then checking if the return of std::env::args() has the desired args, or if it has the ones passed to rustc, yes?

[bjorn3]

Correct, that would be how to test it.

[bjorn3]

So, it turns out a couple of years ago in e86b954 I changed the jit code to intentionally skip over the libstd start function to fix #1151. I pushed a couple of fixes in c41a7db...4d6ac05, but have kept skipping the libstd start function. In any case I can confirm it works now with glibc if I stop skipping the libstd start function.