- Jul 08, 2016
-
-
Peter Smith authored
This seems to be causing a buildbot failure on lld-x86_64-freebsd. Will reproduce locally and fix. llvm-svn: 274841
-
Peter Smith authored
Generalise the Mips LA25 Thunk code and implement ARM and Thumb interworking Thunks. - Introduce a new module Thunks.cpp to store the Target Specific Thunk implementations. - DefinedRegular and Shared have a ThunkData field to record Thunk. - A Target can have more than one type of Thunk. - Support PC-relative calls to Thunks. - Support Thunks to PLT entries. - Existing Mips LA25 Thunk code integrated. - Support for ARMv7A interworking Thunks. Limitations: - Only one Thunk per SymbolBody, this is sufficient for all currently implemented Thunks. - ARM thunks assume presence of V6T2 MOVT and MOVW instructions. Differential revision: http://reviews.llvm.org/D21891 llvm-svn: 274836
-
George Rimar authored
When building executable usually version script is absent. Before this patch error was shown in the case when symbol name contained version and there was no script to match it. Instead of error out patch allows to create new version declaration in this case and use it. gnu linkers do the same. That is PR28359. Differential revision: http://reviews.llvm.org/D21890 llvm-svn: 274828
-
Davide Italiano authored
llvm-svn: 274806
-
Rui Ueyama authored
Symbols.cpp contains functions to handle ELF symbols. demangle() function is essentially a function to work on a string rather than on an ELF symbol. So Strings.cpp is a better place to put that function. This change also make demangle to demangle symbols unconditionally. Previously, it demangled symbols only when Config->Demangle is true. llvm-svn: 274804
-
Rafael Espindola authored
But it was doing that for protected undefined symbols. llvm-svn: 274803
-
- Jul 07, 2016
-
-
Rafael Espindola authored
llvm-svn: 274757
-
Rafael Espindola authored
llvm-svn: 274755
-
George Rimar authored
Previously we had incorrect logic here. Imagine we would have the next script: LIBSAMPLE_1.0 { global: a_2; local: *; }; LIBSAMPLE_2.0 { global: a*; }; According to previous logic it would assign version 1 to a_2 and then would try to reassign it to version 2 because of applying wildcard a*. And show a warning about that. Generally Ian Lance Tailor wrote about next rules that should be applied: (http://www.airs.com/blog/archives/300) Here are the current rules for gold: "If there is an exact match for the mangled name, we use it. If there is more than one exact match, we give a warning, and we use the first tag in the script which matches. If a symbol has an exact match as both global and local for the same version tag, we give an error. Otherwise, we look for an extern C++ or an extern Java exact match. If we find an exact match, we use it. If there is more than one exact match, we give a warning, and we use the first tag in the script which matches. If a symbol has an exact match as both global and local for the same version tag, we give an error. Otherwise, we look through the wildcard patterns, ignoring “*” patterns. We look through the version tags in reverse order. For each version tag, we look through the global patterns and then the local patterns. We use the first match we find (i.e., the last matching version tag in the file). Otherwise, we use the “*” pattern if there is one. We give a warning if there are multiple “*” patterns." Patch makes wildcard matching to be in revered order and to follow after the regular naming matching. Differential revision: http://reviews.llvm.org/D21894 llvm-svn: 274739
-
Rui Ueyama authored
Previously, ch_size was read in host byte order, so if a host and a target are different in byte order, we would produce a corrupted output. llvm-svn: 274729
-
Rui Ueyama authored
llvm-svn: 274724
-
Rui Ueyama authored
warning() depends on Config->FatalWarnings, so we don't want to call that function before we initialize that member. llvm-svn: 274723
-
Rui Ueyama authored
llvm-svn: 274719
-
- Jul 06, 2016
-
-
Rafael Espindola authored
llvm-svn: 274690
-
Rafael Espindola authored
We don't relax it, but we at least recognize it. llvm-svn: 274687
-
Davide Italiano authored
Differential Revision: http://reviews.llvm/org/D22015 llvm-svn: 274684
-
Davide Italiano authored
Pointed out by: Rui Ueyama. llvm-svn: 274643
-
Rafael Espindola authored
Otherwise when extracting these files on a unix system one ends up with files named like "repro\bar\foo.o". llvm-svn: 274622
-
- Jul 04, 2016
-
-
Davide Italiano authored
llvm-svn: 274524
-
Davide Italiano authored
The build otherwise fails with: [ 39%] Building CXX object tools/lld/ELF/CMakeFiles/lldELF.dir/OutputSections.cpp.o /export/gnu/import/git/llvm/tools/lld/ELF/OutputSections.cpp: In member function ‘void lld::elf::GnuHashTableSection<ELFT>::addSymbols(std::vector<std::pair<lld::elf::SymbolBody*, long unsigned int> >&)’: /export/gnu/import/git/llvm/tools/lld/ELF/OutputSections.cpp:585:8: error: inconsistent deduction for ‘auto’: ‘auto’ and then ‘__gnu_cxx::__normal_iterator<std::pair<lld::elf::SymbolBody*, long unsigned int>*, std::vector<std::pair<lld::elf::SymbolBody*, long unsigned int> > >’ Reported by: H. J. Liu llvm-svn: 274518
-
Tom Stellard authored
Reviewers: arsenm, rafael, tony-tye, kzhuravl, ruiu Subscribers: llvm-commits, kzhuravl Differential Revision: http://reviews.llvm.org/D21481 llvm-svn: 274514
-
George Rimar authored
Bot failed: http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/14361/steps/check-lld%20msan/logs/stdio Fix: Initialize Config->FatalWarnings with false. As it might be used once a bit earlier than its initialization from command line arguments. llvm-svn: 274507
-
George Rimar authored
--fatal-warnings: Treat warnings as errors DIfferential revision: http://reviews.llvm.org/D21969 llvm-svn: 274504
-
- Jul 02, 2016
-
-
Rui Ueyama authored
llvm-svn: 274429
-
Rui Ueyama authored
Because the function works on relocations, it should be in Relocations.h instead of OutputSections.h. llvm-svn: 274428
-
Rui Ueyama authored
llvm-svn: 274426
-
- Jul 01, 2016
-
-
Davide Italiano authored
llvm-svn: 274383
-
George Rimar authored
This is PR28358 According to https://www.akkadia.org/drepper/dsohowto.pdf "The fourth point, the VERS 1.0 version being referred to in the VERS 2.0 definition, is not really important in symbol versioning. It marks the predecessor relationship of the two versions and it is done to maintain the similar- ities with Solaris’ internal versioning. It does not cause any problem it might in fact be useful to a human reader so predecessors should always be mentioned." Patch partially reverts 273423 "[ELF] - Implemented version script hierarchies.", version references are just ignored now. Differential revision: http://reviews.llvm.org/D21888 llvm-svn: 274345
-
Rui Ueyama authored
llvm-svn: 274343
-
Eugene Leviant authored
llvm-svn: 274342
-
- Jun 30, 2016
-
-
Rui Ueyama authored
In general, we accept both -foo and --foo as command line options, but if an option is a single letter option, we don't want to allow double dashes because GNU linkers don't accept such combination. llvm-svn: 274219
-
- Jun 29, 2016
-
-
Kevin Enderby authored
Matching change for lld for the llvm change of Archive::create() from ErrorOr<...> to Expected<...> in r274160. llvm-svn: 274161
-
Davide Italiano authored
Thanks to Sean Silva for the suggestion! llvm-svn: 274134
-
George Rimar authored
Option has next description (http://linux.die.net/man/1/ld): "--unresolved-symbols=method Determine how to handle unresolved symbols. There are four possible values for method according to documentation: ignore-all: Do not report any unresolved symbols. report-all: Report all unresolved symbols. This is the default. ignore-in-object-files: Report unresolved symbols that are contained in shared libraries, but ignore them if they come from regular object files. ignore-in-shared-libs: Report unresolved symbols that come from regular object files, but ignore them if they come from shared libraries." Since report-all is default and we traditionally do not report about undefined symbols in lld, report-all does not report about undefines from DSO. ignore-in-object-files also does not do that. Handling of that option differs from what gnu linkers do. Option works in next way in lld: ignore-all: Do not report any unresolved symbols. report-all: Report all unresolved symbols except symbols from DSOs. This is the default. ignore-in-object-files: The same as ignore-all. gnore-in-shared-libs: The same as report-all. This is PR24524. Differential revision: http://reviews.llvm.org/D21794 llvm-svn: 274123
-
George Rimar authored
Previously BC files were not checked for the same platform etc, That lead to confusing error "Invalid section header entry size (e_shentsize) in ELF header" when mixing files for different architectures. Patch fixes PR28324. Differential revision: http://reviews.llvm.org/D21832 llvm-svn: 274113
-
Rui Ueyama authored
llvm-svn: 274112
-
George Rimar authored
As was suggested by Rafael Espíndola. llvm-svn: 274111
-
Rui Ueyama authored
llvm-svn: 274109
-
Davide Italiano authored
So that users are not forced to pass `-m` on the command line when the inputs are all bitcode. PR: 28268 Differential Revision: http://reviews.llvm.org/D21779 llvm-svn: 274107
-
Rui Ueyama authored
llvm-svn: 274103
-