Add a new file AArch64ErrataFix.cpp that implements the logic to scan for
the Cortex-A53 Erratum 843419. This involves finding all the executable
code, disassembling the instructions that might trigger the erratum and
reporting a message if the sequence is detected.
At this stage we do not attempt to fix the erratum, this functionality
will be added in a later patch. See D36749 for proposal.
Differential Revision: https://reviews.llvm.org/D36742
llvm-svn: 319780
With fix:
Specify -soname for input dso to fix up the .dynstr section
size in different environments.
Original commit message:
As mentioned in PR35471, copied symbols did not show
in --Map output. Patch fixes that.
Differential revision: https://reviews.llvm.org/D40785
llvm-svn: 319769
When a linker script is used with a pattern like { *(.bss .bss.*) } the
InX::BssRelRo section will match against .bss.*. By matching on the name
only, in the same way that .data.rel.ro works we prevent this
from happening, but permit scripts that want to explicitly provide
a .bss.rel.ro OutputSection.
Differential Revision: https://reviews.llvm.org/D40735
llvm-svn: 319755
As mentioned in PR35471, copied symbols did not show
in --Map output. Patch fixes that.
Differential revision: https://reviews.llvm.org/D40785
llvm-svn: 319747
Previously, lld exited with an error status if the only option given to
the command was -v. GNU linkers gracefully exit in that case. This patch
makes lld behave like GNU.
Note that even with this patch, lld's -v and --version options behave
slightly differently than GNU linkers' counterparts. For example,
if you run `ld.bfd -v -v`, the version string is printed out twice.
But that is an edge case that I don't think we need to take care of.
Fixes https://bugs.llvm.org/show_bug.cgi?id=31582
Differential Revision: https://reviews.llvm.org/D40810
llvm-svn: 319717
This change actually makes the linker slightly faster. My observation
is that, with this patch, link time of clang without debug is about 1%
faster.
Differential Revision: https://reviews.llvm.org/D40697
llvm-svn: 319600
PR35478 https://bugs.llvm.org/show_bug.cgi?id=35478 points out a flaw
in the implementation of r318924 from D40364. The implementation
depends on the Size field being set or the SyntheticSection::empty()
being accurate. These functions are not reliable as some linker script
commands that have yet to be processed may affect the results, causing
some non-zero size sections to be reported as zero size.
I think the first step is to revert r318924 and come up with a better
solution for the underlying problem rather than trying to layer more
heuristics onto the zero sized output section.
Chances are I'll be out of office by the time anyone sees this so feel
free to commit the revert if you agree with me.
Fixes PR35478
Current thoughts on the underlying problem:
Revisiting the motivation for adding the zero size check in the first
place; it was to prevent 0 sized SyntheticSections that a user does
not have full control over from needlessly breaking the PT_GNU_RELRO,
rather than trying to accommodate arbitrarily complex linker
scripts. Looking at the code, it looks like
removeUnusedSyntheticSections() should remove zero sized synthetic
sections. It does, but it doesn't set the Parent to nullptr, this has
the side effect that Sec == InX::BssRelRo->getParent() will make the
parent OutputSection of InX::BssRelRo RelRo even if there is no
InX::BssRelRo.
I tried a quick experiment with setting the Parent to nullptr and this
flushed out a few interesting test failures, it feels like playing
Jenga with every change:
In the isRelroSection() we have to consider the case where there
is no .plt and .plt.got but there is a ifunc plt with accompanying
(ifunc .got or .plt.got)
The PPC64 has PltHeaderSize == 0. Unfortunately HeaderSize == 0 is
used to choose between the ifunc plt or normal plt. We seem to get
away with this at the moment, but tests start to fail when Parent
is set to nullptr for the .got.plt.
The InX::BssRelRo and InX::Bss never get their sizes set and they
are always removed by removeUnusedSyntheticSections(), their
purpose seems to be as some kind of proxy for add .bss or
.bss.relro InputSections into their parent OutputSections, they
therefore don't behave like other SyntheticSections anyway.
My thinking is that some work is needed to make sure that the Sec ==
SyntheticSection->getParent() does a bit more checking before
returning true, particularly for InX::BssRelRo as that has special
behaviour. I'll hope to post something for review as soon as possible.
Patch by Peter Smith!
llvm-svn: 319563
This is for "Bug 35474 - --emit-relocs produces wrongly-named reloc sections".
LLD currently for scripts like:
.text.boot : { *(.text.boot) }
emits relocation section with name .rela.text because does not take
redefined name of output section into account and builds section name
using rules for non-scripted case. Patch fixes this oddness.
Differential revision: https://reviews.llvm.org/D40652
llvm-svn: 319526
The ELF spec says
Symbols with section index SHN_COMMON may appear only in relocatable
objects.
Currently lld can produce file that break that requirement.
llvm-svn: 319473
When a linker script has "foo = bar" and bar is the result of a copy
relocation foo should point to the same location in .bss.
This is part of a growing evidence that copy relocations should be
implemented by using replaceSymbol to replace the SharedSymbol with a
Defined.
llvm-svn: 319449
Since MarkLive.cpp is the place where we set Live flags for
other sections, it looks correct to do that there.
Benefit is that we stop spreading GC logic outsize of MarkLive.cpp.
Differential revision: https://reviews.llvm.org/D40454
llvm-svn: 319435
The AArch64 unconditional branch and branch and link instructions have a
maximum range of 128 Mib. This is usually enough for most programs but
there are cases when it isn't enough. This change adds support for range
extension thunks to AArch64. For pc-relative thunks we follow the small
code model and use ADRP, ADD, BR. This has a limit of 4 gigabytes.
Differential Revision: https://reviews.llvm.org/D39744
llvm-svn: 319307
The SHT_ARM_ATTRIBUTES section type is in the processor specific space
adding guard to make sure that it is only recognized when EMachine is
EM_ARM.
llvm-svn: 319304
This includes a fix to mark copy reloc aliases as used.
Original message:
[ELF] Do not keep symbols if they referenced only from discarded sections.
This patch also ensures that in case of "--as-needed" is used,
DT_NEEDED entries are not created if they are required only by
these eliminated symbols.
llvm-svn: 319215
lld assumes some ARM features that are not available in all Arm
processors. In particular:
- The blx instruction present for interworking.
- The movt/movw instructions are used in Thunks.
- The J1=1 J2=1 encoding of branch immediates to improve Thumb wide
branch range are assumed to be present.
This patch reads the ARM Attributes section to check for the
architecture the object file was compiled with. If none of the objects
have an architecture that supports either of these features a warning
will be given. This is most likely to affect armv6 as used in the first
Raspberry Pi.
Differential Revision: https://reviews.llvm.org/D36823
llvm-svn: 319169
Currently we mark every shared symbol as STB_WEAK.
That is a hack to make it easy to decide when a .so is needed or not
because of a reference to a given symbol.
That hack leaks when we create copy relocations as shown by the update
to relocation-copy-alias.s.
This patch stores the original binding when we first read a shared
symbol. We still have to update the binding to weak if we see a weak
undef, but I find the logic easier to read where it is now.
llvm-svn: 319127
When an undefined weak reference has a PLT entry we must generate a range
extension thunk for any B or BL that can't reach the PLT entry.
This change explicitly looks for whether a PLT entry exists rather than
assuming that weak references never need PLT entries unless Config->Shared
is in operation. This covers the case where we are linking an executable
with dynamic linking, hence a PLT entry will be needed for undefined weak
references. This case comes up in real programs over 32 Mb in size as there
is a B to a weak reference __gmon__start__ in the Arm crti.o for glibc.
Differential Revision: https://reviews.llvm.org/D40248
llvm-svn: 319020
This patch also ensures that in case of "--as-needed" is used,
DT_NEEDED entries are not created if they are required only by
these eliminated symbols.
Differential Revision: https://reviews.llvm.org/D38790
llvm-svn: 319008
LLD uses .bss.rel.ro for read-only copy relocations whereas the ld.bfd and
gold linkers use .data.rel.ro. In some linker scripts including ld.bfd's
internal linker script, the relro sections are placed sequentially assuming
.data.rel.ro is used. LLD's use of .bss.rel.ro means that the copy
relocations get matched into the .bss section causing the relro sections to
be non-contiguous.
This change checks for a .data.rel.ro OutputSection when a linker script
with the SECTIONS command is used. The section will match in the
.data.rel.ro output section and will maintain contiguous relro.
Differential Revision: https://reviews.llvm.org/D40365
Fixes PR35265
llvm-svn: 318940
When checking for contiguous relro sections we can skip over empty sections.
If there is an empty non-relro section in the middle of a contiguous block
of relro sections then it cannot be written to so it is safe to include in
PT_GNU_RELRO header. If there is a contiguous block of empty relro sections
then no PT_GNU_RELRO header is required for them.
Differential Revision: https://reviews.llvm.org/D40364
llvm-svn: 318924
If a linker script is used that names linker generated synthetic sections
it is possible that the OutputSections for which isRelroSection() is true
are not contiguous. When the relro sections are not contiguous we cannot
describe them with a single PT_GNU_RELRO PHDR. Unfortunately at least one
contemporary dynamic loader only supports one PT_GNU_RELRO PHDR so we
cannot output more than one of these PHDRs. As not including relro
sections in the PHDR will lead to security sensitive sections being
writeable we choose to give an error message instead.
Differential Revision: https://reviews.llvm.org/D40359
[ELF] Skip over empty sections when checking for contiguous relro
llvm-svn: 318920
The MIPS GOT section has a number of local entries based on the number of pages
needed for output sections referenced by GOT page relocations. The number is
recorded in the DT_MIPS_LOCAL_GOTNO dynamic section tag. However, the dynamic tag
is added before assignAddresses has been called, meaning that any section size used
to calculate the value will not include size modifications caused by, for example,
linker scripts and thunks.
This change moves the calculation of DT_MIPS_LOCAL_GOTNO until writeTo, by which
time the output section sizes have been finalized.
Reviewers: ruiu, rafael
Differential Revision: https://reviews.llvm.org/D39493
llvm-svn: 318828
Summary:
I noticed that the reproducers files I was getting from building CheriBSD
didn't work because the --sysroot option was not being rewritten. I've
updated the test to also verify that the rewritten path matches uses a
FileCheck capature instead of a {{.+}} regex
Reviewers: ruiu
Reviewed By: ruiu
Subscribers: llvm-commits, emaste
Differential Revision: https://reviews.llvm.org/D40125
llvm-svn: 318656
Summary:
This matches the behaviour of ld.bfd:
https://sourceware.org/binutils/docs/ld/Options.html#Options
If scriptfile does not exist in the current directory, ld looks for it in
the directories specified by any preceding '-L' options. Multiple '-T'
options accumulate.
Reviewers: ruiu, grimar
Reviewed By: ruiu, grimar
Subscribers: emaste, llvm-commits
Differential Revision: https://reviews.llvm.org/D40129
llvm-svn: 318655
Summary:
The bug triggers when the following conditions are met:
- A thunk is created in a given input section S
- A linker script is specified
- There is at least one matcher in the linker script .text section output
that does not match any of the sections in the input files, before the matcher
that matches section S.
The issue was found when linking the FreeBSD kernel for MIPS when built
with -fPIC. Patch by Alfredo Mazzinghi.
Reviewers: ruiu, psmith, atanasyan
Reviewed By: ruiu
Subscribers: peter.smith, emaste, sdardis, krytarowski, llvm-commits
Differential Revision: https://reviews.llvm.org/D40174
llvm-svn: 318653
It is private to llvm. Instead use llvm/Config/llvm-config.h and check
LLVM_ON_UNIX. That is the same guard that clang uses before including
unistd.h.
llvm-svn: 318558
Recently we teached LLD to report line numbers for duplicate variables
definitions, though currently LLD is unable to do that for case when
strings are not built in .debug_info, but stored in .debug_str instead.
That is because out LLDDwarfObj does not handle .debug_str yet.
Patch fixes that.
Differential revision: https://reviews.llvm.org/D39542
llvm-svn: 318519
This fixes PR35223.
Here I enabled SHF_MERGE section content merging for -r like
we do for regular linking.
Differential revision: https://reviews.llvm.org/D40026
llvm-svn: 318516
Previously our relocations we rewrote were broken for that case.
We emited incorrect addend and broken relocation info field
because did not produce section symbol for mergeable synthetic sections.
Differential revision: https://reviews.llvm.org/D40070
llvm-svn: 318394
An output section can include elements from two input sections with
different sh_entsize. When that happens the output section itself
should not have a sh_entsize.
llvm-svn: 318311
No difference in practice other than having sh_entsize in the output.
This should simplify the patch for handling SHF_MERGE in -r.
Based on a patch by George Rimar.
llvm-svn: 318306
microMIPS symbols including microMIPS PLT records created for regular
symbols needs to be marked by STO_MIPS_MICROMIPS flag in a symbol table.
Additionally microMIPS entries in a dynamic symbol table should have
configured less-significant bit. That allows to escape teaching a
dynamic linker about microMIPS symbols.
llvm-svn: 318097
It is really hard to cover restarts in a debugger, SIGKILL or power
failures. I will try to handle them in a followup patch, but it will
not support all the systems lld has to run on.
RemoveFileOnSignal takes care of crashes.
So what is left is making sure all regular exits delete the file. This
patch does that by moving the buffer to error handling. That is a bit
of a hack, but seemed better than to generalize it to take a callback on
construction.
I will implement this on COFF on the next patch.
llvm-svn: 318060
I think the constract of this function is to remove a file in some way,
whether in background or in foreground. This patch makes sure that it
removes a given file.
Differential Revision: https://reviews.llvm.org/D39778
llvm-svn: 317663
It used to rename the file before removing it in a background thread.
A simpler way to delay the removal is simply to open the file.
Since this is a posix specific issue, simplify the windows
implementation.
llvm-svn: 317631
This function is always called with Config->OutputFile. That is not
obvious from reading the function. It should always use Path or take
no argument and always use Config->OutputFile.
llvm-svn: 317536
We have a lot of "if (MIPS)" conditions in lld because the MIPS' ABI
is different at various places than other arch's ABIs at where it
don't have to be different, but we at least want to reduce MIPS-ness
from the regular classes.
llvm-svn: 317525
The ISR in the comment should read ISD for InputSectionDescription. The use
of ISR (InputSectionRange) was from the original implementation that did not
use the sections from InputSectionDescription directly.
llvm-svn: 317469
The Traced flag is unnecessary because we only need to set the index
to -1 to mark a symbol for tracing.
Differential Revision: https://reviews.llvm.org/D39672
llvm-svn: 317450
Now that DefinedRegular is the only remaining derived class of
Defined, we can merge the two classes.
Differential Revision: https://reviews.llvm.org/D39667
llvm-svn: 317448
Common symbols are now represented with a DefinedRegular that points
to a BssSection, even during symbol resolution.
Differential Revision: https://reviews.llvm.org/D39666
llvm-svn: 317447
I don't remember why I made shared symbols one type of defined symbols.
Shared symbols aren't undefined, so it could be considered defined, but
categorizing three symbols as:
- defined
- really defined
- shared
- undefined
is not as intuitive as
- defined
- shared
- undefined
to me. So, in this patch, I made a change to stop handling shared
symbols as defined symbols.
Surprisingly, I didn't have to update any tests for this change.
Differential Revision: https://reviews.llvm.org/D39394
llvm-svn: 317446
That class is used only by LinkerScript.cpp, so we should move it to
that file. Also, it no longer has to be a "factory" class. It can just
be a non-member function.
llvm-svn: 317427
r317396 changed the way how we handle the -defsym option. The option is
now handled using the infrastructure for the linker script.
We used to handle both -defsym and -wrap using the same set of functions
in the symbol table. Now, we don't need to do that.
This patch rewrites the functions so that they become more straightforward.
The new functions directly handle -wrap rather than abstract it.
llvm-svn: 317426
Stop using SectionKey for creating output sections.
Initially SectionKey was designed because we merged section with
use of Flags and Alignment fields. Currently LLD merges them by name only,
except the case when -relocatable output is produced. In that case
we still merge sections only with the same flags and alignment.
There is probably no issue at all to stop using Flags and Alignment for -r and
just disable the merging in that case.
After doing that change we can get rid of using SectionKey. That is not only
simplifies the code, but also gives some perfomance boost.
I tried to link chrome and mozilla, results are next:
* chrome link time goes from 1,666750355s to 1,551585364s, that is about 7%.
* mozilla time changes from 3,210261947 to 3,153782940, or about 2%.
Differential revision: https://reviews.llvm.org/D39594
llvm-svn: 317406
Currently LLD tries to use information about functions and variables location
taking it from debug sections. When --strip-* is given we discard such sections
and that breaks error reporting.
Patch stops discarding such sections and just removes them from InputSections list.
Differential revision: https://reviews.llvm.org/D39550
llvm-svn: 317405
Now that we have only SymbolBody as the symbol class. So, "SymbolBody"
is a bit strange name now. This is a mechanical change generated by
perl -i -pe s/SymbolBody/Symbol/g $(git grep -l SymbolBody lld/ELF lld/COFF)
nd clang-format-diff.
Differential Revision: https://reviews.llvm.org/D39459
llvm-svn: 317370
Not sure why that seems did not break any llvm bots or
my windows local build, but is was required to fix compilation
breakage of my ubuntu build when using
gcc version 8.0.0 20171019 (experimental)
llvm-svn: 317317
When findMemoryRegion do search to find a region for output section it
iterates over MemoryRegions which is DenseMap and so does not
guarantee iteration in insertion order. As a result selected region depends
on its name and not on its definition position
Testcase shows the issue, patch fixes it. Behavior after applying the patch
seems consistent with bfd.
Differential revision: https://reviews.llvm.org/D39544
llvm-svn: 317307
Currently we do not strip .zdebug_*, what looks wrong.
Also this simplifies the testcase we have for this options.
Differential revision: https://reviews.llvm.org/D39552
llvm-svn: 317306
Recently we teached LLD to report line numbers for duplicate variables
definitions, though currently LLD is unable to do that for case when
strings are not built in .debug_info, but stored in .debug_str instead.
That is because out LLDDwarfObj does not handle .debug_str yet.
Patch fixes that.
Differential revision: https://reviews.llvm.org/D39542
llvm-svn: 317305
The way we handle ONLY_IF_RO/ONLY_IF_RW constraints in
processSectionCommands is a bit tricky. If input sections
does no satisfy given constraint we remove command from
commands list. It seems too complex, what we can do instead
is to make the OutputCommand empty. So that at later steps
LLD will remove it just like it deal with other empty output commands.
That allows to simplify the loop a bit.
Differential revision: https://reviews.llvm.org/D39094
llvm-svn: 317082
This is PR34826.
Currently LLD is unable to report line number when reporting
duplicate declaration of some variable.
That happens because for extracting line information we always use
.debug_line section content which describes mapping from machine
instructions to source file locations, what does not help for
variables as does not describe them.
In this patch I am taking the approproate information about
variables locations from the .debug_info section.
Differential revision: https://reviews.llvm.org/D38721
llvm-svn: 317080
StringTableSection does not implement postThunkContents, so calling it on these
sections is pointless (it calls an empty virtual function), and we can remove it.
Reviewers: ruiu
Differential Revision: https://reviews.llvm.org/D39460
llvm-svn: 317014
SymbolBody and Symbol were separated classes due to a historical reason.
Symbol used to be a pointer to a SymbolBody, and the relationship
between Symbol and SymbolBody was n:1.
r2681780 changed that. Since that patch, SymbolBody and Symbol are
allocated next to each other to improve memory locality, and they have
1:1 relationship now. So, the separation of Symbol and SymbolBody no
longer makes sense.
This patch merges them into one class. In order to avoid updating too
many places, I chose SymbolBody as a unified name. I'll rename it Symbol
in a follow-up patch.
Differential Revision: https://reviews.llvm.org/D39406
llvm-svn: 317006
Summary:
**Problem**
`--exclude-libs` does not work for static libraries affected by the `--whole-archive` option.
**Description**
`--exclude-libs` creates a list of static library paths and does library lookups in this list.
`--whole-archive` splits the static libraries that follow it into separate objects. As a result, lld no longer sees static libraries among linked files and does no `--exclude-libs` lookups.
**Solution**
The proposed solution is to make `--exclude-libs` consider object files too. When lld finds an object file it checks whether this file originates from an archive and, if so, looks the archive up in the `--exclude-libs` list.
Reviewers: ruiu, rafael
Reviewed By: ruiu
Subscribers: asl, ikudrin, llvm-commits, emaste
Tags: #lld
Differential Revision: https://reviews.llvm.org/D39353
llvm-svn: 316998
When there is no SECTION commands given, all sections are
technically orphans, but now we handle script orphans sections
and regular "orphans" sections for non-scripted case differently,
though we can handle them at one place.
Patch do that change.
Differential revision: https://reviews.llvm.org/D39045
llvm-svn: 316984
It does not seem that createSections() is a good place for
applying sorting. Patch changes code to do that inside
sortSections(), which looks more appropriate place.
Differential revision: https://reviews.llvm.org/D39371
llvm-svn: 316893
This bit is to manage whether an input section has already been assigned
to some output section by linker scripts or not. So it logically belongs
to InputSectionBase. SectionBase is a common base class for input and
output sections, so that wasn't the right place to define the bit.
llvm-svn: 316879
edata needs to be set to the end of the last mapped initialized
section. We were previously mishandling the case where there were no
non-mapped sections by setting it to the end of the last section in
the output file.
Differential Revision: https://reviews.llvm.org/D39399
llvm-svn: 316877
Because of r314495 which converts DefinedCommon symbols to DefinedRegular
symbols, common symbols are no longer reachable to the MapFile writer.
So the code to handle common symbols is now dead.
llvm-svn: 316846
I don't think we have to aim for precise bug compatibility.
We can return a nullptr if a section is consumed by the linker, and
the rest should naturally work.
llvm-svn: 316817
DSO is short for dynamic shared object, so the function name was a
little confusing because it sounded like it didn't work when we were
a creating statically-linked executable or something.
What we mean by "DSO" here is the current output file that we are
creating. Thus the new name. Alternatively, we could call it the current
ELF module, but "module" is a overloaded word, so I avoided that.
llvm-svn: 316809
The Android relocation packing format is a more compact
format for dynamic relocations in executables and DSOs
that is based on delta encoding and SLEBs. An overview
of the format can be found in the Android source code:
https://android.googlesource.com/platform/bionic/+/refs/heads/master/tools/relocation_packer/src/delta_encoder.h
This patch implements relocation packing using that format.
This implementation uses a more intelligent algorithm for compressing
relative relocations than Android's own relocation packer. As a
result it can generally create smaller relocation sections than
that packer. If I link Chromium for Android targeting ARM32 I get a
.rel.dyn of size 174693 bytes, as compared to 371832 bytes with gold
and the Android packer.
Differential Revision: https://reviews.llvm.org/D39152
llvm-svn: 316775
This is for PR34852.
GCC 8.0 or earlier have a bug that it emits R_386_GOTPC relocations
against _GLOBAL_OFFSET_TABLE for .debug_info. The bug seems to have
been fixed in 2017: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82630,
but we do not want LLD to report errors for such inputs.
In this patch we ignore such relocations.
Differential revision: https://reviews.llvm.org/D38625
llvm-svn: 316761
It was reported (https://reviews.llvm.org/D38724#902841) that when we use
-ffunction-sections --emit-relocs build, REL[A] output section receives the name of first
input section, like .rela.text.first_function_in_text rather than .rela.text.
It is probably not really an issue as sh_info still points to correct target section, but
it does not look clean in output and allows internal section name to leak there,
what at least looks confusing and is not consistent with ld.bfd.
Patch changes this behavior so that target output section name is used as a base.
Differential revision: https://reviews.llvm.org/D39242
llvm-svn: 316760
This moves reporting of garbage collected sections right after
we do GC. That simplifies things.
Differential revision: https://reviews.llvm.org/D39058
llvm-svn: 316759
This change allows Thunks to be added on multiple passes. To do this we must
merge only the thunks added in each pass, and deal with thunks that have
drifted out of range of their callers.
A thunk may end out of range of its caller if enough thunks are added in
between the caller and the thunk. To handle this we create another thunk.
Differential Revision: https://reviews.llvm.org/D34692
llvm-svn: 316754
This change adds initial support for range extension thunks. All thunks must
be created within the first pass so some corner cases are not supported. A
follow up patch will add support for multiple passes.
With this change the existing tests arm-branch-error.s and
arm-thumb-branch-error.s now no longer fail with an out of range branch.
These have been renamed and tests added for the range extension thunk.
Differential Revision: https://reviews.llvm.org/D34691
llvm-svn: 316752
When an OutputSection is larger than the branch range for a Target we
need to place thunks such that they are always in range of their caller,
and sufficiently spaced to maximise the number of callers that can use
the thunk. We use the simple heuristic of placing the
ThunkSection at intervals corresponding to a target specific branch range.
If the OutputSection is small we put the thunks at the end of the executable
sections.
Differential Revision: https://reviews.llvm.org/D34689
llvm-svn: 316751
Instead of maintaining a map of the std::vector to ThunkSections, record the
ThunkSections directly in InputSectionDescription.
Differential Revision: https://reviews.llvm.org/D37743
llvm-svn: 316750
Previously, EhFrameSection pushes data to EhFrameHdr by calling addFde
function. By making EhFrameHdr pull data from EhFrameSection, we can
eliminate a member from EhFrameHdr.
llvm-svn: 316730
When LLD do ICF for 2 identical sections it leaves 2 duplicate entries in .eh_frame
pointing to the same address. After that it fixes .eh_frame_header's header,
so that it says it contains single FDE, though section itself contains 2
(it contains garbage data at tail).
As a result excessive entries in .eh_frame and excessive dummy data in .eh_frame_header
emited to output. Patch fixes that. This is PR34518.
Differential revision: https://reviews.llvm.org/D38998
llvm-svn: 316648
Summary:
The COFF linker and the ELF linker have long had similar but separate
Error.h and Error.cpp files to implement error handling. This change
introduces new error handling code in Common/ErrorHandler.h, changes the
COFF and ELF linkers to use it, and removes the old, separate
implementations.
Reviewers: ruiu
Reviewed By: ruiu
Subscribers: smeenai, jyknight, emaste, sdardis, nemanjai, nhaehnle, mgorny, javed.absar, kbarton, fedor.sergeev, llvm-commits
Differential Revision: https://reviews.llvm.org/D39259
llvm-svn: 316624
"/DISCARD/" is a special section name in the linker script to discard
input sections. Previously, we handled it as if it were a real section,
so an input section can be assigned but dead. However, allowing sections
to be
- assigned and alive (will be emitted),
- not assigned and dead (removed), or
- assigned but dead (???)
feels logically wrong and practically error-prone. This patch removes
the last combination of the states.
llvm-svn: 316622
It is PR34946.
Spec (http://man7.org/linux/man-pages/man1/ld.1.html) tells about
--orphan-handling=MODE, option where MODE can be one of four:
"place", "discard", "warn", "error".
Currently we already report orphans when -verbose given,
what becomes excessive with option implemented.
Patch stops reporting orphans when -versbose is given,
and support "place", "warn" and "error" modes.
It is not yet clear that "discard" mode is useful so it is not supported.
Differential revision: https://reviews.llvm.org/D39000
llvm-svn: 316583
This is PR34886.
SUBALIGN command currently triggers failture if result expression
is zero. Patch fixes the issue, treating zero as 1, what is consistent with
other places and ELF spec it seems.
Patch also adds "is power of 2" check for this and other expressions
returning alignment.
Differential revision: https://reviews.llvm.org/D38846
llvm-svn: 316580
This is "Bug 34836 - --gc-sections remove relocations from --emit-relocs",
When --emit-relocs is used, LLD currently always drops SHT_REL[A] sections from
output if --gc-sections is present. Patch fixes the issue.
Differential revision: https://reviews.llvm.org/D38724
llvm-svn: 316418
If a struct has a std::unique_ptr member, the logical interpretation
is that that member will be destroyed with the struct.
That is not the case for Ctx. It is has to be deleted earlier and its
lifetime is defined by the functions where the AddressState is
created.
llvm-svn: 316378
r315292 introduced a change that's supposed to consistently ignore
"dead" output sections when placing orphans. Unfortunately, that
change doesn't handle the special case when the orphan section is
second to last section and the last section is dead (e.g. because
it's being discarded) introducing a regression in some cases.
This change handles this case by using the same predicate when
checking the last section.
Differential Revision: https://reviews.llvm.org/D39172
llvm-svn: 316307
The support of R_PPC_ADDR16_HI improves ld compatibility and makes
things on par with RuntimeDyldELF that already implements this
relocation.
Patch by vit9696.
llvm-svn: 316306
We used to have a map from section piece offsets to section pieces
as a cache for binary search. But I found that the map took quite a
large amount of memory and didn't make linking faster. So, in this
patch, I removed the map.
This patch saves 566 MiB of RAM (2.019 GiB -> 1.453 GiB) when linking
clang with debug info, and the link time is 4% faster in that test case.
Thanks for Sean Silva for pointing this out.
llvm-svn: 316305
By assuming that mergeable input sections are smaller than 4 GiB,
lld's memory usage when linking clang with debug info drops from
2.788 GiB to 2.019 GiB (measured by valgrind, and that does not include
memory space for mmap'ed files). I think that's a reasonable assumption
given such a large RAM savings, so this patch.
According to valgrind, gold needs 3.54 GiB of RAM to do the same thing.
NB: This patch does not introduce a limitation on the size of
output sections. You can still create sections larger than 4 GiB.
llvm-svn: 316280
The original patch was reported to break a libcxx bot. Unfortunately I
could not reproduce the issue and the bot log is not available anymore.
This patch changes the handling of shared symbols. I will watch the
bot and see it breaks.
Original message:
--------------------------------------------------------------
Handle shared and lazy symbol in the gnu hash construction.
We were not considering those symbols undefined and they could end up
in the end of the dynamic symbol table.
--------------------------------------------------------------
llvm-svn: 316051
The original patch was reported to break a libcxx bot. Unfortunately
I could not reproduce the issue and the bot log is not available anymore.
This patch changes the handling of just lazy symbols. I will watch the
bot and see it breaks.
Original message:
--------------------------------------------------------------
Handle shared and lazy symbol in the gnu hash construction.
We were not considering those symbols undefined and they could end up
in the end of the dynamic symbol table.
--------------------------------------------------------------
llvm-svn: 316004
static __global int Var = 0;
__global int* Ptr[] = {&Var};
...
In this case Var is a non premptable symbol and so its address can be used as the value of Ptr, with a base relative relocation that will add the delta between the ELF address and the actual load address. Such relocations do not require a symbol.
This also fixes LLD which was incorrectly generating a PCREL64 for this case.
Differential Revision: https://reviews.llvm.org/D38910
llvm-svn: 315936
These are generated by the linker itself and it shouldn't treat
them as unrecognized. This was introduced in r315552 and is triggering
an error when building UBSan shared library for i386.
Differential Revision: https://reviews.llvm.org/D38899
llvm-svn: 315737
Summary:
This will allow using the functionality from other linkers. It is also
a prerequisite for sharing the error logging code.
Reviewers: ruiu
Reviewed By: ruiu
Subscribers: emaste, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D38822
llvm-svn: 315725
Relocations.cpp is still head-scratching. Even though relocations are
processed by multiple functions, the functions are effectively one
gigantic function with lots of local and global shared states, because
they are really tightly coupled. It is really hard to predict whether
a change to a function will or will not affect other functions behaviors.
What I'm trying to do is to rewrite the code without breaking the
existing tests so that the code can tolerate a more aggressive
refactoring (i.e. splitting it to logically separated steps).
llvm-svn: 315673
This is not a mechanical transformation. Even though I believe this
patch is correct, I'm not 100% sure if lld with this patch behaves
exactly the same way as before on all edge cases. At least all tests
still pass.
I'm submitting this patch because it took almost a day to understand
this function, and I don't want to lose it.
llvm-svn: 315658
This patch merges computeAddend and computeMipsAddend.
Getting an addend for a relocation is usually pretty easy:
it is either in the r_addend field (if RELA) or in a target
section (if REL).
However, MIPS has many special rules that are different from
other ELF ABIs. I don't think there were technical reasons to
be different, but the reality is that they are different.
It is unfortunate that we had to pass many parameters to
computeAddend, but it seems unavoidable because of MIPS.
llvm-svn: 315617
This is an attempt to make lld's relocation handler code understandable.
Since I don't fully understand what exactly this function does for all
possible cases (I believe no one can), I'm not really sure if this patch
is NFC, but at least no functionality change intended. All tests still pass.
llvm-svn: 315612
It doesn't make sense to link from an alloc section to a non alloc
one as we were doing.
This matches the behavior of both gold and bfd.
llvm-svn: 315584
Previously we did not support following:
foo = ~0xFF;
and had to add space before numeric value:
foo = ~ 0xFF
That was constistent with ld.bfd < 2.30, which shows:
script.txt:3: undefined symbol `~2' referenced in expression,
but inconsistent with gold.
It was fixed for ld.bfd 2.30 as well:
https://sourceware.org/bugzilla/show_bug.cgi?id=22267
Differential revision: https://reviews.llvm.org/D36508
llvm-svn: 315569
A section was passed to getRelExpr just to create an error message.
But if there's an invalid relocation, we would eventually report it
in relocateOne. So we don't have to pass a section to getRelExpr.
llvm-svn: 315552
We were using uint32_t as the type of relocation kind. It has a
readability issue because what Type really means in `uint32_t Type`
is not obvious. It could be a section type, a symbol type or a
relocation type.
Since we do not do any arithemetic operations on relocation types
(e.g. adding one to R_X86_64_PC32 doesn't make sense), it would be
more natural if they are represented as enums. Unfortunately, that
is not doable because relocation type definitions are spread into
multiple header files.
So I decided to use typedef. This still should be better than the
plain uint32_t because the intended type is now obvious.
llvm-svn: 315525
This patch doesn't change the behavior of the program because it
would eventually return None at end of the function. But it is
better to return None early if we know it will eventually happen.
llvm-svn: 315495
This is PR34546.
Currently LLD creates output sections even if it has no input sections,
but its command contains an assignment.
Committed code just assigns the same flag that was used in previous
live section.
That does not work sometimes. For example if we have following script:
.ARM.exidx : { *(.ARM.exidx*) }
.foo : { _foo = 0; } }
Then first section has SHF_LINK_ORDER flag. But section foo should not.
That was a reason of crash in OutputSection::finalize(). LLD tried to calculate
Link value, calling front() on empty input sections list.
We should only keep access flags and omit all others when creating such sections.
Patch fixes the crash observed.
Differential revision: https://reviews.llvm.org/D37736
llvm-svn: 315441
Usually, a function that does symbol lookup takes symbol name as
its first argument. Also, if a function takes a source location hint,
it is usually the last parameter. So the previous parameter order
was counter-intuitive.
llvm-svn: 315433
Because of r314495, DefinedCommon symbols cannot reach to
getSymbolValue function. When they reach the fucntion, they have
already been converted to DefinedRegular symbols.
llvm-svn: 315432
We used CurAddressState to capture a dynamic context just like
we use lambdas to capture static contexts. So, CurAddressState
is used everywhere in LinkerScript.cpp. It is worth a shorter
name.
llvm-svn: 315418
"Commands" was ambiguous because in the linker script, everything is
a command. We used to handle only SECTIONS commands, and at the time,
it might make sense to call them the commands, but it is no longer
the case. We handle not only SECTIONS but also MEMORY, PHDRS, VERSION,
etc., and they are all commands.
llvm-svn: 315409
HasSections is true if there is at least one SECTIONS linker
script command, and it is not directly related to whether we have
section objects or not. So I think the new name is better.
llvm-svn: 315405
ScriptConfiguration was a class to contain parsed results of
linker scripts. LinkerScript is a class to interpret it.
That ditinction was needed because we haven't instantiated
LinkerScript early (because, IIRC, LinkerScript class was a
ELFT template function). So, when we parse linker scripts,
we couldn't directly store the result to a LinkerScript instance.
Now, that limitation is gone. We instantiate LinkerScript
at the very beginning of our main function. We can directly
store parse results to a LinkerScript instance.
llvm-svn: 315403
Because addRegular's functionality is tightly coupled with
addSymbol, and the former is called only once, it makes sense
to merge the two functions. This patch also adds comments.
llvm-svn: 315401
The condition whether a section is alive or not by default
is becoming increasingly complex, so the decision of garbage
collection is spreading over InputSection.h and MarkLive.cpp,
which is not a good state.
This moves the code to MarkLive.cpp, to keep the file the central
place to make decisions about garbage collection.
llvm-svn: 315384
We just don't need one with the current setup.
We only error on undefined references that are used by some
relocation.
If we managed to relax all uses of __tls_get_addr, no relocation uses
it and we don't produce an error.
This is less code and fixes the case were we fail to relax. Before we
would produce a broken output, but now we produce an error.
llvm-svn: 315334
When parsing linker scripts, LLD previously started with a '.' value of 0,
regardless of the internal default image base for the target, and regardless of
switches such as --image-base. It seems reasonable to use a different image base
value when using linker scripts and --image-base is specified, since otherwise the
switch has no effect. This change does this, as well as removing unnecessary
initialisation of Dot where it is not used.
The default image base should not be used when processing linker
scripts, because this will change the behaviour for existing linker script users,
and potentially result in invalid output being produced, as a subsequent assignment
to Dot could move the location counter backwards. Instead, we maintain the existing
behaviour of starting from 0 if --image-base is not specified.
Reviewers: ruiu
Differential Revision: https://reviews.llvm.org/D38360
llvm-svn: 315293
When findOrphanPos does the reverse search to find the OutputSection
preceding the orphan's insertion point, look for a live OutputSection
and ignore "dead" OutputSection's. This matches the behaviour of the
forward search performed earlier in this function.
Added test which without the above fix fails as a result of an orphan
executable section being incorrectly placed in a non-executable segment.
Differential Review: https://reviews.llvm.org/D38690
llvm-svn: 315292
Previously, when we added an input section to an output section, we
called `OutputSectionFactory::addInputSec`. This isn't a good design
because, a factory class is intended to create a new object and
return it, but in this use case, it will never create a new object.
This patch fixes the design flaw.
llvm-svn: 315138
Factory::addInputSec added an output section to Script->Opt.Commands,
but that is too subtle. This patch makes it explicit so that it is easy
to see when a new element is added to Script->Opt.Commands.
llvm-svn: 315129
This patch moves a std::find to a new function. It also removes
the following piece of code. I believe it should be fine because all
tests still pass.
unsigned Index = std::distance(Opt.Commands.begin(), I);
assert(Sec->SectionIndex == INT_MAX || Sec->SectionIndex == Index);
Sec->SectionIndex = Index;
llvm-svn: 315125
addSection function was hard to read because it behaves differently
depending on its arguments but what exactly it does is not clear.
Now it should be better. Still, it is not clear (not what but) why
it does what it does, but I'll take a look at it later.
llvm-svn: 315124
I hadn't synced past the change that changed the default hash style
to --hash-style=both, so my test had the symbols in the wrong order.
llvm-svn: 315119
Dynamic lists in an executable are additive, not restrictive, so we
must continue to export preempted symbols even with a dynamic list.
This fixes sanitizer interception of libc symbols (and should also fix
symbol preemption by users of sanitizers).
Differential Revision: https://reviews.llvm.org/D38647
llvm-svn: 315114
This reverts commit r314616 because nested parallel-for loops can hang.
Our ThreadPoolExecutor is not necessarily able to handle nested calls.
llvm-svn: 315098
Before this patch we would copy foo into real_foo and wrap_foo into
foo. The net result is that __wrap_foo shows up twice in the symbol
table.
With this patch we:
* save a copy of __real_foo before copying foo.
* drop one of the __wrap_foo from the symbol table.
* if __real_foo was not undefined, add a *new* symbol with that content to
the symbol table.
The net result is that
Anything using foo now uses __wrap_foo
Anything using __real_foo now uses foo.
Anything using __wrap_foo still does.
And the symbol table has foo, __wrap_foo and __real_foo (if defined).
Which I think is the desired behavior.
llvm-svn: 315097
Summary:
These are 16 bit relocations and not part of a HI/LO pair so we need to
check that they don't overflow.
Reviewers: atanasyan
Reviewed By: atanasyan
Subscribers: ruiu, llvm-commits, emaste, sdardis
Tags: #lld
Differential Revision: https://reviews.llvm.org/D38614
llvm-svn: 315073
LLD produces broken .dynamic section when --no-rosegment and at least
one of following options is present:
1) -z rodynamic is given.
2) MIPS target.
That happens because code that writes .dynamic assumes target buffer
is zero-filled, what can be not true after LLD fills it with trap
instructions. With one of two options above, .dynamic becomes
SHF_ALLOC section, so can be affected.
Differential revision: https://reviews.llvm.org/D38580
llvm-svn: 315054
We produce broken output currently.
Code that writes .dynsym assumes output buffer is zero-filled,
though that is not always true. When --no-rosegment is given,
buffer can be filled with trap instructions. Patch fixes the issue.
It is relative with PR34705.
Differential revision: https://reviews.llvm.org/D38579
llvm-svn: 315053
Its PR34712,
GNU linkers recently changed default values to "both" of "sysv".
Patch do the same for all targets except MIPS, where .gnu.hash
section is not yet supported.
Code suggested by Rui Ueyama.
Differential revision: https://reviews.llvm.org/D38407
llvm-svn: 315051
Summary:
We were crashing when linking telnetd in FreeBSD because lld was emitting
corrupted output files for --norosegment. In this file the version index of some symbols
was set to 9 but lld only found 8 version definitions.
I am not sure how to create a minimal .so file that also exposes this behaviour so I just added the one that initially caused the error to Inputs/
This partially addresses https://bugs.llvm.org/show_bug.cgi?id=34705
Reviewers: ruiu, rafael, pcc, grimar
Reviewed By: ruiu
Subscribers: emaste, krytarowski
Tags: #lld
Differential Revision: https://reviews.llvm.org/D38397
llvm-svn: 315036
Summary:
We were crashing when linking telnetd in FreeBSD because lld was emitting
corrupted output files for --norosegment. In this file the version index of some symbols
was set to 9 but lld only found 8 version definitions.
I am not sure how to create a minimal .so file that also exposes this behaviour so I just added the one that initially caused the error to Inputs/
This partially addresses https://bugs.llvm.org/show_bug.cgi?id=34705
Reviewers: ruiu, rafael, pcc, grimar
Reviewed By: ruiu
Subscribers: emaste, krytarowski
Tags: #lld
Differential Revision: https://reviews.llvm.org/D38397
llvm-svn: 315035
I think it is not defined what would happen to detached threads
when the main thread tries to exit. That means it was not guaranteed
that unlinkAsync correctly removes a temporary file. It was also
reported that this unlinkAsync caused a crash on Windows.
This patch adds a few new functions so that the main thread always
waits for non-main threads before exitting.
I don't actually like the new two functions, runBackground and
waitForBackgroundThreads, because it looks like it is a bit
overdesigned. After all, what we are doing with these functions
is to just remove a file.
An alternative would be to do fork(2) and make the child process
remove a file asynchronously. However, it has its own problems.
Correctly forking and reclaiming a resource using waitpid(2) is not
doable unless we know our process-wide settings (such as signal mask),
but we can't make any assumption on it when lld is embedded to other
process. So I chose to stick with threads instead of multi-processes.
Differential Revision: https://reviews.llvm.org/D38571
llvm-svn: 315033
We used to call exitLld() from a leaf function, Writer::run(), because
we had objects on the stack whose dtors are expensive. Now we no longer
have such objects on the stack, so there's no reason to exist from the
leaf function.
llvm-svn: 314869
When reporting a symbol conflict, LLD parses the debug info to report
source location information. Sections have not been decompressed at this
point, so if an object file contains zlib compressed debug info, LLD
ends up passing this compressed debug info to the DWARF parser, which
causes debug info parsing failures and can trigger assertions in the
parser (as the test case demonstrates).
Decompress debug sections when constructing the LLDDwarfObj to avoid
this issue. This doesn't handle GNU-style compressed debug info sections
(.zdebug_*), which at present are simply ignored by LLDDwarfObj; those
can be done in a follow-up.
Differential Revision: https://reviews.llvm.org/D38491
llvm-svn: 314866
We have this comment in LinkerDriver::link
After this, no new names except a few linker-synthesized ones
will be added to the symbol table.
but that was not true because new symbols could be added by processing
the -u option.
llvm-svn: 314842
The issue with std:🧵:hardware_concurrency is that it forwards
to libc and some implementations (like glibc) don't take thread
affinity into consideration.
With this change a llvm program that can execute in only 2 cores will
use 2 threads, even if the machine has 32 cores.
This makes benchmarking a lot easier, but should also help if someone
doesn't want to use all cores for compilation for example.
llvm-svn: 314810
If symbol has the STO_MIPS_MICROMIPS flag and requires a thunk to perform
call PIC from non-PIC functions, we need to generate a thunk with microMIPS
code.
llvm-svn: 314797
New lld's files are spread under lib subdirectory, and it isn't easy
to find which files are actually maintained. This patch moves maintained
files to Common subdirectory.
Differential Revision: https://reviews.llvm.org/D37645
llvm-svn: 314719
Reads from `Live` and writes to `OutputOff` in the following code race
even though they are logically independent because they are bitfields
sharing the same word.
for (size_t I = 0, E = Sec->Pieces.size(); I != E; ++I) {
if (!Sec->Pieces[I].Live)
continue;
CachedHashStringRef Str = Sec->getData(I);
size_t ShardId = getShardId(Str.hash());
if ((ShardId & (Concurrency - 1)) == ThreadId)
Sec->Pieces[I].OutputOff = Shards[ShardId].add(Str);
}
llvm-svn: 314711
Currently LLD calls the `isMicroMips` routine to determine type of PLT entries
needs to be generated: regular or microMIPS. This routine checks ELF
header flags in the `FirstObj` to retrieve type of linked object files.
So if the first file does not contain microMIPS code, LLD will generate
PLT entries with regular (non-microMIPS) code only.
Ideally, if a PLT entry is referenced by microMIPS code only this entry
should contain microMIPS code, if a PLT entry is referenced by regular
code this entry should contain regular code. In a "mixed" case the PLT
entry can be either microMIPS or regular, but each "cross-mode-call" has
additional cost.
It's rather difficult to implement this ideal solution. But we can
assume that if there is an input object file with microMIPS code, the
most part of the code is microMIPS too. So we need to deduce type of PLT
entries based on finally calculated ELF header flags and do not check
only the first input object file.
This change implements this.
- The `getMipsEFlags` renamed to the `calcMipsEFlags`. The function
called from the `LinkerDriver::link`. Result is stored in
the Configuration::MipsEFlags field.
- The `isMicroMips` and `isMipsR6` routines access the `MipsEFlags`
field to get and check calculated ELF flags.
- New types of PLT records created when necessary.
Differential revision: https://reviews.llvm.org/D37747
llvm-svn: 314675
That makes code a bit more consistent. Instead of removing sections there
we can just mark them as dead. So that removeEmptyCommands() will
handle the rest.
Differential revision: https://reviews.llvm.org/D38393
llvm-svn: 314654
Computing section content hashes early seems like a win in terms of
performance. It increases a chance that two different sections will get
different class IDs from the beginning.
Without threads, this patch improves Chromium link time by about 0.3
seconds. With threads, by 0.1 seconds. That's less than 1% time saving
but not bad for a small patch.
llvm-svn: 314644
I don't know why we didn't use parallelForEach to call writeTo,
but there should be no reason to not do that, as most writeTo
functions are safe to run concurrently.
llvm-svn: 314616
The result of hash_value(StringRef) depends on sizeof(size_t).
That causes lld to create different mergeable table contents on
32-bit machines.
This patch is to use xxHash64 so that we get the same hash values
on 32-bit machines.
llvm-svn: 314603
String merging is one of the most time-consuming functions in lld.
This patch parallelize it to speed it up. On my 2-socket 20-core
40-threads Xeon E5-2680 @ 2.8 GHz machine, this patch shorten the
clang debug build link time from 7.11s to 5.16s. It's a 27%
improvement and actually pretty noticeable. In this test condition,
lld is now 4x faster than gold.
Differential Revision: https://reviews.llvm.org/D38266
llvm-svn: 314588
Convert all common symbols to regular symbols after scan.
This means that the downstream code does not to handle common symbols as a special case.
Differential Revision: https://reviews.llvm.org/D38137
llvm-svn: 314495
Peter Smith