| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
| |
Now that getSectionPiece uses OffsetMap, it is advantageous to
initialize it earlier.
llvm-svn: 329242
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D44991
llvm-svn: 329233
|
|
|
|
|
|
|
|
| |
This makes the sort order a little clearer.
Differential Revision: https://reviews.llvm.org/D45282
llvm-svn: 329227
|
|
|
|
| |
llvm-svn: 329224
|
|
|
|
|
|
|
| |
It seems I accidentally overspecified the section size in my previous
commit, whereas it was previously carefully left out.
llvm-svn: 329222
|
|
|
|
|
|
|
|
|
|
|
|
| |
One place where this seems to matter is to make sure the .rsrc section comes
after .text. The Win32 UpdateResource() function can change the contents of
.rsrc. It will move the sections that come after, but if .text gets moved, the
entry point header will not get updated and the executable breaks. This was
found by a test in Chromium.
Differential Revision: https://reviews.llvm.org/D45260
llvm-svn: 329221
|
|
|
|
|
|
|
|
| |
We were ignoring the addend if the piece was dead. I don't expect this
to make a difference in any real world situations, but it is simpler
anyway.
llvm-svn: 329219
|
|
|
|
|
|
|
|
|
|
| |
isPicRel is used to check if we want to create the dynamic relocations.
Not all of the dynamic relocations we create are passing through this
check, but those that are, probably better be whitelisted.
Differential revision: https://reviews.llvm.org/D45252
llvm-svn: 329203
|
|
|
|
| |
llvm-svn: 329180
|
|
|
|
|
|
|
|
|
| |
Rename field, added comments.
This is splitted from the D44894.
Requested to be committed as independent cleanup.
llvm-svn: 329162
|
|
|
|
|
|
| |
Renaming was requested in post commit review for D43820.
llvm-svn: 329159
|
|
|
|
|
|
| |
Was requested during post commit review.
llvm-svn: 329155
|
|
|
|
|
|
|
|
| |
Patch by Alexandre Ganea.
Differential Revision: https://reviews.llvm.org/D45232
llvm-svn: 329132
|
|
|
|
| |
llvm-svn: 329126
|
|
|
|
| |
llvm-svn: 329125
|
|
|
|
| |
llvm-svn: 329124
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the lld perf builder r328686 had a negative impact in
stalled-cycles-frontend. Somehow that stat is not showing on my
machine, but the attached patch shows an improvement on cache-misses,
which is probably a reasonable proxy.
My working theory is that given a large input the pieces vector is out
of cache by the time initOffsetMap runs.
Both finalizeContents implementation have a convenient location for
initializing the OffsetMap, so this seems the best solution.
llvm-svn: 329117
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D45227
llvm-svn: 329107
|
|
|
|
|
|
|
|
|
|
| |
--symbol-ordering-file.
This improved performance by 0.5-1% linking Chromium for Android.
Differential Revision: https://reviews.llvm.org/D45222
llvm-svn: 329106
|
|
|
|
|
|
| |
r329092 broke buildbots.
llvm-svn: 329103
|
|
|
|
|
|
| |
We were setting IsUsedInRegularObj in lazy symbols only used from IR.
llvm-svn: 329101
|
|
|
|
|
|
|
| |
Previously, fetchIfLazy did more than the name says. Now, setting
to UsedInRegularObj is moved to another function.
llvm-svn: 329092
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
r328610 fixed a data race in the COFF linker. This change makes a
similar fix to the ELF linker.
Reviewers: ruiu, pcc, rnk
Reviewed By: ruiu
Subscribers: emaste, llvm-commits, arichardson
Differential Revision: https://reviews.llvm.org/D45192
llvm-svn: 329088
|
|
|
|
|
|
|
|
|
| |
Patch removes Lazy class which
is just an excessive layer.
Differential revision: https://reviews.llvm.org/D45083
llvm-svn: 329086
|
|
|
|
|
|
|
|
|
|
| |
Added checks to test that we do not produce
output where VA of sections overruns the address
space available.
Differential revision: https://reviews.llvm.org/D43820
llvm-svn: 329063
|
|
|
|
| |
llvm-svn: 329062
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes PR36927.
The issue is next. Imagine we have -Ttext 0x7c and code below.
.code16
.global _start
_start:
movb $_start+0x83,%ah
So we have R_386_8 relocation and _start at 0x7C.
Addend is 0x83 == 131. We will sign extend it to 0xffffffffffffff83.
Now, 0xffffffffffffff83 + 0x7c gives us 0xFFFFFFFFFFFFFFFF.
Techically 0x83 + 0x7c == 0xFF, we do not exceed 1 byte value, but
currently LLD errors out, because we use checkUInt<8>.
Let's try to use checkInt<8> now and the following code to see if it can help (no):
main.s:
.byte foo
input.s:
.globl foo
.hidden foo
foo = 0xff
Here, foo is 0xFF. And addend is 0x0. Final value is 0x00000000000000FF.
Again, it fits one byte well, but with checkInt<8>,
we would error out it, so we can't use it.
What we want to do is to check that the result fits 1 byte well.
Patch changes the check to checkIntUInt to fix the issue.
Differential revision: https://reviews.llvm.org/D45051
llvm-svn: 329061
|
|
|
|
|
|
|
|
| |
Groups paired options together.
Differential revision: https://reviews.llvm.org/D45090
llvm-svn: 329060
|
|
|
|
|
|
|
|
|
|
|
| |
Having 8/16 bits dynamic relocations is incorrect.
Both gold and bfd (built from latest sources) disallow
that too.
Differential revision: https://reviews.llvm.org/D45158
llvm-svn: 329059
|
|
|
|
| |
llvm-svn: 329058
|
|
|
|
|
|
|
|
|
|
| |
OffsetMap maps to a SectionPiece index, but we were not taking
advantage of that in getSectionPiece.
With this patch both getOffset and getSectionPiece use OffsetMap and
the binary search is moved to findSectionPiece.
llvm-svn: 329044
|
|
|
|
|
|
|
|
| |
They are to pull out an object file for a symbol, but for a historical
reason the code is written in two separate functions. This patch
merges them.
llvm-svn: 329039
|
|
|
|
| |
llvm-svn: 329034
|
|
|
|
|
|
|
| |
This is nice for testing since it is the first TrapInst whose bytes
are not all the same.
llvm-svn: 329014
|
|
|
|
|
|
|
|
|
|
| |
The Plt relative relocations are R_PPC64_JMP_SLOT in the V2 abi, and we only
reserve 2 double words instead of 3 at the start of the array of PLT entries for
lazy linking.
Differential Revision: https://reviews.llvm.org/D44951
llvm-svn: 329006
|
|
|
|
|
|
|
|
| |
Add the default version of a plt stub for the V2 Elf abi.
Differential Revision: https://reviews.llvm.org/D44850
llvm-svn: 329004
|
|
|
|
|
|
|
|
| |
Adds a simple test for accessing a local global variable in the ElfV2 abi.
Checks that the toc base used is the expected offset from the .TOC. symbol,
and that the offsets for the global are calculated relative to the toc base.
llvm-svn: 328982
|
|
|
|
|
|
|
| |
This is consistent with bfd and we already supported it,
though test did not contain the explicit check.
llvm-svn: 328967
|
|
|
|
| |
llvm-svn: 328908
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
targets with limited-range branches.
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
|
|
|
|
|
|
|
|
| |
later on are initialized properly.
Differential Revision: https://reviews.llvm.org/D44986
llvm-svn: 328902
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the end.
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
|
|
|
|
| |
llvm-svn: 328882
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before:
$ ld.lld --plugin-opt=-foo
ld.lld: --Unknown command line argument '-abc'
After:
$ ld.lld --plugin-opt=-foo
ld.lld: --plugin-opt: ld.lld --Unknown command line argument '-abc'
Differential Revision: https://reviews.llvm.org/D45075
llvm-svn: 328880
|
|
|
|
|
|
|
|
|
| |
contradicting MSDN.
Also add a test for /FIXED.
https://reviews.llvm.org/D45087
llvm-svn: 328879
|
|
|
|
|
|
|
|
|
|
| |
/FIXED:NO is always the default, so that part needs no work.
Also test the interaction of /ORDER: with /INCREMENTAL.
https://reviews.llvm.org/D45091
llvm-svn: 328877
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D45001
llvm-svn: 328873
|
|
|
|
| |
llvm-svn: 328863
|
|
|
|
|
|
|
|
|
| |
As of rL215127, FileCheck has an -allow-empty flag,
so this could be used instead of writing a dummy line.
But it looks like the log is never empty now, so not
even that is needed.
llvm-svn: 328862
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|