[llvm-dev] unusual use of getenv

[Michael Kruse via llvm-dev]

I am pretty sure this has nothing to do with Windows, but with static linking.

When building an executable (opt, clang) we need to ensure that all
the symbols are available in the artifact to ensure that a loaded
plugin uses them. Otherwise the linker may discard object files from
.a libraries that are not used by the executable itself, which only
uses a subset of the functionality. In particular, one wants to ensure
that all passes are available in the opt executable, even though no
default pass pipeline does not reference a pass but can be added using
the cl::opt mechanism.

Michael


Am Mo., 2. Nov. 2020 um 13:00 Uhr schrieb Luke Drummond via llvm-dev
<llvm-dev at lists.llvm.org>:
>
> 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
>
> --
> Codeplay Software Ltd.
> Company registered in England and Wales, number: 04567874
> Registered office: Regent House, 316 Beulah Hill, London, SE19 3HF
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev