| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
| |
We were already doing it for strings. This matches the behavior of
bfd and gold.
llvm-svn: 284598
|
|
|
|
|
|
|
|
|
|
|
| |
Even with the hash table cache, binary search was still pretty
hot. This can be made even faster with prefetching.
Idea from http://cglab.ca/~morin/misc/arraylayout-v2/
I will suggest moving this to llvm.
llvm-svn: 284594
|
|
|
|
|
|
|
| |
The table was still being resized as grow doesn't account for the fact
that the table needs to remain 3/4 full.
llvm-svn: 284487
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
CachedHashStringRef.
Summary:
Reclaiming the name 'CachedHashString' will let us add a type with that
name that owns its value.
Reviewers: timshen
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D25644
llvm-svn: 284434
|
|
|
|
|
|
| |
So that we can use the function from anywhere.
llvm-svn: 284092
|
|
|
|
| |
llvm-svn: 284079
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, we supported only SHF_COMPRESSED sections because it's
new and it's the ELF standard. But there are object files compressed
in the GNU style out there, so we had to support it.
Sections compressed in the GNU style start with ".zdebug_" and
contain different headers than the ELF standard's one. In this
patch, getRawCompressedData is responsible to handle it.
A tricky thing about GNU-style compressed sections is that we have
to rename them when creating output sections. ".zdebug_" prefix
implies the section is compressed. We need to rename ".zdebug_"
".debug" because our output sections are not compressed.
We do that in this patch.
llvm-svn: 284068
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The .ARM.exidx sections contain a table. Each entry has two fields:
- PREL31 offset to the function the table entry describes
- Action to take, either cantunwind, inline unwind, or PREL31 offset to
.ARM.extab section
The table entries must be sorted in order of the virtual addresses the
first entry of the table describes. Traditionally this is implemented by
the SHF_LINK_ORDER dependency. Instead of implementing this directly we
sort the table entries post relocation.
The .ARM.exidx OutputSection is described by the PT_ARM_EXIDX program
header
Differential revision: https://reviews.llvm.org/D25127
llvm-svn: 283730
|
|
|
|
|
|
|
| |
Also use uint64_t instead of uintX_t so that you don't have to
think about two different cases to verify that the code is correct.
llvm-svn: 283585
|
|
|
|
| |
llvm-svn: 283556
|
|
|
|
|
|
|
|
|
|
|
|
| |
I found that this check still may be useful in some cases.
At fact since we use uint32_t alignment, then maximum value
that is valid for us is 0x80000000. But some broken files,
for example file from testcase may have greater value.
Because of that offset calculation overflow and crash happens.
Differential revision: https://reviews.llvm.org/D25324
llvm-svn: 283544
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This spreads out computing the hash and using it in a hash table. The
speedups are:
firefox
master 6.811232891
patch 6.559280249 1.03841162939x faster
chromium
master 4.369323666
patch 4.33171853 1.00868134338x faster
chromium fast
master 1.856679971
patch 1.850617741 1.00327578725x faster
the gold plugin
master 0.32917962
patch 0.325711944 1.01064645023x faster
clang
master 0.558015452
patch 0.550284165 1.01404962652x faster
llvm-as
master 0.032563515
patch 0.032152077 1.01279662275x faster
the gold plugin fsds
master 0.356221362
patch 0.352772162 1.00977741549x faster
clang fsds
master 0.635096494
patch 0.627249229 1.01251060127x faster
llvm-as fsds
master 0.030183188
patch 0.029889544 1.00982430511x faster
scylla
master 3.071448906
patch 2.938484138 1.04524944215x faster
This seems to be because we don't stall as much. When linking firefox
stalled-cycles-frontend goes from 57.56% to 55.55%.
With -O2 the difference is even more significant since we avoid
recomputing the hash. For firefox we go from 9.990295265 to
9.149627521 seconds (1.09x faster).
llvm-svn: 283367
|
|
|
|
|
|
|
|
|
| |
It is pretty easy to get the data from the InputSection, so we don't
have to store it.
This opens the way for storing the hash instead.
llvm-svn: 283357
|
|
|
|
| |
llvm-svn: 283340
|
|
|
|
|
|
|
|
|
|
|
| |
with size of zero.
Previously lld would hang in infinite loop in this case,
patch fixes the issue. Object was found during AFL run.
Differential revision: https://reviews.llvm.org/D25229
llvm-svn: 283208
|
|
|
|
|
|
|
|
|
| |
Follow-up to r282716. Reject input files with non-zero GP0 value only in
case of relocatable object generation. In other case we can handle
arbitrary GP0 value so it does not have a sense to make the restriction
so wide.
llvm-svn: 283194
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Case was revealed by id_000010,sig_08,src_000000,op_havoc,rep_4 from PR30540.
Out implementation uses uint32 for storing section alignment value,
what seems reasonable, though if value exceeds 32 bits bounds we have
truncation and final value of 0.
Patch fixes the issue.
Differential revision: https://reviews.llvm.org/D25082
llvm-svn: 283097
|
|
|
|
| |
llvm-svn: 282851
|
|
|
|
|
|
|
| |
The missing case was when a merge section was only referenced from
non-alloca sections.
llvm-svn: 282847
|
|
|
|
|
|
|
|
|
|
| |
We would crash when a non-alloca section pointed to a gced part of a
merge section.
That can happen when a C/c++ constant in put in a merge section and
debug info is present.
llvm-svn: 282845
|
|
|
|
|
|
|
|
|
|
| |
LLD does not update relocations addends when generate a relocatable
object. That is why we should not write a non-zero GP0 value into
the .reginfo and .MIPS.options sections. And we should not accept input
object files with non-zero GP0 value because we cannot handle them
properly.
llvm-svn: 282716
|
|
|
|
|
|
| |
Differential revision: https://reviews.llvm.org/D25033
llvm-svn: 282708
|
|
|
|
|
|
|
|
|
|
|
|
| |
If we pass --gc-sections to lld and .tbss is not referenced,
the section is reclaimed and lld doesn't create a TLS program header.
R_TLS tries to access the program header -> lld crashes.
Mimic what bfd/gold do in this case and resolve a weak undefined
TLS symbol to the base of the TLS block, i.e. give it a value of zero.
Differential Revision: https://reviews.llvm.org/D24832
llvm-svn: 282279
|
|
|
|
|
|
| |
r279456 guarantees that this condition is always satisfied.
llvm-svn: 281426
|
|
|
|
| |
llvm-svn: 281210
|
|
|
|
|
|
|
|
| |
This reverts commit r281096.
The previous link errors should be fixed by r281208.
llvm-svn: 281209
|
|
|
|
|
|
|
|
|
| |
This reverts commit r281084.
The link was failing on some bots. No idea why. I will try to
reproduce it on Monday.
llvm-svn: 281096
|
|
|
|
| |
llvm-svn: 281084
|
|
|
|
|
|
|
|
| |
This simplifies error handling as there is now only one place in the
code that needs to consider the possibility that the name is
corrupted. Before we would do it in every access.
llvm-svn: 280937
|
|
|
|
| |
llvm-svn: 280925
|
|
|
|
| |
llvm-svn: 280856
|
|
|
|
|
|
|
|
|
|
| |
Previously we used LayoutInputSection class to correctly assign
symbols defined in linker script. This patch removes it and uses
pointer to preceding input section in SymbolAssignment class instead.
Differential revision: https://reviews.llvm.org/D23661
llvm-svn: 280348
|
|
|
|
|
|
|
|
| |
They were both pointing to the start of the got, not the end.
Fixes pr28924.
llvm-svn: 280310
|
|
|
|
| |
llvm-svn: 280305
|
|
|
|
| |
llvm-svn: 280237
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is fix for PR28976.
Problem was that in scanRelocs, we computed relocation offset too early
for case when linkerscript was used. Patch fixes the issue
delaying the calculation.
Differential revision: https://reviews.llvm.org/D23655
llvm-svn: 279264
|
|
|
|
|
|
|
| |
This section supersedes .reginfo and .MIPS.options sections. But for now
we have to support all three sections for ABI transition period.
llvm-svn: 278482
|
|
|
|
| |
llvm-svn: 278322
|
|
|
|
| |
llvm-svn: 277566
|
|
|
|
|
|
|
|
|
| |
Previously addends were ignored. This is PR28779.
Patch fixes the issue.
Differential revision: https://reviews.llvm.org/D23011
llvm-svn: 277432
|
|
|
|
|
|
|
| |
Since CommonInputSection is a singleton class, we don't need
to store pointers to all DefinedCommon symbols.
llvm-svn: 277410
|
|
|
|
| |
llvm-svn: 277103
|
|
|
|
|
|
|
|
|
| |
All other singleton instances are accessible globally.
CommonInputSection shouldn't be an exception.
Differential Revision: https://reviews.llvm.org/D22935
llvm-svn: 277034
|
|
|
|
| |
llvm-svn: 277023
|
|
|
|
|
|
|
|
|
|
| |
Not all relocations from a .eh_frame that point to an executable
section should be ignored. In particular, the relocation finding the
personality function should not.
This is a reduction from trying to bootstrap a static lld on linux.
llvm-svn: 276329
|
|
|
|
|
|
| |
This opens the way for having a different Piece type for EhInputSection.
llvm-svn: 276275
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We no longer need it for relocations in .eh_frame.
The only relocations that point to .eh_frame are the ones trying to
find the output .eh_frame.
This actually fixes a bug in the symbol value code. It was not
handling -1 as an indicator for a piece not being included in the
output.
llvm-svn: 276175
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We will need to do something like this to support range extension
thunks since that process is iterative.
Doing this also has the advantage that when doing the regular
relocation scan the offset in the output section is known and we can
just store that. This reduces the number of times we have to run
getOffset and I think will allow a more specialized .eh_frame
representation.
By itself this is already a performance win.
firefox
master 7.295045737
patch 7.209466989 0.98826892235
chromium
master 4.531254468
patch 4.509221804 0.995137623774
chromium fast
master 1.836928973
patch 1.823805241 0.992855612714
the gold plugin
master 0.379768791
patch 0.380043405 1.00072310839
clang
master 0.642698284
patch 0.642215663 0.999249070657
llvm-as
master 0.036665467
patch 0.036456225 0.994293213284
the gold plugin fsds
master 0.40395817
patch 0.404384555 1.0010555177
clang fsds
master 0.722045545
patch 0.720946135 0.998477367518
llvm-as fsds
master 0.03292646
patch 0.032759965 0.994943428477
scylla
master 3.427376378
patch 3.368316181 0.98276810292
llvm-svn: 276146
|
|
|
|
| |
llvm-svn: 276121
|
|
|
|
|
|
|
|
|
|
|
| |
Creating sections on linkerscript side requires some methods
that can be reused if are exported from writer.
Patch implements that change.
Differential revision: http://reviews.llvm.org/D20104
llvm-svn: 275162
|