[llvm-dev] unusual use of getenv

[Johannes Doerfert via llvm-dev]

Last time I removed the getenv calls, as an Aprils fool joke btw [1],
I ended up with a compiler that was unable to do a stage 2 build, IIRC.

It might depend on the kind of build you do, e.g., static vs dynamic 
libraries.

~ Johannes


[1] https://lists.llvm.org/pipermail/llvm-dev/2019-April/131466.html


On 11/2/20 12:49 PM, Luke Drummond via llvm-dev wrote:
> Hi folks
>
> I noticed something interesting when debugging a program that uses llvm
> for JIT compilation.
>
> Running `ltrace` surfaced a number of `getenv("bar")` calls coming from
> llvm. It turns out these are not "real" `getenv` calls, but are an
> optimization "do nothing" escape hatch which have been in
> `llvm/include/llvm/LinkAllPasses.h` [for over 15years](1) - apparently
> as a way to prevent the compiler eliminating symbol references to
> optimization pass initialization functions. I took a look at the code
> and couldn't really work out what issue is being solved as the commit
> messages from 2005 have something to be desired ;)
>
> I removed the whole function body from my local tree and `ninja check`
> was happy in release mode (amd64-linux-gcc-10.2). Given its age, and the
> fact that it's been through several iterations, I guess I've stumbled
> upon a Chesterton Fence and would appreciate some input on whether this
> is still needed. I see the original commit was Windows only, and was
> then updated to use `getenv` as a way to support this behaviour
> cross-platform.
>
> It's more weird than pernicious given that nothing is done with the
> result, but to me it feels dirty and confusing to query the process
> environment in this way. As such, I wonder 3 things:
>
>      1. Is this still needed? I don't know enough about the original
>         toolchains affected to know if the problem still exists, but my
>         limited testing shows that it doesn't seem to affect Linux
>         builds.
>      2. If 1: Is there a better way e.g. define our own function that
>         can't be eliminated instead of `getenv` or use features of newer
>         language standards and toolchains introduced since 2005 that might
>         make the original problem go away on its own (I don't know what
>         these might be).
>      3. If 1 and not 2: could we make it more obvious that this comes
>         from LLVM for those in my situation e.g.
>         `getenv("LLVM_IGNORE_THIS_GETENV")` or similar instead of the
>         unhelpful "bar" variable?
>
> If it's no longer needed in any case, I can post a removal patch.
>
> Any input is appreciated.
>
> All the Best
>
> Luke
>
> [1] https://github.com/llvm/llvm-project/commit/00d5508496c1e#diff-7206f3725623127339dd17671577a6888ee3402d2e667ae9dd1457ea3600f4e7R3
>