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
r283984 introduced a problem of too many warning messages being shown
when -ffunction-sections and -fdata-sections were used in conjunction
with --gc-sections linker flag and debugging information present. This
happens because lot of relocations from .debug_line section may become
invalid in such case. The newer fix doesn't show any warning message but
zeroes OutSec pointer in createInputSectionList() to avoid crash, when
relocations are written
llvm-svn: 284010
Following the lazy reference might bring in an object file that depends
on bitcode files that weren't part of the LTO step.
Differential Revision: https://reviews.llvm.org/D25461
llvm-svn: 283989
I don't really understand why we get a larger .rodata section only
on this bot. I guess it may be picking up a library which contains
a .rodata. I removed the specific values since their values are not
important for this test case.
llvm-svn: 283931
This part was splitted from D25016.
When sh_info value was set in the way that non-local symbol was treated as local, lld
was asserting, patch fixes that.
Differential revision: https://reviews.llvm.org/D25371
llvm-svn: 283859
Before the default was whatever number hardware_concurrency() returned.
Users can specify the number of threads via --lto-jobs=X option.
llvm-svn: 283787
Sometimes the very first PT_LOAD segment, created by lld, can be empty.
This happens when (all conditions met):
- Linker script is used
- First section in ELF image is not RO
- Not enough space for program headers.
Differential revision: https://reviews.llvm.org/D25330
llvm-svn: 283760
With fix: commit changes from InputFiles.cpp too.
Original commit message:
We have following code in lld, that truncates the alignment value to 32 bit. Big alignment in this case
may give result 0 and crash later.
template <class ELFT>
CommonInputSection<ELFT>::CommonInputSection(std::vector<DefinedCommon *> Syms)
: InputSection<ELFT>(nullptr, &Hdr, "") {
....
for (DefinedCommon *Sym : Syms) {
this->Alignment = std::max<uintX_t>(this->Alignment, Sym->Alignment);
...
}
}
Patch fixes the issue.
Differential revision: https://reviews.llvm.org/D25235
llvm-svn: 283738
.ARM.exidx sections have a reverse dependency on the section they have
a SHF_LINK_ORDER dependency on. In other words a .ARM.exidx section is
live only if the executable section it describes is live. We implement
this with a reverse dependency field in InputSection.
Adding the dependency to InputSection is the simplest implementation
but it could be moved out to a separate map if it were found to decrease
performance for non ARM targets.
Differential revision: https://reviews.llvm.org/D25234
llvm-svn: 283734
We have following code in lld, that truncates the alignment value to 32 bit. Big alignment in this case
may give result 0 and crash later.
template <class ELFT>
CommonInputSection<ELFT>::CommonInputSection(std::vector<DefinedCommon *> Syms)
: InputSection<ELFT>(nullptr, &Hdr, "") {
....
for (DefinedCommon *Sym : Syms) {
this->Alignment = std::max<uintX_t>(this->Alignment, Sym->Alignment);
...
}
}
Patch fixes the issue.
Differential revision: https://reviews.llvm.org/D25235
llvm-svn: 283733
Absolute local symbols with name staring from ".L" were reason of crash.
The same could happen when using some broken inputs found by AFL.
Patch fixes that.
Differential revision: https://reviews.llvm.org/D25365
llvm-svn: 283731
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
When sh_info of sumbol table value was set to zero, lld was asserting.
Patch fixes the issue.
Differential revision: https://reviews.llvm.org/D25016
llvm-svn: 283562
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
Previously if sh_size of dynamic section was broken,
lld may crash. Or even may not crash if used 32 bits host.
(then value may be truncated to 32 bits when doing pointer arithmetic
and could be just zero).
Patch fixes the issue.
Differential revision: https://reviews.llvm.org/D25327
llvm-svn: 283533
createELFObj() may call error(...), for example when file is too short.
In that case header is not set and following line lead to crash:
EMachine = ELFObj.getHeader()->e_machine;
Patch fixes the issue.
Differential revision: https://reviews.llvm.org/D25233
llvm-svn: 283532
This patch makes the check for null section stricter,
so it is only allowed for STT_SECTION symbols now.
Differential revision: https://reviews.llvm.org/D25231
llvm-svn: 283426
With this, "llvm-pdbdump yaml -ipi-stream" prints out an IPI stream.
Previously it crashed because it can't handle the case where IPI
stream doesn't exist.
llvm-svn: 283392
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
Do not merge sections if generating a relocatable object. It makes
the code simpler because we do not need to update relocations addends
to reflect changes introduced by merging. Instead of that we write
such "merge" sections into separate OutputSections and keep SHF_MERGE
/ SHF_STRINGS flags and sh_entsize value to be able to perform merging
later during a final linking.
Differential Revision: http://reviews.llvm.org/D25066
llvm-svn: 283300
Rui Ueyama