<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">FWIW, Raymond Chen recommended a slight variant of this technique as of 2015, using SetLastError: <a href="https://devblogs.microsoft.com/oldnewthing/20150102-00/?p=43233" class="">https://devblogs.microsoft.com/oldnewthing/20150102-00/?p=43233</a><div class=""><br class=""></div><div class="">—Owen<br class=""><div class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Nov 2, 2020, at 12:00 PM, David Blaikie via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">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 class=""><br class="">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 class=""><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" class="">llvm-dev@lists.llvm.org</a>> wrote:<br class=""></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 class="">
<br class="">
When building an executable (opt, clang) we need to ensure that all<br class="">
the symbols are available in the artifact to ensure that a loaded<br class="">
plugin uses them. Otherwise the linker may discard object files from<br class="">
.a libraries that are not used by the executable itself, which only<br class="">
uses a subset of the functionality. In particular, one wants to ensure<br class="">
that all passes are available in the opt executable, even though no<br class="">
default pass pipeline does not reference a pass but can be added using<br class="">
the cl::opt mechanism.<br class="">
<br class="">
Michael<br class="">
<br class="">
<br class="">
Am Mo., 2. Nov. 2020 um 13:00 Uhr schrieb Luke Drummond via llvm-dev<br class="">
<<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a>>:<br class="">
><br class="">
> Hi folks<br class="">
><br class="">
> I noticed something interesting when debugging a program that uses llvm<br class="">
> for JIT compilation.<br class="">
><br class="">
> Running `ltrace` surfaced a number of `getenv("bar")` calls coming from<br class="">
> llvm. It turns out these are not "real" `getenv` calls, but are an<br class="">
> optimization "do nothing" escape hatch which have been in<br class="">
> `llvm/include/llvm/LinkAllPasses.h` [for over 15years](1) - apparently<br class="">
> as a way to prevent the compiler eliminating symbol references to<br class="">
> optimization pass initialization functions. I took a look at the code<br class="">
> and couldn't really work out what issue is being solved as the commit<br class="">
> messages from 2005 have something to be desired ;)<br class="">
><br class="">
> I removed the whole function body from my local tree and `ninja check`<br class="">
> was happy in release mode (amd64-linux-gcc-10.2). Given its age, and the<br class="">
> fact that it's been through several iterations, I guess I've stumbled<br class="">
> upon a Chesterton Fence and would appreciate some input on whether this<br class="">
> is still needed. I see the original commit was Windows only, and was<br class="">
> then updated to use `getenv` as a way to support this behaviour<br class="">
> cross-platform.<br class="">
><br class="">
> It's more weird than pernicious given that nothing is done with the<br class="">
> result, but to me it feels dirty and confusing to query the process<br class="">
> environment in this way. As such, I wonder 3 things:<br class="">
><br class="">
> 1. Is this still needed? I don't know enough about the original<br class="">
> toolchains affected to know if the problem still exists, but my<br class="">
> limited testing shows that it doesn't seem to affect Linux<br class="">
> builds.<br class="">
> 2. If 1: Is there a better way e.g. define our own function that<br class="">
> can't be eliminated instead of `getenv` or use features of newer<br class="">
> language standards and toolchains introduced since 2005 that might<br class="">
> make the original problem go away on its own (I don't know what<br class="">
> these might be).<br class="">
> 3. If 1 and not 2: could we make it more obvious that this comes<br class="">
> from LLVM for those in my situation e.g.<br class="">
> `getenv("LLVM_IGNORE_THIS_GETENV")` or similar instead of the<br class="">
> unhelpful "bar" variable?<br class="">
><br class="">
> If it's no longer needed in any case, I can post a removal patch.<br class="">
><br class="">
> Any input is appreciated.<br class="">
><br class="">
> All the Best<br class="">
><br class="">
> Luke<br class="">
><br class="">
> [1] <a href="https://github.com/llvm/llvm-project/commit/00d5508496c1e#diff-7206f3725623127339dd17671577a6888ee3402d2e667ae9dd1457ea3600f4e7R3" rel="noreferrer" target="_blank" class="">https://github.com/llvm/llvm-project/commit/00d5508496c1e#diff-7206f3725623127339dd17671577a6888ee3402d2e667ae9dd1457ea3600f4e7R3</a><br class="">
><br class="">
> --<br class="">
> Codeplay Software Ltd.<br class="">
> Company registered in England and Wales, number: 04567874<br class="">
> Registered office: Regent House, 316 Beulah Hill, London, SE19 3HF<br class="">
> _______________________________________________<br class="">
> LLVM Developers mailing list<br class="">
> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a><br class="">
> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank" class="">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br class="">
_______________________________________________<br class="">
LLVM Developers mailing list<br class="">
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a><br class="">
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank" class="">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br class="">
</blockquote></div>
_______________________________________________<br class="">LLVM Developers mailing list<br class=""><a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a><br class="">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev<br class=""></div></blockquote></div><br class=""></div></div></body></html>