That is consistent with other symbols: _edata, _etext
and can help to avoid duplicate code.
Differential revision: http://reviews.llvm.org/D18655
llvm-svn: 265129
This fixes bootstrap of llvm-tblgen (with LTO) and PR27150.
Slightly longer explanation follows.
Emission of .init_array instead of .ctors is supported only on a
subset of the Target LLVM supports. Codegen needs to be conservative
and always emit .ctors unless instructed otherwise (based on target).
If the dynamic linker sees .init_array it completely ignores
what's inside .ctors and therefore some constructors are not called
(and this causes llvm-tblgen to crash on startup).
Teach LLD/LTO about the Codegen options so we end up always emitting
.init_array and avoid this issue.
In future, we might end up supporting mix of .ctors and .init_array
in different input files if this shows up as a real-world use case.
The way gold handles this case is mapping .ctors from input into
.init_array in output. There's also another caveat because
as far as I understand .ctors run in reverse order so when we do
the copy/mapping we need to reverse copy in the output if there's
more than one ctor. That's why I'd rather avoid this complicate logic
unless there's a real need.
An analogous reasoning holds for .dtors/.fini_array.
llvm-svn: 265085
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
If we make R_MIPS_LO16 a relative relocation, linker:
- never creates R_MIPS_COPY relocation for it
- attempts to create R_MIPS_REL32 dynamic relocation if R_MIPS_LO16's
target is a preemptible symbol
Differential Revision: http://reviews.llvm.org/D18607
llvm-svn: 264956
gold and bfd do not include the undefined locals in symtab.
We have no reasons to support that either.
That fixes PR27016
Differential revision: http://reviews.llvm.org/D18554
llvm-svn: 264843
The original comments were separated by new code that is irrelevant to
the comment. This patch moves the comment to the right place and update it.
llvm-svn: 264816
This simplifies a few things
* Read the value as early as possible, instead of passing a pointer to
the location.
* Print the warning for missing pair close to where we find out it is
missing.
* Don't pass the value to relocateOne.
llvm-svn: 264802
Mips aligns PT_LOAD to 16 bits (0x10000). That means that the lower 16
bits are always the same, so we can, effectively, say that the
relocation is relative.
llvm-svn: 264761
Local symbol which requires GOT entry initialized by "page" address.
This address is high 16 bits of sum of the symbol value and the relocation
addend. In the relocation scanning phase final values of symbols are unknown
so to reduce number of allocated GOT entries do the following trick. Save
all output sections referenced by GOT relocations during the relocation
scanning phase. Then later in the `GotSection::finalize` method calculate
number of "pages" required to cover all saved output sections and allocate
appropriate number of GOT entries. We assume the worst case - each 64kb
page of the output section has at least one GOT relocation against it.
Differential Revision: http://reviews.llvm.org/D18349
llvm-svn: 264730
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
Some optimizations, e.g. SimplifyLibCalls, can replace functions with
others as part of the lowering, e.g. printf => puts.
The new symbols don't have the isUsedInRegularObj flag set so they
don't get included in the final symbol table (and dynamic symbol
table), and the dynamic linker gets confused. Include them as a fix.
Differential Revision: http://reviews.llvm.org/D18357
llvm-svn: 264688
IPO doesn't work very well across symbols referenced
by others TUs. The linker here tries to evaluate
which symbols are safe to internalize and switches
their linkage.
Differential Revision: http://reviews.llvm.org/D18415
llvm-svn: 264585
This patch simplifies the isRelRelative for AArch64 and add the missing
ones for bootstrap and test-suite. It also adds more testing for
shared object creation.
llvm-svn: 264322
Ensure we keep the symbol we need to before it reaches
the Writer (and hit an assertion), changing its linkage
from linkonce_odr to weak. For a more detailed description
of the problem, see PR19901 where a similar problem was
fixed for the gold plugin. Thanks to Rafael for providing
a testcase.
llvm-svn: 264111
The code for LTO has been growing, so now is probably a good time to
move it to its own file. SymbolTable.cpp is for symbol table, and
because compiling bitcode files are semantically not a part of
symbol table, this is I think a good thing to do.
http://reviews.llvm.org/D18370
llvm-svn: 264091
When a tls access is optimized, a group of relocations is converted at a
time.
We were already skipping relocations that were optimized out in
relocate, but not in scanRelocs.
This is a small optimization. I got here while working on a patch that
will always keep scanRelocs and relocate in sync.
llvm-svn: 264048
R_X86_64_GOTPCRELX and R_X86_64_REX_GOTPCRELX relocations were added in latest ABI:
https://github.com/hjl-tools/x86-psABI/wiki/x86-64-psABI-r249.pdf
They should be generated instead of R_X86_64_GOTPCREL for cases
when relaxation is possible. Currently this patch just process them in the
same way like R_X86_64_GOTPCREL. That should work for now
and we can implement relaxations later.
There is no testcases provided as I think there is no way to generate
such relocations using llvm-mc atm.
Differential revision: http://reviews.llvm.org/D18301
llvm-svn: 264043
Now local symbols have SymbolBody so we can handle all kind of symbols
in the GotSection::addEntry method. The patch moves the code from
addMipsLocalEntry to addEntry. NFC.
Differential Revision: http://reviews.llvm.org/D18302
llvm-svn: 264032
Just ignore the -rpath-link command line
option in the same way like gold do.
Behavior of lld/gold differs from gnu ld here.
GNU ld tries to resolve undefined symbols in all
shared object files at link time.
Differential revision: http://reviews.llvm.org/D18269
llvm-svn: 263876
This is required to get 'clang -flto' to work transparently
with lld. Please refer to the short comment in the code
for a more detailed explanation.
llvm-svn: 263862
-pie
--pic-executable
Create a position independent executable. This is currently only
supported on ELF platforms. Position independent executables are
similar to shared libraries in that they are relocated by the
dynamic linker to the virtual address the OS chooses for them
(which can vary between invocations). Like normal dynamically
linked executables they can be executed and symbols defined in the
executable cannot be overridden by shared libraries.
Differential revision: http://reviews.llvm.org/D18183
llvm-svn: 263693
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
George Rimar