[llvm-dev] unusual use of getenv

[David Blaikie via llvm-dev]

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.

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?

On Mon, Nov 2, 2020 at 11:54 AM Michael Kruse via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> I am pretty sure this has nothing to do with Windows, but with static
> linking.
>
> When building an executable (opt, clang) we need to ensure that all
> the symbols are available in the artifact to ensure that a loaded
> plugin uses them. Otherwise the linker may discard object files from
> .a libraries that are not used by the executable itself, which only
> uses a subset of the functionality. In particular, one wants to ensure
> that all passes are available in the opt executable, even though no
> default pass pipeline does not reference a pass but can be added using
> the cl::opt mechanism.
>
> Michael
>
>
> Am Mo., 2. Nov. 2020 um 13:00 Uhr schrieb Luke Drummond via llvm-dev
> <llvm-dev at lists.llvm.org>:
> >
> > 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
> _______________________________________________
> 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/aba2de35/attachment.html>