<div dir="ltr">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?)</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Nov 2, 2020 at 11:00 AM Luke Drummond via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi folks<br>
<br>
I noticed something interesting when debugging a program that uses llvm<br>
for JIT compilation.<br>
<br>
Running `ltrace` surfaced a number of `getenv("bar")` calls coming from<br>
llvm. It turns out these are not "real" `getenv` calls, but are an<br>
optimization "do nothing" escape hatch which have been in<br>
`llvm/include/llvm/LinkAllPasses.h` [for over 15years](1) - apparently<br>
as a way to prevent the compiler eliminating symbol references to<br>
optimization pass initialization functions. I took a look at the code<br>
and couldn't really work out what issue is being solved as the commit<br>
messages from 2005 have something to be desired ;)<br>
<br>
I removed the whole function body from my local tree and `ninja check`<br>
was happy in release mode (amd64-linux-gcc-10.2). Given its age, and the<br>
fact that it's been through several iterations, I guess I've stumbled<br>
upon a Chesterton Fence and would appreciate some input on whether this<br>
is still needed. I see the original commit was Windows only, and was<br>
then updated to use `getenv` as a way to support this behaviour<br>
cross-platform.<br>
<br>
It's more weird than pernicious given that nothing is done with the<br>
result, but to me it feels dirty and confusing to query the process<br>
environment in this way. As such, I wonder 3 things:<br>
<br>
1. Is this still needed? I don't know enough about the original<br>
toolchains affected to know if the problem still exists, but my<br>
limited testing shows that it doesn't seem to affect Linux<br>
builds.<br>
2. If 1: Is there a better way e.g. define our own function that<br>
can't be eliminated instead of `getenv` or use features of newer<br>
language standards and toolchains introduced since 2005 that might<br>
make the original problem go away on its own (I don't know what<br>
these might be).<br>
3. If 1 and not 2: could we make it more obvious that this comes<br>
from LLVM for those in my situation e.g.<br>
`getenv("LLVM_IGNORE_THIS_GETENV")` or similar instead of the<br>
unhelpful "bar" variable?<br>
<br>
If it's no longer needed in any case, I can post a removal patch.<br>
<br>
Any input is appreciated.<br>
<br>
All the Best<br>
<br>
Luke<br>
<br>
[1] <a href="https://github.com/llvm/llvm-project/commit/00d5508496c1e#diff-7206f3725623127339dd17671577a6888ee3402d2e667ae9dd1457ea3600f4e7R3" rel="noreferrer" target="_blank">https://github.com/llvm/llvm-project/commit/00d5508496c1e#diff-7206f3725623127339dd17671577a6888ee3402d2e667ae9dd1457ea3600f4e7R3</a><br>
<br>
-- <br>
Codeplay Software Ltd.<br>
Company registered in England and Wales, number: 04567874<br>
Registered office: Regent House, 316 Beulah Hill, London, SE19 3HF<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>