This requires knowing input section offsets in output sections before
scanRelocs. This is generally a good thing and should allow further
simplifications in the creation of dynamic relocations.
llvm-svn: 265673
We have to differentiate undefined symbols from bitcode and undefined
symbols from other sources.
Undefined symbols from bitcode should not inhibit the symbol being
internalized. Undefined symbols from other sources should.
llvm-svn: 265536
ELF and program header are not part of OutputSections list anymore.
That helps to avoid having and working with functions like dummySectionsNum().
Still keeping them as sections helps to simplify the code.
Differential revision: http://reviews.llvm.org/D18743
llvm-svn: 265522
Where Clang's AArch64 backend seems to differ from the X86 backend is
that it tends to use the GOT more aggressively.
After getting CloudABI PIEs working on x86-64, I noticed that accessing
global variables would still crash on aarch64. Tracing it down, it turns
out that the GOT was filled with entries assuming the base address was
zero.
It turns out that we skip generating relocations for GOT entries in case
the relocation pointing towards the GOT is relative. Whether the thing
pointing to the GOT is absolute or relative shouldn't make any
difference; the GOT entry itself should contain the absolute address,
thus needs a relocation regardless.
Approved by: rafael
Differential Revision: http://reviews.llvm.org/D18739
llvm-svn: 265453
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
Our symbol representation was redundant, and some times would get out of
sync. It had an Elf_Sym, but some fields were copied to SymbolBody.
Different parts of the code were checking the bits in SymbolBody and
others were checking Elf_Sym.
There are two general approaches to fix this:
* Copy the required information and don't store and Elf_Sym.
* Don't copy the information and always use the Elf_Smy.
The second way sounds tempting, but has a big problem: we would have to
template SymbolBody. I started doing it, but it requires templeting
*everything* and creates a bit chicken and egg problem at the driver
where we have to find ELFT before we can create an ArchiveFile for
example.
As much as possible I compared the test differences with what gold and
bfd produce to make sure they are still valid. In most cases we are just
adding hidden visibility to a local symbol, which is harmless.
In most tests this is a small speedup. The only slowdown was scylla
(1.006X). The largest speedup was clang with no --build-id, -O3 or
--gc-sections (i.e.: focus on the relocations): 1.019X.
llvm-svn: 265293
Extracts code for initializing dummies sections
to avoid possible duplication in following patches.
Differential review: http://reviews.llvm.org/D18691
llvm-svn: 265159
Some functions in Writer reports error using HasError, and some reports
their return values. This patch makes them to consistently use HasError.
llvm-svn: 265156
fixAbsoluteSymbols fixes linker-created symbol addresses. Since we don't
create such symbols for relocatable output, we don't need to call this
function.
llvm-svn: 265154
assignAddressesRelocatable function did not set addresses to sections
despite its name. What it actually did is to set file offsets to sections.
assignAddresses function assigned addresses and file offsets to sections.
So there was a confusion what they were doing, and they had duplicate code.
This patch separates file offset assignments from address assignments.
A new function, assignFileOffsets assign file offsets. assignAddresses
do not care about file offsets anymore.
llvm-svn: 265151
The extra fix is to note that it still requires copy relocations.
Original message:
Change how we handle R_MIPS_LO16.
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.
P.S.: Suggestions for a better name for the predicate are welcome :-)
llvm-svn: 265150
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
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
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
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
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
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
-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
We want to make SymbolBody the central place to query symbol information.
This patch also renames canBePreempted to isPreemptible because I feel that
the latter is slightly better (the former is three words and the latter
is two words.)
llvm-svn: 263386
