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
Looks like it is not allowed to have an .rst file in this directory
that does not belong to a document tree. I don't know why. This patch
adds a file back to fix a bot.
llvm-svn: 296087
__ehdr_start should be pointing to ELF file headers, not program
headers.
This is a reland of D30319.
Differential Revision: https://reviews.llvm.org/D30323
llvm-svn: 296085
Summary: Creates bitcode files suitable for use with ThinLTO, then checks that the linker can build an executable from them.
Reviewers: ruiu, pcc
Reviewed By: pcc
Subscribers: mehdi_amini, Prazek, llvm-commits
Differential Revision: https://reviews.llvm.org/D30277
llvm-svn: 296042
With this we complete the transition out of special output sections,
and with the previous patches it should be possible to merge
OutputSectionBase and OuputSection.
llvm-svn: 296023
With the current design an InputSection is basically anything that
goes directly in a OutputSection. That includes plain input section
but also synthetic sections, so this should probably not be a
template.
llvm-svn: 295993
For functions the linker uses a related hack: creating a plt in the
main executable that preempts the function.
Like bfd and gold, we don't disable it with nocopyreloc.
llvm-svn: 295976
We have InputSection, MergeInputSection and EhInputSection, so
isa<MergeInputSection> is equivalent to !isa<InputSection> && !isa<
EhInputSection>.
llvm-svn: 295937
We shouldn't report an error for R_*_NONE relocs since we're emitting
them when writing relocations to discarded sections.
Differential Revision: https://reviews.llvm.org/D30279
llvm-svn: 295936
I really do not understand what is going on on some Windows buildbots,
but FileCheck command on some buildbot behaves like long lines were
truncated. I'll try to find a cause of the issue, but let me relax the
test so that they'll succeed on all buildbots.
llvm-svn: 295798
I added this log message to test the /msvclto option, but
this output might confuse FileCheck. This patch attempts to fix
it by removing it.
llvm-svn: 295793
LLD is a multi-threaded program. errs() or outs() are not guaranteed
to be thread-safe (they are actually not).
LLD's message(), log() or error() are thread-safe. We should use them.
llvm-svn: 295787
This change exposes the symbol table insert method and uses it to
insert the linkerscript defined symbols directly into the symbol
table to avoid unnecessarily pulling the object out of an archive.
Differential Revision: https://reviews.llvm.org/D30224
llvm-svn: 295780
Patch fixes PR32024.
Sections that were not marked as Live has null output section.
Previously we tried to access that field and segfaulted.
Differential revision: https://reviews.llvm.org/D30188
llvm-svn: 295727
r295240 tweaked LLD to generate a symbol table when passing in
--export-dynamic, even when creating static executables. Add a test to
make sure this never regresses.
Reviewed by: ruiu, rafael
Differential Revision: https://reviews.llvm.org/D30175
llvm-svn: 295725
Previously we evaluated the values of LMA incorrectly for next cases:
.text : AT(ADDR(.text) - 0xffffffff80000000) { ... }
.data : AT(ADDR(.data) - 0xffffffff80000000) { ... }
.init.begin : AT(ADDR(.init.begin) - 0xffffffff80000000) { ... }
Reason was that we evaluated offset when VA was not assigned. For case above
we ended up with 3 loads that has similar LMA and it was incorrect.
That is critical for linux kernel.
Patch updates the offset after VA calculation. That fixes the issue.
Differential revision: https://reviews.llvm.org/D30163
llvm-svn: 295722
Previously LLD would error out just "ld.lld: error: unable to move location counter backward"
What does not really reveal the place of issue,
Patch adds location to the output.
Differential revision: https://reviews.llvm.org/D30187
llvm-svn: 295720
Previously ASSERT we implemented returned expression value.
Ex:
. = ASSERT(0x100);
would set Dot value to 0x100
Form of assert when it is assigned to Dot was implemented for
compatibility with very old GNU ld which required it.
Some scripts in the wild, including linux kernel scripts
use such ASSERTs at the end for doing different checks.
Currently we fail with "unable to move location counter backward"
for such scripts. Patch changes ASSERT to return location counter
value to fix that.
Differential revision: https://reviews.llvm.org/D30171
llvm-svn: 295703
This change moves the SymbolBodies with isLocal() == true before the global
symbols then calculating NumLocals rather than assuming all locals are
added before globals and the first NumLocals have isLocal() == true. This
permits Thunks to be moved after the pass that adds global symbols from
synthetics to the symbol table.
Differential revision: https://reviews.llvm.org/D30085
llvm-svn: 295650
Behavior races on ErrorCount. If the enqueued paths are evaluated
eagerly (in enqueuePath) then the behavior is as the test expects. But
they may not be evaluated until the future is waited on, in run() -
which is after the early return/exit on ErrorCount. (this causes the
test to fail (because in the "/ERRORCOUNT:XYZ" test, no other errors
are printed), at least for me, on linux)
This reverts commit r295507.
llvm-svn: 295590
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.
Reviewers: pcc, ruiu
Reviewed By: ruiu
Differential Revision: https://reviews.llvm.org/D29691
llvm-svn: 295507
Previously LLD crashed on on provided testcases because "/DISCARD/" was
not supported. Patch implements that.
After this I think there is no known issues with --emit-relocs implementation
required for linux kernel linking.
Differential revision: https://reviews.llvm.org/D29273
llvm-svn: 295488
I splitted it from D29273.
Since we plan to make relocatable sections as dependent for target ones for
--emit-relocs implementation, this change is required to support .eh_frame case.
EhInputSection inherets from InputSectionBase and not from InputSection.
So for case when it has relocation section, it should be able to access DependentSections
vector.
This case is real for Linux kernel.
Differential revision: https://reviews.llvm.org/D30084
llvm-svn: 295483
This is a small difference I noticed to gold and bfd. When given
--print-gc-sections, we print sections a linkerscript marks
DISCARD. The other linkers don't.
llvm-svn: 295467
This case should be possible to handle, but it is hard:
* In order to create program headers correctly, we have to scan the
sections in the order they are in the file.
* To find that order, we have to "execute" the linker script.
* The linker script can contain SIZEOF_HEADERS.
So to support this we have to start with a guess of how many headers
we need (3), run the linker script and try to create the program
headers. If it turns out we need more headers, we run the script again
with a larger SIZEOF_HEADERS.
Also, running the linker script depends on knowing the size of the
sections, so we have to finalize them. But creating the program
headers can change the value stored in some sections, so we have to
split size finalization and content finalization.
Looks like the last part is also needed for range extension thunks, so
we might support this at some point. For now just report an error
instead of producing broken files.
llvm-svn: 295458
Without this we would produce two relocation sections pointing to the
same section, which gnu tools reject.
This fixes pr31986.
The implementation of -r/--emit-reloc is getting fairly
complicated. But lets get the test passing before trying to refactor
it.
llvm-svn: 295385
Some PDBs or object files can contain references to other PDBs
where the real type information lives. When this happens,
all type indices in the original PDB are meaningless because
their records are not there.
With this patch we add the ability to pull type info from those
secondary PDBs.
Differential Revision: https://reviews.llvm.org/D29973
llvm-svn: 295382
SHF_LINK_ORDER sections adds special ordering requirements.
Such sections references other sections. Previously we would crash
if section that other were referenced to was discarded by script.
Patch fixes that by discarding all dependent sections in that case.
It supports chained dependencies, testcase is provided.
Differential revision: https://reviews.llvm.org/D30033
llvm-svn: 295332
Unfortunately, the common way of writing linker scripts seems to be
to get the output of ld.bfd --verbose and edit it a bit.
Also unfortunately, the bfd default script contains things like
.rela.dyn : { *(... .rela.data ...) }
but bfd actually ignores that for -emit-relocs, so we have to do the
same.
llvm-svn: 295324
That fixes a case when section has more than one metadata
section. Previously GC would collect one of such sections
because we had implementation that stored only last one as
dependent.
Differential revision: https://reviews.llvm.org/D29981
llvm-svn: 295298
This patch removes NeedsCopyOrPltAddr and instead add two variables,
NeedsCopy and NeedsPltAddr. This uses one more bit in Symbol class,
but the actual size doesn't increase because we had unused bits.
This should improve code readability.
llvm-svn: 295287
This is slightly inefficient than the previous code, but that is really
negligible as this function is usually called at most only a few times.
llvm-svn: 295282
Previously, space in a BSS section for copy relocations are reserved
in a special way. We directly manipulated size of the BSS section.
r294577 changed the way of doing it. Now, we create an instance of
CopyRelSection (which is a synthetic input section) for each copy
relocation.
This patch removes the remains of the old way and add CopyRelSections
to BSS sections using `addSections` function, which is the usual
way to add an input section to an output section.
llvm-svn: 295278
In the target dependent code we already always return a int64_t. In
the target independent code we carefully use uintX_t, which has the
same result given 2 complement rules.
This just simplifies the code to use int64_t everywhere.
llvm-svn: 295263
For CloudABI I'm only interested in generating non-PIC/PIE executables
on armv6 and i686, as PIE introduces larger overhead than on aarch64 and
x86_64. Still, I want to be able to instruct the linker to generate a
dynamic symbol table if requested. One example use for this is that
dynamic symbol tables can be used by programs to print nicely formatted
stacktraces, including symbol names.
Right now there seems to be some logic in LLD that it only wants to emit
dynamic symbol tables when either linking against libraries or when
building PIC. Let's extend this to also take --export-dynamic into
account.
Reviewed by: ruiu
Differential Revision: https://reviews.llvm.org/D29982
llvm-svn: 295240
The linker script lexer is context-sensitive. In the regular context,
arithmetic operator characters are regular characters, but in the
expression context, they are independent tokens. This afects how the
lexer tokenizes "3*4", for example. (This kind of expression is real;
the Linux kernel uses it.)
This patch defines function `maybeSplitExpr`. This function splits the
current token into multiple expression tokens if the lexer is in the
expression context.
Differential Revision: https://reviews.llvm.org/D29963
llvm-svn: 295225
Main intention of test was to check that
we do not crash, but for additional check
it previously run readobj for input object
instead of output.
llvm-svn: 295161
If target of R_MIPS_GOT16 relocation is a local symbol its addend
is high 16 bits of complete addend. To calculate a final value, the addend
of this relocation is read, shifted to the left and combined with addend
of paired R_MIPS_LO16 relocation. To save updated addend when the linker
produces a relocatable output, we need to store high 16 bits of the
addend's value. It is different from the case of writing the relocation
result when the linker saves a 16-bit GOT index as-is.
llvm-svn: 295159
This is still not sufficient for lld to handle its own output when a
fde points to a discarded section. I am investigating if it is better
to change the -r output or make lld able to read the current version.
llvm-svn: 295141
This is a really horrible case. If a .eh_frame points to a discarded
section, it is not clear what is the correct thing to do.
It looks like ld.bfd discards the entire .eh_frame content and gold
discards the second relocation, leaving one frame with an fde that
refers to a bogus location. This is similar to what gold does.
llvm-svn: 295133
This reverts commit r295102.
In the link of seabios the assumption seems to be that the section has
an actual address, so this is not sufficient. Changing the assembly
code to add a "a" flag seems like the correct thing to do instead of
extending this hack.
Sorry about the noise.
Original message:
Relax the restriction on what relocations can be in a non-alloc section.
The main thing that they can't have is relocations that require the
creation of gots or plt. For now also accept R_PC.
Found while linking seabios.
llvm-svn: 295130
The main thing that they can't have is relocations that require the
creation of gots or plt. For now also accept R_PC.
Found while linking seabios.
llvm-svn: 295102
If we had SHT_GROUP sections, then when -r was used we might crash.
This is PR31952.
Issue happened because we emited relocation section though its target was discared
because was a member of duplicated group. When we tried to get VA of target,
segfault happened.
Core cause is the bug that GNU as 2.27 (and probably later versions) has.
In compare with llvm-mc, it does not include relocation sections into the group,
like shown in testcase. This patch covers that case.
Differential revision: https://reviews.llvm.org/D29929
llvm-svn: 295067
Patch makes addends for addends of R_386_8, R_386_16 relocations
be sign extended.
The same we did earlier for PC ones,
currenly LLD fails to link linux kernel,
reporting relocation out of range because of this.
Differential revision: https://reviews.llvm.org/D29714
llvm-svn: 295052
Unfortunately some consumers of our .o files produced with -r expect
only one section symbol per section. That is true of at least of go's
own linker.
Combining them is a somewhat convoluted process. We have to create a
symbol for every section since we don't know which ones will be
needed. The relocation sections also have to be written first to
handle the Elf_Rel addend.
I did consider a completely different approach:
We could remove the -r special case of relocation sections when
reading. We would instead have a copyRelocs function that is used
instead of scanRelocs. It would create a DynamicReloc for each
relocation and a RelocationSection for each input relocation section.
A complication of such change is that DynamicReloc would have to take
a section index and a input section instead of a symbol since with
-emit-relocs some DynamicReloc would hold relocations referring to the
dynamic symbol table and other to the static symbol table.
That would be a pretty big change, and if we do it it is probably
better to do it as a refactoring.
llvm-svn: 294816
LLVM defines `PTHREAD_LIB` which is used by AddLLVM.cmake and various projects
to correctly link the threading library when needed. Unfortunately
`PTHREAD_LIB` is defined by LLVM's `config-ix.cmake` file which isn't installed
and therefore can't be used when configuring out-of-tree builds. This causes
such builds to fail since `pthread` isn't being correctly linked.
This patch attempts to fix that problem by renaming and exporting
`LLVM_PTHREAD_LIB` as part of`LLVMConfig.cmake`. I renamed `PTHREAD_LIB`
because It seemed likely to cause collisions with downstream users of
`LLVMConfig.cmake`.
llvm-svn: 294690
Much of the code in PltSection and IPltSection is similar, we identify
the IPlt by a HeaderSize of 0 and alter our behaviour in the member
functions appropriately:
-Iplt does not have a header
-Iplt always follows after the Plt
Differential Revision: https://reviews.llvm.org/D29664
llvm-svn: 294579
When we need a copy relocation we create a synthetic SHT_NOBITS
section that contains the right amount of ZI and assign it to either
.bss or .rel.ro.bss as appropriate. This allows the dynamic relocation
to be placed on the InputSection, removing the last case where a
dynamic relocation is stored as an offset from the OutputSection. This
has the side effect that we can run assignOffsets() after scanRelocs()
without losing the additional ZI needed for the copy relocations.
Differential Revision: https://reviews.llvm.org/D29637
llvm-svn: 294577
Fix the test zlib conditional to use LLVM_ENABLE_ZLIB value when
building stand-alone. The HAVE_LIBZ is not available when performing
a stand-alone build. Since the zlib support is a feature of
the underlying LLVM library, it exports the actual status as the final
value of LLVM_ENABLE_ZLIB in LLVMConfig.
While at it, canonicalize the boolean value into 0/1 and remove unused
CMake definitions (most likely copied from clang).
Differential Revision: https://reviews.llvm.org/D29340
llvm-svn: 294508
Use both LLD- and LLVM-specific binary&library directories when LLD is
being built stand-alone. This ensures that the freshly built tools and
libraries are found and used correctly.
Without this patch, the test suite uses LLVM_TOOLS_DIR and LLVM_LIBS_DIR
to locate lld, and set PATH and LD_LIBRARY_PATH. When doing
a stand-alone builds, these variables represent the installed LLVM.
As a result, tests either fail due to missing lld executables/libraries
or use an earlier installed LLD version rather than the one being built.
To solve this, an additional LLD_TOOLS_DIR and LLD_LIBS_DIR variables
are added that are populated using LLVM_*_OUTPUT_INTDIR. Those variables
are populated with directories used to output built executables
and libraries. In stand-alone builds, they represent the directories
used by LLD. In integrated builds, they have the same values as
LLVM_*_DIR and therefore using them does not harm.
The new variables are prepended to PATH and LD_LIBRARY_PATH to ensure
that freshly built binaries are preferred over potentially earlier
installed ones. Furthermore, the resulting PATH is used to locate tools
for substitutions since the search includes both tools built as part of
LLD and of LLVM.
Differential Revision: https://reviews.llvm.org/D29335
llvm-svn: 294507
The test is failing on the bot because "/subsystem:console" was
truncated for some reason. I don't know why that is happening on
that machine (it is not reproducible on my Windows machine).
In this patch, I'm trying to tame it by making the output shorter.
llvm-svn: 294502
Summary: This adds an option to save temporary files generated during link-time optimization. This can be useful for debugging.
Reviewers: ruiu, pcc
Reviewed By: ruiu, pcc
Subscribers: mehdi_amini
Differential Revision: https://reviews.llvm.org/D29518
llvm-svn: 294498
with temporarily file name fix in testcase.
Original commit message:
-q, --emit-relocs - Generate relocations in output
Simplest implementation:
* no GC case,
* no "/DISCARD/" linkerscript command support.
This patch is extracted from D28612 / D29636,
Relative to PR31579.
Differential revision: https://reviews.llvm.org/D29663
llvm-svn: 294469
-q, --emit-relocs - Generate relocations in output
Simplest implementation:
* no GC case,
* no "/DISCARD/" linkerscript command support.
This patch is extracted from D28612 / D29636,
Relative to PR31579.
Differential revision: https://reviews.llvm.org/D29663
llvm-svn: 294464
OUTPUT_ARCH command can contain architecture values separated with ":", like:
OUTPUT_ARCH(i386:x86-64)
We did not support that, because got 3 lexer tokens here after recent changes.
This trivial patch fixes the issue, now whole expression inside
OUTPUT_ARCH is just ignored.
Differential revision: https://reviews.llvm.org/D29640
llvm-svn: 294432
LLD already parses ALIGN expression to specifiy alignment for output
sections in linker scripts but it never applies the alignment to the
output section. This change handles that.
Differential Revision: https://reviews.llvm.org/D29689
llvm-svn: 294374
DefinedSynthetic symbols are attached to sections,
for the case when such symbol was attached to non-allocated section,
we calculated its value incorrectly.
We subtracted Body->Section->Addr, but non-allocatable sections
should have zero VA in output and therefore result value was wrong.
And at the same time we have Body->Section->Addr != 0 for them
internally because use it for calculation of section size.
Patch fixes calculation of such symbols values.
Differential revision: https://reviews.llvm.org/D29653
llvm-svn: 294322
We had assignSymbol and assignSectionSymbol methods which has similar functionality.
Patch removes one of copy and reuses another in code.
Differential revision: https://reviews.llvm.org/D29582
llvm-svn: 294290
Previously we did not do that. For example, for R_386_PC8,
0xFF addend was not treated as 0xFFFFFFFF(-1),
but was 0x000000FF.
Recently added checks for R_386_PC8/R_386_PC16 failed because of calculation
overflow as a result.
Differential revision: https://reviews.llvm.org/D29490
llvm-svn: 294289
If `/debugtypes` is used to omit the codeview information, we would not
have constructed the debug info codeview record which is used to tie the
PDB to the binary. In such a case, rub out the GUID and Age fields.
llvm-svn: 294279
If relocations don't have addends, addends are embedded in operands.
getImplicitAddend is a function to read addends. Addends can be
negative numbers, so the return type of the function should be a
signed integer type.
llvm-svn: 294253
We now create a dummy section with index 1 before processing the
linker script.
Thanks to George Rimar for finding the bug and providing the initial
testcase.
llvm-svn: 294252
This patch defines a new command line option, /MSVCLTO, to LLD.
If that option is given, LLD invokes link.exe to link LTO-generated
object files. This is hacky but useful because link.exe can create
PDB files.
Differential Revision: https://reviews.llvm.org/D29526
llvm-svn: 294234
This is a fix for Bugzilla 31813.
The problem is that the tokenizer does not create a separate token for
":" unless there's white space before it. Changed it to always create
a token for ":" and reworked some logic that relied on ":" being
attached to some tokens like "global:" and "local:".
llvm-svn: 294006
With a synthetic merge section we can have, for example, a single
.rodata section with stings, fixed sized constants and non merge
constants.
I can be simplified further by not setting Entsize, but that is
probably better done is a followup patch.
This should allow some cleanup in the linker script code now that
every output section command maps to just one output section.
llvm-svn: 294005
This reverts commit r293970.
After more discussion, this belongs to the linker side and
there is no added value to do it at this level.
llvm-svn: 293993
When a symbol is not exported outside of the
DSO, it is can be hidden. Usually we try to internalize
as much as possible, but it is not always possible, for
instance a symbol can be referenced outside of the LTO
unit, or there can be cross-module reference in ThinLTO.
This is a recommit of r293912 after fixing build failures,
and a recommit of r293918 after fixing LLD tests.
Differential Revision: https://reviews.llvm.org/D28978
llvm-svn: 293970
Summary: The COFF linker previously implemented link-time optimization using an API which has now been marked as legacy. This change refactors the COFF linker to use the new LTO API, which is also used by the ELF linker.
Reviewers: pcc, ruiu
Reviewed By: pcc
Subscribers: mgorny, mehdi_amini
Differential Revision: https://reviews.llvm.org/D29059
llvm-svn: 293967
Summary: llvm/CodeGen/CommandFlags.h a utility function InitTargetOptionsFromCodeGenFlags which is used to set target options from flags based on the command line. The command line flags are stored in globals defined in the same file, and including the file in multiple places causes the globals to be defined multiple times, leading to linker errors. This change adds a single place in lld where these globals are defined and exports only the utility function. This makes it possible to call InitTargetOptionsFromCodeGenFlags from multiple places in lld, which a follow-up change will do.
Reviewers: davide, ruiu
Reviewed By: davide, ruiu
Subscribers: mgorny
Differential Revision: https://reviews.llvm.org/D29058
llvm-svn: 293965
Instead of creating multiple PHDRs in a single loop, this patch
runs one for loop for each PHDR type. I think this improves code
readability.
llvm-svn: 293832
Previously, mergeTypeStreams returns only true or false, so it was
impossible to know the reason if it failed. This patch changes the
function signature so that it returns an Error object.
Differential Revision: https://reviews.llvm.org/D29362
llvm-svn: 293820
There could be multiple discontiguous output .note sections in which
case we need to put these into separate PT_NOTE segments rather then
placing them into a single segment. Where possible, we could reorder
the input sections to make sure that all .note are layed out next to
each other to avoid creation multiple PT_NOTE segments, but even in
that case, it's still possible to construct a discontiguous case e.g.
by using a linker script.
Differential Revision: https://reviews.llvm.org/D29364
llvm-svn: 293811
This is a fix for Bugzilla 28579.
The problem is that in --reproduce links the file path in -o option is
copied verbatim. When "lld @response.txt" link is run against the
extracted test case, if -o contains anything other that a plain file
name, the link will likely fail because the target directory in -o may
not exists. Stripping the directory path will create the output file
in the top level test directory.
Patch by Dmitry Mikulin!
llvm-svn: 293792
Thunks are now implemented by redirecting the relocation to the
symbol S, to a symbol TS in a Thunk. The Thunk will transfer control
to S. This has the following implications:
- All the side-effects of Thunks happen within createThunks()
- Thunks are no longer stored in InputSections and Symbols no longer
need to hold a pointer to a Thunk
- The synthetic Thunk sections need to be merged into OutputSections
This implementation is almost a direct conversion of the existing
Thunks with the following exceptions:
- Mips LA25 Thunks are placed before the InputSection that defines
the symbol that needs a Thunk.
- All ARM Thunks are placed at the end of the OutputSection of the
first caller to the Thunk.
Range extension Thunks are not supported yet so it is optimistically
assumed that all Thunks can be reused.
This is a recommit of r293283 with a fixed comparison predicate as
std::merge requires a strict weak ordering.
Differential revision: https://reviews.llvm.org/D29327
llvm-svn: 293757
This is alternative to D28857 which was incorrect.
One of linux scripts contains:
vvar_start = . - 2 * (1 << 12);
vvar_page = vvar_start;
vvar_vsyscall_gtod_data = vvar_page + 128;
Previously we did not mark first expression as non-absolute,
though it contains location counter.
And LLD failed with error:
relocation R_X86_64_PC32 cannot refer to absolute symbol
This patch should fix the issue, and opens road for doing the same for other operators
(though not clear if that is needed).
Differential revision: https://reviews.llvm.org/D29332
llvm-svn: 293748
Previously, we were printing out something like this for
sections/symbols with alignment 16
0000000000201000 0000000000000182 10 .data
which I think confusing. I think printing it in decimal is better.
Differential Revision: https://reviews.llvm.org/D29258
llvm-svn: 293685
It is not clear what we should do when overflow occurs for these
relocations because the relocations are not an official part of
the i386 psABI. But checking for overflow is generally a good to do
and is consistent with other relocations such as R_X86_64_8.
llvm-svn: 293683
Our reporting for that case was just like:
ld.lld: error: do not know how to handle relocation 'R_386_PC8' (23)
It did not give any information about error location.
Patch adds filename to error.
Differential revision: https://reviews.llvm.org/D29282
llvm-svn: 293640
Add the CMake bits necessary to run lld tests (and unittests) when
building stand-alone. The code is based on the equivalent code in clang,
and includes:
1. checking for Python, searching for lit and necessary LLVM test tools
(FileCount and not),
2. building LLVM test tools (FileCount and not) from LLVM sources if
they are not installed,
3. building gtest libraries from LLVM sources,
4. adjusting dependencies so that test targets depend only on those LLVM
targets that are available for a particular variant of stand-alone
build.
With this patch, I am able to successfully run 1002 (+10 unsupported)
lit tests on Gentoo using installed LLVM.
Differential Revision: https://reviews.llvm.org/D28750
llvm-svn: 293630
Linux kernel linkerscript contains additional semicolon (last line):
.apicdrivers : AT(ADDR(.apicdrivers) - LOAD_OFFSET) {
__apicdrivers = .;
*(.apicdrivers);
I checked that both gold and bfd are able to parse something like:
.text : { ;;*(.text);;S = 0;; } }
Patch do the same.
Differential revision: https://reviews.llvm.org/D29276
llvm-svn: 293612
If no bss sections appear after the relro segment, the loader will round
the r/w segment size to the target's page size. Align the relro size in the
same way to ensure that it does not extend past the end of the program's
own memory region.
Differential Revision: https://reviews.llvm.org/D29242
llvm-svn: 293519
ld.bfd showed error on previous inputs, result values were larger than 8/16 bits,
though ld.gold accepted them.
ABI says "The R_386_16, and R_386_8 relocations truncate the computed
value to 16-bits and 8-bits respectively".
Patch changes inputs to have result calculated values of relocations to fit 8 and 16 bits.
That can be used for implementation of more strict checks, like bfd do.
Differential revision: https://reviews.llvm.org/D29270
llvm-svn: 293479
The symbols _end, end, _etext, etext, _edata, edata and __ehdr_start
refer to positions in the file and are therefore not absolute. Making
them absolute was on unfortunate cargo cult of what bfd was doing.
Changing the symbols allows for pc relocations to them to be resolved,
which should fix the wine build.
llvm-svn: 293385
[ELF] Fixed formatting. NFC
and
[ELF] Bypass section type check
Differential revision: https://reviews.llvm.org/D28761
They do the opposite of what was asked for in the code review.
llvm-svn: 293320
Now reportUndefined only has to look at Config->UnresolvedSymbols and
the symbol. getUnresolvedSymbolOption does all the hard work of
mapping options like -shared and -z defs to one of the
UnresolvedPolicy enum entries.
The critical fix is that now "-z defs --warn-unresolved-symbols" only
warns.
llvm-svn: 293290
Thunks are now implemented by redirecting the relocation to the
symbol S, to a symbol TS in a Thunk. The Thunk will transfer control
to S. This has the following implications:
- All the side-effects of Thunks happen within createThunks()
- Thunks are no longer stored in InputSections and Symbols no longer
need to hold a pointer to a Thunk
- The synthetic Thunk sections need to be merged into OutputSections
This implementation is almost a direct conversion of the existing
Thunks with the following exceptions:
- Mips LA25 Thunks are placed before the InputSection that defines
the symbol that needs a Thunk.
- All ARM Thunks are placed at the end of the OutputSection of the
first caller to the Thunk.
Range extension Thunks are not supported yet so it is optimistically
assumed that all Thunks can be reused.
Differential Revision: https://reviews.llvm.org/D29129
llvm-svn: 293283
Currently LLVM can only generate PIC code for MIPS64 with the N64 as
it uses the idiom "isPositionIndependent() || IsABI_N64()" throughout the
MIPS backend. r293164 changed this, causing test failures for LLD.
This patch changes the tests minimally to preserve existing test coverage
and one case where the test was "right" in the wrong circumstance.
Reviewers: atanasyan
Differential Revision: https://reviews.llvm.org/D29194
llvm-svn: 293275
Summary: MSVC allows linker options to be specified in source code. One of these is the /INCLUDE directive, which specifies that a symbol must be added to the symbol table, even if it otherwise wouldn't be. Existing tests cover the case where the linker is given an object file with an /INCLUDE directive, but we also need to cover the case where /INCLUDE is specified in a bitcode file (as would happen when using LTO). This new test covers that case.
Reviewers: pcc, ruiu
Reviewed By: ruiu
Differential Revision: https://reviews.llvm.org/D29096
llvm-svn: 293107
Rui Ueyama