This implementation is known to work in very simple cases (see new test case).
Details
Diff Detail
Event Timeline
This is very small amount code, and all the things seem to fit naturally to the existing things. Very nice.
COFF/InputFiles.cpp | ||
---|---|---|
255 | Use parentheses for ifs having elses for consistency. | |
265 | Ditto | |
COFF/InputFiles.h | ||
167 | Can you add a brief comment for this class saying that this is for LTO, just like I did for other classes? | |
173 | Use override instead of virtual. | |
176 | Add using llvm::LTOModule at beginning of this file. | |
181 | Name -> Filename. | |
COFF/SymbolTable.cpp | ||
65 | Move this piece of code after addArchive(ArchiveFile *) for consistent order. | |
193 | Remove this blank line. | |
197 | Use real type instead of auto. | |
210 | You want to cache size() -- for (unsigned I = 1, E = BitcodeFiles.size(), I != E ...) | |
218–236 | What does this code do? Why do we need to insert new Undefined symbols at this point? Ah, I think I understand what you are doing. LTO object file is added after all files are resolved, and at this moment we are about to add "duplicate" symbols, correct? Maybe a better approach is to tweak Defined::compare so that any symbol whose type is of DefinedBitcode always "win" over any other symbols. | |
238 | You want to return addFile's return value. | |
COFF/SymbolTable.h | ||
53 | Also mention that that this function is called after all files are added and before writer writes results to a file. | |
COFF/Symbols.cpp | ||
85 | Use new instead of make_unique with consistency with other lines in this function. |
COFF/SymbolTable.cpp | ||
---|---|---|
236 | On second thought, I'm now thinking that replacing DefinedBitcode symbols with regular defined symbols can be done without going through addFile. We have a list of symbols which need to be replaced, and we also have symbols in this file that should replace them. So we can just do that by overriding Symbol's Body pointers. Not sure which is better, so it's just an idea. |
COFF/SymbolTable.cpp | ||
---|---|---|
236 |
Correct.
Do you mean that non-DefinedBitcode symbols should win over DefinedBitcode symbols? I did consider that approach to start with, but the problem with that approach is that it would prevent us from diagnosing multiply defined symbols correctly. Consider the case where a.o (bitcode) and b.o (COFF) both define a strong symbol 'foo'. When linking a.o with b.o, when we add b.o we will need to diagnose a conflict between a DefinedBitcode and a DefinedRegular. When linking a.o on its own, we have exactly the same situation when we add the LTO object, but we shouldn't diagnose.
I prefer this approach. I'm a little concerned about duplication of logic between here and SymbolTable::resolve (especially once we add more COFF features), but maybe that should be dealt with later if it becomes a problem. |
Add a comment saying that initialize for LTO.