[llvm-dev] unusual use of getenv

[David Blaikie via llvm-dev]

Reid/Hans - you two happen to have any ideas what this device might've been
introduced to address on Windows 15 years ago? (possible that it was a real
issue back then, or even a misunderstanding that might've been common/you
might be aware of?)

On Mon, Nov 2, 2020 at 11:00 AM Luke Drummond via llvm-dev <
llvm-dev at lists.llvm.org> 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
>
> --
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20201102/05fc8f63/attachment.html>