I'm assuming that addGetSourcecodeSteps takes care of checking out the correct revision. From a cursory look at LLVMBuildFactory and the Buildbot documentation, this appears to be the case.
Fri, Oct 25
Sep 26 2019
Sep 25 2019
Sep 24 2019
Thanks! Removing unnecessary llvm:: prefix before commit.
@ruiu's comments (thanks!)
Sep 20 2019
@MaskRay's comments. Thanks! I've changed the original code to match.
Sep 19 2019
Sep 13 2019
I don't think we should keep flag help texts in sync where it doesn't make sense. "Archive" is posix terminology. It's true that "wholearchive" has "archive" in it, but its help text on msdn is "Include All Library Object Files" :)
Sep 12 2019
The help text for -start-lib and -end-lib matches that in the ELF linker. Please keep those matching by changing it there, too. Also, I think s/library/archive/, so that it matches the naming of -wholearchive.
Sep 3 2019
Aug 30 2019
Implemented ruiu's requests before committing. Thanks for reviewing!
Aug 29 2019
- allow mixing -start-lib and -wholearchive:
Aug 28 2019
- made AddMode an enum class
- simplified AddMode computation in OPT_INPUT case
- added missing std::moves
- use auto instead of explicitly naming LazyArchive
Aug 27 2019
Primarily, this change adds a LazyObject Symbol kind, and a LazyObjFile InputFile kind. A LazyObject represents a symbol defined in a LazyObjFile, and a LazyObjFile is either a native object file or a bitcode file that we know of, but have not yet decided to link in. As with the LazyArchive symbols we already had, when we encounter both a lazy symbol and an Undefined symbol, we resolve this by linking in the file that defines the symbol, so the result is a Defined symbol.
fix places where I needed to add handling of LazyObject symbols
Seeing the code here, I see I still need to handle LazyObject in symbol resolution.
Aug 26 2019
@ruiu, I'd like your opinion on this.
Related bug: https://bugs.llvm.org/show_bug.cgi?id=42717
Aug 21 2019
Aug 16 2019
changed flag name to -lto-obj-path:
Aug 12 2019
Landed in r368612 / d47622.
'll call the Config field ltoObjPath, same as in the ELF linker.
After discussion in person, we decided on -lto-obj-path: similar to the naming in the ELF linker, and we'
@rnk, what do you think of the name I proposed?
Aug 9 2019
Aug 8 2019
In ELF, the config name is ltoObjPath, and the flag is -plugin-opt=obj-path=
Aug 7 2019
Unfortunately, this causes some problems. It looks like the sections are created with different attributes than the original. This causes problems such as sections being writable when the original was read-only, including https://crbug.com/990942 where that causes program crashes. There is some more discussion on that bug report.
Aug 1 2019
Heh, I just missed the revert. @jdenny, feel free to use this as inspiration.
Jul 26 2019
Jul 25 2019
Jul 19 2019
replaced assert with llvm_unreachable
Jul 18 2019
Linking ThinLTO chrome.dll with an undefined symbol:
added comment explaining BitcodeFiles::instances.empty() check
addressed @ruiu's comments
Jul 17 2019
The basic idea here is:
don't process bitcode files in resolveRemainindUndefines
removed redundant check
Ready for review now.
Jul 15 2019
Simplified after rebasing on top of r366127.
Fix typo pointed out by MaskRay (thanks!)
Jul 11 2019
This was suggested on D64458.
rebased and updated variable naming convention
Just chiming in to say this change makes me very happy. I'm pleasantly surprised by how much easier to read I'm finding the code. Thanks for doing this!
new variable naming style
removed getThinLTOOutputFile identity function