- User Since
- Nov 16 2012, 5:35 PM (356 w, 2 d)
Feb 24 2015
Seems I'm the only one that wants this, abandoning. That's too bad. Standalone builds are really nice in component-oriented builds, especially when managing multiple build variations. Unfortunately, all my code that demonstrates this is locked inside our company. Oh well - perhaps another day.
LGTM. cmake_minimum_required() can be moved into the Standalone conditional, if that is ever added back in.
Feb 23 2015
Feb 21 2015
LLD is in an awkward limbo state where it acts like it's a first-class member of the LLVM tree and also acts like an independent project that only depends on LLVM for its Support and CMake libraries. If it wants to be the former, LLD should respect LLVM_TARGETS_TO_BUILD. If the latter, it doesn't matter and could have its own Targets.def. But if that's the case, LLD should have a standalone CMake build.
Feb 20 2015
Feb 19 2015
@kcc, I'll see what I can do. Let's continue this discussion on llvmdev. LLD is now free of ASan errors, but I haven't yet had a chance to evaluate MSan. By the looks of those scripts, I should probably fix up any MSan-reported bugs before lighting up that bot.
Feb 18 2015
To my knowledge, there isn't an ASan bot for LLD.
Cleanup, per Rafael's feedback.
Feb 17 2015
Can others please review? Thanks.
Feb 13 2015
Feb 5 2015
Thanks! Committed in r228351
Feb 3 2015
Jan 31 2015
Jan 30 2015
I think I was only looking at this from the perspective of the build and not from the developer. Since the two targets are conceptually distinct, I don't want to create confusion by merging the directories.
So it doesn't look like there's much interest in moving lld into the llvm repo, but I'd still like to move forward with supporting LLVM_TARGETS_TO_BUILD. Here's what needs to be done:
Jan 28 2015
No, we don't have to do this. We don't have to do anything. This is open source!
Jan 26 2015
Jan 23 2015
Should be fixed in r226989.
This version constructs the LinkingContext with static methods and a class factory. The previous version would blow up if a LinkingContext contained member variables.
Rui, any objections?
Jan 22 2015
This version leaves the targets' LinkingContext headers in their respective source directories and instead follows the pattern from the LLVM repo, which is to generate a header from the build configuration.
The reason I moved the headers is because the driver needs access each target's LinkingContext constructor. Before this patch, that code was in lldELF which created a cyclic dependency.
We could, but that would diverge from the way the LLVM repo is organized. I think a good compromise here would be to move all method implementations into each public header's respective .cpp file. Would you like me to do that as part of this patch?
Per Shankar, tuck all ELF includes in one header that the Driver then includes.
Jan 21 2015
Committed in r226732. Thanks!
Committed in r226702. Thanks!
There will be follow-up patches to continue fixing link-time dependences, but I'd prefer to land this one first to avoid rebasing. It aims to be noncontroversial, whereas experiments in the follow-up patches are starting to look pretty insane. I think it'll have to be broken up into smaller patches as well.
Rafael, now that the standalone CMake build is gone, we can assume lld is a subdirectory of the llvm source tree. I'd like to proceed as though the lld will eventually be fully integrated. We therefore do not need the feature of clang's wrapper, which is to retarget the install directory.
Jan 20 2015
Committed in r226643. Thanks!
Thanks. I'm afraid we won't be able to reassign the author field in the git mirror until the next llvm.org update. I'll go ahead and land this patch now.
To #1: that's why this patch stops here. We can move exactly this far before having that discussion.
Per Chandler, use add_llvm_library directly. Also, fix most of the shared library build on OS X. This is as much as I can fix without splitting the ReaderWriter library. I plan to do that right after this patch lands.
Thanks for your patience. Could you please rebase your change on the latest? r226557 changed the TargetRelocationHandler and removed unhandledReferenceType().
Jan 19 2015
Hi Denis, I've volunteered to land this patch. Due to the size of the contribution, I'd like to put some extra effort into ensuring that your name ends up in the Author field on the git mirror. If we're able to configure git-svn to do that, I hope we can have it done and this patch landed in the next day or two. If you'd rather see it land today and don't mind my name stamped all over "git blame" output, I can go ahead and pull the trigger immediately. Please let me know your preference.
Committed in r226473. Renato, I added the CHECK-LABEL you mentioned.
Jan 17 2015
Jan 16 2015
Jan 12 2015
Thanks Erik. Good test and looks consistent with the X86_64 implementation. I'll try to find one more person to review. Hopefully we can land this one soon.
Attempt 2: Use a regex that accepts any set of characters that ends in a [back]slash.