| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
| |
This was raised in comments for D41592.
With current code we always assign parent
section for Rel[a] sections like
InX::RelaPlt or InX::RelaDyn, so checking
their parent for null is excessive.
llvm-svn: 321581
|
|
|
|
|
|
|
| |
This simplifies toRegularSection and reduces the noise in a followup
patch.
llvm-svn: 321240
|
|
|
|
|
|
|
| |
It was only templated so it could create a dummy section header that
was immediately parsed back.
llvm-svn: 321235
|
|
|
|
|
|
| |
Every shared symbol has a file, so we can use a reference.
llvm-svn: 321187
|
|
|
|
|
|
|
|
| |
The value of the symbol in the assignment should include the sentinel entry.
Differential Revision: https://reviews.llvm.org/D41234
llvm-svn: 321154
|
|
|
|
|
|
|
| |
These values are trivially never null. While at it, also use
InputSection instead of InputSectionBase when possible.
llvm-svn: 321126
|
|
|
|
|
|
|
|
|
|
|
| |
We add dynamic section entries both in the ctor of the class and
DynamicSection::finalizeContents(). Some entries need to be added early
in the ctor because they add strings to .dynstr. Other entries were
intended to be added in finalizeContents(). However, some entries are
added in the ctor even though they don't add strings. This patch
fix the issue.
llvm-svn: 320851
|
|
|
|
| |
llvm-svn: 320671
|
|
|
|
|
|
|
|
|
|
|
|
| |
We might crash in 'ARMExidxSentinelSection::writeTo()' because it expected
the sentinel entry to be put in the same 'InputSectionDescription' as
the last real entry. This assumption fails if the last output section command
for .ARM.exidx is anything but an input section description, because in this
case 'OutputSection::addSection()' creates a new 'InputSectionDescription'.
Differential Revision: https://reviews.llvm.org/D41105
llvm-svn: 320668
|
|
|
|
|
|
| |
If a section has been replaced (Sec != Sec->Repl) it is not Live.
llvm-svn: 320597
|
|
|
|
|
|
|
|
|
|
|
|
| |
By using an index instead of a pointer for verdef we can put the index
next to the alignment field. This uses the otherwise wasted area and
reduces the shared symbol size.
By itself the performance change of this is in the noise, but I have a
followup patch to remove another 8 bytes that improves performance
when combined with this.
llvm-svn: 320449
|
|
|
|
| |
llvm-svn: 320327
|
|
|
|
| |
llvm-svn: 320324
|
|
|
|
| |
llvm-svn: 320323
|
|
|
|
|
|
|
| |
They were not used in InputFiles.h and it was getting too easy to add
circular includes.
llvm-svn: 320256
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D40994
llvm-svn: 320130
|
|
|
|
| |
llvm-svn: 320072
|
|
|
|
| |
llvm-svn: 320070
|
|
|
|
|
|
|
| |
With this memory usage when linking clang goes from 174.62MB to
172.77MB.
llvm-svn: 320069
|
|
|
|
|
|
|
|
| |
We fill executable sections with trap instructions (0xcc or equivalent).
If a .gnu.hash section was put into an executable segment, we created
corrupted .gnu.hash section. This patch fixes the issue.
llvm-svn: 319863
|
|
|
|
|
|
|
|
|
|
| |
This change actually makes the linker slightly faster. My observation
is that, with this patch, link time of clang without debug is about 1%
faster.
Differential Revision: https://reviews.llvm.org/D40697
llvm-svn: 319600
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
when --emit-reloc used with linker script.
This is for "Bug 35474 - --emit-relocs produces wrongly-named reloc sections".
LLD currently for scripts like:
.text.boot : { *(.text.boot) }
emits relocation section with name .rela.text because does not take
redefined name of output section into account and builds section name
using rules for non-scripted case. Patch fixes this oddness.
Differential revision: https://reviews.llvm.org/D40652
llvm-svn: 319526
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Our on-disk hash table was unnecessarily large. The cost of collision is
not high in the .gnu.hash table because each symbol in the .gnu.hash
table has a hash value with it. So, for each collided symbol, the
dynamic linker just compares an integer, which is pretty cheap.
This patch increases the load factor by about 8. Here's a comparison.
$ readelf --histogram libclangSema.so.6.0.0svn-new-lld
Histogram for `.gnu.hash' bucket list length (total of 582 buckets):
Length Number % of total Coverage
0 11 ( 1.9%)
1 35 ( 6.0%) 1.5%
2 93 ( 16.0%) 9.5%
3 108 ( 18.6%) 23.4%
4 121 ( 20.8%) 44.1%
5 86 ( 14.8%) 62.6%
6 63 ( 10.8%) 78.8%
7 38 ( 6.5%) 90.2%
8 18 ( 3.1%) 96.4%
9 6 ( 1.0%) 98.7%
10 3 ( 0.5%) 100.0%
$ readelf --histogram libclangSema.so.6.0.0svn-old-lld
Histogram for `.gnu.hash' bucket list length (total of 4093 buckets):
Length Number % of total Coverage
0 1498 ( 36.6%)
1 1545 ( 37.7%) 37.7%
2 712 ( 17.4%) 72.5%
3 251 ( 6.1%) 90.9%
4 66 ( 1.6%) 97.3%
5 16 ( 0.4%) 99.3%
6 5 ( 0.1%) 100.0%
$ readelf --histogram libclangSema.so.6.0.0svn-bfd
Histogram for `.gnu.hash' bucket list length (total of 1004 buckets):
Length Number % of total Coverage
0 92 ( 9.2%)
1 227 ( 22.6%) 9.8%
2 266 ( 26.5%) 32.6%
3 222 ( 22.1%) 61.2%
4 115 ( 11.5%) 81.0%
5 55 ( 5.5%) 92.8%
6 21 ( 2.1%) 98.2%
7 6 ( 0.6%) 100.0%
$ readelf --histogram libclangSema.so.6.0.0svn-gold
Histogram for `.gnu.hash' bucket list length (total of 2053 buckets):
Length Number % of total Coverage
0 671 ( 32.7%)
1 709 ( 34.5%) 30.4%
2 470 ( 22.9%) 70.7%
3 141 ( 6.9%) 88.9%
4 54 ( 2.6%) 98.2%
5 5 ( 0.2%) 99.2%
6 3 ( 0.1%) 100.0%
Differential Revision: https://reviews.llvm.org/D40683
llvm-svn: 319503
|
|
|
|
|
|
|
| |
We are already paying the cost of storing a InputFile in every
Symbol, so use it uniformly.
llvm-svn: 319378
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D40571
llvm-svn: 319221
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D40338
llvm-svn: 318938
|
|
|
|
|
|
| |
This is a reduction of a patch by Rui Ueyama.
llvm-svn: 318852
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The MIPS GOT section has a number of local entries based on the number of pages
needed for output sections referenced by GOT page relocations. The number is
recorded in the DT_MIPS_LOCAL_GOTNO dynamic section tag. However, the dynamic tag
is added before assignAddresses has been called, meaning that any section size used
to calculate the value will not include size modifications caused by, for example,
linker scripts and thunks.
This change moves the calculation of DT_MIPS_LOCAL_GOTNO until writeTo, by which
time the output section sizes have been finalized.
Reviewers: ruiu, rafael
Differential Revision: https://reviews.llvm.org/D39493
llvm-svn: 318828
|
|
|
|
|
|
|
| |
Since we always have Binding in the current symbol design IsLocal is
redundant.
llvm-svn: 318497
|
|
|
|
|
|
|
|
|
|
| |
No difference in practice other than having sh_entsize in the output.
This should simplify the patch for handling SHF_MERGE in -r.
Based on a patch by George Rimar.
llvm-svn: 318306
|
|
|
|
|
|
|
|
|
|
|
|
| |
symbols
microMIPS symbols including microMIPS PLT records created for regular
symbols needs to be marked by STO_MIPS_MICROMIPS flag in a symbol table.
Additionally microMIPS entries in a dynamic symbol table should have
configured less-significant bit. That allows to escape teaching a
dynamic linker about microMIPS symbols.
llvm-svn: 318097
|
|
|
|
|
|
|
|
|
| |
of microMIPS code
The less-significant bit signals about microMIPS code for jump/branch
instructions.
llvm-svn: 317741
|
|
|
|
|
|
|
|
|
| |
We have a lot of "if (MIPS)" conditions in lld because the MIPS' ABI
is different at various places than other arch's ABIs at where it
don't have to be different, but we at least want to reduce MIPS-ness
from the regular classes.
llvm-svn: 317525
|
|
|
|
|
|
| |
This function is now equivalent to isDefined().
llvm-svn: 317449
|
|
|
|
|
|
|
|
|
| |
Now that DefinedRegular is the only remaining derived class of
Defined, we can merge the two classes.
Differential Revision: https://reviews.llvm.org/D39667
llvm-svn: 317448
|
|
|
|
|
|
|
|
|
| |
Common symbols are now represented with a DefinedRegular that points
to a BssSection, even during symbol resolution.
Differential Revision: https://reviews.llvm.org/D39666
llvm-svn: 317447
|
|
|
|
|
|
|
|
|
|
| |
This patch is mechanically created by
sed -i -e s/Body/Sym/g lld/ELF/*.{cpp,h}
and clang-format-diff.
llvm-svn: 317392
|
|
|
|
| |
llvm-svn: 317383
|
|
|
|
|
|
|
| |
A mechanical rename caused an illegal name conflict between
a variable and a type, which was picked up by GCC.
llvm-svn: 317380
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now that we have only SymbolBody as the symbol class. So, "SymbolBody"
is a bit strange name now. This is a mechanical change generated by
perl -i -pe s/SymbolBody/Symbol/g $(git grep -l SymbolBody lld/ELF lld/COFF)
nd clang-format-diff.
Differential Revision: https://reviews.llvm.org/D39459
llvm-svn: 317370
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
SymbolBody and Symbol were separated classes due to a historical reason.
Symbol used to be a pointer to a SymbolBody, and the relationship
between Symbol and SymbolBody was n:1.
r2681780 changed that. Since that patch, SymbolBody and Symbol are
allocated next to each other to improve memory locality, and they have
1:1 relationship now. So, the separation of Symbol and SymbolBody no
longer makes sense.
This patch merges them into one class. In order to avoid updating too
many places, I chose SymbolBody as a unified name. I'll rename it Symbol
in a follow-up patch.
Differential Revision: https://reviews.llvm.org/D39406
llvm-svn: 317006
|
|
|
|
|
|
|
|
| |
All SHT_NOTE sections should have minimum alignment 4.
Differential Revision: https://reviews.llvm.org/D38907
llvm-svn: 316961
|
|
|
|
|
|
|
| |
This change allows us to use less templates for Shared symbol and
the functions that deals with shared symbols.
llvm-svn: 316841
|
|
|
|
|
|
|
|
|
|
|
|
| |
DSO is short for dynamic shared object, so the function name was a
little confusing because it sounded like it didn't work when we were
a creating statically-linked executable or something.
What we mean by "DSO" here is the current output file that we are
creating. Thus the new name. Alternatively, we could call it the current
ELF module, but "module" is a overloaded word, so I avoided that.
llvm-svn: 316809
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
packing format.
The Android relocation packing format is a more compact
format for dynamic relocations in executables and DSOs
that is based on delta encoding and SLEBs. An overview
of the format can be found in the Android source code:
https://android.googlesource.com/platform/bionic/+/refs/heads/master/tools/relocation_packer/src/delta_encoder.h
This patch implements relocation packing using that format.
This implementation uses a more intelligent algorithm for compressing
relative relocations than Android's own relocation packer. As a
result it can generally create smaller relocation sections than
that packer. If I link Chromium for Android targeting ARM32 I get a
.rel.dyn of size 174693 bytes, as compared to 371832 bytes with gold
and the Android packer.
Differential Revision: https://reviews.llvm.org/D39152
llvm-svn: 316775
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When an OutputSection is larger than the branch range for a Target we
need to place thunks such that they are always in range of their caller,
and sufficiently spaced to maximise the number of callers that can use
the thunk. We use the simple heuristic of placing the
ThunkSection at intervals corresponding to a target specific branch range.
If the OutputSection is small we put the thunks at the end of the executable
sections.
Differential Revision: https://reviews.llvm.org/D34689
llvm-svn: 316751
|
|
|
|
| |
llvm-svn: 316738
|
|
|
|
| |
llvm-svn: 316736
|
|
|
|
| |
llvm-svn: 316735
|
|
|
|
| |
llvm-svn: 316734
|