| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: To be consistent with other files where only SignExtend64 is used.
Reviewers: ruiu, espindola
Subscribers: emaste, arichardson, llvm-commits
Differential Revision: https://reviews.llvm.org/D50366
llvm-svn: 339083
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GNU ld's manual says that TARGET(foo) is basically an alias for
`--format foo` where foo is a BFD target name such as elf64-x86-64.
Unlike GNU linkers, lld doesn't allow arbitrary BFD target name for
--format. We accept only "default", "elf" or "binary". This makes
situation a bit tricky because we can't simply make TARGET an alias for
--target.
A quick code search revealed that the usage number of TARGET is very
small, and the only meaningful usage is to switch to the binary mode.
Thus, in this patch, we handle only TARGET(elf.*) and TARGET(binary).
Differential Revision: https://reviews.llvm.org/D48153
llvm-svn: 339060
|
|
|
|
|
|
|
|
| |
This allows safe ICF to work when linking with LTO.
Differential Revision: https://reviews.llvm.org/D50221
llvm-svn: 339050
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
During copy relocation of a variable defined in a DSO, if a TLS variable in that DSO happens to have the same st_value, it would also be copied. This was unnecessary because the addresses of TLS variables are relative to TLS segment. They don't interfere with non-TLS variables.
This copying behavior can be harmful in the following scenario:
For function-scope thread-local variables with non-trivial constructors,
they have guard variables. In the case of x86_64 general-dynamic model:
template <int N>
void foo() {
thread_local std::string a;
}
GOT[n] R_X86_64_DTPMOD64 guard variable for a
GOT[n+1] R_X86_64_DTPOFF64 guard variable for a
GOT[n+2] R_X86_64_DTPMOD64 a
GOT[n+3] R_X86_64_DTPOFF64 a
a and its guard variable are both represented as TLS variables, which
should be within the same module. If one is copy relocated to the main
module while the other is not, their module ID will mismatch and can
cause access without prior construction.
Reviewers: ruiu, espindola
Subscribers: emaste, arichardson, llvm-commits
Differential Revision: https://reviews.llvm.org/D50289
llvm-svn: 339042
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some parts of the code changed are a bit old. I found traces in 2016.
Initiall commits has test cases and perhaps reasonable comments.
For example, we had segfaults earlier and had the code to fix them.
Now, in 2018, I think it is excessive to have these parts, because
we do not have segfaults and our code was changed a lot (softly saying).
I reviewed the current sources and I think that at this point of the
execution flow, we should never face with
the conditions checked and so I removing them in this patch.
This helps to cleanup the code.
llvm-svn: 339003
|
|
|
|
|
|
|
|
|
|
| |
case when we fail to write the output."
It broke BB:
http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/builds/34382/steps/test/logs/stdio
http://lab.llvm.org:8011/builders/lld-x86_64-freebsd/builds/21932/steps/test_lld/logs/stdio
llvm-svn: 338960
|
|
|
|
|
|
|
|
| |
output.
We did not report the file name and had no test for that case.
llvm-svn: 338959
|
|
|
|
|
|
|
| |
This change removes the dead code and makes cosmetic change
showing why it was dead.
llvm-svn: 338957
|
|
|
|
|
|
|
| |
rangeToString() takes addres and length,
previously it was called incorrectly.
llvm-svn: 338956
|
|
|
|
|
|
|
|
|
|
|
| |
This simplifies the code a bit.
It is NFC except that it removes early exit for Count == 0
which does not seem to be useful (we have no such tests either).
Differential revision: https://reviews.llvm.org/D49136
llvm-svn: 338953
|
|
|
|
|
|
|
|
|
|
| |
error handling. Add test file for better code-coverage. Update tests to be more complete.
Submitting patch on behalf of saugustine.
Differential Revision: https://reviews.llvm.org/D49926
llvm-svn: 338750
|
|
|
|
|
|
|
| |
In according to the comment, undefined symbol should never reach there.
So, should be able to remove the check. I am assuming this is NFC.
llvm-svn: 338723
|
|
|
|
|
|
|
| |
BB is unhappy :`-(
http://lab.llvm.org:8011/builders/lld-perf-testsuite/builds/5632
llvm-svn: 338722
|
|
|
|
|
|
|
| |
There is no point to explicitly proccess the expressions this patch removes.
We already have a llvm_unreachable for the default case.
llvm-svn: 338718
|
|
|
|
|
|
|
|
|
|
|
| |
It does not seem that this code is alive.
I seems was needed previously but we fixed it.
If it is still needed, it needs new tests,
but for now I do not know how to trigger it,
and so I removed it.
llvm-svn: 338713
|
|
|
|
|
|
|
|
| |
Code was never executed with our test cases,
though it is valid and I think we can always run it.
This improves code coverage.
llvm-svn: 338708
|
|
|
|
|
|
|
|
| |
isHeaderSection can be useful I believe,
but probably not right now and not
for this case.
llvm-svn: 338699
|
|
|
|
|
|
|
|
|
|
|
|
| |
Patch by Konstantin Schwarz!
If more than a single output section is added to a PT_LOAD header,
only the first section should set the LMAOffset of the segment.
Otherwise, we get a load-address overlap error
Differential revision: https://reviews.llvm.org/D50133
llvm-svn: 338697
|
|
|
|
|
|
|
|
|
|
|
|
| |
Patch by Konstantin Schwarz!
If both the MemRegion and LMARegion are set for an output section in
a linker script, we should only increase the LMARegion if it is
different from the MemRegion. Otherwise, we reserve the memory twice.
Differential revision: https://reviews.llvm.org/D50065
llvm-svn: 338684
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Patch by Konstantin Schwarz!
The condition to create a new phdr must also check the usage of "AT>"
linker script command, and create a new PT_LOAD header if a new LMARegion is used.
This fixes PR38307
Differential revision: https://reviews.llvm.org/D50052
llvm-svn: 338679
|
|
|
|
| |
llvm-svn: 338647
|
|
|
|
| |
llvm-svn: 338642
|
|
|
|
|
|
|
| |
This reverts commit r338596 because it contained a functional change.
The patch accidentally replaced StringRef::startswith with the exact match.
llvm-svn: 338600
|
|
|
|
| |
llvm-svn: 338596
|
|
|
|
|
|
| |
Removal of extra line
llvm-svn: 338533
|
|
|
|
| |
llvm-svn: 338498
|
|
|
|
| |
llvm-svn: 338497
|
|
|
|
|
|
|
|
|
|
| |
isOutputFormatBinary returns false in such case.
Example: --oformat elf64-x86-64
Differential Revision: https://reviews.llvm.org/D50105
llvm-svn: 338445
|
|
|
|
|
|
|
|
|
|
|
|
| |
If any of our inputs are bitcode files, the LTO code generator may create
references to certain library functions that might not be explicit in the
bitcode file's symbol table. If any of those library functions are defined
in a bitcode file in an archive member, we need to arrange to use LTO to
compile those archive members by adding them to the link beforehand.
Differential Revision: https://reviews.llvm.org/D50017
llvm-svn: 338434
|
|
|
|
| |
llvm-svn: 338409
|
|
|
|
|
|
|
|
|
|
| |
This patch does the same thing as r338153 for COFF.
Note that this patch affects only the order of log messages.
The output file is already deterministic.
Differential Revision: https://reviews.llvm.org/D50023
llvm-svn: 338406
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The Tag_ABI_VFP_args build attribute controls the procedure call standard
used for floating point parameters on ARM. The values are:
0 - Base AAPCS (FP Parameters passed in Core (Integer) registers
1 - VFP AAPCS (FP Parameters passed in FP registers)
2 - Toolchain specific (Neither Base or VFP)
3 - Compatible with all (No use of floating point parameters)
If the Tag_ABI_VFP_args build attribute is missing it has an implicit value
of 0.
We use the attribute in two ways:
- Detect a clash in calling convention between Base, VFP and Toolchain.
we follow ld.bfd's lead and do not error if there is a clash between an
implicit Base AAPCS caused by a missing attribute. Many projects
including the hard-float (VFP AAPCS) version of glibc contain assembler
files that do not use floating point but do not have Tag_ABI_VFP_args.
- Set the EF_ARM_ABI_FLOAT_SOFT or EF_ARM_ABI_FLOAT_HARD ELF header flag
for Base or VFP AAPCS respectively. This flag is used by some ELF
loaders.
References:
- Addenda to, and Errata in, the ABI for the ARM Architecture for
Tag_ABI_VFP_args
- Elf for the ARM Architecture for ELF header flags
Fixes PR36009
Differential Revision: https://reviews.llvm.org/D49993
llvm-svn: 338377
|
|
|
|
| |
llvm-svn: 338275
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This adds an LLD flag to mark executable LOAD segments execute-only for AArch64 targets.
In AArch64 the expectation is that code is execute-only compatible, so this just adds a linker option to enforce this.
Patch by: ivanlozano (Ivan Lozano)
Reviewers: srhines, echristo, peter.smith, eugenis, javed.absar, espindola, ruiu
Reviewed By: ruiu
Subscribers: dokyungs, emaste, arichardson, kristof.beyls, llvm-commits
Differential Revision: https://reviews.llvm.org/D49456
llvm-svn: 338271
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is relative to https://bugs.llvm.org//show_bug.cgi?id=38119.
SHT_SYMTAB section is able to keep symbols with output section indices
up to 0xff00 (SHN_LORESERVE). But if we have indices that are greater
than that (PR shows that it might happen), we need to use
SHT_SYMTAB_SHNDX extended section. It was not supported by LLD.
Description of the SHT_SYMTAB_SHNDX section is here:
https://docs.oracle.com/cd/E19683-01/817-3677/chapter6-94076/index.html.
Differential revision: https://reviews.llvm.org/D49541
llvm-svn: 338247
|
|
|
|
|
|
| |
And add a test.
llvm-svn: 338213
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The xxHash64 function has been made unsigned-char-independent, so
we can reland this change now.
Original commit message:
> The icf-safe.s test currently fails on 32-bit platforms because it uses
> the --print-icf-sections flag and depends on the output appearing in
> a specific order. However, this flag causes the output to depend on
> the order of the sections in the Sections array, which depends on the
> hash values returned from hash_combine, which happen to be different
> for that test between 32-bit and 64-bit platforms.
>
> This change makes the output deterministic by using xxHash64 instead of
> hash_combine.
Differential Revision: https://reviews.llvm.org/D49877
llvm-svn: 338153
|
|
|
|
|
|
|
| |
This reverts commit r338088. To unbreak our integrate.
The resulting lld output is different if compiled with '-funsigned-char'.
llvm-svn: 338110
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The icf-safe.s test currently fails on 32-bit platforms because it uses
the --print-icf-sections flag and depends on the output appearing in
a specific order. However, this flag causes the output to depend on
the order of the sections in the Sections array, which depends on the
hash values returned from hash_combine, which happen to be different
for that test between 32-bit and 64-bit platforms.
This change makes the output deterministic by using xxHash64 instead of
hash_combine.
Differential Revision: https://reviews.llvm.org/D49877
llvm-svn: 338088
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: This behavior matches ld.bfd -Ld --version-script=t.script a.o
Reviewers: ruiu, espindola
Subscribers: emaste, arichardson, llvm-commits
Differential Revision: https://reviews.llvm.org/D49820
llvm-svn: 337969
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We are already ICF'ing these sections as a unit with their dependent
sections, so they don't need to be considered for ICF individually.
This change also "fixes" slowness caused by our quadratic-in-group-size
relocation segregation algorithm on 32-bit ARM platforms with unwind
data and ICF on rodata. In this scenario almost every function's
.ARM.exidx is identical except for the targets of the relocations
that refer to the function and its .ARM.extab, which causes almost
all of the program's .ARM.exidx sections to be initially added to the
same class, which causes us to compare every such section with every
other such section.
Differential Revision: https://reviews.llvm.org/D49716
llvm-svn: 337967
|
|
|
|
|
|
|
|
| |
Update testcase
Differential Revision: https://reviews.llvm.org/D49567
llvm-svn: 337829
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If we fail to merge a secondary GOT with the primary GOT but so far only
one merged GOT has been created (the primary one), the final element in
MergedGots is the primary GOT. Thus we should not try to merge with this
final element passing IsPrimary=false, since this will ignore the fact
that the destination GOT does in fact need a header, and those extra two
entries can be enough to allow the merge to incorrectly occur. Instead
we should check for this case before attempting the second merge.
Patch by James Clarke.
Differential revision: https://reviews.llvm.org/D49422
llvm-svn: 337810
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The gold behaviour with regard to --keep-unique is arguably a bug.
I also noticed a bug in my patch, which is that we mislink the
following program with --icf=safe by merging f3 and f4:
void f1() {}
void f2() {}
__attribute__((weak)) void* f3() { return f1; }
__attribute__((weak)) void* f4() { return f2; }
int main() {
printf("%p %p\n", f3(), f4());
}
llvm-svn: 337729
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Signed values for the FDE PC addr were not correctly handled in
readFdeAddr(). If the value is negative and the type of the value is
smaller than 64 bits, the FDE PC addr overflow error would be
incorrectly triggered.
Fixed readFdeAddr() to properly handle signed values by sign extending
where appropriate.
Differential Revision: https://reviews.llvm.org/D49557
llvm-svn: 337683
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Under --icf=all we now only apply KeepUnique to non-executable
address-significant sections. This has the effect of making --icf=all
mean unsafe ICF for executable sections and safe ICF for non-executable
sections.
With this change the meaning of the KeepUnique bit changes to
"does the current ICF mode (together with the --keep-unique and
--ignore-data-address-equality flags) require this section to be
kept unique".
Differential Revision: https://reviews.llvm.org/D49626
llvm-svn: 337640
|
|
|
|
|
|
|
|
|
|
| |
The only restriction is that we cannot merge more than one KeepUnique
section together. This matches gold's behaviour and reduces code size
when using --icf=safe.
Differential Revision: https://reviews.llvm.org/D49622
llvm-svn: 337638
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
lld currently prepends the absolute path to itself to every diagnostic it
emits. This path can be longer than the diagnostic, and makes the actual error
message hard to read.
There isn't a good reason for printing this path: if you want to know which lld
you're running, pass -v to clang – chances are that if you're unsure of this,
you're not only unsure when it errors out. Some people want an indication that
the diagnostic is from the linker though, so instead print just the basename of
the linker's path.
Before:
```
$ out/bin/clang -target x86_64-unknown-linux -x c++ /dev/null -fuse-ld=lld
/Users/thakis/src/llvm-mono/out/bin/ld.lld: error: cannot open crt1.o: No such file or directory
/Users/thakis/src/llvm-mono/out/bin/ld.lld: error: cannot open crti.o: No such file or directory
/Users/thakis/src/llvm-mono/out/bin/ld.lld: error: cannot open crtbegin.o: No such file or directory
/Users/thakis/src/llvm-mono/out/bin/ld.lld: error: unable to find library -lgcc
/Users/thakis/src/llvm-mono/out/bin/ld.lld: error: unable to find library -lgcc_s
/Users/thakis/src/llvm-mono/out/bin/ld.lld: error: unable to find library -lc
/Users/thakis/src/llvm-mono/out/bin/ld.lld: error: unable to find library -lgcc
/Users/thakis/src/llvm-mono/out/bin/ld.lld: error: unable to find library -lgcc_s
/Users/thakis/src/llvm-mono/out/bin/ld.lld: error: cannot open crtend.o: No such file or directory
/Users/thakis/src/llvm-mono/out/bin/ld.lld: error: cannot open crtn.o: No such file or directory
clang: error: linker command failed with exit code 1 (use -v to see invocation)
```
After:
```
$ out/bin/clang -target x86_64-unknown-linux -x c++ /dev/null -fuse-ld=lld
ld.lld: error: cannot open crt1.o: No such file or directory
ld.lld: error: cannot open crti.o: No such file or directory
ld.lld: error: cannot open crtbegin.o: No such file or directory
ld.lld: error: unable to find library -lgcc
ld.lld: error: unable to find library -lgcc_s
ld.lld: error: unable to find library -lc
ld.lld: error: unable to find library -lgcc
ld.lld: error: unable to find library -lgcc_s
ld.lld: error: cannot open crtend.o: No such file or directory
ld.lld: error: cannot open crtn.o: No such file or directory
clang: error: linker command failed with exit code 1 (use -v to see invocation)
```
https://reviews.llvm.org/D49189
llvm-svn: 337634
|
|
|
|
|
|
|
|
|
|
|
|
| |
addresses
Reviewers: grimar, ruiu, espindola
Subscribers: emaste, arichardson, llvm-commits
Differential Revision: https://reviews.llvm.org/D49607
llvm-svn: 337610
|
|
|
|
|
|
|
|
| |
Add support and update the testcase.
Differential Revision: https://reviews.llvm.org/D49394
llvm-svn: 337494
|