| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Reduced from a firefox build.
llvm-svn: 271950
|
|
|
|
| |
llvm-svn: 271815
|
|
|
|
|
|
| |
We were not handling page relative relocations.
llvm-svn: 271798
|
|
|
|
| |
llvm-svn: 270986
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
This reverts commit r270551.
Sorry, I commited the wrong branch :-(
llvm-svn: 270554
|
|
|
|
| |
llvm-svn: 270551
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
non-alloc input section
llvm-svn: 270328
|
|
|
|
| |
llvm-svn: 268976
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
It was getting out of sync if we had undefined symbols at the start of
the symbol table.
llvm-svn: 268077
|
|
|
|
|
|
| |
We were not producing them if the library had version info.
llvm-svn: 268060
|
|
|
|
|
|
|
|
| |
versioned DSOs.
Differential Revision: http://reviews.llvm.org/D19464
llvm-svn: 267775
|
|
|
|
|
|
|
| |
Since this semicolon existed in an early test file,
it has spread to many files.
llvm-svn: 267659
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D19517
llvm-svn: 267566
|
|
|
|
|
|
| |
Now that the support for the 'new' relocations is available.
llvm-svn: 267310
|
|
|
|
|
|
|
| |
Return the right expression for R_X86_64_GOTPCRELX and
R_X86_64_REX_GOTPCRELX.
llvm-svn: 266810
|
|
|
|
|
|
|
| |
It shows that we correctly look at liveness based on the final symbol
resolution.
llvm-svn: 266440
|
|
|
|
| |
llvm-svn: 266425
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
calculation. NFC.
llvm-svn: 266119
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
If a shared library has a protected symbol 'foo', that doesn't imply
that the symbol 'foo' in the output should be protected or not.
llvm-svn: 265794
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
Show that in addition to handling empty .eh_frame, it is merged with any
regular .eh_frame.
llvm-svn: 265588
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
| |
symbols. NFC.
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
|
|
|
|
|
|
|
| |
It had been created with a lld version that was producing an invalid
sh_info.
llvm-svn: 265305
|
|
|
|
| |
llvm-svn: 265139
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
| |
preemptible symbol when linking shared object.
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
|
|
|
|
|
|
|
|
|
| |
This reverts commit r263664.
The reason we were getting broken files was lld -r, and that has been
fixed.
llvm-svn: 263944
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 263238
|
|
|
|
|
|
|
|
| |
When the symbol can be preempted the error is not entirely accurate.
This just makes upcoming patches more readable.
llvm-svn: 262954
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
GNU ld and gold have these paths as default search paths.
If you don't want these directories, pass -nostdlib.
llvm-svn: 262910
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
relocatable output.
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
|