| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 328847
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
Template is just unnecessary.
Differential Revision: https://reviews.llvm.org/D45063
llvm-svn: 328843
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D44962
llvm-svn: 328841
|
|
|
|
| |
llvm-svn: 328817
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are two FPMs in an MSF file, the idea being that for
incremental updates you can write to the alternate one and then
atomically swap them on commit. LLVM defaulted to using FPM1
on the first commit, but this differs from Microsoft's behavior
which is to default to using FPM2 on the first commit. To
eliminate some byte-level file differences, this patch changes
LLVM's default to also be FPM2.
Additionally, LLVM was trying to be "smart" about marking FPM
pages allocated. In addition to marking every page belonging
to the alternate FPM as unallocated, LLVM also marked pages at
the end of the main FPM which were not needed as unallocated.
In order to match the behavior of Microsoft-generated PDBs, we
now always mark every FPM block as allocated, regardless of
whether it is in the main FPM or the alt FPM, and regardless of
whether or not it describes blocks which are actually in the file.
This has the side benefit of simplifying our code.
llvm-svn: 328812
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
This patch rewrites the function to remove lambda callbacks and use
of template. The algorithm is the same as before.
llvm-svn: 328810
|
|
|
|
| |
llvm-svn: 328794
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 328739
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 328736
|
|
|
|
| |
llvm-svn: 328733
|
|
|
|
|
|
|
|
|
|
|
| |
NFC.
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
|
|
|
|
|
|
| |
This addresses a late review comment from D44427/rLLD328643
llvm-svn: 328700
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Sample for the OVERLAY command from the spec
(https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/4/html/Using_ld_the_GNU_Linker/sections.html)
uses MAX command that we do not support currently:
. = 0x1000 + MAX (SIZEOF (.text0), SIZEOF (.text1));
This patch implements support for MIN and MAX.
Differential revision: https://reviews.llvm.org/D44734
llvm-svn: 328696
|
|
|
|
|
|
| |
This is a small optimization and avoids the need to use call_once.
llvm-svn: 328686
|
|
|
|
| |
llvm-svn: 328685
|
|
|
|
|
|
|
| |
We don't support input merge sections larger than 4gb, so these can be
uint32_t.
llvm-svn: 328684
|
|
|
|
| |
llvm-svn: 328679
|
|
|
|
|
|
|
|
|
|
| |
This enables callback-style programming where the JavaScript environment
can call back into the Wasm environment using a function pointer
received from the module.
Differential Revision: https://reviews.llvm.org/D44427
llvm-svn: 328643
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
I noticed that we were not testing this while working on another patch.
llvm-svn: 328631
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Fixes PR36823.
Reviewers: ruiu, pcc, rnk
Reviewed By: ruiu
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D44716
llvm-svn: 328610
|
|
|
|
| |
llvm-svn: 328605
|
|
|
|
| |
llvm-svn: 328604
|
|
|
|
| |
llvm-svn: 328594
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Thanks to George Rimar for pointing it out.
llvm-svn: 328571
|
|
|
|
| |
llvm-svn: 328569
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the .got
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
layout for them.
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
|
|
|
|
|
|
| |
There were a few too many places duplicating this.
llvm-svn: 328402
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
SectionBase::getOutputSection handles replacement sections, so this
code doesn't have to.
llvm-svn: 328390
|
|
|
|
|
|
| |
A bug in BFD linker is not our FIXME item.
llvm-svn: 328381
|
|
|
|
|
|
|
|
|
|
|
|
| |
This was reverted several times due to what ultimately turned out
to be incompatibilities in our serialized hash table format.
Several changes went in prior to this to fix those issues since
they were more fundamental and independent of supporting injected
sources, so now that those are fixed this change should hopefully
pass.
llvm-svn: 328363
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When investigating bugs in PDB generation, the first step is
often to do the same link with link.exe and then compare PDBs.
But comparing PDBs is hard because two completely different byte
sequences can both be correct, so it hampers the investigation when
you also have to spend time figuring out not just which bytes are
different, but also if the difference is meaningful.
This patch fixes a couple of cases related to string table emission,
hash table emission, and the order in which we emit strings that
makes more of our bytes the same as the bytes generated by MS PDBs.
Differential Revision: https://reviews.llvm.org/D44810
llvm-svn: 328348
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 328319
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
proccess .eh_frame"
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
|
|
|
|
| |
llvm-svn: 328285
|
|
|
|
|
|
|
| |
With this patch lld will iterate over compile units to find the line
tables instead of assuming there is only one at offset 0.
llvm-svn: 328284
|
|
|
|
|
|
| |
This is an i386 test, so it should be 4.
llvm-svn: 328223
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently lld just parses the .debug_line section assuming that there
is only one compile unit. That assumption is false (PR36793).
I have a patch that changes lld to iterate over the compile units and
parse the portions of the .debug_line they point to (which fixes
PR36793).
A problem is that we will then need a compiler unit pointing to
.debug_line for lld to see it.
It seems like bfd has the same restriction.
This patch updates existing tests to add a minimal compile unit so
that they still work with PR36793 fixed.
llvm-svn: 328215
|