Previously, the code we set to our .plt entries expected that .got
and .got.plt are consecutive in the virtual address space.
Since %ebx points to the last entry of .got for position-independent
code, it assumed that .got is accessible with small negative
displacements and .got.plt are accessible with small positive
displacements.
That assumption was simply wrong. We don't impose any restrictions on
relative layout of .got and .got.plt. As a result, the control is
transferred to a bogus address from .plt at runtime, which resulted in
segfaults.
This patch removes that wrong assumption. We still assume that .got.plt
has a fixed relative address to .got, but we no longer assume that they
are consecutive in memory.
With this change, a "hello world" program compiled with -fPIC works.
Fixes https://bugs.llvm.org/show_bug.cgi?id=31332.
Differential Revision: https://reviews.llvm.org/D31682
llvm-svn: 299553
For range extension thunks we will need to repeatedly call createThunks()
until no more thunks are created. We will need to retain the state of
Thunks that we have created so far to avoid recreating them on later
passes. This change does not change the functionality of createThunks().
Differential Revision: https://reviews.llvm.org/D31654
llvm-svn: 299530
GNU linkers define __bss_start symbol.
Patch teaches LLD to do that. This is PR32051.
Below is part of standart ld.bfd script:
.data1 : { *(.data1) }
_edata = .; PROVIDE (edata = .);
. = .;
__bss_start = .;
.bss :
{
Currently LLD can emit up to 3 .bss* sections as one of testcase shows.
Implementation inserts this symbol before first .bss* output section.
Differential revision: https://reviews.llvm.org/D30419
llvm-svn: 299528
LinkerScript.cpp contains both the linker script processor and the
linker script parser. I put both into a single file, but the file grown
too large, so it's time to put them into two different files.
llvm-svn: 299515
Summary:
This adds support for reporting multiple errors in a single invocation of lld-link. The limit defaults to 20 and can be changed with the /ERRORLIMIT command line parameter, or set to unlimited by passing a value of 0.
This is a new attempt after r295507, which was reverted because opening files raced with exiting early, causing the test to be flaky. This version avoids the race by exiting before calling enqueuePath.
Reviewers: pcc, ruiu
Reviewed By: ruiu
Subscribers: llvm-commits, dblaikie
Differential Revision: https://reviews.llvm.org/D31688
llvm-svn: 299496
The ELF spec says:
all of the non-default visibility attributes, when applied to a symbol
reference, imply that a definition to satisfy that reference must be
provided within the current executable or shared object.
But we were trying to resolve those undef references to shared
symbols. That causes odd results like creating a got entry with
a relocation pointing to 0.
llvm-svn: 299464
As with the changes made in r297645, we do not want a potentially long link to
be run, if it will ultimately fail because the map file is not writable. This
change reuses the same functionality as the output file path check. See
https://reviews.llvm.org/D30449 for further justification and explanations.
Reviewers: ruiu
Differential Revision: https://reviews.llvm.org/D31603
llvm-svn: 299420
The existing names for the ARM and Thumb Thunks highlight their current
use as interworking Thunks. These Thunks can also be used for range
extension Thunks where there is no state change. This change makes the name
more generic so it is suitable for range extension.
Differential Revision: https://reviews.llvm.org/D31605
llvm-svn: 299418
Summary:
The TypeTableBuilder provides stable storage for type records. We don't
need to copy all of the bytes into a flat vector before adding it to the
TpiStreamBuilder.
This makes addTypeRecord take an ArrayRef<uint8_t> and a hash code to go
with it, which seems like a simplification.
Reviewers: ruiu, zturner, inglorion
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D31634
llvm-svn: 299406
Previous error message style:
error: /home/alice/src/bar.c:12: relocation R_X86_64_PLT32 cannot refer to absolute symbol 'answer' defined in /home/alice/src/foo.o
New error message style:
error: relocation R_X86_64_PLT32 cannot refer to absolute symbol: foo
>>> defined in /home/alice/src/foo.o
>>> referenced by bar.c:12 (/home/alice/src/bar.c:12)
>>> /home/alice/src/bar.o:(.text+0x1)
llvm-svn: 299390
LogName member was added to construct input file names for logging
only once. This patch does this in a different way. Now toString
caches its results.
Differential Revision: https://reviews.llvm.org/D31546
llvm-svn: 299375
This patch is intended to improve readability of "duplicate symbol"
error messages.
Without this patch:
/ssd/clang/bin/ld.lld: error: /ssd/llvm-project/lld/ELF/Relocations.cpp:1054: duplicate symbol 'lld:🧝:demangle(llvm::StringRef)'
/ssd/clang/bin/ld.lld: error: /ssd/llvm-project/lld/ELF/Strings.cpp:93: previous definition was here
With this patch:
/ssd/clang/bin/ld.lld: error: duplicate symbol: lld:🧝:demangle(llvm::StringRef)
>>> defined at Strings.cpp:93 (/ssd/llvm-project/lld/ELF/Strings.cpp:93)
>>> Strings.cpp.o:(lld:🧝:demangle(llvm::StringRef)) in archive lib/liblldELF.a
>>> defined at Relocations.cpp:1054 (/ssd/llvm-project/lld/ELF/Relocations.cpp:1054)
>>> Relocations.cpp.o:(.text+0x4C30) in archive lib/liblldELF.a
Discussion thread:
http://lists.llvm.org/pipermail/llvm-dev/2017-March/111459.html
Differential Revision: https://reviews.llvm.org/D31507
llvm-svn: 299280
This is a test change applicable for ARM targets.
Previously LLVM would generate a mapping symbol when code contains only
data. This was changed as part of
https://reviews.llvm.org/D30724
and to be more close to the ARM ELF ABI.
The test case is changed to check for behavior with minimal changes.
Patch by Shankar Easwaran
Differential Revision: https://reviews.llvm.org/D31500
llvm-svn: 299212
Introduce symbol table data structures that can be potentially written to
disk, have the LTO library build those data structures using temporarily
constructed modules and redirect the LTO library implementation to go through
those data structures. This allows us to remove the LLVMContext and Modules
owned by InputFile.
With this change I measured a peak memory consumption decrease from 5.4GB to
2.8GB in a no-op incremental ThinLTO link of Chromium on Linux. The impact on
memory consumption is larger in COFF linkers where we are currently forced
to materialize all metadata in order to read linker options. Peak memory
consumption linking a large piece of Chromium for Windows with full LTO and
debug info decreases from >64GB (OOM) to 15GB.
Part of PR27551.
Differential Revision: https://reviews.llvm.org/D31364
llvm-svn: 299168
Previously, undefined symbol errors are one line like this
and wasn't easy to read.
/ssd/clang/bin/ld.lld: error: /ssd/llvm-project/lld/ELF/Writer.cpp:207: undefined symbol 'lld:🧝:EhFrameSection<llvm::object::ELFType<(llvm::support::endianness)0, true> >::addSection(lld:🧝:InputSectionBase*)'
This patch make it more structured like this.
bin/ld.lld: error: undefined symbol: lld:🧝:EhFrameSection<llvm::object::ELFType<(llvm::support::endianness)0, true>
>>> Referenced by Writer.cpp:207 (/ssd/llvm-project/lld/ELF/Writer.cpp:207)
>>> Writer.cpp.o in archive lib/liblldELF.a
Discussion thread:
http://lists.llvm.org/pipermail/llvm-dev/2017-March/111459.html
Differential Revision: https://reviews.llvm.org/D31481
llvm-svn: 299097
This patch changes GnuHashTableSection implementation
to avoid depend on uintX_t and other ELFT stuff, reducing amount of
changes for following patch(es).
Differential revision: https://reviews.llvm.org/D31184
llvm-svn: 298998
Summary: In the ELF linker, we create the buffer identifier for bitcode files by appending the object name to the archive name. This change makes the COFF linker do the same. Without the change, ThinLTO builds can fail with an error message about multiple ThinLTO modules per object file, caused by object files contained in different archives having the same name.
Reviewers: pcc, ruiu
Reviewed By: pcc
Subscribers: mehdi_amini
Differential Revision: https://reviews.llvm.org/D31402
llvm-svn: 298942
.gnu.hash happen to contain only 32-bit integers for 32-bit arch,
but the section contents are not uniform array members, so setting
entsize doesn't make much sense. This behavior seems to have been
blindly copied from GNU linkers.
llvm-svn: 298934
This patch calls getAddend on a relocation only when the relocation is RELA.
That doesn't really improve runtime performance but should improve
readability as the code now matches the function description.
llvm-svn: 298828
Previously, computeAddend had many parameters but most of them were
used only for MIPS. The MIPS ABI is too odd that I don't want to mix
it into the regular code path. Splitting the function into non-MIPS
and MIPS parts makes the regular code path easy to follow.
llvm-svn: 298817
C is short for Chunk, but we are no longer using that term.
RI is probably short for relocation iterator, but this is not an interator.
llvm-svn: 298786
Previously, relocation offsets are recalculated for .eh_frame sections
inside the main loop, and that messed up the main loop. This patch
separates that logic into a dedicated class.
llvm-svn: 298785
Summary: MSVC does this when producing a PDB.
Reviewers: ruiu
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D31316
llvm-svn: 298717
The original code is a big `if` and `else` which ends with `continue`
like this:
if (cond) {
...
// fall through
} else {
...
continue;
}
This patch rewrites it with the following.
if (!cond) {
...
continue;
}
...
llvm-svn: 298672
This requires collectign all symbols referenced in the linker script
and adding them to symbol table as undefined symbol.
Differential Revision: https://reviews.llvm.org/D31147
llvm-svn: 298577
I honestly do not understand this part of code as it is too tangled.
What I'm trying now is to carefully disentangle it by transforming
code without changing meaining to see if I can improve overall
readability.
llvm-svn: 298576
This is to improve compatibility with GNU Libtool that expect
/supported targets:.* elf/ in a message for the -help option.
Differential Revision: https://reviews.llvm.org/D31208
llvm-svn: 298568
This will be used in the sanitizer test suite, which wants to use DWARF
line tables.
At some point we should reconsider how LLD handles the long section
names required by DWARF debug sections.
llvm-svn: 298544
This is a shorthand for Config->Wordsize == 8. So this is not strictly
necessary but seems handy. "Is 64 bit?" is easier to read than "Is
wordsize 8 byte?"
llvm-svn: 298463
LinkerScript used to be a template class, so we couldn't instantiate
that class in elf::link. We instantiated ScriptConfig class earlier
instead so that the linker script parser can store configurations to
the object.
Now that LinkerScript is not a template, it doesn't make sense to
separate ScriptConfig from LinkerScript. This patch merges them.
llvm-svn: 298457
Patch moves Sections array to
InputFile (root class for input files).
That allows to detemplate GdbIndexSection.
Differential revision: https://reviews.llvm.org/D30976
llvm-svn: 298345
Summary:
This also delays setting the output filename based on the first input
argument until after processing /def.
Fixes PR32354
Reviewers: ruiu, pcc
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D31152
llvm-svn: 298327
In doing so, clean up the MD5 interface a little. Most
existing users only care about the lower 8 bytes of an MD5,
but for some users that care about the upper and lower,
there wasn't a good interface. Furthermore, consumers
of the MD5 checksum were required to handle endianness
details on their own, so it seems reasonable to abstract
this into a nicer interface that just gives you the right
value.
Differential Revision: https://reviews.llvm.org/D31105
llvm-svn: 298322
The patch introduces two new relocations expressions R_MIPS_GOT_GP and
R_MIPS_GOT_GP_PC. The first one represents a current value of `_gp`
pointer and used to calculate relocations against the `__gnu_local_gp`
symbol. The second one represents the offset between the beginning of
the function and the `_gp` pointer's value.
There are two motivations for introducing new expressions:
- It's better to keep all non-trivial relocation calculations in the
single place - `getRelocTargetVA` function.
- Relocations against both `_gp_disp` and `__gnu_local_gp` symbols
depend on the `_gp` value. It's a magical value points to the "middle"
of GOT. Now all relocations use a common `_gp` value. But in fact,
under some conditions each input file might require its own `_gp`
value. I'm going to implement it in the future patches. So it's
better to make `MipsGotSection` responsible for calculation of
the `_gp` value.
llvm-svn: 298306
This continues detemplation process.
Detemplating MipsGotSection<ELFT> is helpfull because can
help to detemplate getRelocTargetVA. (one more change is required)
It opens road to detemplation of GotSection<ELFT> and probably
something else after that.
Differential revision: https://reviews.llvm.org/D31090
llvm-svn: 298272
This is a safeguard against data loss if the user specifies a directory
that is not a cache directory. Teach the existing cache pruning clients
to create files with appropriate names.
Differential Revision: https://reviews.llvm.org/D31109
llvm-svn: 298271
Does not introduce anything new,
just performs detemplate, using methods we
already have.
Differential revision: https://reviews.llvm.org/D30935
llvm-svn: 298269
We had a few Config member functions that returns configuration values.
For example, we had is64() which returns true if the target is 64-bit.
The return values of these functions are constant and never change.
This patch is to compute them only once to make it clear that they'll
never change.
llvm-svn: 298168
__start_xxx symbol keeps section xxx alive only if it is not
SHF_LINK_ORDER. Such sections can be used for user metadata, when
__start_xxx is used to iterate over section contents at runtime, and
the liveness is determined solely by the linked (associated) section.
This was earlier implemented in r294592, and broken in r296723.
Differential Revision: https://reviews.llvm.org/D30964
llvm-svn: 298154
Summary:
When we perform LTO builds with a version of ar that does not
understand LLVM bitcode objects, we end up with undefined references,
because our archive files do not list the bitcode symbols in their
indices. The error messages do not make it clear what the real problem
is. This change adds a note that points out the likely problem and
solution. It is similar in spirit to r282633, but aims to avoid false
positives by only triggering when we see both undefined references and
archives without symbols in their indices.
Fixes PR32281.
Reviewers: davide, ruiu, tejohnson
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D31011
llvm-svn: 298124
Do not take in account the `Live` flag while collecting .reginfo, .MIPS.options,
and .MIPS.abiflags input sections to produce corresponding output sections.
These sections have information purpose and should be always produced per
ABI requirements.
llvm-svn: 298093
With fix of next warning:
Writer.cpp:361:3: warning: suggest parentheses around assignment used as truth value [-Wparentheses]
Original commit message:
Patch reuses BssSection section to simplify creation of
COMMON section.
Differential revision: https://reviews.llvm.org/D30690
llvm-svn: 298086
This fixes pr32031 by representing the expressions results as a
SectionBase and offset. This allows us to use an input section
directly instead of getting lost trying to compute an offset in an
outputsection when not all the information is available yet.
This also creates a struct to represent the *value* of and expression,
allowing the expression itself to be a simple typedef. I think this is
easier to read and will make it easier to extend the expression
computation to handle more complicated cases.
llvm-svn: 298079
It failed for me under windows,
touch reported invalid date format.
Seems related to 12h/24h format, though
I don't understant why 197001010200 does not work,
but 197001010300 works, I see no logic here.
Changed to 197001011200.
llvm-svn: 298064
Was fixed, details on review page.
Original commit message:
That removes CopyRelSection class completely, making
Bss/BssRelRo to be just regular synthetics.
This is splitted from D30541 and polished.
Difference from D30541 that all logic of SharedSymbol
converting to DefinedRegular was removed for now and
probably will be posted as separate patch.
Differential revision: https://reviews.llvm.org/D30892
llvm-svn: 298062
Patch to fix lld tests after my llvm-objdump patch to fix branch labels for
Thumb targets.
Reviewed by: emaste
Differential Revision: https://reviews.llvm.org/D30986
llvm-svn: 298055
This patch causes us to use pruneCache() to prune the ThinLTO cache after
completing LTO. A new flag --thinlto-cache-policy allows users to configure
the policy.
Differential Revision: https://reviews.llvm.org/D31021
llvm-svn: 298036
The Archive object owns the memory buffers of any thin archive members, so we
need to make sure the object is still in scope when we access archive members.
Differential Revision: https://reviews.llvm.org/D31066
llvm-svn: 298033
After the call to sys::fs::exists succeeds, indicating a cache hit, we call
AddFile and the client will open the file using the supplied path. If the
client is using cache pruning, there is a potential race between the pruner
and the client. To avoid this, change the caching API so that it provides
a MemoryBuffer to the client, and have clients use that MemoryBuffer where
possible.
This scheme won't work with the gold plugin because the plugin API expects a
file path. So we have the gold plugin use the buffer identifier as a path and
live with the race for now. (Note that the gold plugin isn't actually affected
by the problem at the moment because it doesn't support cache pruning.)
This effectively reverts r279883 modulo the change to use the existing path
in the gold plugin.
Differential Revision: https://reviews.llvm.org/D31063
llvm-svn: 298020
The MSVC linker doesn't like archive files containing non-native object
files.
When we are doing an LTO build, we may create archive files containing
both LLVM bitcode files and native object files. For example, if a
project contains assembly files and C++ files, we create native object
files for the assembly files and LLVM bitcode files for the C++ files.
With the /msvclto option, LLD passes archive files to the MSVC linker.
Previously, we didn't pass archive files if they contain at least one
bitcode files. That wasn't correct because the native object files that
weren't passed to the MSVC linker may be needed to complete linking.
In this patch, we create new temporary archive files to strip bitcode
files.
Differential Revision: https://reviews.llvm.org/D31053
llvm-svn: 297997
This test would have been broken if we convert SharedSymbols
to DefinerRegular without saving the symbol version information when
creating .bss/.bss.rel.ro sections for copy relocations.
Relative to D30541, PR32167
llvm-svn: 297948
That allows to detemplate getGotPltOffset/getGotPltVA
methods of SymbolBody and also will help to detemplate
DynamicReloc itself later.
llvm-svn: 297946
Previously we did not have support for writing detailed
module information for each module, as well as the symbol
records. This patch adds support for this, and in doing
so enables the ability to construct minimal PDBs from
just a few lines of YAML. A test is added to illustrate
this functionality.
llvm-svn: 297900
Patch splits In<ELFT> into 2 classes: one for non-templated sections,
second contains ELFT templated ones.
That allows to code that was detemplated to access non-templated sections freely,
and should open road for futher detemplation proccess.
Differential revision: https://reviews.llvm.org/D30939
llvm-svn: 297844
After introducing Config->is64Bit() and
recent changes in LinkerScriptBase, some
sections can be detemplated trivially. This
is one of such cases.
llvm-svn: 297825
StringTableSection was <ELFT> templated previously,
It disallow to de-template code that uses it,
for example LinkerScript<ELFT>::discard uses it as:
if (S == In<ELFT>::ShStrTab)
error("discarding .shstrtab section is not allowed");
It seems we can try to detemplate some of synthetic sections
and somehow make them available for non-templated calls.
(move out of In<ELFT> struct probably).
Differential revision: https://reviews.llvm.org/D30933
llvm-svn: 297815
That removes CopyRelSection class completely, making
Bss/BssRelRo to be just regular synthetics.
This is splitted from D30541 and polished.
Difference from D30541 that all logic of SharedSymbol
converting to DefinedRegular was removed for now and
probably will be posted as separate patch.
Differential revision: https://reviews.llvm.org/D30892
llvm-svn: 297814
Patch introduces Config->is64Bit() and with help of that detemplates
GotPltSection and IgotPltSection sections
Differential revision: https://reviews.llvm.org/D30944
llvm-svn: 297813
D30229 changes the defaults based on section names to match the
GAS behavior, which breaks some of the tests that rely on the old
defaults.
Differential Revision: https://reviews.llvm.org/D30967
llvm-svn: 297803
This also requires postponing the assignment the assignment of
symbols defined in input linker scripts since those can refer to
output sections and in case we don't have a SECTIONS command, we
need to wait until all output sections have been created and
assigned addresses.
Differential Revision: https://reviews.llvm.org/D30851
llvm-svn: 297802
Being passed -z notext is a pretty strong indication that the user is
OK with text relocations. This is not the same behavior as bfd, but
bfd defaults to -z notext, so it has to try to avoid text relocations
and use them as a last resort.
llvm-svn: 297789
That moves all members that s possible to move for now (all which
does not depend on ELFT templating).
After that change LinkerScript contains only 8 methods in total,
and I believe it is possible to move them all after tweaking other
parts of linker. And we will be able to have single class for
linkerscript at the end.
llvm-svn: 297735
We can move all not templated functionality to LinkerScriptBase.
Patch do that for hasPhdrsCommands() and shows how it helps to detemplate
things in other places.
Probably we should be able to merge these 2 classes into single one after such steps.
Even if not, it still looks as reasonable cleanup for me.
Differential revision: https://reviews.llvm.org/D30895
llvm-svn: 297714
lld crashes when .eh_frame or .eh_frame_hdr section is discarded
in linker script and there is no PHDRS directive.
Differential revision: https://reviews.llvm.org/D30885
llvm-svn: 297712
Synthetic sections don't belong to any input file, but still they
are input sections. Whenever problem occurs with relocations in
these sections lld crashes in error reporting, trying to print
input file name.
Differential revision: https://reviews.llvm.org/D30889
llvm-svn: 297711
Previously, it created a temporary directory and then failed when
FileOutputBuffer tried to rename that file to the destination file
(which is actually a directory name).
Differential Revision: https://reviews.llvm.org/D30912
llvm-svn: 297679
Patch from James Henderson.
If a user has a long link, e.g. due to a large LTO link, they do not
wish to run it and find that it failed because there was a mistake in
their command-line, after they waited for some significant amount of
time. This change adds some basic checking of the linker output file
path, which is run shortly after parsing the command-line and linker
script. An error is emitted if LLD cannot write to the specified path.
Differential Revision: https://reviews.llvm.org/D30449
llvm-svn: 297645
Fix a bug introduced in r297313 which caused them to resolve to the end
of the ELF header in PIEs and DSOs.
Differential Revision: https://reviews.llvm.org/D30843
llvm-svn: 297638
Options can start with `-` or `--` unless they start with "o".
Any option that starts with `-o` should be interpreted as an output
file name. This is a quote from the GNU ld man page.
Note -- there is one exception to this rule. Multiple letter
options that start with a lower case 'o' can only be preceded by
two dashes. This is to reduce confusion with the -o option.
So for example -omagic sets the output file name to magic whereas
--omagic sets the NMAGIC flag on the output.
We didn't handle that properly before.
llvm-svn: 297508
Using .eh_frame input section pattern in linker script currently
causes a crash; this is because .eh_frame input sections require
special handling since they're all combined into a synthetic
section rather than regular output section.
Differential Revision: https://reviews.llvm.org/D30627
llvm-svn: 297501
gold linker manual describes them as:
-z text Do not permit relocations in read-only segments
-z notext Permit relocations in read-only segments (default)
In LLD default is to not permit them. Patch implements -z notext.
Differential revision: https://reviews.llvm.org/D30530
llvm-svn: 297366
.eh_frame_hdr is a header constructed for .eh_frame sections.
We do not proccess .eh_frame when doing relocatable output,
so should not try to create .eh_frame_hdr too.
Previous behavior without this patch is segfault.
Fixes PR32118.
Differential revision: https://reviews.llvm.org/D30566
llvm-svn: 297365
Previously, if you have foo=bar in a definition file, this assertion
could fire because when symbols are read from file they could be mangled.
It seems that due to historical reasons underscore mangling scheme is
really ad-hoc, and I cannot find a clean way to handle this. I had
to just de-mangle symbols to search again.
llvm-svn: 297357
With this we have a single section hierarchy. It is a bit less code,
but the main advantage will be in a future patch being able to handle
foo = symbol_in_obj;
in a linker script. Currently that fails since we try to find the
output section of symbol_in_obj. With this we should be able to just
return an InputSection from the expression.
llvm-svn: 297313
This change moves the calls to finalizeContent() for each synthetic section
before createThunks(). This will allow us to assign addresses prior to
calling createThunks(). As addition of thunks may add to the static
symbol table and may affect the size of the mips got section we introduce a
couple of additional member functions to update these values.
Differential revision: https://reviews.llvm.org/D29983
llvm-svn: 297277
Some archive files created during chromium build contains both BC
and native files. If that's the case, we want to pass the archive
file to link.exe. Otherwise, the MSVC linker would complain that
there's an unresolved symbol in a given set of files.
I cannot explain why link.exe doesn't complain about the presence
of bitcode files in this case, but it seems link.exe doesn't touch BC.
llvm-svn: 297229
If /msvclto is specified, we compile bitcode files and pass it to the
MSVC linker, stripping all bitcode files. We haven't stripped archive
files, because I was thinking that the MSVC linker wouldn't touch files
in archive files. When we pass an object file to link.exe, all symbols
have been resolved already, so link.exe shoulnd't need any of the files
in archives.
It turns out that even though link.exe doesn't need to do that, it
seems to try to read each file in all archives. And if there's a non-
COFF file in an archive, it exists with an error message. So we need
to remove archives from the command line too.
llvm-svn: 297191
This change fixes a bug in which the Mips LA25 Thunks are always assigned
to the same Output section as the caller and not the callee as expected.
Differential Revision: https://reviews.llvm.org/D30637
llvm-svn: 297135
This puts us at parity with bfd, which could already gc this case.
I noticed the sections not being gced when linking a modified freebsd
kernel. A section that was not gced and not mentioned in the linker
script would end up breaking the expected layout. Since fixing the gc
is relatively simple and an improvement, that seems better than trying
to hack the orphan placement code.
There are 173 input section in the entire link whose names are valid C
identifiers, so this is probably not too performance critical.
llvm-svn: 297049
In compare with D30458, this makes Bss/BssRelRo to be pure
synthetic sections.
That removes CopyRelSection class completely, making
Bss/BssRelRo to be just regular synthetics.
SharedSymbols involved in creating copy relocations are
converted to DefinedRegular, what also simplifies things.
Differential revision: https://reviews.llvm.org/D30541
llvm-svn: 297008
Prior to MSVC 2015 we had to manually include this header any
time we were going to include <thread> or <future> due to a
bug in MSVC's STL implementation. This has been fixed in MSVC
for some time now, and we require VS 2015 minimum, so we can
remove this across all subprojects.
llvm-svn: 296906
After several smaller patches to get most of the core improvements
finished up, this patch is a straight move and header fixup of
the source.
Differential Revision: https://reviews.llvm.org/D30266
llvm-svn: 296810
We were not gcing any section whose name was a C identifier. Both gold
and bfd only keep those if they are used.
To avoid having to create the __start/__stop symbols early or doing
string lookups in resolvedReloc, this patch just looks for undefined
symbols __start/__stop to decide if a section is needed or not.
llvm-svn: 296723
This patch adds an option named --thinlto-cache-dir, which specifies the
path to a directory in which to cache native object files for ThinLTO
incremental builds.
Differential Revision: https://reviews.llvm.org/D30509
llvm-svn: 296702
That class had three member functions, and all of them are just reader
methods that did not depend on class members, so they can be just non-
member functions.
Probably we should reorganize the functions themselves because their
return types doesn't make much sense to me, but for now I just moved
these functions out of the class.
llvm-svn: 296700
Looks like .gdb.index and its support classes do things that they don't
have to or shouldn't do do. This patch addresses one of these issues.
GdbHashTab class is a hash table class. Just like other in-memory hash
tables, that incrementally updates its internal data and resizes buckets
as new elements are added so that key lookup is always fast.
But that is completely not necessary.
Unlike debuggers, we only produce hash tables for .gdb.index and
never read them. So incrementally updating a hash table in memory is
just a waste of resource and complicates the code. What we should
do is to accumulate symbols and then create the final hash table
at once.
llvm-svn: 296678
In many places we reset Size to 0 before calling assignOffsets()
manually. Sometimes we don't do that.
It looks we can just always do that inside.
Previous code had:
template <class ELFT> void OutputSection::assignOffsets() {
uint64_t Off = Size;
And tests feels fine with Off = 0.
I think Off = Size make no sence.
Differential revision: https://reviews.llvm.org/D30463
llvm-svn: 296609
This implementation is probably slightly inefficient than before,
but that should be negligible because this is not a performance-
critical pass.
llvm-svn: 296570
Previously, LLD merged all read-only sections. So the following
program prints out "true" if -icf=all is specified.
static const int foo = 1;
static const int bar = 1;
int main() { printf("%s\n", &foo == &bar ? "true" : "false"); }
This is somewhat counter-intuitive, and it actually caused nasty issues.
One example is https://bugs.chromium.org/p/chromium/issues/detail?id=682773#c24.
This patch changes the way how it works. Now ICF merges only functions
(i.e. executable sections).
Differential Revision: https://reviews.llvm.org/D30365
llvm-svn: 296534
I do not fully understand why we had these values in the tests, but
the new value matches what ld.bfd and ld.gold set, so I guess that
was just a mistake.
Differential Revision: https://reviews.llvm.org/D30441
llvm-svn: 296505
This reverts commit r296378.
I am pretty sure this is incorrect. In particular, for just
.cfi_startproc
nop
.cfi_endproc
We now add an extra 4 zeros that neither bfd nor gold add.
llvm-svn: 296503
There are many special cases and a layer of abstraction or two in the
way, but the VA calculation in the typical case is actually very simple
and probably makes perfect sense even to somebody new to linkers.
Also, this line brings together many components and is a good place to
start understanding the linker (or improve one's existing
understanding).
llvm-svn: 296451
Naively it seemed at first like getVA had the responsibility of adding
the addend, and getSymVA had the responsibility of getting the symbol
VA.
So it was not obvious to me at first why getVA passes Addend to
getSymVA. In fact, it passes it as a mutable reference.
It turns out that it only matters for SHF_MERGE sections, and in
particular only for STT_SECTION symbols that are used as a hack for
reducing the number of local symbols (e.g. to avoid a local symbol for
each string in the string table).
llvm-svn: 296448
In other places in LLD, we use write32<E> instead of Elf_Word.
This patch uses the same technique in the hash table classes.
The hash table classes needs improving as they have almost no
comments. We at least need to describe the hash table structure
and why we have to support two different on-disk hash tables
for the same purpose. I'll do that later.
llvm-svn: 296439
Previously, these two functions put their symbols in different queues.
Now that the queues have been merged. So there's no point to keep two
separate functions.
llvm-svn: 296435
That function doesn't use any member of SymbolTableSection, so I
couldn't see a reason to make it a member of that class. The function
takes a SymbolBody, so it is more natural to make it a member of
SymbolBody.
llvm-svn: 296433
Previously, there were three conditions: .symtab, .dynsym or we are
producing a relocatable output. Turned out that the third condition is
the same as the first one. This patch removes that third condition and
simplify code.
llvm-svn: 296431
We really need to find a way to get this info from a single point of
truth in the LLVM backend, but it seems that the EM_* constants are
buried deep inside the constructors of the MCAsmBackend's.
For now, just fill in entries as we run into cases. AFAIK these mappings
are largely immutable, so we get a 75% discount on the technical debt
(code is duplicated, but little chance of divergence).
llvm-svn: 296429
The previous code was a bit hard to understand because it unnecessarily
distinguished local and non-local symbols. It had NumLocals member
variable, but that variable didn't have a number of local symbols but
had some value that I cannot describe easily.
This patch rewrites SynbolTableSection::finalizeContents and
SymbolTableSection::writeTo to make it easy to understand. NumLocals
member variable has been removed, and writeGlobalSymbols and
writeLocalSymbols have been merged into one function.
There's still a piece of code that I think unnecessary. I'm not removing
that code in this patch, but will do in a follow-up patch.
llvm-svn: 296423
Before the endianness was specified on each call to read
or write of the StreamReader / StreamWriter, but in practice
it's extremely rare for streams to have data encoded in
multiple different endiannesses, so we should optimize for the
99% use case.
This makes the code cleaner and more general, but otherwise
has NFC.
llvm-svn: 296415
This part of code is hard to understand because NumLocals does not
actually mean the number of local symbols but something else (!).
We need to rewrite. But before that we need to clean it up.
llvm-svn: 296400
This was reverted because it was breaking some builds, and
because of incorrect error code usage. Since the CL was
large and contained many different things, I'm resubmitting
it in pieces.
This portion is NFC, and consists of:
1) Renaming classes to follow a consistent naming convention.
2) Fixing the const-ness of the interface methods.
3) Adding detailed doxygen comments.
4) Fixing a few instances of passing `const BinaryStream& X`. These
are now passed as `BinaryStreamRef X`.
llvm-svn: 296394
Patch by Mark Kettenis.
Currenlty ld.lld does not add a terminator (a CIE with its length field
set to zero) to the .eh_frame sections it generates. While the relevant
standards (the AMD64 SysV ABI and the Linux LSB) are not explicit about
this, such a terminator is expected by some unwinder implementations and
seems to be always emitted by ld.bfd. In addition to that, the Linux LSB
https://refspecs.linuxfoundation.org/LSB_5.0.0/LSB-Core-generic/LSB-Core-generic/ehframechpt.html#EHFRAME
explicitly says that
The .eh_frame section shall contain 1 or more Call Frame Information
(CFI) records.
Currently, if the .eh_frame sections of the input files only contain
terminators, ld.lld emits a zero=sized .eh_frame section
which clearly doesn't meet that requirement.
The diff makes sure a terminator gets added to each .eh_frame section
and adjusts all the relevant tests to account for that. An additional
test isn't needed as these adjustments mean that the existence of the
terminator is tested for by several tests already.
Differential Revision: https://reviews.llvm.org/D30335
llvm-svn: 296378
The list of all input sections was defined in SymbolTable class for a
historical reason. The list itself is not a template. However, because
SymbolTable class is a template, we needed to pass around ELFT to access
the list. This patch moves the list out of the class so that it doesn't
need ELFT.
llvm-svn: 296309
r296215, "[PDB] General improvements to Stream library."
r296217, "Disable BinaryStreamTest.StreamReaderObject temporarily."
r296220, "Re-enable BinaryStreamTest.StreamReaderObject."
r296244, "[PDB] Disable some tests that are breaking bots."
r296249, "Add static_cast to silence -Wc++11-narrowing."
std::errc::no_buffer_space should be used for OS-oriented errors for socket transmission.
(Seek discussions around llvm/xray.)
I could substitute s/no_buffer_space/others/g, but I revert whole them ATM.
Could we define and use LLVM errors there?
llvm-svn: 296258
This adds various new functionality and cleanup surrounding the
use of the Stream library. Major changes include:
* Renaming of all classes for more consistency / meaningfulness
* Addition of some new methods for reading multiple values at once.
* Full suite of unit tests for reader / writer functionality.
* Full set of doxygen comments for all classes.
* Streams now store their own endianness.
* Fixed some bugs in a few of the classes that were discovered
by the unit tests.
llvm-svn: 296215
This is part of a larger effort to get the Stream code moved
up to Support. I don't want to do it in one large patch, in
part because the changes are so big that it will treat everything
as file deletions and add, losing history in the process.
Aside from that though, it's just a good idea in general to
make small changes.
So this change only changes the names of the Stream related
source files, and applies necessary source fix ups.
llvm-svn: 296211
Rui Ueyama