<div dir="ltr">Oh, right, this stuff. I guess the non-windows solution might've been a volatile read, for instance? So maybe not so much that the general machinery isn't needed, but that perhaps MSVC does something interesting with a volatile read or whatever other solution might've been used.<br><br>Hmm, not sure why the whole file was added only when MSVC support was added - if it is a "static library object file selection" issue. Wouldn't that have turned up on other platforms before that moment?</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Nov 2, 2020 at 11:54 AM Michael Kruse 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">I am pretty sure this has nothing to do with Windows, but with static linking.<br>
<br>
When building an executable (opt, clang) we need to ensure that all<br>
the symbols are available in the artifact to ensure that a loaded<br>
plugin uses them. Otherwise the linker may discard object files from<br>
.a libraries that are not used by the executable itself, which only<br>
uses a subset of the functionality. In particular, one wants to ensure<br>
that all passes are available in the opt executable, even though no<br>
default pass pipeline does not reference a pass but can be added using<br>
the cl::opt mechanism.<br>
<br>
Michael<br>
<br>
<br>
Am Mo., 2. Nov. 2020 um 13:00 Uhr schrieb Luke Drummond via llvm-dev<br>
<<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>>:<br>
><br>
> 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>
_______________________________________________<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>