The PPC64 elf V2 abi defines 2 entry points for a function. There are a few
places we need to calculate the offset from the global entry to the local entry
and how this is done is not straight forward. This patch adds a helper function
mostly for documentation purposes, explaining how the 2 entry points differ and
why we choose one over the other, as well as documenting how the offsets are
encoded into a functions st_other field.
Differential Revision: https://reviews.llvm.org/D52231
llvm-svn: 342603
The access sequence for global variables in the medium and large code models use
2 instructions to add an offset to the toc-pointer. If the offset fits whithin
16-bits then the instruction that sets the high 16 bits is redundant.
This patch adds the --toc-optimize option, (on by default) and enables rewriting
of 2 instruction global variable accesses into 1 when the offset from the
TOC-pointer to the variable (or .got entry) fits in 16 signed bits. eg
addis %r3, %r2, 0 --> nop
addi %r3, %r3, -0x8000 --> addi %r3, %r2, -0x8000
This rewriting can be disabled with the --no-toc-optimize flag
Differential Revision: https://reviews.llvm.org/D49237
llvm-svn: 342602
Summary:
For --pack-dyn-relocs=android, finalizeSections calls
LinkerScript::assignAddresses and
AndroidPackedRelocationSection::updateAllocSize in a loop,
where assignAddresses lays out the ELF image, then updateAllocSize
determines the size of the Android packed relocation table by encoding it.
Encoding the table requires knowing the values of relocation addends.
To get the addend of a TLS relocation, updateAllocSize can call getSymVA
on a TLS symbol before setPhdrs has initialized Out::TlsPhdr, producing an
error:
<file> has an STT_TLS symbol but doesn't have an SHF_TLS section
Fix the problem by initializing Out::TlsPhdr immediately after the program
headers are created. The segment's p_vaddr field isn't initialized until
setPhdrs, so use FirstSec->Addr, which is what setPhdrs would use.
FirstSec will typically refer to the .tdata or .tbss output section, whose
(tentative) address was computed by assignAddresses.
Android currently avoids this problem because it uses emutls and doesn't
support ELF TLS. This problem doesn't apply to --pack-dyn-relocs=relr
because SHR_RELR only handles relative relocations without explicit addends
or info.
Fixes https://bugs.llvm.org/show_bug.cgi?id=37841.
Reviewers: ruiu, pcc, chh, javed.absar, espindola
Subscribers: emaste, arichardson, llvm-commits, srhines
Differential Revision: https://reviews.llvm.org/D51671
llvm-svn: 342432
A General-dynamic tls access can be written using a R_PPC64_TLSGD16 relocation
if the target got entry is within 16 bits of the TOC-base. This patch adds
support for R_PPC64_TLSGD16 by relaxing it the same as a R_PPC64_GOT_TLSGD16_LO.
Differential Revision: https://reviews.llvm.org/D52055
llvm-svn: 342411
There are a growing number of places when we either want to read or write an
instruction when handling a half16 relocation type. On big-endian the buffer
pointer is pointing into the middle of the word we want and on little-endian it
is pointing to the start of the word. These 2 helpers are to simplify reading
and writing in these contexts.
Differential Revision: https://reviews.llvm.org/D52115
llvm-svn: 342410
tolower() has some overhead because current locale is considered (though in lld the default "C" locale is used which does not matter too much). llvm::toLower is more efficient as it compiles to a compare and a conditional jump, as opposed to a libc call if tolower is used.
Disregarding locale also matches gdb's behavior (gdb/minsyms.h):
#define SYMBOL_HASH_NEXT(hash, c) \
((hash) * 67 + TOLOWER ((unsigned char) (c)) - 113)
where TOLOWER (include/safe-ctype.h) is a macro that uses a lookup table under the hood which is similar to llvm::toLower.
Reviewers: ruiu, espindola
Subscribers: emaste, arichardson, llvm-commits
Differential Revision: https://reviews.llvm.org/D52128
llvm-svn: 342342
These files used to contain classes and functions for .gdb_index,
but they are moved to SyntheticSections.{cpp,h}, so the name is now
irrelevant.
llvm-svn: 342299
Once we create .gdb_index contents, .zdebug_gnu_pub{names,types}
are useless, so there's no need to keep their uncompressed data
in memory.
I observed that for a test case in which lld creates a 3GB .gdb_index
section, the maximum resident set size reduced from 43GB to 29GB after
this patch.
Differential Revision: https://reviews.llvm.org/D52126
llvm-svn: 342297
-z interpose sets the DF_1_INTERPOSE flag, marking the object as an
interposer.
Via FreeBSD PR 230604, linking Valgrind with lld failed.
Differential Revision: https://reviews.llvm.org/D52094
llvm-svn: 342239
If --just-syms is used the mapping symbols from the ELF file will be
absolute symbols with no section. The code to process mapping symbols in
--fix-cortex-a53-843419 assumes that these symbols have a defining section
so a crash will result when --just-syms is used. The simple fix is to not
process the symbol when it doesn't have a section.
Fixes PR37971
Differential Revision: https://reviews.llvm.org/D52038
llvm-svn: 342146
Summary: This protects lld from a null pointer dereference when a faulty input file has such invalid sh_link fields.
Reviewers: ruiu, espindola
Reviewed By: ruiu
Subscribers: emaste, arichardson, llvm-commits
Differential Revision: https://reviews.llvm.org/D51743
llvm-svn: 341611
section will not have an input file. Don't crash under those circumstances.
Neither clang nor llvm-mc generates R_X86_64_PC32 relocations due to
https://reviews.llvm.org/D43383, which makes it hard to write a test case.
However, gcc does generate such relocations. I want to get a fix in now,
but will figure out a way to actually exercise this code path as soon
as I can.
llvm-svn: 341408
This patch moves the checking for too large offsets into merge sections
earlier.
Without this change the large offset generated in the added test-case
will cause an assert (as it happens to be a value reserved as a
"tombstone" in the DenseMap implementation) when OffsetMap is queried in
getSectionPiece().
To simplify the code and avoid future mistakes I have refactored so that
there is only one function that looks up offsets in the OffsetMap.
Differential Revision: https://reviews.llvm.org/D51180
llvm-svn: 341206
These symbols are declared early with the same value, so they otherwise
appear identical to ICF.
Differential Revision: https://reviews.llvm.org/D51376
llvm-svn: 340998
With this patch, lld creates a .note.GNU_stack and adds that to an
output file if it is creating a re-linkable object file (i.e. if -r
is given). If we don't do this, and if you use GNU linkers as a final
linker, they create an executable whose stack area is executable,
which is considered pretty bad these days.
Differential Revision: https://reviews.llvm.org/D51400
llvm-svn: 340902
Relanding r340564, original commit message:
Fixes the handling of *_DS relocations used on DQ-form instructions where we
were overwriting some of the extended opcode bits. Also adds an alignment check
so that the user will receive a diagnostic error if the value we are writing
is not properly aligned.
Differential Revision: https://reviews.llvm.org/D51124
llvm-svn: 340832
Looking at the current implementation and algorithm description,
it does not seem we need to keep vector with all edges for
each cluster and can just remember the best one. This is NFC change.
Differential revision: https://reviews.llvm.org/D50609
llvm-svn: 340806
This reverts commit 5125b44dbb5d06b715213e4bec75c7346bfcc7d3.
ppc64-dq.s and ppc64-error-missaligned-dq.s fail on several of the build-bots.
Reverting to investigate.
llvm-svn: 340568
Fixes the handling of *_DS relocations used on DQ-form instructions where we
were overwriting some of the extended opcode bits. Also adds an alignment check
so that the user will receive a diagnostic error if the value we are writing
is not properly aligned.
Differential Revision: https://reviews.llvm.org/D51124
llvm-svn: 340564
This is a minor follow-up to https://reviews.llvm.org/D49189. On Windows, lld
used to print "lld-link.exe: error: ...". Now it just prints "lld-link: error:
...". This matches what link.exe does (it prints "LINK : ...") and makes lld's
output less dependent on the host system.
https://reviews.llvm.org/D51133
llvm-svn: 340487
We have an issue with -wrap that the option doesn't work well when
renamed symbols get PLT entries. I'll explain what is the issue and
how this patch solves it.
For one -wrap option, we have three symbols: foo, wrap_foo and real_foo.
Currently, we use memcpy to overwrite wrapped symbols so that they get
the same contents. This works in most cases but doesn't when the relocation
processor sets some flags in the symbol. memcpy'ed symbols are just
aliases, so they always have to have the same contents, but the
relocation processor breaks that assumption.
r336609 is an attempt to fix the issue by memcpy'ing again after
processing relocations, so that symbols that are out of sync get the
same contents again. That works in most cases as well, but it breaks
ASan build in a mysterious way.
We could probably fix the issue by choosing symbol attributes that need
to be copied after they are updated. But it feels too complicated to me.
So, in this patch, I fixed it once and for all. With this patch, we no
longer memcpy symbols. All references to renamed symbols point to new
symbols after wrapSymbols() is done.
Differential Revision: https://reviews.llvm.org/D50569
llvm-svn: 340387
Summary:
For -thinlto-object-suffix-replace=old\;new, in
tools/gold/gold-plugin.cpp, the thinlto object filename is Path minus
optional old suffix.
static std::string getThinLTOObjectFileName(StringRef Path, StringRef OldSuffix,
StringRef NewSuffix) {
if (OldSuffix.empty() && NewSuffix.empty())
return Path;
StringRef NewPath = Path;
NewPath.consume_back(OldSuffix);
std::string NewNewPath = NewPath;
NewNewPath += NewSuffix;
return NewNewPath;
}
Currently lld will error that the path does not end with old suffix.
This patch makes lld accept such paths but only add new suffix if Path
ends with old suffix. This fixes a link error where bitcode members in
an archive are regular LTO objects without old suffix.
Acording to tejohnson, this will "enable supporting mix and match of
minimized ThinLTO bitcode files with normal ThinLTO bitcode files in a
single link (where we want to apply the suffix replacement to the
minimized files, and just ignore it for the normal ThinLTO files)."
Reviewers: ruiu, pcc, tejohnson, espindola
Reviewed By: tejohnson
Subscribers: emaste, inglorion, arichardson, eraman, steven_wu, dexonsmith, llvm-commits
Differential Revision: https://reviews.llvm.org/D51055
llvm-svn: 340364
This patch adds the target call back relaxTlsIeToLe to support TLS relaxation
from initial exec to local exec model.
Differential Revision: https://reviews.llvm.org/D48091
llvm-svn: 340281
Our code in LazyObjFile::parse() has an ELFT switch and
adds a lazy object by its ELFT kind.
Though it might be possible to add a file using a different
architecture and make LLD to silently accept it (if the file
is empty or contains only week symbols). That itself, not a
huge issue perhaps (because the error would be reported later
if the file is fetched), but still does not look clean and correct.
It is possible to report an error earlier and clean up the
code. That is what the patch does.
Ideally, we might want to reuse isCompatible from SymbolTable.cpp,
but it is static and accepts a file as an argument, what is not
convenient. Since such a situation should be rare, I think it
should be OK to go with the way chosen in this patch.
Differential revision: https://reviews.llvm.org/D50899
llvm-svn: 340257
This fixes the following warning when compiling with gcc version 8.0.1 20180319 (experimental) (GCC):
/home/umb/LLVM/llvm/tools/lld/ELF/SyntheticSections.cpp:1951:46: warning: enumeral and non-enumeral type in conditional expression [-Wextra]
return OS->SectionIndex >= SHN_LORESERVE ? SHN_XINDEX : OS->SectionIndex;
llvm-svn: 340164
Older Arm architectures do not support the MOVT and MOVW instructions so we
must use an alternative sequence of instructions to transfer control to the
destination.
Assuming at least Armv5 this patch adds support for Thunks that load or add
to the program counter. Note that there are no Armv5 Thumb Thunks as there
is no Thumb branch instruction in Armv5 that supports Thunks. These thunks
will not work for Armv4t (arm7tdmi) as this architecture cannot change state
from using the LDR or ADD instruction.
Differential Revision: https://reviews.llvm.org/D50077
llvm-svn: 340160
The Thumb BL and BLX instructions on older Arm Architectures such as v5 and
v6 have a constrained encoding J1 and J2 must equal 1, later Architectures
relaxed this restriction allowing J1 and J2 to be used to calculate a larger
immediate.
This patch adds support for the old encoding, it is used when the build
attributes for the input objects only contain older architectures.
Differential Revision: https://reviews.llvm.org/D50076
llvm-svn: 340159
Summary: This makes it conform to what the comment says. Otherwise when getErrPlace() is called afterwards, cast<InputSection>(D) will cause incompatible cast as MergeInputSection is not a subclass of InputSection.
Reviewers: ruiu, grimar, espindola, pcc
Reviewed By: grimar
Subscribers: emaste, arichardson, llvm-commits
Differential Revision: https://reviews.llvm.org/D50742
llvm-svn: 339904
This patch solves 2 problems:
1) It adds a test to check the line below:
https://github.com/llvm-mirror/lld/blob/master/ELF/InputFiles.cpp#L334
Test case contains SHT_GROUP section with a broken (0xFF) flag.
2) The patch fixes the case when we silently accepted such broken groups
in the case when there were no other objects with the same group signature.
llvm-svn: 339765
We have a dead piece of code there which is impossible to trigger
using regular objects I believe.
Patch removes it and adds a test case showing how this condition
can be triggered with use of a broken object and crash the linker.
llvm-svn: 339680
The code involved was simply dead. `IgnoreAll` value is used in
`maybeReportUndefined` only which is never called for -r.
And at the same time `IgnoreAll` was set only for -r.
llvm-svn: 339672
That piece of code is really very old and "protected"
from TLS relocations against symbol in non-allocatable sections.
It is useless because normally non-alloc sections have relocations
with allocatable targets, but not the reverse.
And so the code was simply dead.
llvm-svn: 339553
It turns out that postThunkContents() is only used for
sorting symbols in .symtab.
Though we can instead move the logic to SymbolTableBaseSection::finalizeContents(),
postpone calling it and then get rid of postThunkContents completely.
Differential revision: https://reviews.llvm.org/D49547
llvm-svn: 339413
We have a crash issue when handling the empty -defsym.
For parsing this option we are using ScriptParser class which is used
generally for reading the linker script. For empty defsym case, we
pass the empty memory buffer and crash in the place removed in https://reviews.llvm.org/rL336436.
But reverting of the above patch would not help here (we would still crash but a bit later). And
even after fixing the crash we would report something like
"lld.exe: error: -defsym:1: unexpected EOF"
It is probably not the appropriate message because mentions EOF.
I think the issue should be handled on a higher level like this patch does.
So we do not want to pass the empty memory buffer first of all I believe.
Differential revision: https://reviews.llvm.org/D50498
llvm-svn: 339412
Patch by PkmX.
This patch makes lld recognize RISC-V target and implements basic
relocation for RV32/RV64 (and RVC). This should be necessary for static
linking ELF applications.
The ABI documentation for RISC-V can be found at:
https://github.com/riscv/riscv-elf-psabi-doc/blob/master/riscv-elf.md.
Note that the documentation is far from complete so we had to figure out
some details from bfd.
The patch should be pretty straightforward. Some highlights:
- A new relocation Expr R_RISCV_PC_INDIRECT is added. This is needed as
the low part of a PC-relative relocation is linked to the corresponding
high part (auipc), see:
https://github.com/riscv/riscv-elf-psabi-doc/blob/master/riscv-elf.md#pc-relative-symbol-addresses
- LLVM's MC support for RISC-V is very incomplete (we are working on
this), so tests are given in objectyaml format with the original
assembly included in the comments. Once we have complete support for
RISC-V in MC, we can switch to llvm-as/llvm-objdump.
- We don't support linker relaxation for now as it requires greater
changes to lld that is beyond the scope of this patch. Once this is
accepted we can start to work on adding relaxation to lld.
Differential Revision: https://reviews.llvm.org/D39322
llvm-svn: 339364
This is a larger patch. This relocation has irregular immediate
masks that require a lookup to find the correct mask.
Differential Revision: https://reviews.llvm.org/D50450
llvm-svn: 339332
Adding all libcall symbols to the link can have undesired consequences.
For example, the libgcc implementation of __sync_val_compare_and_swap_8
on 32-bit ARM pulls in an .init_array entry that aborts the program if
the Linux kernel does not support 64-bit atomics, which would prevent
the program from running even if it does not use 64-bit atomics.
This change makes it so that we only add libcall symbols to the
link before LTO if we have to, i.e. if the symbol's definition is in
bitcode. Any other required libcall symbols will be added to the link
after LTO when we add the LTO object file to the link.
Differential Revision: https://reviews.llvm.org/D50475
llvm-svn: 339301
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
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
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
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
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
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
This reverts commit r338596 because it contained a functional change.
The patch accidentally replaced StringRef::startswith with the exact match.
llvm-svn: 338600
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
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
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
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
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
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
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
Currently, getFdePC() returns uint64_t. Its because the following
encodings might use 8 bytes: DW_EH_PE_absptr and DW_EH_PE_udata8.
But caller assigns returned value to uint32_t field:
https://github.com/llvm-mirror/lld/blob/master/ELF/SyntheticSections.cpp#L508
Value is used for building .eh_frame_hdr section.
We use DW_EH_PE_sdata4 encoding for building it at this moment:
https://github.com/llvm-mirror/lld/blob/master/ELF/SyntheticSections.cpp#L2545
And that means that an overflow issue might happen if
DW_EH_PE_absptr/DW_EH_PE_udata8 address encodings are present
in .eh_frame. In that case, before this patch, we silently would
truncate the address and produced broken .eh_frame_hdr section.
It would be not hard to support real 64-bit values for
DW_EH_PE_absptr/DW_EH_PE_udata8 encodings, but it is
unclear if it is usefull and if we should do it.
Since nobody faced/reported it, int this patch I only implement
a check to stop producing broken output silently for now.
llvm-svn: 337382
This is a part of ttps://bugs.llvm.org//show_bug.cgi?id=38119
We produce broken ELF header now when the number of output sections is >= SHN_LORESERVE (0xff00).
ELF spec says (http://www.sco.com/developers/gabi/2003-12-17/ch4.eheader.html):
e_shnum:
If the number of sections is greater than or equal to SHN_LORESERVE (0xff00), this member has the value zero
and the actual number of section header table entries is contained in the sh_size field of the section header at index 0.
(Otherwise, the sh_size member of the initial entry contains 0.)
e_shstrndx
If the section name string table section index is greater than or equal to SHN_LORESERVE (0xff00), this member has the
value SHN_XINDEX (0xffff) and the actual index of the section name string table section is contained in the sh_link field of
the section header at index 0. (Otherwise, the sh_link member of the initial entry contains 0.)
We did not set these fields correctly earlier. The patch fixes the issue.
Differential revision: https://reviews.llvm.org/D49371
llvm-svn: 337363
Code was dead because at the moment of BssSection creation
it can never have a parent. Also, code simply does not
make sence as alignment adjastment happens when
BssSection is added to its parent later.
llvm-svn: 337276
There are following symbols currently available:
DefinedKind, SharedKind, UndefinedKind, LazyArchiveKind, LazyObjectKind.
Our code calls getSize() only for first two and there
seems to be no reason to return 0 for the rest.
llvm-svn: 337265
Summary:
This adds support to option -plugin-opt=dwo_dir=${DIR}. This option is used to specify the directory to store the .dwo files when LTO and debug fission is used
at the same time.
Reviewers: ruiu, espindola, pcc
Reviewed By: pcc
Subscribers: eraman, dexonsmith, mehdi_amini, emaste, arichardson, steven_wu, llvm-commits
Differential Revision: https://reviews.llvm.org/D47904
llvm-svn: 337195
Archives created with ThinLTO are bitcodes, they also need to be searched for excluded symbols.
Differential Revision: https://reviews.llvm.org/D48857
llvm-svn: 336826
If we have 2 bitcode inputs for different targets, LLD would
print "<internal>" instead of the name of one of the files.
The patch adds a test and fixes this issue.
llvm-svn: 336794
Since .gdb_index sections contain all known symbols, they can be very large.
One of my executables has a .gdb_index section of 1350 GiB. Uniquifying
symbols by name takes 3.77 seconds on my machine. This patch parallelize it.
Time to call createSymbols() with 8.4 million unique symbols:
Without this patch: 3773 ms
Parallelism = 1: 4374 ms
Parallelism = 2: 2628 ms
Parallelism = 16: 837 ms
As you can see above, this algorithm is a bit more inefficient
than the non-parallelized version, but even with dual-core, it is
faster than that, so I think it is overall a win.
Differential Revision: https://reviews.llvm.org/D49164
llvm-svn: 336790
This workaround is for GCC 5.4.1. Without this workaround, lld will
produce larger .gdb_index sections for object files compiled with the
buggy version of the compiler.
Since it is not for correctness, and it affects only debug builds (since
you are generating .gdb_index sections), perhaps the hack shouldn't have been
added in the first place. At least, I think it is time to remove this hack.
Differential Revision: https://reviews.llvm.org/D49149
llvm-svn: 336788
This patch merges createGdbIndex function and GdbIndexSection's
constructor into a single static member function of the class.
This patch also change how we keep CU vectors. Previously, CuVector
and GdbSymbols were parallel arrays, but there's no reason to choose that
design. Now, CuVector is a member of GdbSymbol class.
A lot of members are removed from GdbIndexSection. Previously, it has
members that need to be kept in sync over several phases. I belive the new
design is less error-prone, and the new code is much easier to read
than before.
llvm-svn: 336743
This fix add more test cases for routines check MIPS ELF header flags and
flags from .MIPS.abiflags sections. The tests use yaml2obj for object
files generation because not all combinations of flags can be produced
by LLVM tools.
llvm-svn: 336704
.gdb_index sections can be very large. When you are compiling
multi-gibibyte executables, they can be larger than 1 GiB. The previous
implementation of .gdb_index seems to consume too much memory.
This patch reduces memory consumption by eliminating temporary objects.
In one experiment, memory consumption of GdbIndexSection class is
reduced from 962 MiB to 228 MiB when creating a .gdb_index of 1350 GiB.
Differential Revision: https://reviews.llvm.org/D49094
llvm-svn: 336672
Rui Ueyama