MipsReginfoInputSection is basically just a container of Elf_Mips_Reginfo
struct. This patch makes that struct directly accessible from others.
llvm-svn: 256984
The R_MIPS_GPREL16 / R_MIPS_GPREL32 relocations use the following
expressions for calculations:
```
local symbol: S + A + GP0 - GP
global symbol: S + A - GP
GP - Represents the final gp value, i.e. _gp symbol
GP0 - Represents the gp value used to create the relocatable object
```
The GP0 value is taken from the .reginfo data section defined by an object
file. To implement that I keep a reference to `MipsReginfoInputSection`
in the `ObjectFile` class. This reference is used by the
`ObjectFile::getMipsGp0` method to return the GP0 value.
Differential Revision: http://reviews.llvm.org/D15760
llvm-svn: 256416
MIPS .reginfo section provides information on the registers used by
the code in the object file. Linker should collect this information and
write .reginfo section in the output file. This section contains a union
of used registers masks taken from input .reginfo sections and final
value of the `_gp` symbol.
For details see the "Register Information" section in Chapter 4 in the
following document:
ftp://www.linux-mips.org/pub/linux/mips/doc/ABI/mipsabi.pdf
The patch implements .reginfo sections handling with a couple missed
features: a) it does not put output .reginfo section into the separate
REGINFO segment; b) it does not merge `ri_cprmask` masks from input
section. These features will be implemented later.
Differential Revision: http://reviews.llvm.org/D15669
llvm-svn: 256119
Some MIPS relocations including `R_MIPS_HI16/R_MIPS_LO16` use combined
addends. Such addend is calculated using addends of both paired relocations.
Each `R_MIPS_HI16` relocation is paired with the next `R_MIPS_LO16`
relocation. ABI requires to compute such combined addend in case of REL
relocation record format only.
For details see p. 4-17 at
ftp://www.linux-mips.org/pub/linux/mips/doc/ABI/mipsabi.pdf
This patch implements lookup of the next paired relocation suing new
`InputSectionBase::findPairedRelocLocation` method. The primary
disadvantage of this approach is that we put MIPS specific logic into
the common code. The next disadvantage is that we lookup `R_MIPS_LO16`
for each `R_MIPS_HI16` relocation, while in fact multiple `R_MIPS_HI16`
might be paired with the single `R_MIPS_LO16`. From the other side
this way allows us to keep `MipsTargetInfo` class stateless and implement
later relocation handling in parallel.
This patch does not support `R_MIPS_HI16/R_MIPS_LO16` relocations against
`_gp_disp` symbol. In that case the relocations use a special formula for
the calculation. That will be implemented later.
Differential Revision: http://reviews.llvm.org/D15112
llvm-svn: 254461
This adds support for:
* Uniquing CIEs
* Dropping FDEs that point to dropped sections
It drops 657 488 bytes from the .eh_frame of a Release+Asserts clang.
The link time impact is smallish. Linking clang with a Release+Asserts
lld goes from 0.488064805 seconds to 0.504763060 seconds (1.034 X slower).
llvm-svn: 252790
Section garbage collection is a feature to remove unused sections
from outputs. Unused sections are sections that cannot be reachable
from known GC-root symbols or sections. Naturally the feature is
implemented as a mark-sweep garbage collector.
In this patch, I added Live bit to InputSectionBase. If and only
if Live bit is on, the section will be written to the output.
Starting from GC-root symbols or sections, a new function, markLive(),
visits all reachable sections and sets their Live bits. Writer then
ignores sections whose Live bit is off, so that such sections are
excluded from the output.
This change has small negative impact on performance if you use
the feature because making sections means more work. The time to
link Clang changes from 0.356s to 0.386s, or +8%.
It reduces Clang size from 57,764,984 bytes to 55,296,600 bytes.
That is 4.3% reduction.
http://reviews.llvm.org/D13950
llvm-svn: 251043
Given the name, it is natural for this function to compute the full target.
This will simplify SHF_MERGE handling by allowing getLocalRelTarget to
centralize the addend logic.
llvm-svn: 250731
This patch is to use ELFT instead of Is64Bits to template OutputSection
and its subclasses. This increases code size slightly because it creates
two identical functions for some classes, but that's only 20 KB out of
33 MB, so it's negligible.
This is as per discussion with Rafael. He's not fan of the idea but OK
with this. We'll revisit later to this topic.
llvm-svn: 250466
When a relocation points to a SHF_MERGE section, the addend has special meaning.
It should be used to find what in the section the relocation points to. It
should not be added to the output position.
Centralizing it means that the above rule will be implemented once, not once
per target.
llvm-svn: 250421
Under the PPC64 ELF ABI, functions that might call into other modules (and,
thus, need to load a different TOC base value into %r2), need to restore the
old value after the call. The old value is saved by the .plt code, and the
caller only needs to include a nop instruction after the call, which the linker
will transform into a TOC restore if necessary.
In order to do this the relocation handler needs two things:
1. It needs to know whether the call instruction it is modifying is targeting
a .plt stub that will load a new TOC base value (necessitating a restore after
the call).
2. It needs to know where the buffer ends, so that it does not accidentally
run off the end of the buffer when looking for the 'nop' instruction after the
call.
Given these two pieces of information, we can insert the restore instruction in
place of the following nop when necessary.
llvm-svn: 250110
Previously, output sections that are handled specially by the linker
(e.g. PLT or GOT) were created by Writer and passed to other classes
that need them. The problem was that because these special sections
are required by so many classes, the plumbing work became too much
burden.
This patch is to simply make them accessible from anywhere in the
linker to eliminate the plumbing work once and for all.
http://reviews.llvm.org/D13486
llvm-svn: 249590
Rui Ueyama