Initially LLD generates Elf_Rel relocations for O32 ABI and Elf_Rela
relocations for N32 / N64 ABIs. In other words, format of input and
output relocations was always the same. Now LLD generates all output
relocations using Elf_Rel format only. It conforms to ABIs requirement.
The patch suggested by Alexander Richardson.
llvm-svn: 324064
--nopie was a typo. GNU gold doesn't recognize it. It is also
inconsistent with other options that have --foo and --no-foo.
Differential Revision: https://reviews.llvm.org/D42825
llvm-svn: 324043
In GNU linkers, the last semicolon is optional. We can't link libstdc++
with lld because of that difference.
Differential Revision: https://reviews.llvm.org/D42820
llvm-svn: 324036
Currently ICF information is output through stderr if the "--verbose"
flag is used. This differs to Gold for example, which uses an explicit
flag to output this to stdout. This commit adds the
"--print-icf-sections" and "--no-print-icf-sections" flags and changes
the output message format for clarity and consistency with
"--print-gc-sections". These messages are still output to stderr if
using the verbose flag. However to avoid intermingled message output to
console, this will not occur when the "--print-icf-sections" flag is
used.
Existing tests have been modified to expect the new message format from
stderr.
Patch by Owen Reynolds.
Differential Revision: https://reviews.llvm.org/D42375
Reviewers: ruiu, rafael
Reviewed by:
llvm-svn: 323976
Don't include type signatures that are not referenced by
some relocation.
We don't include this in the -gc-sections settings since
we are always building the type section from scratch,
just like we do the table elements.
In the future we might want to unify the relocation
processing which is currently done once for gc-sections
and then again for building the sympathetic type and
table sections.
Differential Revision: https://reviews.llvm.org/D42747
llvm-svn: 323931
Summary:
r323164 made lld-link not overwrite import libraries when their
contents haven't changed. MSVC's link.exe does this only when
performing incremental linking. This change makes lld-link's import
library overwriting similarly dependent on whether or not incremental
linking is being performed. This is controlled by the /incremental or
/incremental:no options. In addition, /opt:icf, /opt:ref, and /order
turn off /incremental and issue a warning if /incremental was
specified on the command line.
Reviewers: rnk, ruiu, zturner
Reviewed By: ruiu
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D42716
llvm-svn: 323930
Summary: Instead of fatal-ing out when missing a type server PDB, insead warn and cache the miss.
Reviewers: rnk, zturner
Reviewed By: rnk
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D42188
llvm-svn: 323893
Summary:
While trying to make a linker script behave the same way with lld as it did
with bfd, I discovered that lld currently doesn't diagnose overlapping
output sections. I was getting very strange runtime failures which I
tracked down to overlapping sections in the resulting binary. When linking
with ld.bfd overlapping output sections are an error unless
--noinhibit-exec is passed and I believe lld should behave the same way
here to avoid surprising crashes at runtime.
The patch also uncovered an errors in the tests: arm-thumb-interwork-thunk
was creating a binary where .got.plt was placed at an address overlapping
with .got.
Reviewers: ruiu, grimar, rafael
Reviewed By: ruiu
Differential Revision: https://reviews.llvm.org/D41046
llvm-svn: 323856
When there is a duplicate absolute symbol, LLD reports <internal>
instead of known object file name currently.
Patch fixes the issue.
Differential revision: https://reviews.llvm.org/D42636
llvm-svn: 323849
In this initial version we only GC symbols with `hidden` visibility since
other symbols we export to the embedder.
We could potentially modify this the future and only use symbols
explicitly passed via `--export` as GC roots.
This version of the code only does GC of data and code. GC for the
types section is coming soon.
Differential Revision: https://reviews.llvm.org/D42511
llvm-svn: 323842
Add a simple start entry point input file and have the tests
reference that rather than duplicating these.
This allows more tests to be pure `.test` files rather than
`.ll`.
Differential Revision: https://reviews.llvm.org/D42662
llvm-svn: 323838
Previously an empty CPU string was passed to the LTO engine which
resulted in a generic CPU for which certain features like NOPL were
disabled. This fixes that.
Patch by Pratik Bhatu!
llvm-svn: 323801
Currently symbols assigned or created by linkerscript are not processed early
enough. As a result it is not possible to version them or assign any other flags/properties.
Patch creates Defined symbols for -defsym and linkerscript symbols early,
so that issue from above can be addressed.
It is based on Rafael Espindola's version of D38239 patch.
Fixes PR34121.
Differential revision: https://reviews.llvm.org/D41987
llvm-svn: 323729
I didn't implement the feature in the original patch because I didn't
come up with an idea to do that easily and efficiently. Turned out that
that is actually easy to implement.
In this patch, we collect comdat sections before gc is run and warn on
nonexistent symbols in an order file.
Differential Revision: https://reviews.llvm.org/D42658
llvm-svn: 323699
This should fix PR36017.
The root problem is that we were creating a PT_LOAD just for the
header. That was technically valid, but inconvenient: we should not be
making the ELF discontinuous.
The solution is to allow a section with LMAExpr to be added to a
PT_LOAD if that PT_LOAD doesn't already have a LMAExpr.
llvm-svn: 323625
Patch adds one more module with non-prevailing
version of asm symbol, defined in main module
This is for D42107, which is under review.
Extended version of testcase would fail with the
diff 9 version of patch posted.
llvm-svn: 323584
With the /order option, you can give an order file. An order file
contains symbol names, one per line, and the linker places comdat
sections in that given order. The option is used often to optimize
an output binary for (in particular, startup) speed by improving
locality.
Differential Revision: https://reviews.llvm.org/D42598
llvm-svn: 323579
This fixes the crash reported at PR36083.
The issue is that we were trying to put all the sections in the same
PT_LOAD and crashing trying to write past the end of the file.
This also adds accounting for used space in LMARegion, without it all
3 PT_LOADs would have the same physical address.
llvm-svn: 323449
Previously, we were ensuring that the "output index" for
InputFunctions was unique across all symbols that referenced
a function body, but allowing the same function body to have
multiple table indexes.
Now, we use the same mechanism for table indexes as we already
do for output indexes, ensuring that each InputFunction is only
placed in the table once.
This makes the LLD output table denser and smaller, but should
not change the behaviour.
Note that we still need the `Symbol::TableIndex` member, to
store the table index for function Symbols that don't have an
InputFunction, i.e. for address-taken imports.
Patch by Nicholas Wilson!
Differential Revision: https://reviews.llvm.org/D42476
llvm-svn: 323379
Previously llvm was using 0 as the first table index for wasm object
files but now that has switched to 1 we can have the output of lld
do the same and simplify the code.
Patch by Nicholas Wilson!
Differential Revision: https://reviews.llvm.org/D42096
llvm-svn: 323378
Since SyntheticSection::getParent() may return null, dereferencing
this pointer in ARMExidxSentinelSection::empty() call from
removeUnusedSyntheticSections() results in crashes when linking ARM
binaries.
Patch by vit9696!
llvm-svn: 323366
This is somewhat preferable since (in many cases) it allows llc
to be run directly on the .ll files without having to pass the
`-mtriple` argument.
Differential Revision: https://reviews.llvm.org/D42438
llvm-svn: 323299
There seems to be an bug related to table relocations not being
written correctly in this case. This change is intended simply
to increase the coverage, not fix the issue.
llvm-svn: 323282
TABLE relocations now store the function that is being refered
to indirectly.
See rL323165.
Also extend the call-indirect.ll a little.
Based on a patch by Nicholas Wilson!
llvm-svn: 323168
Summary:
This detects when an import library is about to be overwritten with a
newly built one with the same contents, and keeps the old library
instead. The use case for this is to avoid needlessly rebuilding
targets that depend on the import library in build systems that rely
on timestamps to determine whether a target requires rebuilding.
This feature was requested in PR35917.
Reviewers: rnk, ruiu, zturner, pcc
Reviewed By: ruiu
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D42326
llvm-svn: 323164
Summary:
First, we need to explain the core of the vulnerability. Note that this
is a very incomplete description, please see the Project Zero blog post
for details:
https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html
The basis for branch target injection is to direct speculative execution
of the processor to some "gadget" of executable code by poisoning the
prediction of indirect branches with the address of that gadget. The
gadget in turn contains an operation that provides a side channel for
reading data. Most commonly, this will look like a load of secret data
followed by a branch on the loaded value and then a load of some
predictable cache line. The attacker then uses timing of the processors
cache to determine which direction the branch took *in the speculative
execution*, and in turn what one bit of the loaded value was. Due to the
nature of these timing side channels and the branch predictor on Intel
processors, this allows an attacker to leak data only accessible to
a privileged domain (like the kernel) back into an unprivileged domain.
The goal is simple: avoid generating code which contains an indirect
branch that could have its prediction poisoned by an attacker. In many
cases, the compiler can simply use directed conditional branches and
a small search tree. LLVM already has support for lowering switches in
this way and the first step of this patch is to disable jump-table
lowering of switches and introduce a pass to rewrite explicit indirectbr
sequences into a switch over integers.
However, there is no fully general alternative to indirect calls. We
introduce a new construct we call a "retpoline" to implement indirect
calls in a non-speculatable way. It can be thought of loosely as
a trampoline for indirect calls which uses the RET instruction on x86.
Further, we arrange for a specific call->ret sequence which ensures the
processor predicts the return to go to a controlled, known location. The
retpoline then "smashes" the return address pushed onto the stack by the
call with the desired target of the original indirect call. The result
is a predicted return to the next instruction after a call (which can be
used to trap speculative execution within an infinite loop) and an
actual indirect branch to an arbitrary address.
On 64-bit x86 ABIs, this is especially easily done in the compiler by
using a guaranteed scratch register to pass the target into this device.
For 32-bit ABIs there isn't a guaranteed scratch register and so several
different retpoline variants are introduced to use a scratch register if
one is available in the calling convention and to otherwise use direct
stack push/pop sequences to pass the target address.
This "retpoline" mitigation is fully described in the following blog
post: https://support.google.com/faqs/answer/7625886
We also support a target feature that disables emission of the retpoline
thunk by the compiler to allow for custom thunks if users want them.
These are particularly useful in environments like kernels that
routinely do hot-patching on boot and want to hot-patch their thunk to
different code sequences. They can write this custom thunk and use
`-mretpoline-external-thunk` *in addition* to `-mretpoline`. In this
case, on x86-64 thu thunk names must be:
```
__llvm_external_retpoline_r11
```
or on 32-bit:
```
__llvm_external_retpoline_eax
__llvm_external_retpoline_ecx
__llvm_external_retpoline_edx
__llvm_external_retpoline_push
```
And the target of the retpoline is passed in the named register, or in
the case of the `push` suffix on the top of the stack via a `pushl`
instruction.
There is one other important source of indirect branches in x86 ELF
binaries: the PLT. These patches also include support for LLD to
generate PLT entries that perform a retpoline-style indirection.
The only other indirect branches remaining that we are aware of are from
precompiled runtimes (such as crt0.o and similar). The ones we have
found are not really attackable, and so we have not focused on them
here, but eventually these runtimes should also be replicated for
retpoline-ed configurations for completeness.
For kernels or other freestanding or fully static executables, the
compiler switch `-mretpoline` is sufficient to fully mitigate this
particular attack. For dynamic executables, you must compile *all*
libraries with `-mretpoline` and additionally link the dynamic
executable and all shared libraries with LLD and pass `-z retpolineplt`
(or use similar functionality from some other linker). We strongly
recommend also using `-z now` as non-lazy binding allows the
retpoline-mitigated PLT to be substantially smaller.
When manually apply similar transformations to `-mretpoline` to the
Linux kernel we observed very small performance hits to applications
running typical workloads, and relatively minor hits (approximately 2%)
even for extremely syscall-heavy applications. This is largely due to
the small number of indirect branches that occur in performance
sensitive paths of the kernel.
When using these patches on statically linked applications, especially
C++ applications, you should expect to see a much more dramatic
performance hit. For microbenchmarks that are switch, indirect-, or
virtual-call heavy we have seen overheads ranging from 10% to 50%.
However, real-world workloads exhibit substantially lower performance
impact. Notably, techniques such as PGO and ThinLTO dramatically reduce
the impact of hot indirect calls (by speculatively promoting them to
direct calls) and allow optimized search trees to be used to lower
switches. If you need to deploy these techniques in C++ applications, we
*strongly* recommend that you ensure all hot call targets are statically
linked (avoiding PLT indirection) and use both PGO and ThinLTO. Well
tuned servers using all of these techniques saw 5% - 10% overhead from
the use of retpoline.
We will add detailed documentation covering these components in
subsequent patches, but wanted to make the core functionality available
as soon as possible. Happy for more code review, but we'd really like to
get these patches landed and backported ASAP for obvious reasons. We're
planning to backport this to both 6.0 and 5.0 release streams and get
a 5.0 release with just this cherry picked ASAP for distros and vendors.
This patch is the work of a number of people over the past month: Eric, Reid,
Rui, and myself. I'm mailing it out as a single commit due to the time
sensitive nature of landing this and the need to backport it. Huge thanks to
everyone who helped out here, and everyone at Intel who helped out in
discussions about how to craft this. Also, credit goes to Paul Turner (at
Google, but not an LLVM contributor) for much of the underlying retpoline
design.
Reviewers: echristo, rnk, ruiu, craig.topper, DavidKreitzer
Subscribers: sanjoy, emaste, mcrosier, mgorny, mehdi_amini, hiraditya, llvm-commits
Differential Revision: https://reviews.llvm.org/D41723
llvm-svn: 323155
This was added to mimic ELF, but maintaining it has cost
and we currently don't have any use for it outside of the
test code.
Differential Revision: https://reviews.llvm.org/D42324
llvm-svn: 323154
It is possible for a link to fail with an undefined reference, unless
--gc-sections is specified, removing the reference in the process. This
doesn't look to be tested anywhere explicitly, so I thought it useful
to add a test for it to ensure the behaviour is maintained.
Reviewers: ruiu
Differential Revision: https://reviews.llvm.org/D42299
llvm-svn: 323099
Its much easier to export it via setHidden(false), now that
that is a thing.
As a side effect the start function is not longer always exports first
(becuase its being exported just like all the other function).
Differential Revision: https://reviews.llvm.org/D42321
llvm-svn: 323025
Rui Ueyama