[llvm-dev] unusual use of getenv
Luke Drummond via llvm-dev
llvm-dev at lists.llvm.org
Mon Nov 2 10:49:04 PST 2020
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
More information about the llvm-dev
mailing list