For undef-not-suggest.test, we currently make redundant alternative
spelling suggestions:
```
ld.lld: error: relocation refers to a discarded section: .text.foo
>>> defined in a.o
>>> section group signature: foo
>>> prevailing definition is in a.o
>>> referenced by a.o:(.rodata+0x0)
>>> did you mean:
>>> defined in: a.o
ld.lld: error: relocation refers to a symbol in a discarded section: foo
>>> defined in a.o
>>> section group signature: foo
>>> prevailing definition is in a.o
>>> referenced by a.o:(.rodata+0x8)
>>> did you mean: for
>>> defined in: a.o
```
Reviewed By: grimar, ruiu
Differential Revision: https://reviews.llvm.org/D71735
Summary:
If none of the input files are ELF object files (for example, when
generating an object file from a single binary input file via
"-b binary"), use a fallback value for the ELF header flags instead
of crashing with an assertion failure.
Reviewers: MaskRay, ruiu, espindola
Reviewed By: MaskRay, ruiu
Subscribers: kevans, grimar, emaste, arichardson, asb, rbar, johnrusso, simoncook, sabuasal, niosHD, kito-cheng, shiva0217, zzheng, edward-jones, rogfer01, MartinMosbeck, brucehoult, the_o, rkruppe, PkmX, jocewei, psnobl, benna, Jim, lenary, s.egerton, pzheng, sameer.abuasal, apazos, luismarques, llvm-commits, jrtc27
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71101
Previously this caused crashes in the reportDuplicate method.
A DefinedAbsolute doesn't have any InputFile attached to it, so we
can't report the file for the original symbol.
We could add an InputFile argument to SymbolTable::addAbsolute
only for the sake of error reporting, but even then it'd be assymetrical,
only pointing out the file containing the new conflicting definition,
not the original one.
Differential Revision: https://reviews.llvm.org/D71679
GNU ld creates the synthetic section .iplt, and has a built-in linker
script that assigns .iplt to the output section .plt . There is no
output section named .iplt .
Making .iplt an output section actually has a benefit that makes the
tricky toolchain feature stand out. Symbolizers don't have to deal with
mixed PLT entries (e.g. llvm-objdump -d incorrectly annotates such jump
targets).
On EM_PPC{,64}, .glink contains a PLT resolver and a series of jump
instructions. The 4-byte entry size makes it unnecessary to have an
alignment of 16.
Mark ppc32-gnu-ifunc.s and ppc32-gnu-ifunc-nonpreemptable.s as `XFAIL: *`.
They test IPLT on EM_PPC, which never works.
Reviewed By: peter.smith
Differential Revision: https://reviews.llvm.org/D71520
PltSection is used by both PLT and IPLT. The PLT section may have a
header while the IPLT section does not. Split off IpltSection from
PltSection to be clearer.
Unlike other targets, PPC64 cannot use the same code sequence for PLT
and IPLT. This helps make a future PPC64 patch (D71509) more isolated.
On EM_386 and EM_X86_64, when PLT is empty while IPLT is not, currently
we are inconsistent whether the PLT header is conceptually attached to
in.plt or in.iplt . Consistently attach the header to in.plt can make
the -z retpolineplt logic simpler. It also makes `jmp` point to an
aesthetically better place for non-retpolineplt cases.
Reviewed By: grimar, ruiu
Differential Revision: https://reviews.llvm.org/D71519
This fixes an invalid constant used to detect the reserved range when
reading the compilation unit header. See also: D64622 and D65039.
Differential Revision: https://reviews.llvm.org/D71546
This change only affects EM_386. relOff can be computed from `index`
easily, so it is unnecessarily passed as a parameter.
Both in.plt and in.iplt entries are written by writePLT. For in.iplt,
the instruction `push reloc_offset` will change because `index` is now
different. Fortunately, this does not matter because `push; jmp` is only
used by PLT. IPLT does not need the code sequence.
Reviewed By: grimar, ruiu
Differential Revision: https://reviews.llvm.org/D71518
This reverts commit 2bbd32f5e8, it was
causing UBSan failures like the following:
lld/ELF/Target.cpp:103:41: runtime error: applying non-zero offset 24 to null pointer
When a common symbol is merged with a shared symbol, increase st_size if
the shared symbol has a larger st_size. At runtime, the executable's
symbol overrides the shared symbol. The shared symbol may be created
from common symbols in a previous link. This rule makes sure we pick
the largest size among all common symbols.
This behavior matches GNU ld. See
https://sourceware.org/bugzilla/show_bug.cgi?id=25236 for discussions.
A shared symbol does not hold alignment constraints. Ignore the
alignment update.
Reviewed By: peter.smith
Differential Revision: https://reviews.llvm.org/D71161
Summary:
So far it seems like the only test affected by this change is the one I
recently added for R_MIPS_JALR relocations since the other test cases that
use this function early (unknown-relocation-*) do not have a valid input
section for the relocation offset.
Reviewers: ruiu, grimar, MaskRay, espindola
Reviewed By: ruiu, MaskRay
Subscribers: emaste, sdardis, jrtc27, atanasyan, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D70659
This is equivalent to the existing `import_name` and `import_module`
attributes which control the import names in the final wasm binary
produced by lld.
This maps the existing
This attribute currently requires a string rather than using the
symbol name for a couple of reasons:
1. Avoid confusion with static and dynamic linking which is
based on symbol name. Exporting a function from a wasm module using
this directive is orthogonal to both static and dynamic linking.
2. Avoids name mangling.
Differential Revision: https://reviews.llvm.org/D70520
On some edge cases such as Chromium compiled with full instrumentation we
have a .text section over twice the size of the maximum branch range and
the instrumented code generation containing many examples of the erratum
sequence. The combination of Thunks and many erratum sequences causes
finalizeAddressDependentContent() to not converge. We end up with:
start
- Thunk Creation (disturbs addresses after thunks, creating more patches)
- Patch Creation (disturbs addresses after patches, creating more thunks)
- goto start
In most images with few thunks and patches the mutual disturbance does not
cause convergence problems. As the .text size and number of patches go up
the risk increases.
A way to prevent the thunk creation from interfering with patch creation is
to round up the size of the thunks to a 4KiB boundary when the
erratum patch is enabled. As the erratum sequence only triggers when an
instruction sequence starts at 0xff8 or 0xffc modulo (4 KiB) by making the
thunks not affect addresses modulo (4 KiB) we prevent thunks from
interfering with the patch.
The patches themselves could be aggregated in the same way that Thunks are
within ThunkSections and we could round up the size in the same way. This
would reduce the number of patches created in a .text section size >
128 MiB but would not likely help convergence problems.
Differential Revision: https://reviews.llvm.org/D71281
fixes (remaining part of) pr44071, other part in D71242
The code to insert patch section merges them with a comparison function that
uses logic of the form:
return (isa<PatchSection>(a) && !isa<PatchSection>(b));
If the PatchSections don't implement classof this check fails if b is also
a SyntheticSection. This can result in the patches being out of range if
the SyntheticSection is big, for example a ThunkSection with lots of thunks.
Differential Revision: https://reviews.llvm.org/D71242
fixes (part of) pr44071
clang/gcc -fdebug-type-sections places .debug_types and
.rela.debug_types in a section group, with a signature symbol which
represents the type signature. The section group is for deduplication
purposes.
After D70146, we will discard such section groups. Refine the rule so
that we will retain the group if no member has the SHF_ALLOC flag.
GNU ld has a similar rule to retain the group if all members have the
SEC_DEBUGGING flag. We try to be more general for future-proof purposes:
if other non-SHF_ALLOC sections have deduplication needs, they may be
placed in a section group. Don't discard them.
Reviewed By: grimar
Differential Revision: https://reviews.llvm.org/D71157
Fixes PPC64 part of PR40438
// clang -target ppc64le -c a.cc
// .text.unlikely may be placed in a separate output section (via -z keep-text-section-prefix)
// The distance between bar in .text.unlikely and foo in .text may be larger than 32MiB.
static void foo() {}
__attribute__((section(".text.unlikely"))) static int bar() { foo(); return 0; }
__attribute__((used)) static int dummy = bar();
This patch makes such thunks with addends work for PPC64.
AArch64: .text -> `__AArch64ADRPThunk_ (adrp x16, ...; add x16, x16, ...; br x16)` -> target
PPC64: .text -> `__long_branch_ (addis 12, 2, ...; ld 12, ...(12); mtctr 12; bctr)` -> target
AArch64 can leverage ADRP to jump to the target directly, but PPC64
needs to load an address from .branch_lt . Before Power ISA v3.0, the
PC-relative ADDPCIS was not available. .branch_lt was invented to work
around the limitation.
Symbol::ppc64BranchltIndex is replaced by
PPC64LongBranchTargetSection::entry_index which take addends into
consideration.
The tests are rewritten: ppc64-long-branch.s tests -no-pie and
ppc64-long-branch-pi.s tests -pie and -shared.
Reviewed By: sfertile
Differential Revision: https://reviews.llvm.org/D70937
replaceWithDefined is used by canonical PLT and copy relocations, which
imply that the symbol is preemptable. ppc64BranchltIndex is only used by
non-preemptable cases, and it can only be the default value in
replaceWithDefined.
The .note.gnu.property SHT_NOTE sections on AArch64 (a 64-bit target)
should have alignment 8 to more closely match the binutils implementation
where alignment is 4-bytes on 32-bit machines and 8-bytes on 64-bit
machines.
Previously LLD was using 4 for both 32-bit and 64-bit machines.
Differential Revision: https://reviews.llvm.org/D70962
The PT_GNU_PROPERTY program header describes the location of the
.note.gnu.property SHT_NOTES section. The linux kernel uses this program
header to find the .note.gnu.property section rather than parsing.
Executables that have properties that the kernel needs to act on that don't
have the PT_GNU_PROPERTY program header will not boot.
Differential Revision: https://reviews.llvm.org/D70961
Fixes AArch64 part of PR40438
The current range extension thunk framework does not handle a relocation
relative to a STT_SECTION symbol with a non-zero addend, which may be
used by jumps/calls to local functions on some RELA targets (AArch64,
powerpc ELFv1, powerpc64 ELFv2, etc). See PR40438 and the following
code for examples:
// clang -target $target a.cc
// .text.cold may be placed in a separate output section.
// The distance between bar in .text.cold and foo in .text may be larger than 128MiB.
static void foo() {}
__attribute__((section(".text.cold"))) static int bar() { foo(); return
0; }
__attribute__((used)) static int dummy = bar();
This patch makes such thunks with addends work for AArch64. The target
independent part can be reused by PPC in the future.
On REL targets (ARM, MIPS), jumps/calls are not represented as
STT_SECTION + non-zero addend (see
MCELFObjectTargetWriter::needsRelocateWithSymbol), so they don't need
this feature, but we need to make sure this patch does not affect them.
Reviewed By: peter.smith
Differential Revision: https://reviews.llvm.org/D70637
ThunkCreator::getThunk and ThunkCreator::normalizeExistingThunk
currently assume that the implicit addends are -8 for ARM and -4 for
Thumb. In D70637, ThunkCreator::getThunk will need to take care of the
relocation addend explicitly.
Add the utility function getPCBias() as a prerequisite so that the getThunk change in D70637
can be more general.
Reviewed By: peter.smith
Differential Revision: https://reviews.llvm.org/D70690
This is a follow-up discussed in D70495 thread.
The current logic is unusual for llvm-readobj. It doesn't print predecessors
list when it is empty. This is not good for machine parsers.
D70495 had to add this condition during refactoring to reduce amount of changes,
in tests, because the original code also had a similar logic.
Now seems it is time to get rid of it. This patch does it.
Differential revision: https://reviews.llvm.org/D70717
The previous data had the same length with compression levels 1 and 6
for zlib 1.2.8. Adjust the test to work for this library version. I've
also tested this with zlib 1.2.7 and zlib 1.2.11.
D62381 introduced forEachSymbol(). It seems that many call sites cannot
be parallelized because the body shared some states. Replace
forEachSymbol with iterator_range<filter_iterator<...>> symbols() to
simplify code and improve debuggability (std::function calls take some
frames).
It also allows us to use early return to simplify code added in D69650.
Reviewed By: grimar
Differential Revision: https://reviews.llvm.org/D70505
Currently LLD always use zlib compression level 6.
This patch changes it to use 1 for -O0, -O1 and 6 for -O2.
It fixes https://bugs.llvm.org/show_bug.cgi?id=44089.
There was also a thread in llvm-dev on this topic:
https://lists.llvm.org/pipermail/llvm-dev/2018-August/125020.html
Here is a table with results of building clang mentioned there:
```
Level Time Size
0 0m17.128s 2045081496 Z_NO_COMPRESSION
1 0m31.471s 922618584 Z_BEST_SPEED
2 0m32.659s 903642376
3 0m36.749s 890805856
4 0m41.532s 876697184
5 0m48.383s 862778576
6 1m3.176s 855251640 Z_DEFAULT_COMPRESSION
7 1m15.335s 853755920
8 2m0.561s 852497560
9 2m33.972s 852397408 Z_BEST_COMPRESSION
```
It shows that it is probably not reasonable to use values greater than 6.
Differential revision: https://reviews.llvm.org/D70658
In GNU ld, -Ttext sets the address of the .text section and -Ttext-segment sets the address of the text segment (RX).
gold only supports the -Ttext-segment semantic and treats -Ttext as an alias for -Ttext-segment.
lld only supports the -Ttext semantic and treats -Ttext-segment as an
alias for -Ttext. The text segment will be assigned to an address less
than the specified -Ttext-segment value.
This patch drops the -Ttext-segment alias.
The text segment is traditionally the first segment. Users who specify
-Ttext-segment may actually want to specify --image-base, the lld way to
express this. Unfortunately currently this is supported by GNU ld's
COFF port but not by its ELF port. gold does not support this option.
With -z separate-code, the behavior of GNU ld -Ttext-segment is weird (see https://sourceware.org/bugzilla/show_bug.cgi?id=25207)
rL289827 introduced the alias for linking qemu's non-pie user mode
binaries. As explained previously, this actually assigns the text
segment to an address less than 0x60000000. I feel that a better fix is
on the qemu side:
https://lists.nongnu.org/archive/html/qemu-devel/2019-11/msg02480.html
Reviewed By: grimar, ruiu
Differential Revision: https://reviews.llvm.org/D70468
Remove the lld::enableColors function, as it just obscures which
stream it's affecting, and replace with explicit calls to the stream's
enable_colors.
Also, assign the stderrOS and stdoutOS globals first in link function,
just to ensure nothing might use them.
(Either change individually fixes the issue of using the old
stream, but both together seems best.)
Follow-up to b11386f9be.
Differential Revision: https://reviews.llvm.org/D70492
Summary:
Current versions of clang would erroneously emit this relocation not only
against functions (loaded from the GOT) but also against data symbols
(e.g. a table of function pointers). LLD was then changing this into a
branch-and-link instruction, causing the program to jump to the data
symbol at run time. I discovered this problem when attempting to boot
MIPS64 FreeBSD after updating the to the latest upstream master.
Reviewers: atanasyan, jrtc27, espindola
Reviewed By: atanasyan
Subscribers: emaste, sdardis, krytarowski, MaskRay, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D70406
Our elf-versioninfo.test is not perfect. It does not properly test how
flags are dumped and also we have a bug: they are dumped as enums in
LLVM style now, i.e not dumped properly.
GNU style uses a `versionFlagToString` method to build a string from flags
which seems is consistent with GNU readelf.
In this patch I fixed the issues mentioned.
Differential revision: https://reviews.llvm.org/D70399
In lld we rarely use std::unique_ptr but instead allocate new instances
using lld::make<T>() so that they are deallocated at the end of linking.
This patch changes existing code so that that follows the convention.
Differential Revision: https://reviews.llvm.org/D70420
Based on D70020 by serge-sans-paille.
The ELF spec says:
> Furthermore, there may be internal references among these sections that would not make sense if one of the sections were removed or replaced by a duplicate from another object. Therefore, such groups must be included or omitted from the linked object as a unit. A section cannot be a member of more than one group.
GNU ld has 2 behaviors that we don't have:
- Group members (nextInSectionGroup != nullptr) are subject to garbage collection.
This includes non-SHF_ALLOC SHT_NOTE sections.
In particular, discarding non-SHF_ALLOC SHT_NOTE sections is an expected behavior by the Annobin
project. See
https://developers.redhat.com/blog/2018/02/20/annobin-storing-information-binaries/
for more information.
- Groups members are retained or discarded as a unit.
Members may have internal references that are not expressed as
SHF_LINK_ORDER, relocations, etc. It seems that we should be more conservative here:
if a section is marked live, mark all the other member within the
group.
Both behaviors are reasonable. This patch implements them.
A new field InputSectionBase::nextInSectionGroup tracks the next member
within a group. on ELF64, this increases sizeof(InputSectionBase) froms
144 to 152.
InputSectionBase::dependentSections tracks section dependencies, which
is used by both --gc-sections and /DISCARD/. We can't overload it for
the "next member" semantic, because we should allow /DISCARD/ to discard
sections independent of --gc-sections (GNU ld behavior). This behavior
may be reasonably used by `/DISCARD/ : { *(.ARM.exidx*) }` or `/DISCARD/
: { *(.note*) }` (new test `linkerscript/discard-group.s`).
Reviewed By: ruiu
Differential Revision: https://reviews.llvm.org/D70146
This reverts commit 17e37ba57a
because it introduced a circular dependency between Core and Common.
Because d0371f4736 fixed a build issue,
we no longer need that dependency.
This change is for those who use lld as a library. Context:
https://reviews.llvm.org/D70287
This patch adds a new parmeter to lld::*::link() so that we can pass
an raw_ostream object representing stdout. Previously, lld::*::link()
took only an stderr object.
Justification for making stdoutOS and stderrOS mandatory: I wanted to
make link() functions to take stdout and stderr in that order.
However, if we change the function signature from
bool link(ArrayRef<const char *> args, bool canExitEarly,
raw_ostream &stderrOS = llvm::errs());
to
bool link(ArrayRef<const char *> args, bool canExitEarly,
raw_ostream &stdoutOS = llvm::outs(),
raw_ostream &stderrOS = llvm::errs());
, then the meaning of existing code that passes stderrOS silently
changes (stderrOS would be interpreted as stdoutOS). So, I chose to
make existing code not to compile, so that developers can fix their
code.
Differential Revision: https://reviews.llvm.org/D70292
The patch in https://reviews.llvm.org/D64077 causes a build failure
because both the Defined and SharedSymbol classes are bigger than 80
bytes on MinGW 8.
This patch fixes this build failure by changing the type of the
bitfields. It is a similar change to the bitfield changes in
https://reviews.llvm.org/D64238, but instead of changing to bool I
decided to use uint8_t because one of the bitfields takes up two bits
instead of one.
Note: the patch is slightly different from the one reviewed in
Phabricator, but it is a trivial change to align it with LLVM master
instead of LLVM 9. Also, it passes all lld tests.
Differential Revision: https://reviews.llvm.org/D70266
/align is not supposed to be used without /driver, so it makes sense
to warn if only /align is passed. MSVC link.exe warns on this too.
Differential Revision: https://reviews.llvm.org/D70163
This broke in 51dcb292cc, "[lld-link] diagnose undefined symbols
before LTO when possible" (very soon after the 9.0 branch, so
luckily the 9.0 release is unaffected).
The code for loading objects we believe might be needed for autoimport
(loadMinGWAutomaticImports()) does run before the new
reportUnresolvable() function, but it had a condition to only operate
on symbols from regular object files. This condition came from
resolveRemainingUndefines(), but as loadMinGWAutomaticImports() now
has to operate before the LTO, it has to operate on undefineds from
LTO objects as well.
Differential Revision: https://reviews.llvm.org/D70166
Recommit r373168, which was reverted by r373242. This actually exposed a
boringssl bug which has been fixed for more than one month.
For the following two cases, we currently suppress the symbols. This
patch emits them (compatible with GNU as).
* `test2_a = undef`: if `undef` is otherwise unused.
* `.hidden hidden`: if `hidden` is unused. This is the main point of the
patch, because omitting the symbol would cause a linker semantic
difference.
It causes a behavior change that is not compatible with GNU as:
.weakref foo1, bar1
When neither foo1 nor bar1 is used, we now emit bar1, which is arguably
more consistent.
Another change is that we will emit .TOC. for .TOC.@tocbase . For this
directive, suppressing .TOC. can be seen as a size optimization, but we
choose to drop it for simplicity and consistency.
The definition may be mangled while an undefined reference is not.
This may come up when (1) the reference is from a C file or (2) the definition
misses an extern "C".
(2) is more common. Suggest an arbitrary mangled name that matches the
undefined reference, if such a definition exists.
ld.lld: error: undefined symbol: foo
>>> referenced by a.o:(.text+0x1)
>>> did you mean to declare foo(int) as extern "C"?
>>> defined in: a1.o
Reviewed By: dblaikie, ruiu
Differential Revision: https://reviews.llvm.org/D69650
When missing an extern "C" declaration, an undefined reference may be
mangled while the definition is not. Suggest the missing
extern "C" and the base name.
Reviewed By: ruiu
Differential Revision: https://reviews.llvm.org/D69592
The logic added in r372781 caused ARMExidxSyntheticSection::addSection()
to return false for exidx sections without a link order dep that passed
isValidExidxSectionDep(). This included exidx sections for empty functions. As
a result, such exidx sections would end up treated like ordinary sections and
would end up being laid out before the ARMExidxSyntheticSection, most likely in
the wrong order relative to the exidx entries in the ARMExidxSyntheticSection,
breaking the orderedness invariant relied upon by unwinders. Fix this by
simply discarding such sections.
Differential Revision: https://reviews.llvm.org/D69744
Recent versions of Microsoft's dumpbin tool cannot handle such PE files.
LLVM tools and GNU tools can, and use this to encode long section names
like ".debug_info", which is commonly used for DWARF. Don't do this in
mingw mode or when -debug:dwarf is passed, since the user probably wants
long section names for DWARF sections.
PR43754
Reviewers: ruiu, mstorsjo
Differential Revision: https://reviews.llvm.org/D69594
Test files in the same directory share the same %T. %T is easy to
misuse and cause race conditions (when running concurrently) so it has
been deprecated since D48842 (see docs/CommandGuide/lit.rst).
While here, add `rm -rf %t.dir` so that tests cannot depend on old files lying around.
Reviewed By: jhenderson, ruiu
Differential Revision: https://reviews.llvm.org/D69572
When statically linking PIC code we create an internalized __memory_base
so that memory-base-relative relocation work correctly. The value of
this global should be zero, and not the globalBase since the globalBase
offset is already taken into account by getVirtualAddress.
Fixes: https://github.com/emscripten-core/emscripten/issues/9013
Differential Revision: https://reviews.llvm.org/D69600
Summary:
Add a flag `F_no_mmap` to `FileOutputBuffer` to support
`--[no-]mmap-output-file` in ELF LLD. LLD currently explicitly ignores
this flag for compatibility with GNU ld and gold.
We need this flag to speed up link time for large binaries in certain
scenarios. When we link some of our larger binaries we find that LLD
takes 50+ GB of memory, which causes memory pressure. The memory
pressure causes the VM to flush dirty pages of the output file to disk.
This is normally okay, since we should be flushing cold pages. However,
when using BtrFS with compression we need to write 128KB at a time when
we flush a page. If any page in that 128KB block is written again, then
it must be flushed a second time, and so on. Since LLD doesn't write
sequentially this causes write amplification. The same 128KB block will
end up being flushed multiple times, causing the linker to many times
more IO than necessary. We've observed 3-5x faster builds with
-no-mmap-output-file when we hit this scenario.
The bad scenario only applies to compressed filesystems, which group
together multiple pages into a single compressed block. I've tested
BtrFS, but the problem will be present for any compressed filesystem
on Linux, since it is caused by the VM.
Silently ignoring --no-mmap-output-file caused a silent regression when
we switched from gold to lld. We pass --no-mmap-output-file to fix this
edge case, but since lld silently ignored the flag we didn't realize it
wasn't being respected.
Benchmark building a 9 GB binary that exposes this edge case. I linked 3
times with --mmap-output-file and 3 times with --no-mmap-output-file and
took the average. The machine has 24 cores @ 2.4 GHz, 112 GB of RAM,
BtrFS mounted with -compress-force=zstd, and an 80% full disk.
| Mode | Time |
|---------|-------|
| mmap | 894 s |
| no mmap | 126 s |
When compression is disabled, BtrFS performs just as well with and
without mmap on this benchmark.
I was unable to reproduce the regression with any binaries in
lld-speed-test.
Reviewed By: ruiu, MaskRay
Differential Revision: https://reviews.llvm.org/D69294
Add a new '-z nognustack' option that suppresses emitting PT_GNU_STACK
segment. This segment is not supported at all on NetBSD (stack is
always non-executable), and the option is meant to be used to disable
emitting it.
Differential Revision: https://reviews.llvm.org/D56554
Also mention "basename" and "dirname" in Path.h since I tried
to find these functions by looking for these strings. It might
help others find them faster if the comments contain these strings.
No behavior change.
Differential Revision: https://reviews.llvm.org/D69458
sections, but the current code misses certain variants. In particular, those
named when clang takes the code path in
clang/lib/Driver/ToolChain.cpp:416, where crtfiles are named:
clang_rt.<component>-<arch>-<env>.<suffix>
Previously, the code only handled:
clang_rt.<component>.<suffix>
<component>.<suffix>
This revision fixes that.
Fix PR43767
In -r mode, when processing a SHT_REL[A] that relocates a SHF_MERGE, sec->getRelocatedSection() is a
MergeInputSection and its parent is an OutputSection but is asserted to
be a SyntheticSection (MergeSyntheticSection) in LinkerScript.cpp:addInputSec().
##
The code path is not exercised in non -r mode because the relocated
section changed from MergeInputSection to InputSection.
Reorder the code to make the non -r logic apply to -r as well, thus fix
the crash.
Reviewed By: peter.smith
Differential Revision: https://reviews.llvm.org/D69364
As we now have code that parses the dwarf info for variable locations,
we can use that instead of relying on the higher level Symbolizer library,
reducing the previous two different dwarf codepaths into one.
Differential Revision: https://reviews.llvm.org/D69198
llvm-svn: 375391
Works on this dependency chain:
ArrayRef.h ->
Hashing.h -> --CUT--
Host.h ->
StringMap.h / StringRef.h
ArrayRef is very popular, but Host.h is rarely needed. Move the
IsBigEndianHost constant to SwapByteOrder.h. Clients of that header are
more likely to need it.
llvm-svn: 375316
Summary:
Also changes the wasm YAML format to reflect the possibility of having
multiple return types and to put the returns after the params for
consistency with the binary encoding.
Reviewers: aheejin, sbc100
Subscribers: dschuff, jgravelle-google, hiraditya, sunfish, arphaman, rupprecht, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D69156
llvm-svn: 375283
This fixes the second part of PR42407.
For files with dwarf debug info, it manually loads and iterates
.debug_info to find the declared location of variables, to allow
reporting them. (This matches the corresponding code in the ELF
linker.)
For functions, it uses the existing getFileLineDwarf which uses
LLVMSymbolizer for translating addresses to file lines.
In object files with codeview debug info, only the source location
of duplicate functions is printed. (And even there, only for the
first input file. The getFileLineCodeView function requires the
object file to be fully loaded and initialized to properly resolve
source locations, but duplicate symbols are reported at a stage when
the second object file isn't fully loaded yet.)
Differential Revision: https://reviews.llvm.org/D68975
llvm-svn: 375218
This updates some more places using `%T` to use `%/T` for path normalization.
If this does not work, this and r375126 should be reverted together.
llvm-svn: 375131
Summary:
Glob support was improved to accept `\` as an escape character in r375051, but reverted as r375052 due to a failure in this test on Windows.
The reason this failure seems Windows specific is because the path separator `\` is currently being relied on to be interpreted literally instead of as an escape character. Per documentation on linker input section wildcard patterns, this seems to be a bug in lld accepting `\` as a literal instead of an escape character.
For example:
```
SECTIONS{ .foo :{ /path/to/foo.o(.foo) }} # OK: standard UNIX path
SECTIONS{ .foo :{ C:/path/to/foo.o(.foo) }} # OK: windows accepts slashes in either direction
SECTIONS{ .foo :{ C:\\path\\to\\foo.o(.foo) }} # OK: escape character used to match a literal \
SECTIONS{ .foo :{ C:\path\to\foo.o(.foo) }} # BAD: this actually matches the path C:pathtofoo.o(.foo)
```
This avoids the problem in the test by using `%/T` in place of `%T` to normalize the path separator to `/`, which windows should also accept.
This patch just fixes the test, and glob support will be be relanded separately.
For a sample buildbot error, see: http://lab.llvm.org:8011/builders/clang-x64-windows-msvc/builds/11578/steps/stage%201%20check/logs/stdio
Reviewers: evgeny777, ruiu, MaskRay, espindola
Reviewed By: ruiu, MaskRay
Subscribers: emaste, arichardson, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D69074
llvm-svn: 375126
Undefined symbols in WebAssembly can come with custom `import-module`
and `import-field` attributes. However when reading symbols from
bitcode object files during LTO those curtom attributes are not
available.
Once we compile the LTO object and read in the symbol table from the
object file we have access to these custom attributes. In this case,
when undefined symbols are added and a symbol already exists in the
SymbolTable we can't simple return it, we may need to update the
symbol's attributes.
Fixes: PR43211
Differential Revision: https://reviews.llvm.org/D68959
llvm-svn: 375081
Fix a bug where were not handling relocations against weakly undefined
data symbol. Add a test for this case. Also ensure that the weak
references to data symbols are not pulled in from archive files by
default (but are if `-u <name>` is added to the command line).
Fixes: PR43696
Differential Revision: https://reviews.llvm.org/D69073
llvm-svn: 375077
Summary:
WebAssembly memories are zero-initialized, so when module does not
import its memory initializing .bss sections is guaranteed to be a
no-op. To reduce binary size and initialization time, .bss sections
are simply not emitted into the final binary unless the memory is
imported.
Reviewers: sbc100
Subscribers: dschuff, jgravelle-google, aheejin, sunfish, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D68965
llvm-svn: 374940
This makes use of it slightly clearer, and makes it match the
same construct in the lld ELF linker.
Differential Revision: https://reviews.llvm.org/D68935
llvm-svn: 374869
Summary:
- Expand the "Name" column past 13 characters when any of the section names are longer. Current behavior is a staggard output instead of a nice table if a single name is longer.
- Only print the required number of hex chars for addresses (i.e. 8 characters for 32-bit, 16 characters for 64-bit)
- Fix trailing spaces
Reviewers: grimar, jhenderson, espindola
Reviewed By: grimar
Subscribers: emaste, sbc100, arichardson, aheejin, seiya, llvm-commits, MaskRay
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D68730
llvm-svn: 374795
A common pattern in Windows is to have all your precompiled headers
use an object named stdafx.obj. If you've got a project with many
different static libs, you might use a separate PCH for each one of
these.
During the final link step, a file from A might reference the PCH
object from A, but it will have the same name (stdafx.obj) as any
other PCH from another project. The only difference will be the
path. For example, A might be A/stdafx.obj while B is B/stdafx.obj.
The existing algorithm checks only the filename that was passed on
the command line (or stored in archive), but this is insufficient in
the case where relative paths are used, because depending on the
command line object file / library order, it might find the wrong
PCH object first resulting in a signature mismatch.
The fix here is to simply check whether the absolute path of the
PCH object (which is stored in the input obj file for the file that
references the PCH) *ends with* the full relative path of whatever
is specified on the command line (or is in the archive).
Differential Revision: https://reviews.llvm.org/D66431
llvm-svn: 374442
The only condition that isecLoc becomes null is
Out::bufferStart == nullptr,
isec->getParent()->offset == 0, and
isec->outSecOff == 0.
We can check the first condition only once.
llvm-svn: 374332
isecLoc there can be null, but at the same time isec->getSize() may
be non-null. It is UB to offset a nullptr.The most straight-forward fix
here appears to perform casts+normal integral arithmetics.
FAIL: lld :: ELF/invalid/invalid-relocation-aarch64.test (1158 of 2217)
******************** TEST 'lld :: ELF/invalid/invalid-relocation-aarch64.test' FAILED ********************
Script:
--
: 'RUN: at line 2'; /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm_build_ubsan/bin/yaml2obj /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm-project/lld/test/ELF/invalid/invalid-relocation-aarch64.test -o /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm_build_ubsan/tools/lld/test/ELF/invalid/Output/invalid-relocation-aarch64.test.tmp.o
: 'RUN: at line 3'; not /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm_build_ubsan/bin/ld.lld /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm_build_ubsan/tools/lld/test/ELF/invalid/Output/invalid-relocation-aarch64.test.tmp.o -o /dev/null 2>&1 | /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm_build_ubsan/bin/FileCheck /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm-project/lld/test/ELF/invalid/invalid-relocation-aarch64.test
--
Exit Code: 1
Command Output (stderr):
--
/b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm-project/lld/test/ELF/invalid/invalid-relocation-aarch64.test:4:10: error: CHECK: expected string not found in input
# CHECK: error: unknown relocation (1024) against symbol foo
^
<stdin>:1:1: note: scanning from here
/b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm-project/lld/ELF/Target.cpp💯41: runtime error: applying non-zero offset 24 to null pointer
^
<stdin>:1:118: note: possible intended match here
/b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm-project/lld/ELF/Target.cpp💯41: runtime error: applying non-zero offset 24 to null pointer
^
--
********************
Testing: 0.. 10.. 20.. 30.. 40.. 50.
FAIL: lld :: ELF/invalid/invalid-relocation-x64.test (1270 of 2217)
******************** TEST 'lld :: ELF/invalid/invalid-relocation-x64.test' FAILED ********************
Script:
--
: 'RUN: at line 2'; /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm_build_ubsan/bin/yaml2obj /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm-project/lld/test/ELF/invalid/invalid-relocation-x64.test -o /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm_build_ubsan/tools/lld/test/ELF/invalid/Output/invalid-relocation-x64.test.tmp1.o
: 'RUN: at line 3'; echo ".global foo; foo:" > /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm_build_ubsan/tools/lld/test/ELF/invalid/Output/invalid-relocation-x64.test.tmp2.s
: 'RUN: at line 4'; /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm_build_ubsan/bin/llvm-mc /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm_build_ubsan/tools/lld/test/ELF/invalid/Output/invalid-relocation-x64.test.tmp2.s -o /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm_build_ubsan/tools/lld/test/ELF/invalid/Output/invalid-relocation-x64.test.tmp2.o -filetype=obj -triple x86_64-pc-linux
: 'RUN: at line 5'; not /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm_build_ubsan/bin/ld.lld /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm_build_ubsan/tools/lld/test/ELF/invalid/Output/invalid-relocation-x64.test.tmp1.o /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm_build_ubsan/tools/lld/test/ELF/invalid/Output/invalid-relocation-x64.test.tmp2.o -o /dev/null 2>&1 | /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm_build_ubsan/bin/FileCheck /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm-project/lld/test/ELF/invalid/invalid-relocation-x64.test
--
Exit Code: 1
Command Output (stderr):
--
/b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm-project/lld/test/ELF/invalid/invalid-relocation-x64.test:6:10: error: CHECK: expected string not found in input
# CHECK: error: unknown relocation (152) against symbol foo
^
<stdin>:1:1: note: scanning from here
/b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm-project/lld/ELF/Target.cpp💯41: runtime error: applying non-zero offset 24 to null pointer
^
<stdin>:1:118: note: possible intended match here
/b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm-project/lld/ELF/Target.cpp💯41: runtime error: applying non-zero offset 24 to null pointer
^
--
********************
Testing: 0.. 10.. 20.. 30.. 40.. 50.. 60.. 70.. 80.. 90..
Testing Time: 20.73s
********************
Failing Tests (2):
lld :: ELF/invalid/invalid-relocation-aarch64.test
lld :: ELF/invalid/invalid-relocation-x64.test
llvm-svn: 374329
Similar to D67323, but for COFF. Many lld/COFF/ files already use
`namespace lld { namespace coff {`. Only a few need changing.
Reviewed By: ruiu
Differential Revision: https://reviews.llvm.org/D68772
llvm-svn: 374314
GNU ld looks for a number of other patterns than just lib<name>.dll.a
and lib<name>.a.
GNU ld does support linking directly against a DLL without using an
import library. If that's the only match for a -l argument, point out
that the user needs to use an import library, instead of leaving the
user with a puzzling message about the -l argument not being found
at all.
Also convert an existing case of fatal() into error().
Differential Revision: https://reviews.llvm.org/D68689
llvm-svn: 374292
This pattern matches the ELF implementation add if also useful as
part of a planned change where running `mark` more than once is needed.
Differential Revision: https://reviews.llvm.org/D68749
llvm-svn: 374275
David added the JamCRC implementation in r246590. More recently, Eugene
added a CRC-32 implementation in r357901, which falls back to zlib's
crc32 function if present.
These checksums are essentially the same, so having multiple
implementations seems unnecessary. This replaces the CRC-32
implementation with the simpler one from JamCRC, and implements the
JamCRC interface in terms of CRC-32 since this means it can use zlib's
implementation when available, saving a few bytes and potentially making
it faster.
JamCRC took an ArrayRef<char> argument, and CRC-32 took a StringRef.
This patch changes it to ArrayRef<uint8_t> which I think is the best
choice, and simplifies a few of the callers nicely.
Differential revision: https://reviews.llvm.org/D68570
llvm-svn: 374148
Fixes assert in addLinkerModuleCoffGroup() when using by-ordinal imports
only.
Patch by Stefan Schmidt.
Differential revision: https://reviews.llvm.org/D68352
llvm-svn: 374140
The combination of the two flags doesn't make sense. And other linkers
seem to just ignore --export-dynamic if --relocatable is given, but
we probably should report it as an error to let users know that is
an invalid combination.
Fixes https://bugs.llvm.org/show_bug.cgi?id=43552
Differential Revision: https://reviews.llvm.org/D68441
llvm-svn: 374022
This makes it clear `ELF/**/*.cpp` files define things in the `lld::elf`
namespace and simplifies `elf::foo` to `foo`.
Reviewed By: atanasyan, grimar, ruiu
Differential Revision: https://reviews.llvm.org/D68323
llvm-svn: 373885
This allows us to delete `using namespace llvm::support::endian` and
simplify D68323. This change adds runtime config->endianness check but
the overhead should be negligible.
Reviewed By: ruiu
Differential Revision: https://reviews.llvm.org/D68561
llvm-svn: 373884
Before, SecToClusters[*] was used to track the belonged cluster.
During a merge (From -> Into), every element of From has to be updated.
Use a union-find set to speed up this use case.
Also, replace `std::vector<int> Sections;` with a doubly-linked
pointers: int Next, Prev;
Reviewed By: Bigcheese
Differential Revision: https://reviews.llvm.org/D46228
llvm-svn: 373708
This patch adds /reproduce:<path> option to lld/COFF. This is an
lld-specific option, so we can name it freely. I chose /reproduce
over other names (e.g. /lldlinkrepro) for consistency with other lld
ports.
Differential Revision: https://reviews.llvm.org/D68381
llvm-svn: 373704
This reverts commit r371729 because /linkrepro option also exists
in Microsoft link.exe and their linker takes not a filename but a
directory name as an argument for /linkrepro.
Differential Revision: https://reviews.llvm.org/D68378
llvm-svn: 373703
Summary:
rL371826 rearranged some output from llvm-objdump for GNU objdump compatability, but there still seem to be some more.
I think this rearrangement is a little closer. Overview of the ordering which matches GNU objdump:
* Archive headers
* File headers
* Section headers
* Symbol table
* Dwarf debugging
* Relocations (if `--disassemble` is not used)
* Section contents
* Disassembly
Reviewers: jhenderson, justice_adams, grimar, ychen, espindola
Reviewed By: jhenderson
Subscribers: aprantl, emaste, arichardson, jrtc27, atanasyan, seiya, llvm-commits, MaskRay
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D68066
llvm-svn: 373671
Our .interp section is not a SyntheticSection. As a result, it terminates the
loop in removeUnusedSyntheticSections(). This has at least two consequences:
- The synthetic .bss and .bss.rel.ro sections are always present in
dynamically linked executables, even when they are not needed.
- The synthetic .ARM.exidx (and possibly other) sections are always present
in partitions other than the last one, even when not needed.
.ARM.exidx in particular is problematic because it assumes that its
list of code sections is non-empty in getLinkOrderDep(), which can
lead to a crash if the partition does not have any code sections.
Fix these problems by moving the creation of the .interp sections to the
top of createSyntheticSections(). While here, make the code a little less
error-prone by changing the add() lambdas to take a SyntheticSection instead
of an InputSectionBase.
Differential Revision: https://reviews.llvm.org/D68256
llvm-svn: 373347
Merging SHF_LINK_ORDER sections can affect semantics if the sh_link
fields point to different sections.
Specifically, for SHF_LINK_ORDER sections, the sh_link field acts as a reverse
dependency from the linked section, causing the SHF_LINK_ORDER section to
be included if the linked section is included. Merging sections with different
sh_link fields will cause the entire contents of the SHF_LINK_ORDER section
to be associated with a single (arbitrarily chosen) output section, whereas the
correct semantics are for the individual pieces of the SHF_LINK_ORDER section
to be associated with their linked output sections. As a result we can end up
incorrectly dropping SHF_LINK_ORDER section contents or including the wrong
section contents, depending on which linked sections were chosen.
Differential Revision: https://reviews.llvm.org/D68094
llvm-svn: 373255
For the following two cases, we currently suppress the symbols. This
patch emits them (compatible with GNU as).
* `test2_a = undef`: if `undef` is otherwise unused.
* `.hidden hidden`: if `hidden` is unused. This is the main point of the
patch, because omitting the symbol would cause a linker semantic
difference.
It causes a behavior change that is not compatible with GNU as:
.weakref foo1, bar1
When neither foo1 nor bar1 is used, we now emit bar1, which is arguably
more consistent.
Another change is that we will emit .TOC. for .TOC.@tocbase . For this
directive, suppressing .TOC. can be seen as a size optimization, but we
choose to drop it for simplicity and consistency.
llvm-svn: 373168
Instead of returning an optional, just return the input string if
demangling fails, as that's what all callers use anyway.
Differential Revision: https://reviews.llvm.org/D68015
llvm-svn: 373077
This avoids a few lines of boilerplate of dealing with C string
allocations.
Add a testcase for a case where demangling shouldn't happen.
Differential Revision: https://reviews.llvm.org/D68014
llvm-svn: 373076
Fixes PR43461 (regression caused by D67504)
The partition field of a SECTIONS-specified section is not set after
D67504. The 0 value affects findSection() which checks if the partition
field is 1.
So `Out::initArray = findSection(".init_array")` is null, and
DT_INIT_ARRAYSZ is not set.
Reviewed By: peter.smith
Differential Revision: https://reviews.llvm.org/D68087
llvm-svn: 372996
Summary:
The following patch avoids segfaulting if the section list is empty when writing a mach-o MH_OBJECT. I ran into this case from a more complicated example trying to dead_strip while using '-r' in lld.
I'm not sure if having empty sections is a legal mach-o, but it does seem that other llvm-binutils tools can ingest such a boring object with out issue. Would it be better to emit an error, emit a warning, or do nothing? It seems that adding a warning diagnostic might be helpful to users, as I did not expect to have a section-less object when the linker was done.
Reviewers: kledzik, ruiu
Subscribers: llvm-commits, jrm
Tags: #lld, #llvm
Differential Revision: https://reviews.llvm.org/D67735
llvm-svn: 372995
The R_MIPS_JALR relocation denotes jalr/jr instructions in position
independent code. Both these instructions take a target's address from
the $25 register. If offset to the target symbol fits into the 18-bits,
it's more efficient to replace jalr/jr by bal/b instructions.
Differential Revision: https://reviews.llvm.org/D68057
llvm-svn: 372951
D64906 allows PT_LOAD to have overlapping p_offset ranges. In the
default R RX RW RW layout + -z noseparate-code case, we do not tail pad
segments when transiting to another segment. This can save at most
3*maxPageSize bytes.
a) Before D64906, we tail pad R, RX and the first RW.
b) With -z separate-code, we tail pad R and RX, but not the first RW (RELRO).
In some cases, b) saves one file page. In some cases, b) wastes one
virtual memory page. The waste is a concern on Fuchsia. Because it uses
compressed binaries, it doesn't benefit from the saved file page.
This patch adds -z separate-loadable-segments to restore the behavior before
D64906. It can affect section addresses and can thus be used as a
debugging mechanism (see PR43214 and ld.so partition bug in
crbug.com/998712).
Reviewed By: jakehehrlich, ruiu
Differential Revision: https://reviews.llvm.org/D67481
llvm-svn: 372807
Summary:
When support for ThinLTO was first added to lld, the options that
control it were prefixed with --plugin-opt= for compatibility with
an existing implementation as a linker plugin. This change enables
shorter versions of the options to be used, as follows:
New Existing
-thinlto-emit-imports-files --plugin-opt=thinlto-emit-imports-files
-thinlto-index-only --plugin-opt=thinlto-index-only
-thinlto-index-only= --plugin-opt=thinlto-index-only=
-thinlto-object-suffix-replace= --plugin-opt=thinlto-object-suffix-replace=
-thinlto-prefix-replace= --plugin-opt=thinlto-prefix-replace=
-lto-obj-path= --plugin-opt=obj-path=
The options with the --plugin-opt= prefix have been retained as aliases
for the shorter variants so that they continue to be accepted.
Reviewers: tejohnson, ruiu, espindola
Reviewed By: ruiu
Subscribers: emaste, arichardson, MaskRay, steven_wu, dexonsmith, arphaman, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D67782
llvm-svn: 372798
When /DISCARD/ is used on an input section, that input section may have
a .ARM.exidx metadata section that depends on it. As the discard handling
comes after the .ARM.exidx synthetic section is created we need to make
sure that we account for the case where the .ARM.exidx output section
should be removed because there are no more live input sections.
Differential Revision: https://reviews.llvm.org/D67848
llvm-svn: 372781
D67504 removed uses of `assigned` from OutputSection::addSection, which
makes `assigned` purely used in processSectionCommands() and its
callees. By replacing its references with `parent`, we can remove
`assigned`.
Reviewed By: grimar
Differential Revision: https://reviews.llvm.org/D67531
llvm-svn: 372735
Fixes PR38748
mergeSections() calls getOutputSectionName() to get output section
names. Two MergeInputSections may be merged even if they are made
different by SECTIONS commands.
This patch moves mergeSections() after processSectionCommands() and
addOrphanSections() to fix the issue. The new pass is renamed to
OutputSection::finalizeInputSections().
processSectionCommands() and addorphanSections() are changed to add
sections to InputSectionDescription::sectionBases.
finalizeInputSections() merges MergeInputSections and migrates
`sectionBases` to `sections`.
For the -r case, we drop an optimization that tries keeping sh_entsize
non-zero. This is for the simplicity of addOrphanSections(). The
updated merge-entsize2.s reflects the change.
Reviewed By: grimar
Differential Revision: https://reviews.llvm.org/D67504
llvm-svn: 372734
In case of linking binary blobs which do not have any ELF headers, we can
deduce MIPS ABI ELF header flags from an `emulation` option.
Patch by Kyle Evans.
llvm-svn: 372513
Summary:
If st_link(A)=B, and A has the SHF_LINK_ORDER flag, we may dereference
a null pointer if B is garbage collected (PR43147):
1. In Wrter.cpp:compareByFilePosition, `aOut->sectionIndex` or `bOut->sectionIndex`
2. In OutputSections::finalize, `d->getParent()->sectionIndex`
Simply error and bail out to avoid null pointer dereferences. ld.bfd has
a similar error:
sh_link of section `.bar' points to discarded section `.foo0' of `a.o'
ld.bfd is more permissive in that it just checks whether the linked-to
section of the first input section is discarded. This is likely because
it sets sh_link of the output section according to the first input
section.
Reviewed By: grimar
Differential Revision: https://reviews.llvm.org/D67761
llvm-svn: 372400
copy-rel-abs.s uses llvm-objdump to generate output that's then run
through FileCheck. llvm-objdump prints the file path at the top of the
file, which means that any build path that contains 'zed' will get
false-matched. Ensure that 'zed' is only matched after the 'SYMBOL
TABLE:' output, preventing this from failing if your build directory is
~/build/sanitized-xxx/, or similar.
llvm-svn: 372351
Summary:
This was always the intended behavior, but had not been
implemented. This ordering is important for Emscripten when generating
.mem files while compiling to JS, since only zeros at the end of
initialized memory can be dropped.
Fixes https://github.com/emscripten-core/emscripten/issues/8999
Reviewers: sbc100
Subscribers: dschuff, jgravelle-google, aheejin, sunfish, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D67736
llvm-svn: 372284
D67284 introduced ARMErrataFix.cpp which was derived from
AArch64ErrataFix.cpp. There were some useful refactoring changes made to
ARMErrataFix.cpp made as part of the review. This change applies the
relevant changes back to AArch64ErrataFix.cpp.
Main changes are:
- Old style variable names in comments like IS, are now new style isec.
- Simplify init() collection of mappingSymbols to always start with a code
mapping symbol.
- Simplify logic in mergeCmp().
- Fix one 80 column overflow caused by IS -> isec transformation.
Differential Revision: https://reviews.llvm.org/D67622
llvm-svn: 372094
Provide a missing initializer to get rid of warning provoking buildbot
failures.
error: missing field 'rel' initializer
[-Werror,-Wmissing-field-initializers]
llvm-svn: 371970
The --fix-cortex-a8 option implements a linker workaround for the
coretex-a8 erratum 657417. A summary of the erratum conditions is:
- A 32-bit Thumb-2 branch instruction B.w, Bcc.w, BL, BLX spans two
4KiB regions.
- The destination of the branch is to the first 4KiB region.
- The instruction before the branch is a 32-bit Thumb-2 non-branch
instruction.
The linker fix is to redirect the branch to a patch not in the first
4KiB region. The patch forwards the branch on to its target.
The cortex-a8, is an old CPU, with the first implementation of this
workaround in ld.bfd appearing in 2009. The cortex-a8 has been used in
early Android Phones and there are some critical applications that still
need to run on a cortex-a8 that have the erratum. The patch is applied
roughly 10 times on LLD and 20 on Clang when they are built with
--fix-cortex-a8 on an Arm system.
The formal erratum description is avaliable in the ARM Core Cortex-A8
(AT400/AT401) Errata Notice document. This is available from Arm on
request but it seems to be findable via a web search.
Differential Revision: https://reviews.llvm.org/D67284
llvm-svn: 371965
If there is no readonly section, we map:
* The ELF header at imageBase+maxPageSize
* Program headers at imageBase+maxPageSize+sizeof(Ehdr)
* The first section .text at imageBase+maxPageSize+sizeof(Ehdr)+sizeof(program headers)
Due to the interaction between Writer<ELFT>::fixSectionAlignments and
LinkerScript::allocateHeaders,
`alignDown(p_vaddr(R PT_LOAD)) = alignDown(p_vaddr(RX PT_LOAD))`.
The RX PT_LOAD will override the R PT_LOAD at runtime, which is not ideal:
```
// PHDR at 0x401034, should be 0x400034
PHDR 0x000034 0x00401034 0x00401034 0x000a0 0x000a0 R 0x4
// R PT_LOAD contains just Ehdr and program headers.
// At 0x401000, should be 0x400000
LOAD 0x000000 0x00401000 0x00401000 0x000d4 0x000d4 R 0x1000
LOAD 0x0000d4 0x004010d4 0x004010d4 0x00001 0x00001 R E 0x1000
```
* createPhdrs allocates the headers to the R PT_LOAD.
* fixSectionAlignments assigns `imageBase+maxPageSize+sizeof(Ehdr)+sizeof(program headers)` (formula: `alignTo(dot, maxPageSize) + dot % config->maxPageSize`) to addrExpr of .text
* allocateHeaders computes the minimum address among SHF_ALLOC sections, i.e. addr(.text)
* allocateHeaders sets address of ELF header to `addr(.text)-sizeof(Ehdr)-sizeof(program headers) = imageBase+maxPageSize`
The main observation is that when the SECTIONS command is not used, we
don't have to call allocateHeaders. This requires an assumption that
the presence of PT_PHDR and addresses of headers can be decided
regardless of address information.
This may seem natural because dot is not manipulated by a linker script.
The other thing is that we have to drop the special rule for -T<section>
in `getInitialDot`. If -Ttext is smaller than the image base, the headers
will not be allocated with the old behavior (allocateHeaders is called)
but always allocated with the new behavior.
The behavior change is not a problem. Whether and where headers are
allocated can vary among linkers, or ld.bfd across different versions
(--enable-separate-code or not). It is thus advised to use a linker
script with the PHDRS command to have a consistent behavior across
linkers. If PT_PHDR is needed, an explicit --image-base can be a simpler
alternative.
Differential Revision: https://reviews.llvm.org/D67325
llvm-svn: 371957
This is useful for enforcing that builds are independent of the
environment; it can be used when all system library paths are added
via /libpath: already. It's similar ot cl.exe's /X flag.
Since it should also affect %LINK% (the other caller of
`Process::GetEnv` in lld/COFF), the early-option-parsing needs
to move around a bit. The options are:
- Add a manual loop over the argv ArrayRef and look for "/lldignoreenv".
This repeats the name of the flag in both Options.td and in
DriverUtils.cpp.
- Add yet another table.ParseArgs() call just for /lldignoreenv before
adding %LINK%.
- Use the existing early ParseArgs() that's there for --rsp-quoting and use
it for /lldignoreenv for %LINK% as well. This means --rsp-quoting
and /lldignoreenv can't be passed via %LINK%.
I went with the third approach.
Differential Revision: https://reviews.llvm.org/D67456
llvm-svn: 371852
from thin archives.
Currently lld adds the archive name to MemoryBufferRef identifiers in order to
ensure they are unique. For thin archives, since the file name is already unique and we
want to keep the original path to the file, don't add the archive name.
Differential Revision: https://reviews.llvm.org/D67295
llvm-svn: 371778
ICF is performed after EhInputSections and MergeInputSections were
eliminated from inputSections. Every element of inputSections is an
InputSection.
llvm-svn: 371744
This makes lld-link behave like ld.lld. I don't see a reason for
the two drivers to have different behavior here.
While here, also make lld-link add a version.txt to the tar, like
ld.lld does.
Differential Revision: https://reviews.llvm.org/D67461
llvm-svn: 371729
-z undefs is the inverse of -z defs. It allows unresolved references
from object files. This can be used to cancel --no-undefined or -z defs.
Reviewed By: ruiu
Differential Revision: https://reviews.llvm.org/D67479
llvm-svn: 371715
Patch by Markus Böck.
PR42951: When linking an archive with members that have the same name linking
fails when using the -wholearchive option. This patch passes the index
of the member in the archive to the offset parameter to disambiguate the
member.
Differential Revision: https://reviews.llvm.org/D66239
llvm-svn: 371509
microMIPS jump and link exchange instruction stores a target in a
26-bits field. Despite other microMIPS JAL instructions these bits
are target address shifted right 2 bits [1]. The patch fixes the
JALX instruction decoding and uses 2-bit shift.
[1] MIPS Architecture for Programmers Volume II-B: The microMIPS32 Instruction Set
Differential Revision: https://reviews.llvm.org/D67320
llvm-svn: 371428
```
part.phdrs = script->hasPhdrsCommands() ? script->createPhdrs() : createPhdrs(part);
```
createPhdrs() allocates a PT_PHDR and a PF_R PT_LOAD, which will be
deleted later in LinkerScript::allocateHeaders, but leave a gap between
the program headers and the first section. Don't allocate the segments
to avoid the gap. PT_INTERP is likely not needed as well.
Reviewed By: ruiu
Differential Revision: https://reviews.llvm.org/D67324
llvm-svn: 371398
Add file-level comments
Replace trivial Input/*.s with echo ... | llvm-mc
Delete insignificant addresses to make them more tolerant to layout changes
Simplify test output
Merge merge-section-types.s into compatible-section-types.s and add a missed case
Merge gnu-ifunc-gotpcrel.s (added in D19517) into gnu-ifunc-dso.s (added in D35119) and add missed cases
Delete typed-undef.s - covered by executable-undefined-ignoreall.s
Delete emit-relocs-shared.s - covered by emit-relocs-merge.s
Replace copy-rel-pie.s and copy-rel-pie2.s with canonical-plt-pcrel.s, canonical-plt-symbolic.s and copy-rel.s:
add -no-pie cases.
add a case that a canonical PLT can be created for STT_GNU_IFUNC. The logic in Symbols.h was untested:
// ctor of SharedSymbol
if (this->type == llvm::ELF::STT_GNU_IFUNC)
this->type = llvm::ELF::STT_FUNC;
llvm-svn: 371361
Fangrui Song