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
This is "Bug 34688 - lld much slower than bfd when linking the linux kernel"
Inside copyRelocations() we have O(N*M) algorithm, where N - amount of
relocations and M - amount of symbols in symbol table. It isincredibly slow
for linking linux kernel.
Patch creates local search tables to speedup.
With this fix link time goes for me from 12.95s to 0.55s what is almost 23x
faster. (used release LLD).
Differential revision: https://reviews.llvm.org/D38129
llvm-svn: 314282
SymbolTable::insert() is a hot path function. When linking a clang debug
build, the function is called 3.7 million times. The total amount of "Name"
string contents is 300 MiB. That means this `Name.find("@@")` scans almost
300 MiB of data. That's far from negligible.
StringRef::find(StringRef) uses a sophisticated algorithm, but the
function is slow for a short needle. This patch replaces it with
StringRef::find(char).
This patch alone speeds up a clang debug build link time by 0.5 seconds
from 8.2s to 7.7s. That's 6% speed up. It seems too good for this tiny
change, but looks like it's real.
llvm-svn: 314192
[Synopsys]
Using function elf::link(...) leads to segmentation fault on its second call. First call finishes correctly.
[Solution]
Clear the rest of globals.
Reviewed by: George Rimar and Rui Ueyama
Differential Revision: http://reviews.llvm.org/D38131
llvm-svn: 314108
Previously`InX::Got` and InX::MipsGot synthetic sections
were not removed if ElfSym::GlobalOffsetTable was defined.
ElfSym::GlobalOffsetTable is a symbol for _GLOBAL_OFFSET_TABLE_.
Patch moves ElfSym::GlobalOffsetTable check out from removeUnusedSyntheticSections.
Also note that there was no point to check ElfSym::GlobalOffsetTable for MIPS case
because InX::MipsGot::empty() always returns false for non-relocatable case, and in case
of relocatable output we do not create special symbols anyways.
Differential revision: https://reviews.llvm.org/D37623
llvm-svn: 314099
When -verbose is specified, patch outputs names of each input orphan section
assigned to output.
Differential revision: https://reviews.llvm.org/D37517
llvm-svn: 314098
Previously when BC file had global variable that was accessed from script,
it was optimized away or inlined by IPO.
In this patch I add symbols at left side of assignment expression as LinkerRedefined,
what prevents optimization for them.
Differential revision: https://reviews.llvm.org/D37059
llvm-svn: 314097
We used to sort and uniquify CU vectors, but looks like CU vectors in
.gdb_index sections created by gold are not guaranteed to be sorted.
llvm-svn: 314095
We used to use std::set to uniquify CU vector elements, but as we know,
std::set is pretty slow. Fortunately we didn't actually have to use a
std::set here. This patch replaces it with std::vector.
With this patch, lld's -gdb-index overhead when linking a clang debug
build is now about 1 second (8.65 seconds without -gdb-index vs 9.60
seconds with -gdb-index). Since gold takes more than 6 seconds to create
a .gdb_index for the same output, our number isn't that bad.
llvm-svn: 314094
Previously, we had two levels of hash table lookup. The first hash
lookup uses CachedHashStringRefs as keys and returns offsets in string
table. Then, we did the second hash table lookup to obtain GdbSymbol
pointers. But we can directly map strings to GDbSymbols.
One test file is updated in this patch because we no longer have a '\0'
byte at the start of the string pool, which was automatically inserted
by StringTableBuilder.
This patch speeds up Clang debug build (with -gdb-index) link time by
0.3 seconds.
llvm-svn: 314092
This change alone speeds up linking of Clang debug build with -gdb-index
by 1.2 seconds, from 12.5 seconds to 11.3 seconds. (Without -gdb-index,
lld takes 8.5 seconds to link the same input files.)
llvm-svn: 314090
In order to keep track of symbol renaming, we used to have
Config->SymbolRenaming, and whether a symbol is in the map or not
affects its symbol attribute (i.e. "LinkeRedefined" bit).
This patch adds "CanInline" bit to Symbol to aggreagate symbol
information in one place and removed the member from Config since
no one except SymbolTable now uses the table.
llvm-svn: 314088
This patch rewrites a part of GdbIndexSection to address the following
issues in the previous implementation:
- Previously, some struct declarations were in GdbIndex.h while they
were not used in GdbIndex.cpp. Such structs are moved to
SyntheticSection.h.
- The actual implementation were split into GdbIndexSection and GdbHash
section, but that separation didn't make much sense. They are now
unified as GdbIndexSection.
In addition to the above changes, this patch splits functions, rename
variables and remove redundant functions/variables to generally improve
code quality.
llvm-svn: 314084
For ARM thunks, the `movt` half of the relocation was using an incorrect
offset (it was off by 4 bytes). The original intent seems to have been
for the offset to have been relative to the current instruction, in
which case the difference of 4 makes sense. As the code stands, however,
the offset is always calculated relative to the start of the thunk
(`P`), and so the `movw` and `movt` halves should use the same offset.
This requires a very particular offset between the thunk and its target
to be triggered, and it results in the `movt` half of the relocation
being off-by-one.
The tests here use ARM-Thumb interworking thunks, since those are the
only ARM thunks currently implemented. I actually encountered this with
a range extension thunk (having Peter's patches cherry-picked locally),
but the underlying issue is identical.
Differential Revision: https://reviews.llvm.org/D38112
llvm-svn: 313915
This patch goes back to considering ForceAbsolute in moveAbsRight, but
only if the second argument is not already absolute.
With this we can handle "foo + ABSOLUTE(foo)" and "ABSOLUTE(foo) + foo".
llvm-svn: 313800
The idea of this function is to simplify the implementation of binary
operators like add.
A value might be absolute because of an ABSOLUTE expression, but it
still depends on the value of a section and we might not be able to
evaluate it early. We should keep such values on the LHS, so that we
can delay the evaluation.
We can now handle both "1 + ABSOLUTE(foo)" and "ABSOLUTE(foo) + 1".
llvm-svn: 313794
The previous logic was to try to detect if a linker script defined _gp
by checking !ElfSym::MipsGp->Value. That doesn't work in all cases as
the assigned value can be 0.
We now just always defined it Writer.cpp and always overwrite it
afterwards if needed.
llvm-svn: 313788
Normally to find the offset of a value in a section, we have to
compute the value since the alignment is defined on the final address.
If the alignment is trivial, we can skip the value computation. This
allows us to know the offset even in cases where we cannot yet know
the value.
llvm-svn: 313777
We try to evaluate expressions early when possible, but it is not
possible to evaluate them early if they are based on a section.
Before we would get this wrong on ABSOLUTE expressions.
llvm-svn: 313764
Its a PR34648 which was a segfault that happened because
we stored pointers to elements in DenseMap.
When DenseMap grows such pointers are invalidated.
Solution implemented is to keep elements by pointer
and not by value.
Differential revision: https://reviews.llvm.org/D38034
llvm-svn: 313741
EhSectionPiece used to have a pointer to a section, but that pointer was
mostly redundant because we almost always know what the section is without
using that pointer. This patch removes the pointer from the struct.
This patch also use uint32_t/int32_t instead of size_t to represent
offsets that are hardly be larger than 4 GiB. At the moment, I think it is
OK even if we cannot handle .eh_frame sections larger than 4 GiB.
Differential Revision: https://reviews.llvm.org/D38012
llvm-svn: 313697
CieRecord is a struct containing a CIE and FDEs, but oftentimes the
struct itself is named `Cie` which caused some confusion. This patch
renames them `CieRecords` or `Rec`.
llvm-svn: 313681
Given a linker script that ends in
.some_sec { ...} ;
__stack_start = .;
. = . + 0x2000;
__stack_end = .;
lld would put orphan sections like .comment before __stack_end,
corrupting the intended meaning.
The reason we don't normally move orphans past assignments to . is to
avoid breaking
rx_sec : { *(rx_sec) }
. = ALIGN(0x1000);
/* The RW PT_LOAD starts here*/
but in this case, there is nothing after and it seems safer to put the
orphan section last. This seems to match bfd's behavior and is
convenient for writing linker scripts that care about the layout of
SHF_ALLOC sections, but not of any non SHF_ALLOC sections.
llvm-svn: 313646
This is PR34506.
Imagine we have 2 sections the same name but different COMDAT groups:
.section .foo,"axG",@progbits,bar,comdat
.section .foo,"axG",@progbits,zed,comdat
When linking relocatable we do not merge SHT_GROUP sections. But still would merge
both input sections .foo into single output section .foo.
As a result we will have 2 different SHT_GROUPs containing the same section, what
is wrong.
Patch fixes the issue, preventing merging SHF_GROUP sections with any others.
Differential revision: https://reviews.llvm.org/D37574
llvm-svn: 313621
We crashed when --emit-relocs was used
and relocated section was collected by GC.
Differential revision: https://reviews.llvm.org/D37561
llvm-svn: 313620
This patch removes lot of static Instances arrays from different input file
classes and introduces global arrays for access instead. Similar to arrays we
have for InputSections/OutputSectionCommands.
It allows to iterate over input files in a non-templated code.
Differential revision: https://reviews.llvm.org/D35987
llvm-svn: 313619
EhSectionPiece inherited from SectionPiece, but we did not actually use
EhSectionPiece objects as SectionPiece ojbects. They were handled as
distinct types. So it didn't make much sense to use inheritance.
llvm-svn: 313587
"Repl" member is guranteed to have a non-null pointer. If an input
section is not merged by ICF, "Repl" points to "this". Otherwise, it
points to some other section. It must not be NULL.
llvm-svn: 313556
This is not really OK in C++11, and GCc triggers a warning.
We can switch back to default arguments when C++14 will be the
minimum version of the standard supported, see:
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#974
Ack'ed by Rafael.
llvm-svn: 313550
Does not seem we need to set SectionIndex here.
It is set in finalizeSections() later.
Differential revision: https://reviews.llvm.org/D37815
llvm-svn: 313522
This fixes pr34301.
As the bug points out, we want to keep some relocations with undefined
weak symbols. This means that we cannot always claim that these
symbols are not preemptible as we do now.
Unfortunately, we cannot also just always claim that they are
preemptible. Doing so would, for example, cause us to try to create a
plt entry when we don't even have a dynamic symbol table.
What almost works is to say that weak undefined symbols are
preemptible if and only if we have a dynamic symbol table. Almost
because we don't want to fail the build trying to create a copy
relocation to a weak undefined.
llvm-svn: 313372
Patch removes one of OutputSectionFactory::addInputSec methods.
That allows to simplify reporting of discarded sections and
should help to D37561.
Differential revision: https://reviews.llvm.org/D37735
llvm-svn: 313361
_gp points to a position in the file, so it is not really absolute. It
is also simpler to not force it to be absolute, so if there is no
strong ABI requirement we should not do it.
llvm-svn: 313333
There is no need to scan over all input sections for relocatable output.
As we do not process or scan relocations anyways.
Patch moves check for Config->Relocatable out to avoid that and also removes
excessive check for isa<EhInputSection> from first for loop.
It is excessive because we handle all of them in a second for loop below.
That all allowed to simplify code.
Differential revision: https://reviews.llvm.org/D37746
llvm-svn: 313127
This should fix the lto bootstrap.
It is somewhat hard to remember about lazy symbols deep down in the
link. It might be worth it replacing them with undefined symbols once
we are done adding files.
llvm-svn: 313103
https://reviews.llvm.org/rL312796 meant that references to garbage collected common symbols would cause a segfault.
This change fixes the behaviour for references to stripped common symbols.
Differential Revision: https://reviews.llvm.org/D37718
llvm-svn: 313086
The patch implements initial support of microMIPS code linking:
- Handle microMIPS specific relocations.
- Emit both R1-R5 and R6 microMIPS PLT records.
For now linking mixed set of regular and microMIPS object files is not
supported. Also the patch does not handle (setup and clear) the
least-significant bit of an address which is utilized as the ISA mode
bit and allows to make jump between regular and microMIPS code without
any thunks.
Differential revision: https://reviews.llvm.org/D37335
llvm-svn: 313028
Replace OutputSection *Cmd to OutputSection *OS. The Commands vector was
moved to OutputSection but the names of the variables were not. This patch
changes the names to match.
Differential Revision: https://reviews.llvm.org/D37627
llvm-svn: 313015
When given
foobar = ALIGN(., 0x100);
my expectation from what the manual says is that the final address of
foobar will be aligned. It seems that bfd aligns the offset in the
section, which causes some odd results if the section is not 0x100
aligned. Gold aligns the address.
This changes lld to align the final address.
llvm-svn: 312979
When building COFF programs many targets such as mingw prefer
to have a gnu ld frontend. Rather then having a fully fledged
standalone driver we wrap a shim around the LINK driver.
Extra tests were provided by mstorsjo
Reviewers: mstorsjo, ruiu
Differential Revision: https://reviews.llvm.org/D33880
llvm-svn: 312926
This allows combining --dynamic-list and version scripts too. The
version script controls which symbols are visible, and
--dynamic-list controls which of those are preemptible.
Unlike previous versions, undefined symbols are still considered
preemptible, which was the issue breaking the cfi tests.
This fixes pr34053.
llvm-svn: 312806
to separate commons based on file name patterns. The following linker script
construct does not work because commons are allocated before section placement
is done and the only synthesized BssSection that holds all commons has no file
associated with it:
SECTIONS { .common_0 : { *file0.o(COMMON) }}
This patch changes the allocation of commons to create a section per common
symbol and let the section logic do the layout.
Differential revision: https://reviews.llvm.org/D37489
llvm-svn: 312796
REGION_ALIAS(alias, region)
Alias names can be added to existing memory regions created with
the MEMORY command. Each name corresponds to at most one
memory region.
Differential revision: https://reviews.llvm.org/D37477
llvm-svn: 312777
If --dynamic-list is given, only those symbols are preemptible.
This allows combining --dynamic-list and version scripts too. The
version script controls which symbols are visible, and --dynamic-list
controls which of those are preemptible.
This fixes pr34053.
llvm-svn: 312757
To support errata patching on AArch64 we need to be able to overwrite
an arbitrary instruction with a branch. For AArch64 it is sufficient to
always write all the bits of the branch instruction and not just the
immediate field. This is safe as the non-immediate bits of the branch
instruction are always the same.
Differential Revision: https://reviews.llvm.org/D36745
llvm-svn: 312727
It is a bit more convinent and helps to simplify logic
of program headers allocation a little.
Differential revision: https://reviews.llvm.org/D34956
llvm-svn: 312711
The default padding for an executable segment is the target trap
instruction which for x86_64 is 0xCC. However, the .eh_frame section
requires the padding to be zero. The code that writes the .eh_frame
section assumes that its segment is zero initialized and does not
explicitly write the zero padding. This does not work when the .eh_frame
section is in the executable segment (for example when using
-no-rosegment).
This patch changes the .eh_frame writing code to explicitly write the
zero padding.
Differential Revision: https://reviews.llvm.org/D37462
llvm-svn: 312706
If using --format=binary with an input file name that has one or more non-ascii
characters in, LLD has undefined behaviour (it crashes on my Windows Debug build)
when calling isalnum with these non-ascii characters. Instead, of calling
std::isalnum, this patch uses an internal version that ignores the locale and
checks a specific subset of characters.
Reviewers: ruiu
Differential Revision: https://reviews.llvm.org/D37331
llvm-svn: 312705
The R_AARCH64_LDST<N>_ABS LO12_NC relocations where N is 8, 16, 32, 64 or
128 have a scaled immediate. For example R_AARCH64_LDST32_ABS_LO12_NC
shifts the calculated value right by 4. If the target symbol + relocation
addend is not aligned properly then bits of the answer will be lost.
This change adds an alignment check to the relocations to make sure the
target of the relocation is aligned properly. This matches the behavior of
GNU ld. The motivation is to catch ODR violations such as a declaration of
extern int foo, but a definition of bool foo as the compiler may use
R_AARCH64_LDST32_ABS_LO12_NC for the former, but not align the destination.
Differential Revision: https://reviews.llvm.org/D37444
llvm-svn: 312637
The fixSectionAlignments() function may alter the alignment of some
OutputSections, this is likely to alter the addresses calculated earlier
in assignAddresses(). By moving the call to fixSectionAlignments() we
make sure that assignAddresses() is consistent with the early calculation
used for RangeThunks and the final call just before writing the image.
Differential Revision: https://reviews.llvm.org/D36739
llvm-svn: 312636
The --symbol-ordering-file path was not being rewritten in the response file when
using --reproduce. This patch adds this to the list of switches that are rewritten,
so that the path is somewhere within the reproducer directory tree.
Reviewers: ruiu
Differential Revision: https://reviews.llvm.org/D37480
llvm-svn: 312626
Previously LLD did not calculate LMAOffset correctly when
AT and MEMORY were used together.
Patch fixes PR34407.
Differential revision: https://reviews.llvm.org/D37469
llvm-svn: 312625
std::vector::insert invalidates all iterators, so it was not safe to do
Script->Opt.Commands.insert(++I, Make(ElfSym::End1));
Script->Opt.Commands.insert(++I, Make(ElfSym::End2));
because after the first line, `I` is no longer valid.
This patch rewrites fixes the issue. I belive the new code without
higher-order functions is a bit more readable than before.
llvm-svn: 312570
Pass BSIZE and SHIFT as a function arguments to the `writeRelocation`
routine. It does not make a sense to have so many `writeRelocation's`
instances.
llvm-svn: 312495
Previously it was called twice for .comment synthetic section.
That created 2 pieces of data, which was deduplicated anyways,
but was not clean.
llvm-svn: 312327
Simon Atanasyan