LazyRandomTypeCollection is designed for random access, and in
order to provide this it lazily indexes ranges of types. In the
case of types from an object file, there is no partial index
to build off of, so it has to index the full stream up front.
However, merging types only requires sequential access, and when
that is needed, this extra work is simply wasted. Changing the
algorithm to work on sequential arrays of types rather than
random access type collections eliminates this up front scan.
llvm-svn: 303707
Once the dummy linker script is created, we want it to be used for
everything to avoid having two redundant representations that can get
out of sync.
We were already clearing OutputSections. With this patch we clear the
Sections vector of every OutputSection.
llvm-svn: 303703
By the time we get to linker scripts, all special InputSectionBase
should have been combined into synthetic sections, which are a type of
InputSection. The net result is that we can use InputSection in a few
places that were using InputSectionBase.
llvm-svn: 303702
If the compiler driver passes --build-id and the user uses -Wl to
pass --build-id= then the user's flag should take precedence.
Differential Revision: https://reviews.llvm.org/D33461
llvm-svn: 303689
Previous algotirhm assumed that types and ids are in a single
unified stream. For inputs that come from object files, this
is the case. But if the input is already a PDB, or is the result
of a previous merge, then the types and ids will already have
been split up, in which case we need an algorithm that can
accept operate on independent streams of types and ids that
refer across stream boundaries to each other.
Differential Revision: https://reviews.llvm.org/D33417
llvm-svn: 303577
This reverts commit r303304 because it looks like the change
introduced a crash bug. At least after that change, LLD with thinlto
crashes when linking Chromium.
llvm-svn: 303527
This is split up into two commits.
This commit removes the DEF parser from LLD
See the previous commit for the creation in LLVM.
Reviewers: ruiu
Differential Revision: https://reviews.llvm.org/D32689
llvm-svn: 303491
This was originally reverted because it was a breaking a bunch
of bots and the breakage was not surfacing on Windows. After much
head-scratching this was ultimately traced back to a bug in the
lit test runner related to its pipe handling. Now that the bug
in lit is fixed, Windows correctly reports these test failures,
and as such I have finally (hopefully) fixed all of them in this
patch.
llvm-svn: 303446
This is a squash of ~5 reverts of, well, pretty much everything
I did today. Something is seriously broken with lit on Windows
right now, and as a result assertions that fire in tests are
triggering failures. I've been breaking non-Windows bots all
day which has seriously confused me because all my tests have
been passing, and after running lit with -a to view the output
even on successful runs, I find out that the tool is crashing
and yet lit is still reporting it as a success!
At this point I don't even know where to start, so rather than
leave the tree broken for who knows how long, I will get this
back to green, and then once lit is fixed on Windows, hopefully
hopefully fix the remaining set of problems for real.
llvm-svn: 303409
Right now we have multiple notions of things that represent collections of
types. Most commonly used are TypeDatabase, which is supposed to keep
mappings from TypeIndex to type name when reading a type stream, which
happens when reading PDBs. And also TypeTableBuilder, which is used to
build up a collection of types dynamically which we will later serialize
(i.e. when writing PDBs).
But often you just want to do some operation on a collection of types, and
you may want to do the same operation on any kind of collection. For
example, you might want to merge two TypeTableBuilders or you might want
to merge two type streams that you loaded from various files.
This dichotomy between reading and writing is responsible for a lot of the
existing code duplication and overlapping responsibilities in the existing
CodeView library classes. For example, after building up a
TypeTableBuilder with a bunch of type records, if we want to dump it we
have to re-invent a bunch of extra glue because our dumper takes a
TypeDatabase or a CVTypeArray, which are both incompatible with
TypeTableBuilder.
This patch introduces an abstract base class called TypeCollection which
is shared between the various type collection like things. Wherever we
previously stored a TypeDatabase& in some common class, we now store a
TypeCollection&.
The advantage of this is that all the details of how the collection are
implemented, such as lazy deserialization of partial type streams, is
completely transparent and you can just treat any collection of types the
same regardless of where it came from.
Differential Revision: https://reviews.llvm.org/D33293
llvm-svn: 303388
This converts the last (chronologically) user of OutputSections to use
the linker script commands instead.
The idea is to convert all uses after fabricateDefaultCommands, so
that we have a single representation.
llvm-svn: 303384
Our output is not compatible with the Binding feature, so make it
explicit that.
Differential Revision: https://reviews.llvm.org/D33336
llvm-svn: 303378
Previously, LLD-produced executables had IAT (Import Address Table) and
ILT (Import Lookup Table) as separate chunks of data, although their
contents are identical. My interpretation of the COFF spec when I wrote
the COFF linker is that they need to be separate tables even though they
are the same.
But Peter found that the Windows loader is fine with executables in
which IAT and ILT are merged. This is a patch to merge IAT and ILT.
I confirmed that an lld-link self-hosted with this patch works fine.
Fixes https://bugs.llvm.org/show_bug.cgi?id=33064
Differential Revision: https://reviews.llvm.org/D33326
llvm-svn: 303374
The import lists are already binned by DLL name, so there's no need to
deduplicate here.
Differential Revision: https://reviews.llvm.org/D33330
llvm-svn: 303371
We've been using make<> to allocate new objects in ELF. We have
the same function in COFF, but we didn't use it widely due to
negligence. This patch uses the function in COFF to close the gap
between ELF and COFF.
llvm-svn: 303357
GetSection is a template because write calls relocate.
relocate has two parts. The non alloc code really has to be a
template, as it is looking a raw input file data.
The alloc part is only a template because of getSize.
This patch folds the value of getSize early, detemplates
getRelocTargetVA and splits relocate into a templated non alloc case
and a regular function for the alloc case. This has the nice advantage
of making sure we collect all the information we need for relocations
before getting to InputSection::relocateNonAlloc.
Since we know got is alloc, it can just call the function directly and
avoid the template.
llvm-svn: 303355
When /DEBUG is not specified, /PDB should be ignored. When
/DEBUG is specified, a PDB should be output regardless of
whether or not /PDB is specified. /PDB just overrides the
default name.
This patch implements this behavior, and adds some tests, while
also removing a dead option /DEBUGPDB which was unused in any
code.
Differential Revision: https://reviews.llvm.org/D33302
llvm-svn: 303352
This change adds support for the R_ARM_SBREL32 relocation. The relocation
is a base relative relocation that is produced by clang/llvm when -frwpi
is used. The use case for the -frwpi option is position independent data
for embedded systems that do not have a GOT. With -frwpi all data is
accessed via an offset from a base register (usually r9), where r9 is set
at run time to where the data has been loaded. The base of the data is
known as the static base.
The ARM ABI defines the static base as:
B(S) is the addressing origin of the output segment defining the symbol S.
The origin is not required to be the base address of the segment. For
simplicity we choose to use the base address of the segment.
The ARM procedure call standard only defines a read write variant using
R_ARM_SBREL32 relocations. The read-only data is accessed via pc-relative
offsets from the code, this is implemented in clang as -fropi.
Fixes PR32924
Differential Revision: https://reviews.llvm.org/D33280
llvm-svn: 303337
This reverts re-submits r303225 which was reverted in r303270 because it
broke the sanitizer-windows bot.
The reason of the failure is that we were writing dead symbols to the
symbol table. I fixed the issue.
llvm-svn: 303304
and follow-up r303226 "Fix Windows buildbots."
This broke the sanitizer-windows buildbot.
> Previously, the garbage collector (enabled by default or by explicitly
> passing /opt:ref) did not kill dllimported symbols. As a result,
> dllimported symbols could be added to resulting executables' dllimport
> list even if no one was actually using them.
>
> This patch implements dllexported symbol garbage collection. Just like
> COMDAT sections, dllimported symbols now have Live bits to manage their
> liveness, and MarkLive marks reachable dllimported symbols.
>
> Fixes https://bugs.llvm.org/show_bug.cgi?id=32950
>
> Reviewers: pcc
>
> Subscribers: llvm-commits
>
> Differential Revision: https://reviews.llvm.org/D33264
llvm-svn: 303270
Nothing special here, just detemplates code that became possible
to detemplate after recent commits in a straghtforward way.
Differential revision: https://reviews.llvm.org/D33234
llvm-svn: 303237
Summary:
Previously, the garbage collector (enabled by default or by explicitly
passing /opt:ref) did not kill dllimported symbols. As a result,
dllimported symbols could be added to resulting executables' dllimport
list even if no one was actually using them.
This patch implements dllexported symbol garbage collection. Just like
COMDAT sections, dllimported symbols now have Live bits to manage their
liveness, and MarkLive marks reachable dllimported symbols.
Fixes https://bugs.llvm.org/show_bug.cgi?id=32950
Reviewers: pcc
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D33264
llvm-svn: 303225
SymbolTableBaseSection was introduced.
Detemplation of SymbolTableSection should allow to detemplate more things.
Differential revision: https://reviews.llvm.org/D33124
llvm-svn: 303150
Switch to llvm::to_integer() everywhere in LLD instead of
StringRef::getAsInteger() because API of latter is confusing.
It returns true on error and false otherwise what makes reading
the code incomfortable.
Differential revision: https://reviews.llvm.org/D33187
llvm-svn: 303149
We should only ever expect this function to return a regular
InputSection; I would not expect a function definition to be in a
MergeInputSection or EhInputSection. We were previously crashing
in writeTo if this function returned a section that was not an
InputSection because we do not set OutSec for such sections.
This can happen in practice if a function is defined in an empty
section which shares its offset-in-file with a MergeInputSection,
as in the provided test case.
A better fix for this bug would be to fix the
DWARFUnit::collectAddressRanges() interface to provide section
information (see D33183), but this at least fixes the crash.
Differential Revision: https://reviews.llvm.org/D33176
llvm-svn: 303089
This reorganisation prevents us from cluttering up the top-level lib directory
with more driver libraries such as llvm-dlltool (see D29892).
llvm-svn: 302995
We used to place orphans by just using compareSectionsNonScript.
Then we noticed that since linker scripts can use another order, we
should first try match the section to a given PT_LOAD. But there is
nothing special about PT_LOAD. The same issue can show up for
PT_GNU_RELRO for example.
In general, we have to search for the most similar section and put the
orphan next to it. Most similar being defined as how long they follow
the same code path in compareSecitonsNonScript.
That is what this patch does. We now compute a rank for each output
section, with a bit for each branch in what was
compareSectionsNonScript.
With this findOrphanPos is now fully general and orphan placement can
be optimized by placing every section with the same rank at once.
The included testcase is a variation of many-sections.s that uses
allocatable sections to avoid the fast path in the existing
code. Without threads it goes form 46 seconds to 0.9 seconds.
llvm-svn: 302903
This reverts changes introduced in r302414 "[ELF] - Set DF_STATIC_TLS flag for i386 target."
Because DF_STATIC_TLS does not look to be used by glibc or anything else.
llvm-svn: 302884
Both gold and bfd restrict that one:
ld.bfd: test.o: relocation R_X86_64_TPOFF32 against `var' can not be
used when making a shared object; recompile with -fPIC
ld.gold: error: test.o: unsupported reloc 23 against global symbol var
What looks reasonable because it is 32 bit one. Patch do the same.
Differential revision: https://reviews.llvm.org/D33100
llvm-svn: 302881
Previously we were not printing out the type of the incompatible section
which made it difficult to determine what the problem was.
The error message format has been change to the following:
error: section type mismatch for .shstrtab
>>> <internal>:(.shstrtab): SHT_STRTAB
>>> output section .shstrtab: Unknown
Patch by Alexander Richardson.
Differential Revision: https://reviews.llvm.org/D32488
llvm-svn: 302694
This behavior differs from the semantics implemented by GNU linkers
which only define this symbol iff ELF headers are in the memory
mapped segment.
Differential Revision: https://reviews.llvm.org/D33019
llvm-svn: 302687
This is PR32664.
Issue was revealed by linux kernel script which was:
SECTIONS {
. = (0xffffffff80000000 + ALIGN(0x1000000, 0x200000));
phys_startup_64 = ABSOLUTE(startup_64 - 0xffffffff80000000);
.text : AT(ADDR(.text) - 0xffffffff80000000) {
.....
*(.head.text)
Where startup_64 is in .head.text.
At the place of assignment to phys_startup_64 we can not calculate absolute value for startup_64
because .text section has no VA assigned. Two patches were prepared earlier to address this: D32173 and D32174.
And in comments for D32173 was suggested not try to support this case, but error out.
Differential revision: https://reviews.llvm.org/D32793
llvm-svn: 302668
When compiling LLD using GCC 7 it reports warnings like:
"warning: this statement may fall through [-Wimplicit-fallthrough=]"
LLVM has LLVM_FALLTHROUGH macro which can be used to avoid such warnings.
Together with D33036 this patch fixes them.
Differential revision: https://reviews.llvm.org/D32907
llvm-svn: 302666
Adds support for the ORIGIN and LENGTH linker script built in functions.
ORIGIN(memory) Return the origin of the memory region
LENGTH(memory) Return the length of the memory region
Redo of D29775 for refactored linker script parsing.
Patch by Robert Clarke
Differential Revision: https://reviews.llvm.org/D32934
llvm-svn: 302564
This is a bit easier to read and a lot faster in some cases. A version
of many-sections.s with linker scripts goes from 0m41.232s to
0m19.575s.
llvm-svn: 302528
The code following this one already considers every possible insertion
point for orphan sections, there is no point in sorting them before.
llvm-svn: 302441
This is PR32437.
DF_STATIC_TLS
If set in a shared object or executable, this flag instructs the
dynamic linker to reject attempts to load this file dynamically.
It indicates that the shared object or executable contains code
using a static thread-local storage scheme. Implementations need
not support any form of thread-local storage.
Patch checks if IE/LE relocations were used to check if code uses
static model. If so it sets the DF_STATIC_TLS flag.
Differential revision: https://reviews.llvm.org/D32354
llvm-svn: 302414
Previously it was impossible to use linkerscript with --compress-debug-sections
because of assert failture:
Assertion failed: isFinalized(), file C:\llvm\lib\MC\StringTableBuilder.cpp, line 64
Patch fixes the issue
llvm-svn: 302413
We can set SectionIndex tentatively as we process the linker script
instead of looking it repeatedly.
In general we should try to have as few name lookups as possible.
llvm-svn: 302299
This is one step in preparation of raising this up to
LLVM. This hides all of the Executor stuff in a private
implementation file, leaving only the core algorithms and
the TaskGroup class exposed. In doing so, fix up all the
variable names to conform to LLVM style.
Differential Revision: https://reviews.llvm.org/D32890
llvm-svn: 302288
This feels a bit hackish, but I think it is still an improvement.
The way a tls address is computed in the various architectures is not
that different. For example, for local dynamic we need the base of the
tls (R_TLSLD or R_TLSLD_PC), and the offset of that particular symbol
(R_ABS).
Given the similarity, we can just use the expressions instead of
having two additional target hooks.
llvm-svn: 302279
The test ELF/lto/thin-archivecollision.ll was not testing what it
wanted to test. It needs two archive members with the same name, but
different offsets.
Without this we could remove all references of OffsetInArchive and all
tests would still pass.
Fixing the test showed that the --whole-archive case was broken, which
this patch fixes.
llvm-svn: 302241
In the non linker script case we would try very early to find out if
we could allocate the headers. Failing to do that would add extra
alignment to the first ro section, since we would set PageAlign
thinking it was the first section in the PT_LOAD.
In the linker script case the header allocation must be done in the
end, causing some duplication.
We now tentatively add the headers to the first PT_LOAD and if it
turns out they don't fit, remove them. With this we only need to
allocate the headers in one place in the code.
llvm-svn: 302186
We were correctly computing the size contribution of a .tbss input
section (it is none), but we were incorrectly considering the
alignment of the output section: it was advancing Dot instead of
ThreadBssOffset.
As far as I can tell this was always wrong in our linkerscript
implementation, but that became more visible now that the code is
shared with the non linker script case.
llvm-svn: 302107
It seems virtually everyone who tries to do LTO build with Clang and
LLD was hit by a mistake to forget using llvm-ar command to create
archive files. I wasn't an exception. Since this is an annoying common
issue, it is probably better to handle that gracefully rather than
reporting an error and tell the user to redo build with different
configuration.
Differential Revision: https://reviews.llvm.org/D32721
llvm-svn: 302083
It doesn't matter what binding we store in a non-UsedInRegularObj undefined
symbol because we should reset it when we see a real undefined symbol in
a combined LTO object. The fact that we weren't doing so before is a bug
(PR32899) which is now fixed.
llvm-svn: 302067
The --section-start <name>=<address> needs to be translated into equivalent
linker script commands. There are a couple of problems with the existing
implementation:
- The --section-start with the lowest address is assumed to be at the start
of the map. This assumption is incorrect, we have to iterate through the
SectionStartMap to find the lowest address.
- The addresses in --section-start were being over-aligned when the
sections were marked as PageAlign. This is inconsistent with the use of
SectionStartMap in fixHeaders(), and can cause problems when the PageAlign
causes an "unable to move location counter backward" error when the
--section-start with PageAlign is aligned to an address higher than the next
--section-start. The ld.bfd and ld.gold seem to be more consistent with this
approach but this is not a well specified area.
This change fixes the problems above and also corrects a typo in which
fabricateDefaultCommands() is called with the wrong parameter, it should be
called with AllocateHeader not Config->MaxPageSize.
Differential Revision: https://reviews.llvm.org/D32749
llvm-svn: 302007
Before rL301170 was landed, LLD did not produce correct entries in .gdb_index address area.
Issue was fixed on LLVM DWARF parsers side and was relative to how .debug_ranges
section was scanned. It was main problem of PR32319.
It makes sense to have testcase on LLD size too. This checks that we generate proper values
now, because we do not have any tests for .gdb_index which works with .debug_ranges atm.
Differential revision: https://reviews.llvm.org/D32750
llvm-svn: 302006
Zachary Turner