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
t is possible to create new version of symbol instead of depricated one
using combination of version script and asm commands. For example:
__asm__(".symver b_1,b@LIBSAMPLE_1.0");
int b_1() { return 10; }
__asm__(".symver b_2,b@@LIBSAMPLE_2.0");
int b_2() { return 20; }
This code makes b_2() to be default implementation for b().
b_1() is used for compatibility with binaries compiled against
library of older version LIBSAMPLE_1.0.
This patch implements support for above functionality in lld.
Differential revision: http://reviews.llvm.org/D21681
llvm-svn: 274002
The patch adds one more partition to the MIPS GOT. This time it is for
TLS related GOT entries. Such entries are located after 'local' and 'global'
ones. We cannot get a final offset for these entries at the time of
creation because we do not know size of 'local' and 'global' partitions.
So we have to adjust the offset later using `getMipsTlsOffset()` method.
All MIPS TLS relocations which need GOT entries operates MIPS style GOT
offset - 'offset from the GOT's beginning' - MipsGPOffset constant. That
is why I add new types of relocation expressions.
One more difference from othe ABIs is that the MIPS ABI does not support
any TLS relocation relaxations. I decided to make a separate function
`handleMipsTlsRelocation` and put MIPS TLS relocation handling code
there. It is similar to `handleTlsRelocation` routine and duplicates its
code. But it allows to make the code cleaner and prevent pollution of
the `handleTlsRelocation` by MIPS 'if' statements.
Differential Revision: http://reviews.llvm.org/D21606
llvm-svn: 273569
Patch by Shridhar Joshi.
This option provides names of all the link time modules which define and
reference symbols requested by user. This helps to speed up application
development by detecting references causing undefined symbols.
It also helps in detecting symbols being resolved to wrong (unintended)
definitions in case of applications containing multiple definitions for
same symbols with different types, bindings.
Implements PR28226.
llvm-svn: 273536
With fix:
-soname flag was not set in testcase. Hash calculated for base def was different on local
and bot machines because filename fos used for calculating.
Initial commit message:
Patch implements basic support of versioned symbols.
There is no wildcards patterns matching except local: *;
There is no support for hierarchies.
There is no support for symbols overrides (@ vs @@ not handled).
This patch allows programs that using simple scripts to link and run.
Differential revision: http://reviews.llvm.org/D21018
llvm-svn: 273152
Patch implements basic support of versioned symbols.
There is no wildcards patterns matching except local: *;
There is no support for hierarchies.
There is no support for symbols overrides (@ vs @@ not handled).
This patch allows programs that using simple scripts to link and run.
Differential revision: http://reviews.llvm.org/D21018
llvm-svn: 273143
Add support for the R_ARM_THM relocations used in the objects present
in arm-linux-gnueabihf-gcc. These are:
R_ARM_THM_CALL
R_ARM_THM_JUMP11
R_ARM_THM_JUMP19
R_ARM_THM_JUMP24
R_ARM_THM_MOVT_ABS
R_ARM_THM_MOVW_ABS_NC
Interworking between ARM and Thumb is partially supported with BLX.
The R_ARM_CALL relocation for ARM instructions and R_ARM_THM_CALL
relocation for Thumb instructions will write out a BL or BLX depending
on the state of the Target.
Assumptions:
- Availability of BLX and extended range of Thumb 4-byte Branch
instructions.
- In relocateOne if (Val & 0x1) == 1 target is Thumb, 0 is ARM.
This will hold for objects that comply with the ABI for the
ARM architecture.
This is sufficient for hello world to work with a recent
arm-linux-gnueabihf distribution.
Limitations:
No interworking for R_ARM_JUMP24, R_ARM_THM_JUMP24, R_ARM_THM_JUMP19
and the deprecated R_ARM_PLT32 and R_ARM_PC24 instructions as these
cannot be written out as a BLX and need a state change thunk.
No range extension thunks. The R_ARM_JUMP24 and R_ARM_THM_CALL have a
range of 16Mb
llvm-svn: 272881
This should never happen with correct programs, but it is trivial
write a testcase where lld would crash or report duplicated
symbols. We now behave like when an archive is used and include the
file only once.
llvm-svn: 272724
Add support for an ARM Target and the initial set of relocations
and PLT entries that are necessary for an ARM only hello world to
link. This has been tested against an ARM only sysroot from the
4.2.0 CodeSourcery Lite release.
Tests have been added to test/ELF for the support that has been
implemented.
Main limitations:
- No Thumb support
- Relocations incomplete
- No C++ exceptions support
- No TLS support
- No range extension or interworking veneer (thunk) support
- No Build Attribute support
- No Big-endian support
The deprecated relocations R_ARM_PLT32 and R_ARM_PC24 have been
implemented as these are used by the 4.2.0 CodeSourcery Lite release.
llvm-svn: 271993
MIPS .reginfo and .MIPS.options sections are consumed by the linker, and
the linker produces a single output section. But it is possible that
input files contain section symbol points to the corresponding input
section. In case of generation a relocatable output we need to write
such symbols to the output file.
Fixes bug 27878.
Differential Revision: http://reviews.llvm.org/D20688
llvm-svn: 270910
"A zero length string indicates that no augmentation data is present."
The FreeBSD/mips toolchain (GCC 4.2.1) generates .debug_frame sections
containing CIE records that have an empty augmentation string.
Differential Revision: http://reviews.llvm.org/D19928
llvm-svn: 270706
System V Application Binary Interface AMD64 Architecture Processor Supplement Draft Version 0.99.8
(https://github.com/hjl-tools/x86-psABI/wiki/x86-64-psABI-r249.pdf, B.2 "B.2 Optimize GOTPCRELX Relocations")
introduces possible relaxations for R_X86_64_GOTPCRELX and R_X86_64_REX_GOTPCRELX.
That patch implements the next relaxation:
mov foo@GOTPCREL(%rip), %reg => lea foo(%rip), %reg
and also opens door for implementing all other ones.
Implementation was suggested by Rafael Ávila de Espíndola with few additions and testcases by myself.
Differential revision: http://reviews.llvm.org/D15779
llvm-svn: 270705
Copy relocations are relocations to copy data from DSOs to
executable's .bss segment at runtime. It doesn't make sense to
create such relocations for zero-sized symbols.
GNU linkers don't agree with each other. ld rejects such
relocation/symbol pair. gold don't reject that but do not create
copy relocations as well. I took the former approach because
I don't think the latter is what user wants.
llvm-svn: 270525
We were creating the copy relocations just fine, but then thinking that
the .bss position could be preempted and creating a dynamic relocation
to it, which would crash at runtime since that memory is read only.
llvm-svn: 268668
These would just crash at runtime.
If we ever decide to support rw text segments this should make it easier
to implement as there is now a single point where we notice the problem.
I have tested this with a freebsd buildworld. It found a non pic
assembly file being linked into a .so,. With that fixed, buildworld
finished.
llvm-svn: 268149
We currently don't do a good job of diagnosing inputs that would require
dynamic relocations to be applied to read only segments.
I am about to improve lld in that area, but unfortunately we developed
tests that depend on the current behavior.
To make clear what is actually changing, this first patch just updates
tests to not depend on the current behavior. In most cases this just
means using a rw section instead of a ro one, but that unfortunately
changes many addresses.
llvm-svn: 268145
Previously each archive file was reported no matter were it's member used or not,
like:
lib/libLLVMSupport.a
Now lld prints line for each used internal file, like:
lib/libLLVMSupport.a(lib/Support/CMakeFiles/LLVMSupport.dir/StringSaver.cpp.o)
lib/libLLVMSupport.a(lib/Support/CMakeFiles/LLVMSupport.dir/Host.cpp.o)
lib/libLLVMSupport.a(lib/Support/CMakeFiles/LLVMSupport.dir/ConvertUTF.c.o)
That should be consistent with what gold do.
This fixes PR27243.
Differential revision: http://reviews.llvm.org/D19011
llvm-svn: 266220
Previously, Lazy symbols were created for undefined symbols even though
such symbols cannot be resolved by loading object files. This patch
fixes that bug.
llvm-svn: 265847
The spec says:
If a symbol definition with STV_PROTECTED visibility from a shared
object is taken as resolving a reference from an executable or another
shared object, the SHN_UNDEF symbol table entry created has STV_DEFAULT
visibility.
llvm-svn: 265792
For each copy relocation that we create, look through the DSO's symbol table
for aliases and create a dynamic symbol for each one. This causes the copy
relocation to correctly interpose any aliases.
Copy relocations are relatively uncommon (on my machine, 56% of binaries in
/usr/bin have no copy relocations probably due to being PIEs, 97% of them
have <10, and the binary with the largest number of them has 97) so it's
probably fine to do this in a relatively inefficient way.
Differential Revision: http://reviews.llvm.org/D18731
llvm-svn: 265354
The only way to get an object file with symbols marked by the STO_MIPS_PIC
flag is to link PIC and non-PIC object files and generate a relocatable
output using '-r' command line option. Now LLD is able to generate a relocatable
output but does not mark PIC symbols by the STO_MIPS_PIC flag. So I have
to use binary input mips-sto-pic.o generated by GNU BFD linker.
llvm-svn: 265310
Some targets might require creation of thunks. For example, MIPS targets
require stubs to call PIC code from non-PIC one. The patch implements
infrastructure for thunk code creation and provides support for MIPS
LA25 stubs. Any MIPS PIC code function is invoked with its address
in register $t9. So if we have a branch instruction from non-PIC code
to the PIC one we cannot make the jump directly and need to create a small
stub to save the target function address.
See page 3-38 ftp://www.linux-mips.org/pub/linux/mips/doc/ABI/mipsabi.pdf
- In relocation scanning phase we ask target about thunk creation necessity
by calling `TagetInfo::needsThunk` method. The `InputSection` class
maintains list of Symbols requires thunk creation.
- Reassigning offsets performed for each input sections after relocation
scanning complete because position of each section might change due
thunk creation.
- The patch introduces new dedicated value for DefinedSynthetic symbols
DefinedSynthetic::SectionEnd. Synthetic symbol with that value always
points to the end of the corresponding output section. That allows to
escape updating synthetic symbols if output sections sizes changes after
relocation scanning due thunk creation.
- In the `InputSection::writeTo` method we write thunks after corresponding
input section. Each thunk is written by calling `TargetInfo::writeThunk` method.
- The patch supports the only type of thunk code for each target. For now,
it is enough.
Differential Revision: http://reviews.llvm.org/D17934
llvm-svn: 265059
We have to check the final value that is written.
I don't think this has any real word implications (unless something
supports unaligned instructions), but unblocks simplifying the handling
of PC relative relocations.
llvm-svn: 265009
When R_X86_64_PC32/R_X86_64_32 relocations are
used against preemptible symbol and output is position independent,
error should be generated.
Differential revision: http://reviews.llvm.org/D18190
llvm-svn: 264707
For now just treat such sections as non-mergeable.
Resubmit r263660 with test fix.
Differential Revision: http://reviews.llvm.org/D18225
llvm-svn: 263664
-warn-common
Warn when a common symbol is combined with another common symbol
or with a symbol definition. Unix linkers allow this somewhat
sloppy practice, but linkers on some other operating systems do
not. This option allows you to find potential problems from
combining global symbols.
Differential revision: http://reviews.llvm.org/D17998
llvm-svn: 263413
It was causing errors like
/lib/libc.so.6 is incompatible with elf_x86_64
when linking on Fedora.
Every system has different default paths. It seems better to just trust
the driver to pass the correct -L options.
This reverts commit 262910.
llvm-svn: 262941
There was a known limitation for -r option:
relocations against local symbols were not supported.
For example rel[a].eh_frame sections contained relocations against sections
and that was not supported for -r before. Patch fixes that.
Differential review: http://reviews.llvm.org/D17813
llvm-svn: 262590
For shared libraries we allow any weak undefined symbol to eventually be
resolved, even if we never see a definition in another .so. This matches
the behavior when handling other undefined symbols in a shared library.
For executables, we require seeing a definition in a .so or resolve it
to zero. This is also similar to how non weak symbols are handled.
llvm-svn: 262017
This patch implements the same algorithm as LLD/COFF's ICF. I'm
not going to repeat the same description about how it works, so you
want to read the comment in ICF.cpp in this patch if you want to know
the details. This algorithm should be more powerful than the ICF
algorithm implemented in GNU gold. It can even merge mutually-recursive
functions (which is harder than one might think).
ICF is a fairly effective size optimization. Here are some examples.
LLD: 37.14 MB -> 35.80 MB (-3.6%)
Clang: 59.41 MB -> 57.80 MB (-2.7%)
The lacking feature is "safe" version of ICF. This merges all
identical sections. That is not compatible with a C/C++ language
requirement that two distinct functions must have distinct addresses.
But as long as your program do not rely on the pointer equality
(which is in many cases true), your program should work with the
feature. LLD works fine for example.
GNU gold implements so-called "safe ICF" that identifies functions
that are safe to merge by heuristics -- for example, gold thinks
that constructors are safe to merge because there is no way to
take an address of a constructor in C++. We have a different idea
which David Majnemer suggested that we add NOPs at beginning of
merged functions so that two or more pointers can have distinct
values. We can do whichever we want, but this patch does not
include neither.
http://reviews.llvm.org/D17529
llvm-svn: 261912
-r, -relocatable - Generate relocatable output
Currently does not have support for files containing
relocation sections with entries that refer to local
symbols (like rel[a].eh_frame which refer to sections
and not to symbols)
Differential revision: http://reviews.llvm.org/D14382
llvm-svn: 261838
A weak undefined should not fetch archive members, so we have to keep
the Lazy symbol.
That means the lazy symbol has to encode information about the original
weak undef.
Fixes pr25762.
llvm-svn: 261591
The patch adds lazy relocation support for MIPS and R_MIPS_26 relocation
handing.
R_MIPS_26 relocation might require PLT entry creation. In that case it
is fully supported by the patch. But if the relocation target is a local
symbol we need to use a different expression to calculate the relocation
result. This case is not implemented yet because there is no method to
get know the kind of relocation target in the `relocateOne` routine.
Differential Revision: http://reviews.llvm.org/D16982
llvm-svn: 260424
This is the function equivalent of a copy relocation.
Since functions are expected to change sizes, we cannot use copy
relocations. In situations where one would be needed, what is done
instead is:
* Create a plt entry
* Output an undefined symbol whose addr is the plt entry.
The dynamic linker makes sure any shared library uses the plt entry as
the function address.
llvm-svn: 260224
Summary:
LLVM3.3 (and earlier) would fail to include a relocation section in
the group that the section it was relocating is in. Object files
affected by this issue have been encountered in the wild when using LLD.
This would result in a siutation like:
Section {
Index: 5
Name: .text._Z3fooIiEvv (6)
Type: SHT_PROGBITS (0x1)
Flags [ (0x206)
SHF_ALLOC (0x2)
SHF_EXECINSTR (0x4)
SHF_GROUP (0x200)
]
Address: 0x0
Offset: 0x48
Size: 5
Link: 0
Info: 0
AddressAlignment: 1
EntrySize: 0
}
Section {
Index: 6
Name: .rela.text._Z3fooIiEvv (1)
Type: SHT_RELA (0x4)
Flags [ (0x0)
]
Address: 0x0
Offset: 0x3F0
Size: 24
Link: 8
Info: 5
AddressAlignment: 8
EntrySize: 24
}
In LLD, during symbol resolution, we discard the section containing the
weak symbol, but this amounts to replacing it with
InputSection<ELFT>::Discarded.
When we later saw the corresponding relocation section, we would then
end up pusing onto InputSection<ELFT>::Discarded.RelocSections, which is
bogus.
Reviewers: ruiu, rafael
Subscribers: llvm-commits, Bigcheese
Differential Revision: http://reviews.llvm.org/D16898
llvm-svn: 259831
If object files are drawn from archive files, the error message should
be something like "conflict symbols in foo.a(bar.o) and baz.o" instead
of "conflict symbols in bar.o and baz.o". This patch implements that.
llvm-svn: 259475
Main executable did not export symbols that exist both in the main executable and in DSOs before this patch.
Symbols from object files that override symbols in DSO should be added to .dynsym table.
Differential revision: http://reviews.llvm.org/D16405
llvm-svn: 258672
Added check for terminator CIE/FDE which has zero data size.
void EHOutputSection<ELFT>::addSectionAux(
...
// If CIE/FDE data length is zero then Length is 4, this
// shall be considered a terminator and processing shall end.
if (Length == 4)
break;
...
After this "Bug 25923 - lld/ELF2 linked application crashes if exceptions were used." is fixed for me. Self link of clang also works.
Initial commit message:
[ELF] - implemented --eh-frame-hdr command line option.
--eh-frame-hdr
Request creation of ".eh_frame_hdr" section and ELF "PT_GNU_EH_FRAME" segment header.
Both gold and the GNU linker support an option --eh-frame-hdr which tell them to construct a header for all the .eh_frame sections. This header is placed in a section named .eh_frame_hdr and also in a PT_GNU_EH_FRAME segment. At runtime the unwinder can find all the PT_GNU_EH_FRAME segments by calling dl_iterate_phdr.
This section contains a lookup table for quick binary search of FDEs.
Detailed info can be found here:
http://www.airs.com/blog/archives/462
Differential revision: http://reviews.llvm.org/D15712
llvm-svn: 257889
--eh-frame-hdr
Request creation of ".eh_frame_hdr" section and ELF "PT_GNU_EH_FRAME" segment header.
Both gold and the GNU linker support an option --eh-frame-hdr which tell them to construct a header for all the .eh_frame sections. This header is placed in a section named .eh_frame_hdr and also in a PT_GNU_EH_FRAME segment. At runtime the unwinder can find all the PT_GNU_EH_FRAME segments by calling dl_iterate_phdr.
This section contains a lookup table for quick binary search of FDEs.
Detailed info can be found here:
http://www.airs.com/blog/archives/462
Differential revision: http://reviews.llvm.org/D15712
llvm-svn: 257753
Fix: Added missed input file.
Initial commit message:
[ELF/AArch64] - Implemented R_AARCH64_TLSIE_ADR_GOTTPREL_PAGE21 and R_AARCH64_TLSIE_LD64_GOTTPREL_LO12_NC relocations
* R_AARCH64_TLSIE_ADR_GOTTPREL_PAGE21 is calculated as Page(G(GTPREL(S+A))) – Page(P), set an ADRP immediate field to bits [32:12] of X; check –2^32 ≤ X < 2^32;
* R_AARCH64_TLSIE_LD64_GOTTPREL_LO12_NC is calculated as G(GTPREL(S+A)), set an LD offset field to bits [11:3] of X. No overflow check; check that X&7 = 0.
Differential revision: http://reviews.llvm.org/D16117
llvm-svn: 257596
On Windows different versions of 'sed' work in different text/binary
mode by default. If default mode is text, sed produces corrupted binary
files. Unfortunately there is no standard command line option to select
the mode. Some 'sed' support '-b' to switch to binary mode, while other
ones support '--text' option and does not have '-b' option at all.
llvm-svn: 257471
On MIPS O32 ABI, _gp_disp is a magic symbol designates offset between
start of function and gp pointer into GOT. To make seal with such symbol
we add new method addIgnoredStrong(). It adds ignored symbol with global
binding to prevent the symbol substitution. The addIgnored call is not
enough here because this call adds a weak symbol which might be
substituted by symbol from shared library.
Differential Revision: http://reviews.llvm.org/D16084
llvm-svn: 257449
R_AARCH64_TSTBR14 is calculated as S+A-P,
Set the immediate field of a TBZ/TBNZ instruction to bits [15:2] of X; check -2^15 ≤ X < 2^15
Differential revision: http://reviews.llvm.org/D15824
llvm-svn: 257334
R_AARCH64_CONDBR19 is calculated as S+A-P,
Set the immediate field of a conditional branch instruction to bits [20:2] of X; check -2^20 ≤ X< 2^20.
Afaik there is no document for AARCH64 instruction encoding from official for unknown reason, so
I used gold source code and next link as a reference for implementation: http://kitoslab-eng.blogspot.ru/2012/10/armv8-aarch64-instruction-encoding.html. From which is clear that immediate field of a conditional branch instruction is 5 bits off. That is proved by output which is is equal to gold/bfd now.
Differential revision: http://reviews.llvm.org/D15809
llvm-svn: 257333
In this patch, all symbols are resolved normally and then wrap options
are applied. Renaming is implemented by mutating `Body` pointers of
Symbols. (As a result, Symtab.find(SymbolName)->getName() may return
a string that's different from SymbolName, but that is by design.
I designed the symbol and the symbol table to allow this kind of
operations.)
http://reviews.llvm.org/D15896
llvm-svn: 257075
@indntpoff is similar to @gotntpoff, but for use in position dependent code. While @gotntpoff resolves to GOT slot address relative to the
start of the GOT in the movl or addl instructions, @indntpoff resolves to the
absolute GOT slot address. ("ELF Handling For Thread-Local Storage", Ulrich Drepper).
Differential revision: http://reviews.llvm.org/D15494
llvm-svn: 255884
R_X86_64_SIZE64/R_X86_64_SIZE32 relocations were introduced in 0.98v of "System V Application Binary Interface x86-64" (http://www.x86-64.org/documentation/abi.pdf).
Calculation for them is Z + A, where:
Z - Represents the size of the symbol whose index resides in the relocation entry.
A - Represents the addend used to compute the value of the relocatable field.
Differential revision: http://reviews.llvm.org/D15335
llvm-svn: 255332
Implement the TLS relocation optimization for 32-bit x86 that is described in
"ELF Handling For Thread-Local Storage" by Ulrich Drepper, chapter 5,
"IA-32 Linker Optimizations". Specifically, this patch implements these
optimizations: LD->LE, GD->IE, GD->LD, and IE->LE.
Differential revision: http://reviews.llvm.org/D15292
llvm-svn: 255103
"Ulrich Drepper, ELF Handling For Thread-Local Storage" (5.5 x86-x64 linker optimizations, http://www.akkadia.org/drepper/tls.pdf) shows how GD can be optimized to IE.
This patch implements the optimization.
Differential revision: http://reviews.llvm.org/D15000
llvm-svn: 254713
ABI specifies the allowed range for these relocations as 2^(n-1) <= X < 2^n.
The patch fixes checks and introduces precise tests for these relocations.
Differential revision: http://reviews.llvm.org/D14957
llvm-svn: 254146
Rafael Espindola