Revision tags: llvmorg-4.0.1-rc2, llvmorg-4.0.1-rc1 |
|
#
1df42fac |
| 24-Apr-2017 |
Eugene Zelenko <eugene.zelenko@gmail.com> |
[Object] Fix some Clang-tidy modernize and Include What You Use warnings; other minor fixes (NFC).
llvm-svn: 301275
|
#
b26bc7fd |
| 29-Mar-2017 |
Rafael Espindola <rafael.espindola@gmail.com> |
Add ifunc support to ModuleSymbolTable.
Do that by creating a global_values, which is similar to global_objects, but also iterates over aliases and ifuncs.
llvm-svn: 299018
|
#
d8204472 |
| 09-Mar-2017 |
Teresa Johnson <tejohnson@google.com> |
Perform symbol binding for .symver versioned symbols
Summary: In a .symver assembler directive like: .symver name, name2@@nodename "name2@@nodename" should get the same symbol binding as "name".
Wh
Perform symbol binding for .symver versioned symbols
Summary: In a .symver assembler directive like: .symver name, name2@@nodename "name2@@nodename" should get the same symbol binding as "name".
While the ELF object writer is updating the symbol binding for .symver aliases before emitting the object file, not doing so when the module inline assembly is handled by the RecordStreamer is causing the wrong behavior in *LTO mode.
E.g. when "name" is global, "name2@@nodename" must also be marked as global. Otherwise, the symbol is skipped when iterating over the LTO InputFile symbols (InputFile::Symbol::shouldSkip). So, for example, when performing any *LTO via the gold-plugin, the versioned symbol definition is not recorded by the plugin and passed back to the linker. If the object was in an archive, and there were no other symbols needed from that object, the object would not be included in the final link and references to the versioned symbol are undefined.
The llvm-lto2 tests added will give an error about an unused symbol resolution without the fix.
Reviewers: rafael, pcc
Reviewed By: pcc
Subscribers: mehdi_amini, llvm-commits
Differential Revision: https://reviews.llvm.org/D30485
llvm-svn: 297332
show more ...
|
Revision tags: llvmorg-4.0.0, llvmorg-4.0.0-rc4, llvmorg-4.0.0-rc3, llvmorg-4.0.0-rc2, llvmorg-4.0.0-rc1, llvmorg-3.9.1, llvmorg-3.9.1-rc3, llvmorg-3.9.1-rc2 |
|
#
d64ecf26 |
| 01-Dec-2016 |
Peter Collingbourne <peter@pcc.me.uk> |
Object: Set SF_Indirect in ModuleSymbolTable.
This lets us remove the last use of IRObjectFile::getSymbolGV() in llvm-nm.
Differential Revision: https://reviews.llvm.org/D27076
llvm-svn: 288321
|
#
e2f1b4a6 |
| 01-Dec-2016 |
Peter Collingbourne <peter@pcc.me.uk> |
Object: Add SF_Executable symbol flag.
This allows us to remove a few uses of IRObjectFile::getSymbolGV() in llvm-nm.
While here change host-dependent logic in llvm-nm to target-dependent logic.
D
Object: Add SF_Executable symbol flag.
This allows us to remove a few uses of IRObjectFile::getSymbolGV() in llvm-nm.
While here change host-dependent logic in llvm-nm to target-dependent logic.
Differential Revision: https://reviews.llvm.org/D27075
llvm-svn: 288320
show more ...
|
#
863cbfbe |
| 01-Dec-2016 |
Peter Collingbourne <peter@pcc.me.uk> |
Object: Extract a ModuleSymbolTable class from IRObjectFile.
This class represents a symbol table built from in-memory IR. It provides access to GlobalValues and should only be used if such access i
Object: Extract a ModuleSymbolTable class from IRObjectFile.
This class represents a symbol table built from in-memory IR. It provides access to GlobalValues and should only be used if such access is required (e.g. in the LTO implementation). We will eventually change IRObjectFile to read from a bitcode symbol table rather than using ModuleSymbolTable, so it would not be able to expose the module.
Differential Revision: https://reviews.llvm.org/D27073
llvm-svn: 288319
show more ...
|