[llvm-dev] unusual use of getenv

[Michael Kruse via llvm-dev]

Thanks for the heads-up. I didn't know there ever was a Visual Studio
project file in the repository.

Looking at opt at that time
(https://github.com/llvm/llvm-project/blob/00d5508496c1ec0540da5714b0ed66e64b623df5/llvm/tools/opt/opt.cpp),
there were no calls to initializeCore etc. That is, according to
static linking library rules
(http://www.lurklurk.org/linkers/linkers.html#staticlibs), opt would
not pass that are not added by a default pass manager level.

That is, unless the build system adds a flag
(https://github.com/llvm/llvm-project/blob/00d5508496c1ec0540da5714b0ed66e64b623df5/llvm/Makefile.rules#L302)
that forces all object files to be included. I don't know whether
-export-dynamic does that.

This potentially could also have been solved with the /WHOLEARCHIVE
command line flag for the Microsoft linker.

Michael

Am Di., 10. Nov. 2020 um 06:50 Uhr schrieb Luke Drummond
<luke.drummond at codeplay.com>:
>
> Hi Michael
>
> On Tue Nov 10, 2020 at 1:29 AM GMT, Michael Kruse wrote:
>
> > Am Mo., 2. Nov. 2020 um 14:01 Uhr schrieb David Blaikie
> > <dblaikie at gmail.com>:
> > > 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?
> >
> > It did turn up on non-Windows platforms in
> > https://reviews.llvm.org/D61446. The name of the file where this trick
> > is used "LinkAllPasses.h" should give a hint what it is used for.
> > Looking into the entire history of the file, I have no idea how one
> > would have concluded this whas a Windows thing. It first occurred in
> > 1c5b428ff8234cef705bf57bc1418deb4db25c83 (SVN r23921) when Windows
> > support was not yet a thing.
>
> I concluded this was a windows thing because the origin of the code
> seems to be in 00d5508496c1ec0540da5714b0ed66e64b623df5 which uses the
> windows only `GetCurrentProcess` instead of `getenv`. Chris Lattner then
> changed it to use `getenv` in 63e504ff437d88f0d4bdb0cd50b045655dea6ab1
> (svn r23915).
> 00d550849 is svn r19307 and predates 1c5b428ff823 by ~9 months. The
> "new header" patch you identified as the origin of this code seems to be a copy
> of the original. Reid Spencer then consolidated the two in the subsequent patch
> a3223665010b9a.
>
> That's as far as my archaeology went on this. It's possible that
> 00d550849 includes code copied from elsewhere, but to me it looks like
> 00d550849 is the canonical origin of this code.
>
> All the Best
>
> Luke
>
>
> --
> Codeplay Software Ltd.
> Company registered in England and Wales, number: 04567874
> Registered office: Regent House, 316 Beulah Hill, London, SE19 3HF