For lld-link, unknown '/'-style flags are treated as filenames on POSIX
systems, so only '-'-style flags get typo correction for now. This
matches clang-cl.
PR37006.
Differential Revision: https://reviews.llvm.org/D61443
llvm-svn: 360145
It makes the --plugin-opt=obj-path= and --plugin-opt=thinlto-index-only=
behavior more consistent - the files will be created in the
BitcodeFiles.empty() case, but I assume whether it behaves this way is
not required by anyone.
LTOObj->run() cannot run with empty BitcodeFiles. There would be an error:
ld.lld: error: No available targets are compatible with triple ""
Differential Revision: https://reviews.llvm.org/D61635
llvm-svn: 360129
This is based on D54720 by Sean Fertile.
When accessing a global symbol which is not defined in the translation unit,
compilers will generate instructions that load the address from the toc entry.
If the symbol is defined, non-preemptable, and addressable with a 32-bit
signed offset from the toc pointer, the address can be computed
directly. e.g.
addis 3, 2, .LC0@toc@ha # R_PPC64_TOC16_HA
ld 3, .LC0@toc@l(3) # R_PPC64_TOC16_LO_DS, load the address from a .toc entry
ld/lwa 3, 0(3) # load the value from the address
.section .toc,"aw",@progbits
.LC0: .tc var[TC],var
can be relaxed to
addis 3,2,var@toc@ha # this may be relaxed to a nop,
addi 3,3,var@toc@l # then this becomes addi 3,2,var@toc
ld/lwa 3, 0(3) # load the value from the address
We can delete the test ppc64-got-indirect.s as its purpose is covered by
newly added ppc64-toc-relax.s and ppc64-toc-relax-constants.s
Reviewed By: ruiu, sfertile
Differential Revision: https://reviews.llvm.org/D60958
llvm-svn: 360112
Summary:
While the generic ABI requires notes to be 8-byte aligned in ELF64, many
vendor-specific notes (from Linux, NetBSD, Solaris, etc) use 4-byte
alignment.
In a PT_NOTE segment, if 4-byte aligned notes are followed by an 8-byte
aligned note, the possible 4-byte padding may make consumers fail to
parse the 8-byte aligned note. See PR41000 for a recent report about
.note.gnu.property (NT_GNU_PROPERTY_TYPE_0).
(Note, for NT_GNU_PROPERTY_TYPE_0, the consumers should probably migrate
to PT_GNU_PROPERTY, but the alignment issue affects other notes as well.)
To fix the issue, don't mix notes with different alignments in one
PT_NOTE. If compilers emit 4-byte aligned notes before 8-byte aligned
notes, we'll create at most 2 segments.
sh_size%sh_addralign=0 is actually implied by the rule for linking
unrecognized sections (in generic ABI), so we don't have to check that.
Notes that match in name, type and attribute flags are concatenated into
a single output section. The compilers have to ensure
sh_size%sh_addralign=0 to make concatenated notes parsable.
An alternative approach is to create a PT_NOTE for each SHT_NOTE, but
we'll have to incur the sizeof(Elf64_Phdr)=56 overhead every time a new
note section is introduced.
Reviewers: ruiu, jakehehrlich, phosek, jhenderson, pcc, espindola
Subscribers: emaste, arichardson, krytarowski, fedor.sergeev, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D61296
llvm-svn: 359853
Summary:
The gold plugin behavior (creating empty index files for lazy bitcode
files) was added in D46034, but it missed the case when there is no
non-lazy bitcode files, e.g.
ld.lld -shared crti.o crtbeginS.o --start-lib bitcode.o --end-lib ...
crti.o crtbeginS.o are not bitcode, but our distributed build system
wants bitcode.o.thinlto.bc to confirm all expected outputs are created
based on all of the modules provided to the linker.
Differential Revision: https://reviews.llvm.org/D61420
llvm-svn: 359788
/DISCARD/ output sections were being treated as orphans. As a result, if
a /DISCARD/ output section has been assigned a PHDR, it could cause
incorrect assignment of sections to segments.
Differential Revision: https://reviews.llvm.org/D61186
llvm-svn: 359565
This is a follow up to r358979 which made findOrphanPos only consider
live sections. Unfortunately, this required change to getRankProximity,
used by findOrphanPos, was missed.
Differential Revision: https://reviews.llvm.org/D61197
llvm-svn: 359554
This is https://bugs.llvm.org//show_bug.cgi?id=38750.
If script references empty sections in LOADADDR/ADDR commands
.empty : { *(.empty ) }
.text : AT(LOADADDR (.empty) + SIZEOF (.empty)) { *(.text) }
then an empty section will be removed and LOADADDR/ADDR will evaluate to null.
It is not that user may expect from using of the generic script, what is a common case.
Differential revision: https://reviews.llvm.org/D54621
llvm-svn: 359279
Summary:
We use `uint32_t SectionBase::Alignment` and `uint32_t
PhdrEntry::p_align` despite alignments being 64 bits in ELF64.
Fix the std::max template arguments accordingly.
The currently 160-byte InputSection will become 168 bytes if we make SectionBase::Alignment uint64_t.
Differential Revision: https://reviews.llvm.org/D61171
llvm-svn: 359268
Summary:
We don't take localentry offset into account, and thus may fail to
create a long branch when the gap is just a few bytes smaller than 2^25.
relocation R_PPC64_REL24 out of range: 33554432 is not in [-33554432, 33554431]
relocation R_PPC64_REL24 out of range: 33554436 is not in [-33554432, 33554431]
Fix that by adding the offset to the symbol VA.
Differential Revision: https://reviews.llvm.org/D61058
llvm-svn: 359094
This fixes an issue where a symbol only section at the start of a
PT_LOAD segment, causes incorrect alignment of the file offset for the
start of the segment which results in the output of an invalid ELF.
SHT_PROGBITS was the default output section type in the past.
Differential Revision: https://reviews.llvm.org/D60131
llvm-svn: 358981
This patch changes the behaviour of findOrphanPos to only consider live
sections when placing orphan sections. This used to be how it behaved in
the past.
Differential Revision: https://reviews.llvm.org/D60273
llvm-svn: 358979
Make some small adjustment while touching the code: make parameters
const, use less_first(), etc.
Differential Revision: https://reviews.llvm.org/D60989
llvm-svn: 358943
Summary:
Fixes PR35242. A simplified reproduce:
thread_local int i; int f() { return i; }
% {g++,clang++} -fPIC -shared -ftls-model=local-dynamic -fuse-ld=lld a.cc
ld.lld: error: can't create dynamic relocation R_X86_64_DTPOFF32 against symbol: i in readonly segment; recompile object files with -fPIC or pass '-Wl,-z,notext' to allow text relocations in the output
In isStaticLinkTimeConstant(), Syn.IsPreemptible is true, so it is not
seen as a constant. The error is then issued in processRelocAux().
A symbol of the local-dynamic TLS model cannot be preempted but it can
preempt symbols of the global-dynamic TLS model in other DSOs.
So it makes some sense that the variable is not static.
This patch fixes the linking error by changing getRelExpr() on
R_386_TLS_LDO_32 and R_X86_64_DTPOFF{32,64} from R_ABS to R_DTPREL.
R_PPC64_DTPREL_* and R_MIPS_TLS_DTPREL_* need similar fixes, but they are not handled in this patch.
As a bonus, we use `if (Expr == R_ABS && !Config->Shared)` to find
ld-to-le opportunities. R_ABS is overloaded here for such STT_TLS symbols.
A dedicated R_DTPREL is clearer.
Differential Revision: https://reviews.llvm.org/D60945
llvm-svn: 358870
Summary:
This relocation type is used by R_386_TLS_GD. Its formula is the same as
R_GOTPLT (e.g R_X86_64_GOT{32,64} R_386_TLS_GOTIE). Rename it to be clearer.
Differential Revision: https://reviews.llvm.org/D60941
llvm-svn: 358868
This is https://bugs.llvm.org//show_bug.cgi?id=39857.
I added the comment with much more details to the bug page,
the short version is below.
The following script and code demonstrates the issue:
aliasto__text = __text;
SECTIONS {
.text 0x1000 : { __text = . ; *(.text) }
}
...
call aliasto__text
LLD fails with "cannot refer to absolute symbol: aliasto__text" error.
It happens because at the moment of scanning the relocations
we do not yet assign the correct/final/any section value for the symbol aliasto__text.
I made a change to Relocations.cpp to fix that.
Also, I had to remove the symbol-location.s test case completely, because now it does not
trigger any error. Since now all linker scripts symbols are resolved to constants, no
errors can be triggered at all it seems. I checked that it is consistent with the behavior
of bfd and gold (they do not trigger errors for the case from symbol-location.s), so it should
be OK. I.e. at least it is probably not the best possible, but natural behavior we obtained.
Differential revision: https://reviews.llvm.org/D55423
llvm-svn: 358652
Summary:
If the output section contains only symbol assignments, we copy flags
from the previous sections. Don't set SHF_ALLOC if NonAlloc is true.
We also have to change the type from SHT_NOBITS to SHT_PROGBITS.
In ld.bfd, bfd_elf_get_default_section_type maps non-alloctable sections to SHT_PROGBITS.
Non-alloctable SHT_NOBITS sections do not make sense.
Fixes PR38626
Differential Revision: https://reviews.llvm.org/D59986
llvm-svn: 358650
This generalizes code and also fixes the broken behavior shown in
one of our test cases for some targets, like x86-64.
The issue occurs when the forward declarations are used in the script.
One of the samples is:
SECTIONS {
foo = ADDR(.text) - ABSOLUTE(ADDR(.text));
};
In that case, we have a broken output when output target does
not use thunks. That happens because thunks creating code
(called from maybeAddThunks)
calls Script->assignAddresses() at least one more time,
what fixups the values. As a result final symbols values can
be different on AArch64 and x86, for example.
In this patch, I generalize and rename maybeAddThunks to
finalizeAddressDependentContent and now it is used and called
by all targets.
Differential revision: https://reviews.llvm.org/D55550
llvm-svn: 358646
Summary:
We access Live and OutputOff (which may share the same memory location)
concurrently in 2 parallelForEachN loops. Separating them avoids subtle
data races like D41884/PR35788. This patch places Live and Hash
together.
2 reasons this is appealing:
1) Hash is immutable. Live is almost read-only - only written once in MarkLive.cpp where
Hash is not accessed
2) we already discard low bits of Hash to decide ShardID. It doesn't
matter much if we make 32-bit Hash to 31-bit.
For a huge internal clang -O3 executable (1.6GiB),
`Strings` in StringTableBuilder::finalizeStringTable contains at most 310253 elements.
The expected number of pair-wise collisions 2^(-31) * C(310253,2) ~= 22.41 is too small to have a negative impact on performance.
Actually, my benchmark shows there is actually a minor performance improvement.
Differential Revision: https://reviews.llvm.org/D60765
llvm-svn: 358645
Patch by Gabriel Smith.
The address for a section would be evaluated before the region was
switched to. Because of this, the position within the region would not
be updated. After the region is swapped to the dot would be set to the
out of date position within the region, undoing the section address
evaluation.
To fix this, the region is swapped to before the section's address is
evaluated. As part of the fallout of this, expandMemoryRegions needed
to be gated in setDot on the condition that the evaluated address is
less than the dot. This is for the case where sections are not listed
from lowest address to highest address.
Finally, a test for the case where sections are listed "out of order"
was added.
Differential Revision: https://reviews.llvm.org/D60744
llvm-svn: 358638
With partitions, each partition should have the same build id. This means
that the build id needs to be only computed once, otherwise we will end up
with different build ids in each partition as a result of the file contents
changing. This change moves the computation of the build id into Writer so
that it only happens once.
Differential Revision: https://reviews.llvm.org/D60342
llvm-svn: 358536
The typo was introduced to llvm MC in rL204769 (fixed in rL358247) and then to lld.
Also, for relocatable-many-sections.s, the size of .symtab changed at some point and the formula needs update.
llvm-svn: 358248
Patch by Robert O'Callahan.
Rust projects tend to link in all object files from all dependent
libraries and rely on --gc-sections to strip unused code and data.
Unfortunately --gc-sections doesn't currently strip any debuginfo
associated with GC'ed sections, so lld links in the full debuginfo from
all dependencies even if almost all that code has been discarded. See
https://github.com/rust-lang/rust/issues/56068 for some details.
Properly stripping debuginfo for discarded sections would be difficult,
but a simple approach that helps significantly is to mark debuginfo
sections as live only if their associated object file has at least one
live code/data section. This patch does that. In a (contrived but not
totally artificial) Rust testcase linked above, it reduces the final
binary size from 46MB to 5.1MB.
Differential Revision: https://reviews.llvm.org/D54747
llvm-svn: 358069
The code previously specified a 32-bit range for R_RISCV_HI20 and
R_RISCV_LO12_[IS], however this is incorrect as the maximum offset on
RV64 that can be formed from the immediate of lui and the displacement
of an I-type or S-type instruction is -0x80000800 to 0x7ffff7ff. There
is also the same issue with a c.lui and LO12 pair, whose actual
addressable range should be -0x20800 to 0x1f7ff.
The tests will be included in the next patch that converts all RISC-V
tests to use llvm-mc instead of yaml2obj, as assembler support has
matured enough to write tests in them.
Differential Revision: https://reviews.llvm.org/D60414
llvm-svn: 357995
For partitions I intend to use the same set of version indexes in
each partition for simplicity. Since each partition will need its own
VersionNeedSection this will require moving the verneed tracking out of
VersionNeedSection. The way I've done this is to move most of the tracking
into SharedFile. What will eventually become the per-partition tracking
still lives in VersionNeedSection.
As a bonus the code gets a little simpler and more consistent with how we
handle verdef.
Differential Revision: https://reviews.llvm.org/D60307
llvm-svn: 357926
Previously, we drop symbols starting with .L from the symbol table, so
if there is a relocation that refers a .L symbol, it ended up
referencing a null -- which happened to be interpreted as an absolute
symbol.
This patch copies all symbols including local ones if -emit-reloc is
given.
Fixes https://bugs.llvm.org/show_bug.cgi?id=41385
Differential Revision: https://reviews.llvm.org/D60306
llvm-svn: 357885
And rename the function to combineEhSections(). This makes the processing
of .ARM.exidx even more similar to .eh_frame and means that we can avoid an
additional loop over InputSections.
Differential Revision: https://reviews.llvm.org/D60026
llvm-svn: 357417
Summary:
Some synthetic sections can be empty while still being needed, thus they
can't be removed by removeUnusedSyntheticSections(). Rename this member
function to more appropriate isNeeded() with the opposite meaning.
No functional change intended.
Reviewers: ruiu, espindola
Reviewed By: ruiu
Subscribers: jhenderson, grimar, emaste, arichardson, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D59982
llvm-svn: 357377
This change itself doesn't mean anything, but it helps D59780 because
in patch, we don't know whether we need to create a CET-aware PLT or
not until we read all input files.
llvm-svn: 357194
Recommit r356666 with fixes for buildbot failure, as well as handling for
--emit-relocs, which we decide not to emit any relocation sections as the
table is already position independent and an offline tool can deduce the
relocations.
Instead of creating extra Synthetic .ARM.exidx sections to account for
gaps in the table, create a single .ARM.exidx SyntheticSection that can
derive the contents of the gaps from a sorted list of the executable
InputSections. This has the benefit of moving the ARM specific code for
SyntheticSections in SHF_LINK_ORDER processing and the table merging code
into the ARM specific SyntheticSection. This also makes it easier to create
EXIDX_CANTUNWIND table entries for executable InputSections that don't
have an associated .ARM.exidx section.
Fixes pr40277
Differential Revision: https://reviews.llvm.org/D59216
llvm-svn: 357160
Patch by Tiancong Wang.
In D36351, Call-Chain Clustering (C3) heuristic is implemented with
option --call-graph-ordering-file <file>.
This patch adds a flag --print-symbol-order=<file> to LLD, and when
specified, it prints out the symbols ordered by the heuristics to the
file. The symbols printout is helpful to those who want to understand
the heuristics and want to reproduce the ordering with
--symbol-ordering-file in later pass.
Differential Revision: https://reviews.llvm.org/D59311
llvm-svn: 357133
Summary:
This should address remaining issues discussed in PR36555.
Currently R_GOT*_FROM_END are exclusively used by x86 and x86_64 to
express relocations types relative to the GOT base. We have
_GLOBAL_OFFSET_TABLE_ (GOT base) = start(.got.plt) but end(.got) !=
start(.got.plt)
This can have problems when _GLOBAL_OFFSET_TABLE_ is used as a symbol, e.g.
glibc dl_machine_dynamic assumes _GLOBAL_OFFSET_TABLE_ is start(.got.plt),
which is not true.
extern const ElfW(Addr) _GLOBAL_OFFSET_TABLE_[] attribute_hidden;
return _GLOBAL_OFFSET_TABLE_[0]; // R_X86_64_GOTPC32
In this patch, we
* Change all GOT*_FROM_END to GOTPLT* to fix the problem.
* Add HasGotPltOffRel to denote whether .got.plt should be kept even if
the section is empty.
* Simplify GotSection::empty and GotPltSection::empty by setting
HasGotOffRel and HasGotPltOffRel according to GlobalOffsetTable early.
The change of R_386_GOTPC makes X86::writePltHeader simpler as we don't
have to compute the offset start(.got.plt) - Ebx (it is constant 0).
We still diverge from ld.bfd (at least in most cases) and gold in that
.got.plt and .got are not adjacent, but the advantage doing that is
unclear.
Reviewers: ruiu, sivachandra, espindola
Subscribers: emaste, mehdi_amini, arichardson, dexonsmith, jdoerfert, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D59594
llvm-svn: 356968
lld's mark-sweep garbage collector was written in the visitor pattern.
There are functions that traverses a given graph, and the functions calls
callback functions to dispatch according to node type.
The code was originaly pretty simple, and lambdas worked pretty
well. However, as we add more features to the garbage collector, that became
more like a callback hell. We now have a callback function that wraps
another callback function, for example. It is not easy to follow the flow of
the control.
This patch rewrites it as a regular class. What was once a lambda is now a
regular class member function. I think this change fixes the readability
issue.
No functionality change intended.
Differential Revision: https://reviews.llvm.org/D59800
llvm-svn: 356966
Previously, `Entries` contains pairs of symbols and their indices.
The indices are always 0, x, 2x, 3x, ..., where x is the size of
relocation entry. We didn't have to store that values because we can
compute them when we consume them.
llvm-svn: 356812
There is a reproducible buildbot failure (segfault) on the 2 stage
clang-cmake-armv8-lld bot. Reverting while I investigate.
Differential Revision: https://reviews.llvm.org/D59216
llvm-svn: 356684
Instead of creating extra Synthetic .ARM.exidx sections to account for
gaps in the table, create a single .ARM.exidx SyntheticSection that can
derive the contents of the gaps from a sorted list of the executable
InputSections. This has the benefit of moving the ARM specific code for
SyntheticSections in SHF_LINK_ORDER processing and the table merging code
into the ARM specific SyntheticSection. This also makes it easier to create
EXIDX_CANTUNWIND table entries for executable InputSections that don't
have an associated .ARM.exidx section.
Fixes pr40277
Differential Revision: https://reviews.llvm.org/D59216
llvm-svn: 356666
Summary:
This implements Rui Ueyama's idea in PR39044.
I've checked that ld.bfd and gold do not have the power-of-2 requirement
and do not require sh_entsize to be a multiple of sh_align.
Now on the updated test merge-entsize.s, all the 3 linkers happily
create .rodata that is not 3-byte aligned.
This has a use case in Linux arch/x86/crypto/sha512-avx2-asm.S
It uses sh_entsize of 640, which is not a power of 2.
See https://github.com/ClangBuiltLinux/linux/issues/417
Reviewers: ruiu, espindola
Reviewed By: ruiu
Subscribers: nickdesaulniers, E5ten, emaste, arichardson, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D59478
llvm-svn: 356428
Summary:
Based on Peter Collingbourne's suggestion in D56828.
Before D56828: PT_LOAD(.data PT_GNU_RELRO(.data.rel.ro .bss.rel.ro) .bss)
Old: PT_LOAD(PT_GNU_RELRO(.data.rel.ro .bss.rel.ro) .data .bss)
New: PT_LOAD(PT_GNU_RELRO(.data.rel.ro .bss.rel.ro)) PT_LOAD(.data. .bss)
The new layout reflects the runtime memory mappings.
By having two PT_LOAD segments, we can utilize the NOBITS part of the
first PT_LOAD and save bytes for .bss.rel.ro.
.bss.rel.ro is currently small and only used by copy relocations of
symbols in read-only segments, but it can be used for other purposes in
the future, e.g. if a relro section's statically relocated data is all
zeros, we can move it to .bss.rel.ro.
Reviewers: espindola, ruiu, pcc
Reviewed By: ruiu
Subscribers: nemanjai, jvesely, nhaehnle, javed.absar, kbarton, emaste, arichardson, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D58892
llvm-svn: 356226
We allow an archive file without symbol table as a linker input as a
workaround for a very common error in LTO build. But that logic worked
even for an archive file containing non-bitcode files, which is not
expected. This patch limits that workaround to one that contains only
bitcode files.
Differential Revision: https://reviews.llvm.org/D59373
llvm-svn: 356186
Old: PT_LOAD(.data | PT_GNU_RELRO(.data.rel.ro .bss.rel.ro) | .bss)
New: PT_LOAD(PT_GNU_RELRO(.data.rel.ro .bss.rel.ro) | .data .bss)
The placement of | indicates page alignment caused by PT_GNU_RELRO. The
new layout has simpler rules and saves space for many cases.
Old size: roundup(.data) + roundup(.data.rel.ro)
New size: roundup(.data.rel.ro + .bss.rel.ro) + .data
Other advantages:
* At runtime the 3 memory mappings decrease to 2.
* start(PT_TLS) = start(PT_GNU_RELRO) = start(RW PT_LOAD). This
simplifies binary manipulation tools.
GNU strip before 2.31 discards PT_GNU_RELRO if its
address is not equal to the start of its associated PT_LOAD.
This has been fixed by https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=f2731e0c374e5323ce4cdae2bcc7b7fe22da1a6f
But with this change, we will be compatible with GNU strip before 2.31
* Before, .got.plt (non-relro by default) was placed before .got (relro
by default), which made it impossible to have _GLOBAL_OFFSET_TABLE_
(start of .got.plt on x86-64) equal to the end of .got (R_GOT*_FROM_END)
(https://bugs.llvm.org/show_bug.cgi?id=36555). With the new ordering, we
can improve on this regard if we'd like to.
Reviewers: ruiu, espindola, pcc
Subscribers: emaste, arichardson, llvm-commits, joerg, jdoerfert
Differential Revision: https://reviews.llvm.org/D56828
llvm-svn: 356117
Currently we have -Rpass for filtering the remarks that are displayed as
diagnostics, but when using -fsave-optimization-record, there is no way
to filter the remarks while generating them.
This adds support for filtering remarks by passes using a regex.
Ex: `clang -fsave-optimization-record -foptimization-record-passes=inline`
will only emit the remarks coming from the pass `inline`.
This adds:
* `-fsave-optimization-record` to the driver
* `-opt-record-passes` to cc1
* `-lto-pass-remarks-filter` to the LTOCodeGenerator
* `--opt-remarks-passes` to lld
* `-pass-remarks-filter` to llc, opt, llvm-lto, llvm-lto2
* `-opt-remarks-passes` to gold-plugin
Differential Revision: https://reviews.llvm.org/D59268
Original llvm-svn: 355964
llvm-svn: 355984
This does not appear to be necessary because StringTableSection does not
need to be finalized, which also means that we can remove the call to
finalizeSynthetic on .dynstr.
Differential Revision: https://reviews.llvm.org/D59240
llvm-svn: 355977
This shaves another word off SectionBase and makes it possible to clone a
section using the implicit copy constructor.
This basically reverts r311056, which removed the mutex in order to
make the code easier to understand. On balance I think it's probably more
straightforward to have a mutex here than to have an unusual copy constructor
in SectionBase.
Differential Revision: https://reviews.llvm.org/D59269
llvm-svn: 355966
Currently we have -Rpass for filtering the remarks that are displayed as
diagnostics, but when using -fsave-optimization-record, there is no way
to filter the remarks while generating them.
This adds support for filtering remarks by passes using a regex.
Ex: `clang -fsave-optimization-record -foptimization-record-passes=inline`
will only emit the remarks coming from the pass `inline`.
This adds:
* `-fsave-optimization-record` to the driver
* `-opt-record-passes` to cc1
* `-lto-pass-remarks-filter` to the LTOCodeGenerator
* `--opt-remarks-passes` to lld
* `-pass-remarks-filter` to llc, opt, llvm-lto, llvm-lto2
* `-opt-remarks-passes` to gold-plugin
Differential Revision: https://reviews.llvm.org/D59268
llvm-svn: 355964
We don't need to take a slice of SectionCommands in addOrphanSections()
because it is not modified until the end of the function.
Differential Revision: https://reviews.llvm.org/D59239
llvm-svn: 355954
This matches the ELF does. Update the comment in ELF/Symbols.h and
duplicate it in wasm/Symbols.h
This a followup on rL355580 and rL355577.
Differential Revision: https://reviews.llvm.org/D59075
llvm-svn: 355737
- The Assigned bit was previously taking a word on its own. Move
it into the bit fields in SectionBase.
- NumRelocations and AreRelocsRela were previously also taking up
a word despite only using half of it. Move them into the alignment gap
after SectionBase's fields.
Differential Revision: https://reviews.llvm.org/D59044
llvm-svn: 355622
We're going to need a separate VersionNeedSection for each partition, and
the partition data structure won't be templated.
With this the VersionTableSection class no longer needs ELFT, so detemplate it.
Differential Revision: https://reviews.llvm.org/D58808
llvm-svn: 355478
This lets us detect file size overflows when creating a 64-bit binary on
a 32-bit machine.
Differential Revision: https://reviews.llvm.org/D58840
llvm-svn: 355218
r355153 introduced a build failure on a build bot that uses clang natively
on an armv7-a machine. This a temporary fix to use size_t rather than
uint64_t.
llvm-svn: 355195
This lets us remove the special case from Writer::writeSections(), and also
fixes a bug where .eh_frame_hdr isn't necessarily written in the correct
order if a linker script moves .eh_frame and .eh_frame_hdr into the same
output section.
Differential Revision: https://reviews.llvm.org/D58795
llvm-svn: 355153
That patch is the fix for https://bugs.llvm.org/show_bug.cgi?id=40703
"wrong line number info for obj file compiled with -ffunction-sections"
bug. The problem happened with only .o files. If object file contains
several .text sections then line number information showed incorrectly.
The reason for this is that DwarfLineTable could not detect section which
corresponds to specified address(because address is the local to the
section). And as the result it could not select proper sequence in the
line table. The fix is to pass SectionIndex with the address. So that it
would be possible to differentiate addresses from various sections. With
this fix llvm-objdump shows correct line numbers for disassembled code.
Differential review: https://reviews.llvm.org/D58194
llvm-svn: 354972
This patch removes the precompiled binary from inputs,
replacing it with a YAML. And teaches LLD to report a
section name in case of such error.
Differential revision: https://reviews.llvm.org/D58670
llvm-svn: 354959
Summary:
The gold linker allowed you to output the ELF files after LTO was run. It did
it by using the 'obj-path' option. This replicates that behavior.
Reviewers: espindola, ruiu, MaskRay, pcc
Reviewed By: MaskRay, pcc
Subscribers: grimar, emaste, inglorion, arichardson, steven_wu, dexonsmith, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D56046
llvm-svn: 354917
The linux kernel uses an old flag -p/-no-pipeline-knowledge that is
accepted by bfd and gold but ignored by modern versions of them. The
original option is very old and is pre-ABI, it sometimes comes up in
code-bases that had support for pre ABI toolchains. The Linux kernel uses
it in 3 places in the ARM specific section.
Differential Revision: https://reviews.llvm.org/D58540
llvm-svn: 354769
RelocationBaseSection is not used in -r links, so Config->Relocatable will
always be false.
Differential Revision: https://reviews.llvm.org/D58489
llvm-svn: 354607
Three MIPS-specific sections `.reginfo`, `.MIPS.options`, and `.MIPS.abiflags`
are used by loader to read their contents and setup environment for running
a program. Loader looks up these data in the corresponding segments:
`PT_MIPS_REGINFO`, `PT_MIPS_OPTIONS`, and `PT_MIPS_ABIFLAGS` respectively.
This patch put these sections to separate segments like we do already
for ARM `SHT_ARM_EXIDX` section.
Differential Revision: http://reviews.llvm.org/D58381
llvm-svn: 354468
MIPS R6 code uses the `R_MIPS_PC26_S2` relocation for calls which might
cross boundaries of non-PIC-to-PIC code. We need to create a LA25 thunks
for that case.
llvm-svn: 354312
The patch solves two tasks:
1. MIPS ABI allows to mix regular and microMIPS code and perform
cross-mode jumps. Linker needs to detect such cases and replace
jump/branch instructions by their cross-mode equivalents.
2. Other tools like dunamic linkers need to recognize cases when dynamic
table entries, e_entry field of an ELF header etc point to microMIPS
symbol. Linker should provide such information.
The first task is implemented in the `MIPS<ELFT>::relocateOne()` method.
New routine `fixupCrossModeJump` detects ISA mode change, checks and
replaces an instruction.
The main problem is how to recognize that relocation target is microMIPS
symbol. For absolute and section symbols compiler or assembler set the
less-significant bit of the symbol's value or sum of the symbol's value
and addend. And this bit signals to linker about microMIPS code. For
global symbols compiler cannot do the same trick because other tools like,
for example, disassembler wants to know an actual position of the symbol.
So compiler sets STO_MIPS_MICROMIPS flag in the `st_other` field.
In `MIPS<ELFT>::relocateOne()` method we have a symbol's value only and
cannot access any symbol's attributes. To pass type of the symbol
(regular/microMIPS) to that routine as well as other places where we
write a symbol value as-is (.dynamic section, `Elf_Ehdr::e_entry` field
etc) we set when necessary a less-significant bit in the `getSymVA`
function.
Differential revision: https://reviews.llvm.org/D40147
llvm-svn: 354311
On PowerPC64, it is necessary to keep the LocalEntry bits in st_other,
especially when -r is used. Otherwise, when the resulting object is used
in a posterior linking, LocalEntry info will be unavailable and
functions may be called through the wrong entrypoint.
Patch by Leandro Lupori.
Differential Revision: https://reviews.llvm.org/D56782
llvm-svn: 354184
Summary:
So this patch just make sure that the thread is at least stated
before we return from main.
If we just detach then the thread may be actually be stated just after
the process returned from main and it's calling atexit handers. Then the thread may try to create own function static variable and it will
add new at exit handlers confusing libc.
GLIBC before 2.27 had race in that case which corrupted atexit handlers
list. Support for this use-case for other implementation is also unclear,
so we can try just avoid that.
PR40162
Reviewers: ruiu, espindola
Subscribers: emaste, arichardson, jfb, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D58246
llvm-svn: 354078
Previously, we showed the following message for an unknown relocation:
foo.o: unrecognized reloc 256
This patch improves it so that the error message includes a symbol name:
foo.o: unknown relocation (256) against symbol bar
llvm-svn: 354040
Non-GOT non-PLT relocations to non-preemptible ifuncs result in the
creation of a canonical PLT, which now takes the identity of the IFUNC
in the symbol table. This (a) ensures address consistency inside and
outside the module, and (b) fixes a bug where some of these relocations
end up pointing to the resolver.
Fixes (at least) PR40474 and PR40501.
Differential Revision: https://reviews.llvm.org/D57371
llvm-svn: 353981
This fixes a 7.0 -> 8.0 regression when parsing
OUTPUT_FORMAT("elf32-powerpc"); or elf32-bigmips directive in ldscripts
as well as an unknown emulation error when lld is invoked by clang due
to missed elf32ppclinux case.
Patch by vit9696
Differential Revision: https://reviews.llvm.org/D58005
llvm-svn: 353968
Previously, we validated -z options after we process --version or --help flags.
So, if one of these flags is given, we wouldn't show an "unknown -z option"
error. This patch fixes that behavior.
Differential Revision: https://reviews.llvm.org/D55446
llvm-svn: 353967
A follow up to the intial patch that unblocked linking against libgcc.
For lld we don't need to bother tracking which objects have got based small
code model relocations. This is due to the fact that the compilers on
powerpc64 use the .toc section to generate indirections to symbols (rather then
using got relocations) which keeps the got small. This makes overflowing a
small code model got relocation very unlikely.
Differential Revision: https://reviews.llvm.org/D57245
llvm-svn: 353849
gold accepts quoted strings. binutils requires quoted strings for some
kinds of symbols, e.g.:
it accepts quoted symbols with @ in name:
$ echo 'EXTERN("__libc_start_main@@GLIBC_2.2.5")' > a.script
$ g++ a.script
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/crt1.o: In function `_start':
(.text+0x20): undefined reference to `main'
collect2: error: ld returned 1 exit status
but rejects them if unquoted:
$ echo 'EXTERN(__libc_start_main@@GLIBC_2.2.5)' > a.script
$ g++ a.script
a.script: file not recognized: File format not recognized
collect2: error: ld returned 1 exit status
To maintain compatibility with existing linker scripts support quoted
strings in lld as well.
Patch by Lucian Adrian Grijincu.
Differential Revision: https://reviews.llvm.org/D57987
llvm-svn: 353756
R_X86_64_PC{8,16} relocations are sign-extended, so when we check
for relocation overflow, we had to use checkInt instead of checkUInt.
I confirmed that GNU linkers create the same output for the test case.
llvm-svn: 353437
This is the same as D57749, but for x64 target.
"ELF Handling For Thread-Local Storage" p41 says (https://www.akkadia.org/drepper/tls.pdf):
R_X86_64_GOTTPOFF relocation is used for IE TLS models.
Hence if linker sees this relocation we should add DF_STATIC_TLS flag.
Differential revision: https://reviews.llvm.org/D57821
llvm-svn: 353378
With the following changes:
1) Compilation fix:
std::atomic<bool> HasStaticTlsModel = false; ->
std::atomic<bool> HasStaticTlsModel{false};
2) Adjusted the comment in code.
Initial commit message:
DF_STATIC_TLS flag indicates that the shared object or executable
contains code using a static thread-local storage scheme.
Patch checks if IE/LE relocations were used to check if the code uses
a static model. If so it sets the DF_STATIC_TLS flag.
Differential revision: https://reviews.llvm.org/D57749
----
Modified : /lld/trunk/ELF/Arch/X86.cpp
Modified : /lld/trunk/ELF/Config.h
Modified : /lld/trunk/ELF/SyntheticSections.cpp
Added : /lld/trunk/test/ELF/Inputs/i386-static-tls-model1.s
Added : /lld/trunk/test/ELF/Inputs/i386-static-tls-model2.s
Added : /lld/trunk/test/ELF/Inputs/i386-static-tls-model3.s
Added : /lld/trunk/test/ELF/Inputs/i386-static-tls-model4.s
Added : /lld/trunk/test/ELF/i386-static-tls-model.s
Modified : /lld/trunk/test/ELF/i386-tls-ie-shared.s
Modified : /lld/trunk/test/ELF/tls-dynamic-i686.s
Modified : /lld/trunk/test/ELF/tls-opt-iele-i686-nopic.s
llvm-svn: 353299
DF_STATIC_TLS flag indicates that the shared object or executable
contains code using a static thread-local storage scheme.
Patch checks if IE/LE relocations were used to check if the code uses
a static model. If so it sets the DF_STATIC_TLS flag.
Differential revision: https://reviews.llvm.org/D57749
llvm-svn: 353293
Summary:
R_PPC64_TLSGD and R_PPC64_TLSLD are used as markers on TLS code sequences. After GD-to-IE or GD-to-LE relaxation, the next relocation R_PPC64_REL24 should be skipped to not create a false dependency on __tls_get_addr. When linking statically, the false dependency may cause an "undefined symbol: __tls_get_addr" error.
R_PPC64_GOT_TLSGD16_HA
R_PPC64_GOT_TLSGD16_LO
R_PPC64_TLSGD R_TLSDESC_CALL
R_PPC64_REL24 __tls_get_addr
Reviewers: ruiu, sfertile, syzaara, espindola
Reviewed By: sfertile
Subscribers: emaste, nemanjai, arichardson, kbarton, jsji, llvm-commits, tamur
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D57673
llvm-svn: 353262
Summary:
This follows the ld.bfd/gold behavior.
The error check is useful as it captures a common type of ld.so undefined symbol errors as link-time errors:
// a.cc => a.so (not linked with -z defs)
void f(); // f is undefined
void g() { f(); }
// b.cc => executable with a DT_NEEDED entry on a.so
void g();
int main() { g(); }
// ld.so errors when g() is executed (lazy binding) or when the program is started (-z now)
// symbol lookup error: ... undefined symbol: f
Reviewers: ruiu, grimar, pcc, espindola
Reviewed By: ruiu
Subscribers: llvm-commits, emaste, arichardson
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D57569
llvm-svn: 352943
Summary:
In ld.bfd/gold, --no-allow-shlib-undefined is the default when linking
an executable. This patch implements a check to error on undefined
symbols in a shared object, if all of its DT_NEEDED entries are seen.
Our approach resembles the one used in gold, achieves a good balance to
be useful but not too smart (ld.bfd traces all DSOs and emulates the
behavior of a dynamic linker to catch more cases).
The error is issued based on the symbol table, different from undefined
reference errors issued for relocations. It is most effective when there
are DSOs that were not linked with -z defs (e.g. when static sanitizers
runtime is used).
gold has a comment that some system libraries on GNU/Linux may have
spurious undefined references and thus system libraries should be
excluded (https://sourceware.org/bugzilla/show_bug.cgi?id=6811). The
story may have changed now but we make --allow-shlib-undefined the
default for now. Its interaction with -shared can be discussed in the
future.
Reviewers: ruiu, grimar, pcc, espindola
Reviewed By: ruiu
Subscribers: joerg, emaste, arichardson, llvm-commits
Differential Revision: https://reviews.llvm.org/D57385
llvm-svn: 352826
Previously we were never setting this which means it was always being
set to Default (-O2/-Os).
Differential Revision: https://reviews.llvm.org/D57422
llvm-svn: 352667
Summary:
After rLLD344952 ("Add OUTPUT_FORMAT linker script directive support"),
using BFD names such as `elf64-x86-64-freebsd` the `OUTPUT_FORMAT`
linker script command does not work anymore, resulting in errors like:
```
ld: error: /home/dim/src/clang800-import/stand/efi/loader/arch/amd64/ldscript.amd64:2: unknown output format name: elf64-x86-64-freebsd
>>> OUTPUT_FORMAT("elf64-x86-64-freebsd", "elf64-x86-64-freebsd", "elf64-x86-64-freebsd")
>>> ^
```
To fix this, recognize a `-freebsd` suffix in BFD names, and also set
`Configuration::OSABI` to `ELFOSABI_FREEBSD` for those cases.
Add and/or update several test cases to check for the correct results of
these new `OUTPUT_FORMAT` arguments.
Reviewers: ruiu, atanasyan, grimar, hokein, emaste, espindola
Reviewed By: ruiu
Subscribers: nemanjai, javed.absar, arichardson, krytarowski, kristof.beyls, kbarton, llvm-commits
Differential Revision: https://reviews.llvm.org/D57283
llvm-svn: 352606
Previously we were setting it to the GotPlt output section, which is
incorrect on ARM where this section is in .got. In static binaries
this can lead to sh_info being set to -1 (because there is no .got.plt)
which results in various tools rejecting the output file.
Differential Revision: https://reviews.llvm.org/D57274
llvm-svn: 352413
Summary:
lld discards .gnu.linonce.* sections work around a bug in glibc.
https://sourceware.org/bugzilla/show_bug.cgi?id=20543
Unfortunately, the Linux kernel uses a section named
.gnu.linkonce.this_module to store infomation about kernel modules. The
kernel reads data from this section when loading kernel modules, and
errors if it fails to find this section. The current behavior of lld
discards this section when kernel modules are linked, so kernel modules
linked with lld are unloadable by the linux kernel.
The Linux kernel should use a comdat section instead of .gnu.linkonce.
The minimum version of binutils supported by the kernel supports comdat
sections. The kernel is also not relying on the old linkonce behavior;
it seems to have chosen a name that contains a deprecated GNU feature.
Changing the section name now in the kernel would require all kernel
modules to be recompiled to make use of the new section name. Instead,
rather than discarding .gnu.linkonce.*, let's discard the more specific
section name to continue working around the glibc issue while supporting
linking Linux kernel modules.
Link: https://github.com/ClangBuiltLinux/linux/issues/329
Reviewers: pcc, espindola
Reviewed By: pcc
Subscribers: nathanchance, emaste, arichardson, void, srhines
Differential Revision: https://reviews.llvm.org/D57294
llvm-svn: 352302
Guessing that the slashes used in the scripts SECTION command was causing the
windows related failures in the added test.
Original commit message:
Small code model global variable access on PPC64 has a very limited range of
addressing. The instructions the relocations are used on add an offset in the
range [-0x8000, 0x7FFC] to the toc pointer which points to .got +0x8000, giving
an addressable range of [.got, .got + 0xFFFC]. While user code can be recompiled
with medium and large code models when the binary grows too large for small code
model, there are small code model relocations in the crt files and libgcc.a
which are typically shipped with the distros, and the ABI dictates that linkers
must allow linking of relocatable object files using different code models.
To minimze the chance of relocation overflow, any file that contains a small
code model relocation should have its .toc section placed closer to the .got
then any .toc from a file without small code model relocations.
Differential Revision: https://reviews.llvm.org/D56920
llvm-svn: 352071
This does *not* implement full SHT_GROUP semantic, yet it is a simple step forward:
Sections within a group are still considered valid, but they do not behave as
specified by the standard in case of garbage collection.
Differential Revision: https://reviews.llvm.org/D56437
llvm-svn: 352068
Small code model global variable access on PPC64 has a very limited range of
addressing. The instructions the relocations are used on add an offset in the
range [-0x8000, 0x7FFC] to the toc pointer which points to .got +0x8000, giving
an addressable range of [.got, .got + 0xFFFC]. While user code can be recompiled
with medium and large code models when the binary grows too large for small code
model, there are small code model relocations in the crt files and libgcc.a
which are typically shipped with the distros, and the ABI dictates that linkers
must allow linking of relocatable object files using different code models.
To minimze the chance of relocation overflow, any file that contains a small
code model relocation should have its .toc section placed closer to the .got
then any .toc from a file without small code model relocations.
Differential Revision: https://reviews.llvm.org/D56920
llvm-svn: 351978
LLD's performance on PGO instrumented Windows binaries was still not
great even with the fix in D56955; out of the 2m41s linker runtime,
around 2 minutes were still being spent in ICF. I looked into this more
closely and discovered that the vast majority of the runtime was being
spent segregating .pdata sections with the following relocation chain:
.pdata -> identical .text -> unique PGO counter (not eligible for ICF)
This patch causes us to perform 2 rounds of relocation hash
propagation, which allows the hash for the .pdata sections to
incorporate the identifier from the PGO counter. With that, the amount
of time spent in ICF was reduced to about 2 seconds. I also found that
the same change led to a significant ICF performance improvement in a
regular release build of Chromium's chrome_child.dll, where ICF time
was reduced from around 1s to around 700ms.
With the same change applied to the ELF linker, median of 100 runs
for lld-speed-test/chrome reduced from 4.53s to 4.45s on my machine.
I also experimented with increasing the number of propagation rounds
further, but I did not observe any further significant performance
improvements linking Chromium or Firefox.
Differential Revision: https://reviews.llvm.org/D56986
llvm-svn: 351899
It turns out that sections in PGO instrumented object files on Windows
contain a large number of relocations pointing to themselves. With
r347429 this can cause many sections to receive the same hash (usually
zero) as a result of a section's hash being xor'ed with itself.
This patch causes the COFF and ELF linkers to avoid this problem
by adding the hash of the relocated section instead of xor'ing it.
On my machine this causes the regressing test case
provided by Mozilla to terminate in 2m41s.
Differential Revision: https://reviews.llvm.org/D56955
llvm-svn: 351898
to reflect the new license.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
llvm-svn: 351636
As a follow on to D56666 (r351186) there is a case when taking the address
of an ifunc when linking -pie that can generate a spurious can't create
dynamic relocation R_AARCH64_ADR_PREL_PG_HI21 against symbol in readonly
segment. Specifically the case is where the ifunc is in the same
translation unit as the address taker, so given -fpie the compiler knows
the ifunc is defined in the executable so it can use a non-got-generating
relocation.
The error message is due to R_AARCH64_PLT_PAGE_PC not being added to
isRelExpr, its non PLT equivalent R_AARCH64_PAGE_PC is already in
isRelExpr.
Differential Revision: https://reviews.llvm.org/D56724
llvm-svn: 351335
By default LLD will generate position independent Thunks when the --pie or
--shared option is used. Reference to absolute addresses is permitted in
other cases. For some embedded systems position independent thunks are
needed for code that executes before the MMU has been set up. The option
--pic-veneer is used by ld.bfd to force position independent thunks.
The patch adds --pic-veneer as the option is needed for the Linux kernel
on Arm.
fixes pr39886
Differential Revision: https://reviews.llvm.org/D55505
llvm-svn: 351326
If .rela.iplt does not exist, we used to emit a corrupt symbol table
that contains two symbols, .rela_iplt_{start,end}, pointing to a
nonexisting section.
This patch fixes the issue by setting section index 0 to the symbols
if .rel.iplt section does not exist.
Differential Revision: https://reviews.llvm.org/D56623
llvm-svn: 351218
r347650 fixed pr38074 for AArch64 for static linking. It added two new
RelExpr instances R_AARCH64_GOT_PAGE_PC_PLT and R_GOT_PLT. These need to be
added to isStaticLinkTimeConstant so that the address of an ifunc can be
taken when building a shared library.
fixes pr40250
Differential Revision: https://reviews.llvm.org/D56666
llvm-svn: 351186
When the range between the source and target of a V7PILongThunk exceeded an
int32 we would trigger a relocation out of range error for the
R_ARM_MOVT_PREL or R_ARM_THM_MOVT_PREL relocation. This case can happen when
linking the linux kernel as it is loaded above 0xf0000000.
There are two parts to the fix.
- Remove the overflow check for R_ARM_MOVT_PREL or R_ARM_THM_MOVT_PREL. The
ELF for the ARM Architecture document defines these relocations as having no
overflow checking so the check was spurious.
- Use int64_t for the offset calculation, in line with similar thunks so
that PC + (S - P) < 32-bits. This results in less surprising disassembly.
Differential Revision: https://reviews.llvm.org/D56396
llvm-svn: 350836
The section and offset can be very helpful in diagnosing certian errors.
For example on a relocation overflow or misalignment diagnostic:
test.c:(function foo): relocation R_PPC64_ADDR16_DS out of range: ...
The function foo can have many R_PPC64_ADDR16_DS relocations. Adding the offset
and section will identify exactly which relocation is causing the failure.
Differential Revision: https://reviews.llvm.org/D56453
llvm-svn: 350828
In the PPC64 target we map toc-relative relocations, dynamic thread pointer
relative relocations, and got relocations into a corresponding ADDR16 relocation
type for handling in relocateOne. This patch saves the orignal RelType before
mapping to an ADDR16 relocation so that any diagnostic messages will not
mistakenly use the mapped type.
Differential Revision: https://reviews.llvm.org/D56448
llvm-svn: 350827
Patch by Michael Skvortsov!
This change adds a basic support for linking static MSP430 ELF code.
Implemented relocation types are intended to correspond to the BFD.
Differential revision: https://reviews.llvm.org/D56535
llvm-svn: 350819
ARM and AArch64 use TLS variant 1, where the first two words after the
thread pointer are reserved for the TCB, followed by the executable's TLS
segment. Both the thread pointer and the TLS segment are aligned to at
least the TLS segment's alignment.
Android/Bionic historically has not supported ELF TLS, and it has
allocated memory after the thread pointer for several Bionic TLS slots
(currently 9 but soon only 8). At least one of these allocations
(TLS_SLOT_STACK_GUARD == 5) is widespread throughout Android/AArch64
binaries and can't be changed.
To reconcile this disagreement about TLS memory layout, set the minimum
alignment for executable TLS segments to 8 words on ARM/AArch64, which
reserves at least 8 words of memory after the TP (2 for the ABI-specified
TCB and 6 for alignment padding). For simplicity, and because lld doesn't
know when it's targeting Android, increase the alignment regardless of
operating system.
Differential Revision: https://reviews.llvm.org/D53906
llvm-svn: 350681
Fixes https://bugs.llvm.org/show_bug.cgi?id=40134
addWrappedSymbols() must be called before addReservedSymbols() because the
latter only defines reserved symbols when they are undefined in the symbol
table. If addWrappedSymbols() is called after, then addUndefined() is called
which may lazily pull in more object files that could reference reserved
symbols.
Differential Revision: https://reviews.llvm.org/D56110
llvm-svn: 350251
Summary:
If a DSO appears more than once with and without --as-needed, ld.bfd and gold consider --no-as-needed to takes precedence over --as-needed. lld didn't and this patch makes it do so.
This makes it a bit away from the position-dependent behavior (how
different occurrences of the same DSO interact) and protects us from
some mysterious runtime errors: if some interceptor libraries add their
own --no-as-needed dependencies (e.g. librt.so), and the user
application specifies -Wl,--as-needed -lrt , the absence of the
DT_NEEDED entry would make dlsym(RTLD_NEXT, "clock_gettime") return NULL
and would break at runtime.
Reviewers: ruiu, espindola
Reviewed By: ruiu
Subscribers: emaste, arichardson, llvm-commits
Differential Revision: https://reviews.llvm.org/D56089
llvm-svn: 350105
When parsing CU ranges for gdb-index, handle the error (now propagated
up though the API lld is calling here - previously the error was
printed within the libDebugInfo API, not allowing lld to format or
handle the message at all) - including information about the object and
archive name, as well as failing the link.
llvm-svn: 349979
Summary:
For the 2-bit bloom filter, we currently pick the bits Hash%64 and Hash>>6%64 (Shift2=6), but bits [6:...] are also used to select a word, causing a loss of precision.
In this patch, we choose Shift2=26, with is suggested by Ambrose Feinstein.
Note, Shift2 is computed as maskbitslog2 in bfd/elflink.c and gold/dynobj.cc
It is varying with the number of dynamic symbols but we don't
necessarily copy its rule.
Reviewers: ruiu, espindola
Reviewed By: ruiu
Subscribers: emaste, arichardson, llvm-commits
Differential Revision: https://reviews.llvm.org/D55971
llvm-svn: 349966
Summary:
This is a common error, and because many people don't know what the key
function is, it is sometimes very confusing.
The doc was originally written by Brooks Moses and slightly edited by me.
Reviewers: MaskRay, espindola
Subscribers: emaste, llvm-commits, arichardson
Differential Revision: https://reviews.llvm.org/D55968
llvm-svn: 349941
Summary:
In glibc, libc.so is a linker script with an as-needed dependency on ld-linux-x86-64.so.2
GROUP ( /lib/x86_64-linux-gnu/libc.so.6 /usr/lib/x86_64-linux-gnu/libc_nonshared.a AS_NEEDED ( /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 ) )
ld-linux-x86-64.so.2 (as-needed) defines some symbols which resolve undefined references in libc.so.6, it will therefore be added as a DT_NEEDED entry, which isn't necessary.
The test case as-needed-not-in-regular.s emulates the libc.so scenario, where ld.bfd and gold don't add DT_NEEDED for a.so
The relevant code in gold/resolve.cc:
// If we have a non-WEAK reference from a regular object to a
// dynamic object, mark the dynamic object as needed.
if (to->is_from_dynobj() && to->in_reg() && !to->is_undef_binding_weak())
to->object()->set_is_needed();
in_reg() appears to do something similar to IsUsedInRegularObj.
This patch makes lld do the similar thing, but moves the check from
addShared to a later stage MarkLive where all symbols are scanned.
Reviewers: ruiu, pcc, espindola
Reviewed By: ruiu
Subscribers: emaste, arichardson, llvm-commits
Differential Revision: https://reviews.llvm.org/D55902
llvm-svn: 349849
When we report an error for symbols defined in the linker script,
we do not report the location properly.
For example:
ld.lld: error: relocation R_AARCH64_CALL26 cannot refer to absolute symbol: aliasto__text
>>> defined in <internal>
>>> referenced by rtoabs.o:(.text+0x4)
This patch fixes that.
Differential revision: https://reviews.llvm.org/D55360
llvm-svn: 349612
Previously, this code printed out an error message like this
ld.lld: error: --reproduce: failed to open /foo: cannot open /foo
Apparently "failed to open /foo:" part is redundant.
llvm-svn: 349571
Previously, if you pass -static to lld, lld searches for only foo.a
and skips foo.so for -lfoo option. However, it didn't reject .so files
if you directly pass their pathnames via the command line, which is a bug.
Differential Revision: https://reviews.llvm.org/D55845
llvm-svn: 349557
Summary:
Other large sections (e.g. .rela.dyn .dynstr) may push .note.* off the
first page. They won't be available in core files if RLIMIT_CORE is
limited.
This patch gives priority to alloctable SHT_NOTE sections so that they
are assuredly in the first page and will be available in core files.
They are small and contain important information (e.g. .note.gnu.build-id
identifies the origin of the core, .note.tag stores NT_FREEBSD_ABI_TAG).
Note: gold Output_section_order has a similar rule:
// Loadable read-only note sections come next so that the PT_NOTE
// segment is on the first page of the executable.
ORDER_RO_NOTE,
Reviewers: ruiu, pcc, espindola
Subscribers: emaste, arichardson, llvm-commits
Differential Revision: https://reviews.llvm.org/D55800
llvm-svn: 349524
The code here wants the output section offset of the instruction
requiring the errata patch, not the virtual address. Without this
change we can end up placing a patch out of range if the virtual
address of the code section is large enough.
Differential Revision: https://reviews.llvm.org/D55732
llvm-svn: 349386
ARM Architecture v6m is used by the smallest microcontrollers such as the
cortex-m0. It is Thumb only (no Thumb 2) which prevents it from using the
existing Thumb 2 range extension thunks as these use the Thumb 2 movt/movw
instructions. Range extension thunks are not usually needed for
microcontrollers due to the small amount of flash and ram on the device,
however if code is copied from flash into ram then a range extension thunk
is required to call that code.
This change adds support for v6m range extension thunks. The procedure call
standard APCS permits a thunk to corrupt the intra-procedural scratch
register r12 (referred to as ip in the APCS). Most Thumb instructions do
not permit access to high registers (r8 - r15) so the thunks must spill
some low registers (r0 - r7) to perform the control transfer.
Fixes pr39922
Differential Revision: https://reviews.llvm.org/D55555
llvm-svn: 349337
Previously we considered R_ARM_V4BX to be an absolute relocation,
which meant that we rejected it in read-only sections in PIC output
files. Instead, treat it as a hint relocation so that relocation
processing ignores it entirely.
Also fix a problem with the test case where it was never being run
because it has a .yaml extension and we don't run tests with that
extension.
Differential Revision: https://reviews.llvm.org/D55728
llvm-svn: 349216
`--plugin-opt=emit-llvm` is an option for LTO. It makes the linker to
combine all bitcode files and write the result to an output file without
doing codegen. Gold LTO plugin has this option.
This option is being used for some post-link code analysis tools that
have to see a whole program but don't need to see them in the native
machine code.
Differential Revision: https://reviews.llvm.org/D55717
llvm-svn: 349198
In the ABI for the 64-bit Arm architecture the section on weak references
states:
During linking, the symbol value of an undefined weak reference is:
- Zero if the relocation type is absolute
- The address of the place if the relocation type is pc-relative.
The relocations associated with an ADRP are relative so we should resolve
the undefined weak reference to the place instead of 0. This matches GNU
ld.bfd behaviour.
fixes pr34928
Differential Revision: https://reviews.llvm.org/D55599
llvm-svn: 349024
This was a missing piece.
We started to print LMAs and information about assignments,
but did not do that for assignments outside of section declarations yet.
The patch implements it.
Differential revision: https://reviews.llvm.org/D45314
llvm-svn: 348468
This is a part of
https://bugs.llvm.org/show_bug.cgi?id=39885
Linker script specification says:
"You can specify a file name to include sections from a particular file. You would
do this if one or more of your files contain special data that needs to be at a
particular location in memory."
LLD did not accept this syntax. The patch implements it.
Differential revision: https://reviews.llvm.org/D55324
llvm-svn: 348463
Previously, we have a hash table containing strings and their offsets
to manage mergeable strings. Technically we can live without that, because
we can do binary search on a vector of mergeable strings to find a mergeable
strings.
We did have both the hash table and the binary search because we thought
that that is faster.
We recently observed that lld tend to consume more memory than gold when
building an output with debug info. A few percent of memory is consumed by
the hash table. So, we needed to reevaluate whether or not having the extra
hash table is a good CPU/memory tradeoff. I run a few benchmarks with and
without the hash table.
I got a mixed result for the benchmark. We observed a regression for some
programs by removing the hash table (that's what we expected), but we also
observed that performance imrpovements for some programs. This is perhaps
due to reduced memory usage.
Differential Revision: https://reviews.llvm.org/D55234
llvm-svn: 348401
Patch from Andrew Kelley.
For context, see https://bugs.llvm.org/show_bug.cgi?id=39862
The use case is embedded / OS programming where the kernel wants
access to its own debug info via mapped dwarf info. I have a proof of
concept of this working, using this linker script snippet:
.rodata : ALIGN(4K) {
*(.rodata)
__debug_info_start = .;
KEEP(*(.debug_info))
__debug_info_end = .;
__debug_abbrev_start = .;
KEEP(*(.debug_abbrev))
__debug_abbrev_end = .;
__debug_str_start = .;
KEEP(*(.debug_str))
__debug_str_end = .;
__debug_line_start = .;
KEEP(*(.debug_line))
__debug_line_end =
.;
__debug_ranges_start
= .;
KEEP(*(.debug_ranges))
__debug_ranges_end
= .;
}
Differential revision: https://reviews.llvm.org/D55276
llvm-svn: 348291
When linking the linux kernel on ppc64le
ld.lld -EL -m elf64lppc -Bstatic --orphan-handling=warn --build-id -o
.tmp_vmlinux1 -T ./arch/powerpc/kernel/vmlinux.lds --whole-archive
built-in.a --no-whole-archive --start-group lib/lib.a --end-group
ld.lld: error: discarding .rela.plt section is not allowed
The linker script discards with the following matches
*(.glink .iplt .plt .rela* .comment)
Differential Revision: https://reviews.llvm.org/D54871
llvm-svn: 348258
When linking the linux kernel on ppc64 and ppc
ld.lld: error: unrecognized reloc 11
11 is PPC_REL14 and PPC64_REL14
Differential revision: https://reviews.llvm.org/D54868
llvm-svn: 348255
At least on Linux, if a file size given to FileOutputBuffer is greater
than 2^63, it fails with "Invalid argument" error, which is not a
user-friendly error message. With this patch, lld prints out "output
file too large" instead.
llvm-svn: 348153
There is no need to check that In.DynSymTab != nullptr,
because `includeInDynsym` already checks for `!Config->HasDynSymTab`
and `HasDynSymTab` is the pre-condition for In.DynSymTab creation.
llvm-svn: 348143
Now LLD might build the broken/incomplete .gdb_index when some DWARF v5
sections (like .debug_rnglists and .debug_addr) are used.
Particularly, for the case above, we emit an empty address area.
A test case is provided and patch fixes the issue.
Differential revision: https://reviews.llvm.org/D55109
llvm-svn: 348119
Nico Weber