| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
| |
If we have 2 bitcode inputs for different targets, LLD would
print "<internal>" instead of the name of one of the files.
The patch adds a test and fixes this issue.
llvm-svn: 336794
|
|
|
|
|
|
|
|
|
|
|
|
| |
Patch by Matthew Koontz!
Before, direct calls to __wrap_sym would not map to valid PLT entries,
so they would crash at runtime. This change maps such calls to the same
PLT entry as calls to sym that are then wrapped.
Differential Revision: https://reviews.llvm.org/D48502
llvm-svn: 336609
|
|
|
|
|
|
| |
Requested during post commit review.
llvm-svn: 335447
|
|
|
|
|
|
|
| |
This avoids doing llvm::sort and std::unique for -wrap options.
I think it is more clean way.
llvm-svn: 335337
|
|
|
|
| |
llvm-svn: 332859
|
|
|
|
| |
llvm-svn: 332408
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Suppose we visit symbols in this order:
1. weak definition of foo in a lazy object
2. reference of foo
3 (optional). definition of foo
bfd/gold allows 123 but not 12.
Current --warn-backrefs implementation will report both cases as a backward reference. With this change, both 123 (intended) and 12 (unintended) are allowed. The usage of weak definitions usually imply there are also global definitions, so the trade-off is justified.
Reviewers: ruiu, espindola
Subscribers: emaste, arichardson, llvm-commits
Differential Revision: https://reviews.llvm.org/D46624
llvm-svn: 332061
|
|
|
|
|
|
|
|
| |
thinlto-prefix-replace
Differential Revision: https://reviews.llvm.org/D46034
llvm-svn: 331405
|
|
|
|
|
|
|
|
|
|
|
| |
Our code for LazyObject and LazyArchive duplicates.
This patch extracts the common part to remove
the duplication.
Differential revision: https://reviews.llvm.org/D45516
llvm-svn: 330701
|
|
|
|
|
|
|
|
|
|
|
|
| |
incoming one
Reviewers: ruiu, espindola
Subscribers: emaste, arichardson, llvm-commits
Differential Revision: https://reviews.llvm.org/D45905
llvm-svn: 330491
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I'm proposing a new command line flag, --warn-backrefs in this patch.
The flag and the feature proposed below don't exist in GNU linkers
nor the current lld.
--warn-backrefs is an option to detect reverse or cyclic dependencies
between static archives, and it can be used to keep your program
compatible with GNU linkers after you switch to lld. I'll explain the
feature and why you may find it useful below.
lld's symbol resolution semantics is more relaxed than traditional
Unix linkers. Therefore,
ld.lld foo.a bar.o
succeeds even if bar.o contains an undefined symbol that have to be
resolved by some object file in foo.a. Traditional Unix linkers
don't allow this kind of backward reference, as they visit each
file only once from left to right in the command line while
resolving all undefined symbol at the moment of visiting.
In the above case, since there's no undefined symbol when a linker
visits foo.a, no files are pulled out from foo.a, and because the
linker forgets about foo.a after visiting, it can't resolve
undefined symbols that could have been resolved otherwise.
That lld accepts more relaxed form means (besides it makes more
sense) that you can accidentally write a command line or a build
file that works only with lld, even if you have a plan to
distribute it to wider users who may be using GNU linkers. With
--check-library-dependency, you can detect a library order that
doesn't work with other Unix linkers.
The option is also useful to detect cyclic dependencies between
static archives. Again, lld accepts
ld.lld foo.a bar.a
even if foo.a and bar.a depend on each other. With --warn-backrefs
it is handled as an error.
Here is how the option works. We assign a group ID to each file. A
file with a smaller group ID can pull out object files from an
archive file with an equal or greater group ID. Otherwise, it is a
reverse dependency and an error.
A file outside --{start,end}-group gets a fresh ID when
instantiated. All files within the same --{start,end}-group get the
same group ID. E.g.
ld.lld A B --start-group C D --end-group E
A and B form group 0, C, D and their member object files form group
1, and E forms group 2. I think that you can see how this group
assignment rule simulates the traditional linker's semantics.
Differential Revision: https://reviews.llvm.org/D45195
llvm-svn: 329636
|
|
|
|
| |
llvm-svn: 329126
|
|
|
|
| |
llvm-svn: 329125
|
|
|
|
|
|
| |
r329092 broke buildbots.
llvm-svn: 329103
|
|
|
|
|
|
|
| |
Previously, fetchIfLazy did more than the name says. Now, setting
to UsedInRegularObj is moved to another function.
llvm-svn: 329092
|
|
|
|
|
|
|
|
|
| |
Patch removes Lazy class which
is just an excessive layer.
Differential revision: https://reviews.llvm.org/D45083
llvm-svn: 329086
|
|
|
|
|
|
|
|
| |
They are to pull out an object file for a symbol, but for a historical
reason the code is written in two separate functions. This patch
merges them.
llvm-svn: 329039
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes pr36623.
The problem is that we have to parse versions out of names before LTO
so that LTO can use that information.
When we get the LTO produced .o files, we replace the previous symbols
with the LTO produced ones, but they still have @ in their names.
We could just trim the name directly, but calling parseSymbolVersion
to do it is simpler.
llvm-svn: 328738
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
making them warnings.
We found that when you pass --allow-multiple-definitions or `-z muldefs`
to GNU linkers, they don't complain about duplicate symbols at all. They
don't even print out warnings on it. We emit warnings in that case.
If you pass --fatal-warnings, that difference results in a link failure.
Differential Revision: https://reviews.llvm.org/D44549
llvm-svn: 327920
|
|
|
|
|
|
|
|
|
|
|
|
| |
It looks like the problem that caused us to originally warn instead of
error was that of a symbol being assigned to the same version twice.
Now we don't warn if a symbol is assigned to the same version twice,
but error if it is assigned to multiple.
This fixes pr28342.
llvm-svn: 326813
|
|
|
|
|
|
|
| |
Since r321982 we don't set VersionId in scanShlibUndefined, which
makes InVersionScript redundant.
llvm-svn: 326641
|
|
|
|
|
|
|
| |
With the recent fixes these symbols have more in common than not with
regular undefined symbols.
llvm-svn: 326242
|
|
|
|
|
|
|
|
|
|
|
| |
referenced by DSOs.
It should be possible to resolve undefined symbols in dynamic libraries
using symbols defined in a linker script.
Differential Revision: https://reviews.llvm.org/D43011
llvm-svn: 326176
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We have an internal program that does't link without this patch. I don't
know of any open-source program that needs this, but there might be.
Since this patch improves compatibility with GNU linkers with a few lines
of code, I think it's worth to be committed.
The problem is about undefined symbols in DSOs. Some programs depend on
the GNU linkers' behavior that they pull out object files from archive
files to resolve undefined symbols in DSOs. We already allow that kind of
"reverse" dependency (from DSOs to the main executable) for regular
symbols, in particular, for "__progname" symbol (which is usually in
crt0.o), but that doesn't work if the symbol is in an archive file.
This patch is to make it work.
Differential Revision: https://reviews.llvm.org/D43658
llvm-svn: 325849
|
|
|
|
|
|
|
|
|
|
|
|
| |
There seems to be no reason to collect this list of symbols.
Also fix a bug where --exclude-libs would apply to all symbols that
appear in an archive's symbol table, even if the relevant archive
member was not added to the link.
Differential Revision: https://reviews.llvm.org/D43369
llvm-svn: 325380
|
|
|
|
|
|
|
|
| |
Previously, we accidentally dropped STB_WEAK bit from an undefined symbol
if there is a lazy object symbol with the same name. That caused a
compatibility issue with GNU gold.
llvm-svn: 325316
|
|
|
|
|
|
|
|
| |
It is currently interpreted as reinterpret_cast<>. Make it explicit.
Differential Revision: https://reviews.llvm.org/D43247
llvm-svn: 325033
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D42865
llvm-svn: 324145
|
|
|
|
|
|
|
|
|
|
|
|
| |
absolute symbols.
When there is a duplicate absolute symbol, LLD reports <internal>
instead of known object file name currently.
Patch fixes the issue.
Differential revision: https://reviews.llvm.org/D42636
llvm-svn: 323849
|
|
|
|
|
|
| |
Fixes PR36029.
llvm-svn: 323221
|
|
|
|
|
|
| |
In here too we want the computed output visibility.
llvm-svn: 322586
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
All other templated methods have explicit instantiations but this one is
missing. Discovered while building with a clang with inliner
modifications.
Reviewers: espindola
Subscribers: emaste, llvm-commits, davidxl
Differential Revision: https://reviews.llvm.org/D41847
llvm-svn: 322057
|
|
|
|
|
|
| |
The whole consists of the parts, not the other way around.
llvm-svn: 322042
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
LLD previously used to handle dynamic lists and version scripts in the
exact same way, even though they have very different semantics for
shared libraries and subtly different semantics for executables. r315114
untangled their semantics for executables (building on previous work to
correct their semantics for shared libraries). With that change, dynamic
lists won't set the default version to VER_NDX_LOCAL, and so resetting
the version to VER_NDX_GLOBAL in scanShlibUndefined is unnecessary.
This was causing an issue because version scripts containing `local: *`
work by setting the default version to VER_NDX_LOCAL, but scanShlibUndefined
would override this default, and therefore symbols which should have
been local would end up in the dynamic symbol table, which differs from
both bfd and gold's behavior. gold silently keeps the symbol hidden in
such a scenario, whereas bfd issues an error. I prefer bfd's behavior
and plan to implement that in LLD in a follow-up (and the test case
added here will be updated accordingly).
Differential Revision: https://reviews.llvm.org/D41639
llvm-svn: 321982
|
|
|
|
|
|
|
|
|
|
| |
We normally avoid "switch (Config->EKind)", but in this case I think
it is worth it.
It is only executed when there is an error and it allows detemplating
a lot of code.
llvm-svn: 321404
|
|
|
|
| |
llvm-svn: 321393
|
|
|
|
|
|
| |
It is never null.
llvm-svn: 321198
|
|
|
|
| |
llvm-svn: 321196
|
|
|
|
| |
llvm-svn: 321194
|
|
|
|
|
|
| |
Every shared symbol has a file, so we can use a reference.
llvm-svn: 321187
|
|
|
|
| |
llvm-svn: 321186
|
|
|
|
| |
llvm-svn: 321185
|
|
|
|
|
|
| |
The variable being casted was accessed in the previous line.
llvm-svn: 321140
|
|
|
|
|
|
|
|
|
|
| |
Specifically, libwidevinecdm.so in Chrome has such bad symbol.
It seems the BFD linker handles them as local symbols, so instead
of inserting them to the symbol table, we should skip them too.
Differential Revision: https://reviews.llvm.org/D41257
llvm-svn: 320770
|
|
|
|
|
|
|
| |
We would fail an assert if a shared library had a local symbol after
sh_info.
llvm-svn: 320667
|
|
|
|
|
|
|
|
|
|
|
|
| |
By using an index instead of a pointer for verdef we can put the index
next to the alignment field. This uses the otherwise wasted area and
reduces the shared symbol size.
By itself the performance change of this is in the noise, but I have a
followup patch to remove another 8 bytes that improves performance
when combined with this.
llvm-svn: 320449
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: pcc, ruiu
Subscribers: llvm-commits, emaste
Differential Revision: https://reviews.llvm.org/D40868
llvm-svn: 319860
|
|
|
|
|
|
| |
This particular reportDuplicate is only used with Defined.
llvm-svn: 319451
|
|
|
|
|
|
|
| |
We are already paying the cost of storing a InputFile in every
Symbol, so use it uniformly.
llvm-svn: 319378
|
|
|
|
|
|
|
| |
It was only used for --wrap and I don't think the fields with special
treatment had a meaningful impact on that feature.
llvm-svn: 319265
|