It generally does not matter much where we place sections ordered
by --symbol-ordering-file relative to other sections. But if the
ordered sections are hot (which is the case already for some users
of --symbol-ordering-file, and is increasingly more likely to be
the case once profile-guided section layout lands) and the target
has limited-range branches, it is beneficial to place the ordered
sections in the middle of the output section in order to decrease
the likelihood that a range extension thunk will be required to call
a hot function from a cold function or vice versa.
That is what this patch does. After D44966 it reduces the size of
Chromium for Android's .text section by 60KB.
Differential Revision: https://reviews.llvm.org/D44969
llvm-svn: 328905
Now that we have the ability to create short thunks, it is beneficial
for thunk sections to be surrounded by ThunkSectionSpacing bytes
of code on both sides in order to increase the likelihood that the
distance from the thunk to the target will be sufficiently small to
allow for the creation of a short thunk. This is currently the case
for most thunks that we create, except for the last one, which could,
depending on the size of the output section, potentially appear near
the end and therefore have a relatively small amount of code after it.
This patch moves the last thunk section to ThunkSectionSpacing bytes
before the end of the output section, as long as the section is larger
than 2*ThunkSectionSpacing bytes. It reduces the size of Chromium
for Android's .text section by 32KB.
Differential Revision: https://reviews.llvm.org/D44966
llvm-svn: 328889
I tried a few different designs to find a way to implement it without
too much hassle and settled down with this. Unlike before, object files
given as arguments for --just-symbols are handled as object files, with
an exception that their section tables are handled as if they were all
null.
Differential Revision: https://reviews.llvm.org/D42025
llvm-svn: 328852
A short thunk uses a direct branch (b or b.w) instruction, and is used
when the target has the same thumbness as the thunk and is within
direct branch range (32MB for ARM, 16MB for Thumb-2). Reduces the
size of Chromium for Android's .text section by around 160KB.
Differential Revision: https://reviews.llvm.org/D44963
llvm-svn: 328846
This patch fixes an issue introduced in r328810 which made the algorithm
to always run the loop O(n^2) times, though we can break early. The
output remains the same.
llvm-svn: 328811
The PLT retpoline support for X86 and X86_64 did not include the padding
when writing the header and entries. This issue was revealed when linker
scripts were used, as this disables the built-in behaviour of filling
the last page of executable segments with trap instructions. This
particular behaviour was hiding the missing padding.
Added retpoline tests with linker scripts.
Differential Revision: https://reviews.llvm.org/D44682
llvm-svn: 328777
NonLocal is technically more accurate, but we already use the term
"Global" to specify the non-local part of the symbol table, and
Local <-> Global is easier to digest.
llvm-svn: 328740
This fixes pr36623.
The problem is that we have to parse versions out of names before LTO
so that LTO can use that information.
When we get the LTO produced .o files, we replace the previous symbols
with the LTO produced ones, but they still have @ in their names.
We could just trim the name directly, but calling parseSymbolVersion
to do it is simpler.
llvm-svn: 328738
Also make certain Thunk methods non-const as this will be required for
an upcoming change.
Differential Revision: https://reviews.llvm.org/D44961
llvm-svn: 328732
Some tools (dwarfdump for example) get confused by the current -O0 -r
output since it has multiple copies of .debug_str.
We cannot just merge sections with the same name as they can have
different sh_entsize.
We could have duplicated logic for merging sections based on name and
sh_entsize, but it seems better to just use the existing logic by
enabling optimizations.
llvm-svn: 328640
The Data member of synthetic section's is not valid and empty. The Data
member is required to be valid by ICF as it is used by ICF to determine
the equality of section contents. Therefore, exclude synthetic sections
from ICF.
Fixes bug PR36910.
Differential Revision: https://reviews.llvm.org/D44923
llvm-svn: 328624
SharedFile::parseRest function grew organically and got a bit hard to
understand. This patch refactor it. This patch also adds comments.
Differential Revision: https://reviews.llvm.org/D44860
llvm-svn: 328579
When the target saves ElfSym::GlobalOffsetTable in the .got rather than
.got.plt, Target->GotHeaderEntriesNum states the number of extra entries
required in the .got. Rather than having to add Target->GotHeaderEntriesNum to
NumEntries in every function which refers to NumEntries, this patch changes the
initial value of NumEntries in the constructor.
Differential Revision: https://reviews.llvm.org/D44744
llvm-svn: 328559
Currently, we might have a bug with scripts like below:
.foo : ALIGN(8)
{
*(.foo)
} > ram
because do not expand the memory region when doing ALIGN.
This might result in file range overlaps. The patch fixes the issue.
Differential revision: https://reviews.llvm.org/D44730
llvm-svn: 328479
Currently when we build input sections list in linker script
we ignore all rel[a] sections. That was done to support
scripts like .rela.dyn : { *(.rela.data) } for emit relocs.
Though as a result following scripts were also silently ignored:
/DISCARD/ : { *(.rela.plt)
/DISCARD/ : { *(.rela.dyn)
and we produced output with this sections. That is not ideal.
The solution this patch suggests is simple: do not ignore synthetic
rel[a] sections. That way we can enable common discarding logic
for them and report a proper error.
Differential revision: https://reviews.llvm.org/D41640
llvm-svn: 328419
Previously, we used 0 as an alias for VER_NDX_GLOBAL and had a dummy
entry in SharedFile::Verdefs so that the access to the array is within
its boundary. But that's not straightforwad. We can just stop doing both.
llvm-svn: 328401
Since SectionBase::getOutputSection handles ICF replaces and
SectionBase::getOffset was handling it in some cases, it is more
consistent to have getOffset always handle it.
llvm-svn: 328391
When looking for the output section and the output offset the
expectation was that the caller had looked at Repl. That works fine
for InputSections, but in the case of MergeInputSections the caller
doesn't have the section that is actually replaced.
The original testcase was failing because getOutputSection was
returning null. The slightly extended testcase also checks that
getOffset also checks Repl.
I will send a refactoring separetelly.
llvm-svn: 328332
This fixes PR36367 which is about segfault when --emit-relocs is
used together with .eh_frame sections which happens because
of reordering of regular and .rel[a] sections.
Path changes loop that iterates over input sections to create
relocation target sections first.
Differential revision: https://reviews.llvm.org/D44679
llvm-svn: 328299
The relocations R_PPC64_REL16_LO and R_PPC64_REL16_HA should return R_PC
for getRelExpr since they compute #lo(S + A – P) and #ha(S + A – P).
Differential Revision: https://reviews.llvm.org/D44648
llvm-svn: 328103
Patch teaches LLD to hint user about -fdebug-types-section flag
if relocation overflow happens in debug section.
Differential revision: https://reviews.llvm.org/D40954
llvm-svn: 328081
There are no reasons for them to be STV_DEFAULT,
recently bfd did the same change.
Differential revision: https://reviews.llvm.org/D44566
llvm-svn: 327983
Fangrui Song