The _gp* family of symbols is defined as an offset in .got, and it is
not at all clear what should happen when .got is not defined.
This will allow some simplifications on how these symbols are handled.
llvm-svn: 266063
It is possible to have FDEs with duplicate PCs if ICF was able to merge
functions with FDEs, or if the input files for some reason contained duplicate
FDEs. We previously weren't handling this correctly when producing the
contents of the .eh_frame_hdr section; we were dropping entries and leaving
null entries at the end of the section, which confused consumers of unwind
data, such as the backtrace() function.
Fix the bug by setting the FDE count to the number of FDEs actually emitted
into .eh_frame_hdr, rather than the number of FDEs in .eh_frame.
Differential Revision: http://reviews.llvm.org/D18911
llvm-svn: 265957
It is possible that the same symbol referenced by two kinds of
relocations at the same time. The first type requires say GOT entry
creation, the second type requires dynamic copy relocation. For MIPS
targets they might be R_MIPS_GOT16 and R_MIPS_HI16 relocations. For X86
target they might be R_386_GOT32 and R_386_32 respectively.
Now LLD never creates GOT entry for a symbol if this symbol already has
related copy relocation. This patch solves this problem.
Differential Revision: http://reviews.llvm.org/D18862
llvm-svn: 265910
Previously, Lazy symbols were created for undefined symbols even though
such symbols cannot be resolved by loading object files. This patch
fixes that bug.
llvm-svn: 265847
Now MustBeInDynSym is only true if the symbol really must be in the
dynamic symbol table.
IsUsedInRegularObj is only true if the symbol is used in a .o or -u. Not
a .so or a .bc.
A benefit is that this is now done almost entirilly during symbol
resolution. The only exception is copy relocations because of aliases.
This includes a small fix in that protected symbols in .so don't force
executable symbols to be exported.
This also opens the way for implementing internalize for -shared.
llvm-svn: 265826
The spec says:
If a symbol definition with STV_PROTECTED visibility from a shared
object is taken as resolving a reference from an executable or another
shared object, the SHN_UNDEF symbol table entry created has STV_DEFAULT
visibility.
llvm-svn: 265792
This patch fixes dynamic relocation creation from GOT access in dynamic
objects on aarch64. Current code creates a plt relative one
(R_AARCH64_JUMP_SLOT) instead of a got relative (R_AARCH64_GLOB_DAT).
It leads the programs fails with:
$ cat t.cc
std::string test = "hello...\n";
int main ()
{
printf ("%s\n", test.c_str());
return 0;
}
$ clang++ t.cc -fpic -o t
$ ./t
hello...
Segmentation fault (core dumped)
Due the fact it will try to access the plt instead of the got for
__cxa_atexit registration for the std::string destruction. It will
lead in a bogus function address in atexit.
llvm-svn: 265784
Previously, we supported only one hash function, FNV-1, so
BuildIdSection directly handled hash computation. In this patch,
I made BuildIdSection an abstract class and defined two subclasses,
BuildIdFnv1 and BuildIdMd5.
llvm-svn: 265737
start-lib and end-lib are options to link object files in the same
semantics as archive files. If an object is in start-lib and end-lib,
the object is linked only when the file is needed to resolve
undefined symbols. That means, if an object is in start-lib and end-lib,
it behaves as if it were in an archive file.
In this patch, I introduced a new notion, LazyObjectFile. That is
analogous to Archive file type, but that works for a single object
file instead of for an archive file.
http://reviews.llvm.org/D18814
llvm-svn: 265710
This requires knowing input section offsets in output sections before
scanRelocs. This is generally a good thing and should allow further
simplifications in the creation of dynamic relocations.
llvm-svn: 265673
Similar to r265462, TLS related relocations aren't marked as relative,
meaning that we end up generating R_AARCH64_RELATIVE relocations for
them. This change adds TLS relocations that I've seen on my system. With
this patch applied CloudABI's unit testing binary now passes on aarch64.
Approved by: ruiu
Differential Revision: http://reviews.llvm.org/D18816
llvm-svn: 265575
We have to differentiate undefined symbols from bitcode and undefined
symbols from other sources.
Undefined symbols from bitcode should not inhibit the symbol being
internalized. Undefined symbols from other sources should.
llvm-svn: 265536
When error, this adds the text line of script to the output
and a marks exact incorrect token under it:
line 1: <error text here>
UNKNOWN_TAG {
^
Differential revision: http://reviews.llvm.org/D18699
llvm-svn: 265523
While trying to get PIE work on CloudABI for x86-64, I noticed that even
though GNU ld would generate functional binaries, LLD would not. It
turns out that we generate relocations for referencing TLS objects
inside of the text segment, which shouldn't happen.
This change extends the isRelRelative() function to list some additional
relocation types that should be treated as relative. This makes my C
library unit testing binary work on x86-64.
Approved by: ruiu
Differential Revision: http://reviews.llvm.org/D18688
Fixes bug: https://llvm.org/bugs/show_bug.cgi?id=27174
llvm-svn: 265462
Where Clang's AArch64 backend seems to differ from the X86 backend is
that it tends to use the GOT more aggressively.
After getting CloudABI PIEs working on x86-64, I noticed that accessing
global variables would still crash on aarch64. Tracing it down, it turns
out that the GOT was filled with entries assuming the base address was
zero.
It turns out that we skip generating relocations for GOT entries in case
the relocation pointing towards the GOT is relative. Whether the thing
pointing to the GOT is absolute or relative shouldn't make any
difference; the GOT entry itself should contain the absolute address,
thus needs a relocation regardless.
Approved by: rafael
Differential Revision: http://reviews.llvm.org/D18739
llvm-svn: 265453
Make sure to copy the MustBeInDynSym field when replacing shared symbols with
bitcode symbols, and when replacing bitcode symbols with regular symbols
in addCombinedLtoObject. Fixes interposition of DSO symbols with bitcode
symbols in the main executable.
Differential Revision: http://reviews.llvm.org/D18780
llvm-svn: 265371
For each copy relocation that we create, look through the DSO's symbol table
for aliases and create a dynamic symbol for each one. This causes the copy
relocation to correctly interpose any aliases.
Copy relocations are relatively uncommon (on my machine, 56% of binaries in
/usr/bin have no copy relocations probably due to being PIEs, 97% of them
have <10, and the binary with the largest number of them has 97) so it's
probably fine to do this in a relatively inefficient way.
Differential Revision: http://reviews.llvm.org/D18731
llvm-svn: 265354
This test didn't actually test the functionality. The new test
verifies that "-verify" is passed if and only if -disable-verify
is not given.
llvm-svn: 265316
The only way to get an object file with symbols marked by the STO_MIPS_PIC
flag is to link PIC and non-PIC object files and generate a relocatable
output using '-r' command line option. Now LLD is able to generate a relocatable
output but does not mark PIC symbols by the STO_MIPS_PIC flag. So I have
to use binary input mips-sto-pic.o generated by GNU BFD linker.
llvm-svn: 265310
Our symbol representation was redundant, and some times would get out of
sync. It had an Elf_Sym, but some fields were copied to SymbolBody.
Different parts of the code were checking the bits in SymbolBody and
others were checking Elf_Sym.
There are two general approaches to fix this:
* Copy the required information and don't store and Elf_Sym.
* Don't copy the information and always use the Elf_Smy.
The second way sounds tempting, but has a big problem: we would have to
template SymbolBody. I started doing it, but it requires templeting
*everything* and creates a bit chicken and egg problem at the driver
where we have to find ELFT before we can create an ArchiveFile for
example.
As much as possible I compared the test differences with what gold and
bfd produce to make sure they are still valid. In most cases we are just
adding hidden visibility to a local symbol, which is harmless.
In most tests this is a small speedup. The only slowdown was scylla
(1.006X). The largest speedup was clang with no --build-id, -O3 or
--gc-sections (i.e.: focus on the relocations): 1.019X.
llvm-svn: 265293
So, there are some cases when the IR Linker produces a broken
module (which doesn't pass the verifier) and we end up asserting
inside the verifier. I think it's always a bug producing a module
which does not pass the verifier but there are some cases in which
people can live with the broken module (e.g. if only DebugInfo
metadata are broken). The gold plugin has something similar.
This commit is motivated by a situation I found in the
wild. It seems that somebody else discovered it independently
and reported in PR24923.
llvm-svn: 265258
We already got this right, but it never hurts adding another
test, in case we'll change the handling in the future, to ensure
we don't break it.
llvm-svn: 265256
Currently we create a file called .lto.bc. In UNIX,
ls(1) by default doesn't show up files starting with
a dot, as they're (only by convention) hidden.
This makes the output of -save-temps a little bit
hard to find. Use "a.out.lto.bc" instead if the
output file is not specified.
While here, change an existing -save-temps test to
exercise this more interesting behaviour.
llvm-svn: 265254
If a symbol is defined in an archive, when we replace its body
the isUsedInRegularObj wasn't set correctly. Internalize makes
its decision based on that bit so we ended up internalizing
symbols that we shouldn't (because they're referenced).
This should fix. Thanks to Peter and Rafael for discussion
and help diagnosing the issue!
Found during LTO of unittests.
llvm-svn: 265208
This fixes bootstrap of llvm-tblgen (with LTO) and PR27150.
Slightly longer explanation follows.
Emission of .init_array instead of .ctors is supported only on a
subset of the Target LLVM supports. Codegen needs to be conservative
and always emit .ctors unless instructed otherwise (based on target).
If the dynamic linker sees .init_array it completely ignores
what's inside .ctors and therefore some constructors are not called
(and this causes llvm-tblgen to crash on startup).
Teach LLD/LTO about the Codegen options so we end up always emitting
.init_array and avoid this issue.
In future, we might end up supporting mix of .ctors and .init_array
in different input files if this shows up as a real-world use case.
The way gold handles this case is mapping .ctors from input into
.init_array in output. There's also another caveat because
as far as I understand .ctors run in reverse order so when we do
the copy/mapping we need to reverse copy in the output if there's
more than one ctor. That's why I'd rather avoid this complicate logic
unless there's a real need.
An analogous reasoning holds for .dtors/.fini_array.
llvm-svn: 265085
Some targets might require creation of thunks. For example, MIPS targets
require stubs to call PIC code from non-PIC one. The patch implements
infrastructure for thunk code creation and provides support for MIPS
LA25 stubs. Any MIPS PIC code function is invoked with its address
in register $t9. So if we have a branch instruction from non-PIC code
to the PIC one we cannot make the jump directly and need to create a small
stub to save the target function address.
See page 3-38 ftp://www.linux-mips.org/pub/linux/mips/doc/ABI/mipsabi.pdf
- In relocation scanning phase we ask target about thunk creation necessity
by calling `TagetInfo::needsThunk` method. The `InputSection` class
maintains list of Symbols requires thunk creation.
- Reassigning offsets performed for each input sections after relocation
scanning complete because position of each section might change due
thunk creation.
- The patch introduces new dedicated value for DefinedSynthetic symbols
DefinedSynthetic::SectionEnd. Synthetic symbol with that value always
points to the end of the corresponding output section. That allows to
escape updating synthetic symbols if output sections sizes changes after
relocation scanning due thunk creation.
- In the `InputSection::writeTo` method we write thunks after corresponding
input section. Each thunk is written by calling `TargetInfo::writeThunk` method.
- The patch supports the only type of thunk code for each target. For now,
it is enough.
Differential Revision: http://reviews.llvm.org/D17934
llvm-svn: 265059
We have to check the final value that is written.
I don't think this has any real word implications (unless something
supports unaligned instructions), but unblocks simplifying the handling
of PC relative relocations.
llvm-svn: 265009
If we make R_MIPS_LO16 a relative relocation, linker:
- never creates R_MIPS_COPY relocation for it
- attempts to create R_MIPS_REL32 dynamic relocation if R_MIPS_LO16's
target is a preemptible symbol
Differential Revision: http://reviews.llvm.org/D18607
llvm-svn: 264956
Windows seems to complain that the file cannot be removed because
it is still in use. We don't have to remove the file but instead
just overwrite it, so do that.
llvm-svn: 264915
This patch add a TLS relax optimization test when transforming
Initial-Exec to Local-Exec for local symbols (which can not be preempted).
llvm-svn: 264903
gold and bfd do not include the undefined locals in symtab.
We have no reasons to support that either.
That fixes PR27016
Differential revision: http://reviews.llvm.org/D18554
llvm-svn: 264843
Local symbol which requires GOT entry initialized by "page" address.
This address is high 16 bits of sum of the symbol value and the relocation
addend. In the relocation scanning phase final values of symbols are unknown
so to reduce number of allocated GOT entries do the following trick. Save
all output sections referenced by GOT relocations during the relocation
scanning phase. Then later in the `GotSection::finalize` method calculate
number of "pages" required to cover all saved output sections and allocate
appropriate number of GOT entries. We assume the worst case - each 64kb
page of the output section has at least one GOT relocation against it.
Differential Revision: http://reviews.llvm.org/D18349
llvm-svn: 264730
When R_X86_64_PC32/R_X86_64_32 relocations are
used against preemptible symbol and output is position independent,
error should be generated.
Differential revision: http://reviews.llvm.org/D18190
llvm-svn: 264707
Some optimizations, e.g. SimplifyLibCalls, can replace functions with
others as part of the lowering, e.g. printf => puts.
The new symbols don't have the isUsedInRegularObj flag set so they
don't get included in the final symbol table (and dynamic symbol
table), and the dynamic linker gets confused. Include them as a fix.
Differential Revision: http://reviews.llvm.org/D18357
llvm-svn: 264688
IPO doesn't work very well across symbols referenced
by others TUs. The linker here tries to evaluate
which symbols are safe to internalize and switches
their linkage.
Differential Revision: http://reviews.llvm.org/D18415
llvm-svn: 264585
This patch simplifies the isRelRelative for AArch64 and add the missing
ones for bootstrap and test-suite. It also adds more testing for
shared object creation.
llvm-svn: 264322
The .o path always makes sure to store a power of 2 value in the
Section alignment. However, the YAML code didn't verify this.
Added verification and updated all the tests which had a 3 but meant
to have 2^3.
llvm-svn: 264228
Ensure we keep the symbol we need to before it reaches
the Writer (and hit an assertion), changing its linkage
from linkonce_odr to weak. For a more detailed description
of the problem, see PR19901 where a similar problem was
fixed for the gold plugin. Thanks to Rafael for providing
a testcase.
llvm-svn: 264111
When a tls access is optimized, a group of relocations is converted at a
time.
We were already skipping relocations that were optimized out in
relocate, but not in scanRelocs.
This is a small optimization. I got here while working on a patch that
will always keep scanRelocs and relocate in sync.
llvm-svn: 264048
Some COFF tests used INT_MIN for the alignment of the directive section.
This is invalid; replace the alignment with something more sensible: 1.
llvm-svn: 263723
-pie
--pic-executable
Create a position independent executable. This is currently only
supported on ELF platforms. Position independent executables are
similar to shared libraries in that they are relocated by the
dynamic linker to the virtual address the OS chooses for them
(which can vary between invocations). Like normal dynamically
linked executables they can be executed and symbols defined in the
executable cannot be overridden by shared libraries.
Differential revision: http://reviews.llvm.org/D18183
llvm-svn: 263693
For now just treat such sections as non-mergeable.
Resubmit r263660 with test fix.
Differential Revision: http://reviews.llvm.org/D18225
llvm-svn: 263664
The current code for processCIE and processFDE returns out if it sees
any references. The problem with this is that some references could be
explicit in the binary, while others are implicit as they can be
inferred from the content of the EHFrame itself.
This change walks the references we have against the references we
need, and verifies that all explicit references are in the correct place,
and generates any missing implicit ones.
Reviewed by Lang Hames and Nick Kledzik.
Differential Revision: http://reviews.llvm.org/D15439
llvm-svn: 263590
This fixes a test which exposed an ASan issue.
We assumed that a symbol's section number had a corresponding section
without performing validation.
llvm-svn: 263558
The load configuration directory is a structure whose size varies as the
OS gains additional functionality. To account for this, the structure's
layout begins with a size field; this allows loaders to know which
fields are available.
However, LLD hard-coded the sizes (112 bytes for 64-bit and 64 for
32-bit). This means that we might not inform the loader of all the
pertinent fields or we might claim that there are more fields than are
actually present.
To correctly account for this, the size field must be loaded from the
_load_config_used symbol.
N.B. The COFF spec is either wrong or out of date, the load
configuration directory is not correctly documented in the
specification: it omits the size field.
llvm-svn: 263543
The TLS directory has a different layout depending on the bitness of the
machine the image will run on. LLD would always use the 64-bit TLS
directory for the data directory entry instead of an appropriately sized
TLS directory.
llvm-svn: 263539
-warn-common
Warn when a common symbol is combined with another common symbol
or with a symbol definition. Unix linkers allow this somewhat
sloppy practice, but linkers on some other operating systems do
not. This option allows you to find potential problems from
combining global symbols.
Differential revision: http://reviews.llvm.org/D17998
llvm-svn: 263413
At least Linux has the kernel configuration to include the first page
of the executable into core files. We want build ID section to be
included in core files to identify them.
Here is the link to the description about the kernel configuration.
097f70b3c4/fs/Kconfig.binfmt (L46)
llvm-svn: 263351
which was reverted because included
unrelative changes by mistake.
Original commit message:
[ELF] - Change all messages to lowercase to be consistent.
That is directly opposite to http://reviews.llvm.org/D18045,
which was reverted.
This patch changes all messages to start from lowercase letter if
they were not before.
That is done to be consistent with clang.
Differential revision: http://reviews.llvm.org/D18085
llvm-svn: 263337
This patch implements --build-id. After the linker creates an output file
in the memory buffer, it computes the FNV1 hash of the resulting file
and set the hash to the .note section as a build-id.
GNU ld and gold have the same feature, but their default choice of the
hash function is different. Their default is SHA1.
We made a deliberate choice to not use a secure hash function for the
sake of performance. Computing a secure hash is slow -- for example,
MD5 throughput is usually 400 MB/s or so. SHA1 is slower than that.
As a result, if you pass --build-id to gold, then the linker becomes about
10% slower than that without the option. We observed a similar degradation
in an experimental implementation of build-id for LLD. On the other hand,
we observed only 1-2% performance degradation with the FNV hash.
Since build-id is not for digital certificate or anything, we think that
a very small probability of collision is acceptable.
We considered using other signals such as using input file timestamps as
inputs to a secure hash function. But such signals would have an issue
with build reproducibility (if you build a binary from the same source
tree using the same toolchain, the build id should become the same.)
GNU linkers accepts --build-id=<style> option where style is one of
"MD5", "SHA1", or an arbitrary hex string. That option is out of scope
of this patch.
http://reviews.llvm.org/D18091
llvm-svn: 263292
That is directly opposite to http://reviews.llvm.org/D18045,
which was reverted.
This patch changes all messages to start from lowercase letter if
they were not before.
That is done to be consistent with clang.
Differential revision: http://reviews.llvm.org/D18085
llvm-svn: 263252
It was discussed to make all messages be
lowercase to be consistent with clang.
(also reverts the r263128 which fixed
build bot fail after r263125)
Original commit message:
[ELF] - Consistent spelling for error/warning messages
Previously error and warnings were not consistent in lld.
Some of them started from lowercase letter, others from
uppercase. Also there was one or two which had a dot at the end.
This patch changes all messages to start from uppercase letter if
they were not before.
Differential revision: http://reviews.llvm.org/D18045
llvm-svn: 263240
This is reduced from an issue found in practice.
The original version of D18012 needed another patch to handle this, but
it now works since we are using a more correct GV->hasAppendingLinkage()
check that Rafael suggested.
This is what remains of that other patch.
llvm-svn: 263181
Summary:
More generally, appending linkage is a special case that we don't want
to create a SymbolBody for.
Reviewers: rafael, ruiu
Subscribers: Bigcheese, llvm-commits, joker.eph
Differential Revision: http://reviews.llvm.org/D18012
llvm-svn: 263179
R_X86_64_DTPOFF64 was not handled properly.
Next sample app was impossible to link before this patch:
~/pg/release/bin/clang -target x86_64-pc-linux testthread.cpp -c -g
~/pg/d+a/bin/ld.lld testthread.o
"Unknown TLS optimization" (value was 17)
__thread int x = 0;
void _start() {
}
It works fine now.
Differential revision: http://reviews.llvm.org/D18039
llvm-svn: 263150
(http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/builds/8662).
Test fails on linux only.
Original commit message:
[ELF] - Consistent spelling for error/warning messages
Previously error and warnings were not consistent in lld.
Some of them started from lowercase letter, others from
uppercase. Also there was one or two which had a dot at the end.
This patch changes all messages to start from uppercase letter if
they were not before.
Differential revision: http://reviews.llvm.org/D18045
llvm-svn: 263128
Previously error and warnings were not consistent in lld.
Some of them started from lowercase letter, others from
uppercase. Also there was one or two which had a dot at the end.
This patch changes all messages to start from uppercase letter if
they were not before.
Differential revision: http://reviews.llvm.org/D18045
llvm-svn: 263125
Summary:
They are needed for inline asm during LTO.
In particular we hit the report_fatal_error on
llvm/lib/CodeGen/AsmPrinter/AsmPrinterInlineAsm.cpp:138
LLVM ERROR: Inline asm not supported by this streamer because we don't have an asm parser for this target
Reviewers: ruiu, rafael
Subscribers: Bigcheese, llvm-commits, joker.eph
Differential Revision: http://reviews.llvm.org/D18027
llvm-svn: 263094
Summary:
This implements another part of -save-temps.
After this, the only remaining part is dumping the optimized bitcode. But
currently LLD's LTO doesn't have a non-intrusive place to put this.
Eventually we probably will and it will make sense to add it then.
Reviewers: ruiu, rafael
Subscribers: joker.eph, Bigcheese, llvm-commits
Differential Revision: http://reviews.llvm.org/D18009
llvm-svn: 263070
Summary:
This is useful for debugging issues with LTO.
The option follows the analogous option in ld64 and the gold plugin (per
Rafael's suggestion).
For starters, this only dumps the combined bitcode file.
In a future patch I will add dumping for the .o file.
The naming of the output follows ld64's convention which is slightly more
consistent IMO (consistent `.lto.<extension>` for all the files).
Reviewers: rafael, ruiu
Subscribers: joker.eph, Bigcheese, llvm-commits
Differential Revision: http://reviews.llvm.org/D18006
llvm-svn: 263055
Summary:
At the very least we hit
Assertion failed: (((Flags & RF_HaveUnmaterializedMetadata) || Node->isResolved()) && "Unexpected unresolved node"), function MapMetadataImpl, file /Users/Sean/pg/llvm/lib/Transforms/Utils/ValueMapper.cpp, line 375.
on the included test case.
We currently do things like parse the module twice to keep the
implementation minimal. I think it makes sense to add start with eager
loading for similar reasons.
Reviewers: rafael
Subscribers: ruiu, Bigcheese, llvm-commits, joker.eph
Differential Revision: http://reviews.llvm.org/D17982
llvm-svn: 263045
Each object file compiled in split stack mode will have an empty
section with a special name: .note.GNU-split-stack
We don't support this in linker now, so patch just adds an error out for that.
Differential revision: http://reviews.llvm.org/D17918
llvm-svn: 263039
Summary:
Is there any other code needed for correctly handling appending linkage?
Do we need to do something more with @llvm.global_ctors in
SymbolTable.cpp:addBitcodeFile; otherwise the combined bitcode module
won't have all the global ctors.
Reviewers: rafael
Subscribers: Bigcheese, llvm-commits, joker.eph
Differential Revision: http://reviews.llvm.org/D17975
llvm-svn: 262992
Summary:
This causes the issue in PR26872 to go away now that we aren't creating
symbols for the string literals, but that may just be concealing a
deeper problem, so best to keep that PR open.
Reviewers: rafael
Subscribers: Bigcheese, llvm-commits, joker.eph
Differential Revision: http://reviews.llvm.org/D17971
llvm-svn: 262968
It was a badly specified hack for when a tls relocation should be
propagated to the dynamic relocation table.
This replaces it with a not as bad hack of saying that a local dynamic
tls relocation is never preempted.
I will try to remove even that second hack in the next patch.
llvm-svn: 262955
It was causing errors like
/lib/libc.so.6 is incompatible with elf_x86_64
when linking on Fedora.
Every system has different default paths. It seems better to just trust
the driver to pass the correct -L options.
This reverts commit 262910.
llvm-svn: 262941
This has a few advantages:
* If lld selected a non bitcode symbol, be the bitcode GV is not merged
* lib/Linker is not redoing symbol resolution.
llvm-svn: 262773
When generating relocatable output SHT_NOBITS sections
were still occupy the file space.
Differential revision: http://reviews.llvm.org/D17857
llvm-svn: 262650
The hack of using a plt address as the address of an undefined function
only works in executables. Don't try it with shared libraries.
llvm-svn: 262642
There was a known limitation for -r option:
relocations against local symbols were not supported.
For example rel[a].eh_frame sections contained relocations against sections
and that was not supported for -r before. Patch fixes that.
Differential review: http://reviews.llvm.org/D17813
llvm-svn: 262590
The patch fixes two related problems:
- If CIE augmentation string has 'L' token the CIE contains a byte
defines LSDA encoding. We should skip this byte in `getFdeEncoding`
routine. Before this fix we do not skip it and if the next token
is 'R' treat this byte as FDE encoding.
- FDE encoding format has separate flags e.g. DW_EH_PE_pcrel for
definition of relative pointers. We should add .eh_frame address to
the PC value iif the DW_EH_PE_pcrel is specified.
http://www.airs.com/blog/archives/460
There is one more not fixed problem in this code. If PC value is encoded
using signed relative format e.g. DW_EH_PE_sdata4 | DW_EH_PE_pcrel we
should sign extend result of read32 to perform calculation correctly.
I am going to fix that in a separate patch.
Differential Revision: http://reviews.llvm.org/D17733
llvm-svn: 262461
CoreDriver implements a driver for a hypothetical platform.
It is intended to be used in unittests. However, it is actually
redundant because the features are tested using the real driver
for the real platforms. So we can remove this.
http://reviews.llvm.org/D17698
llvm-svn: 262421
__start_/__end_ <section-name> symbols and other specials like:
preinit_array_start/end
init_array_start/end
fini_array_start/end
should not be created by linker when creating relocatable files.
Differential revision: http://reviews.llvm.org/D17774
llvm-svn: 262366
BSD linker scripts contain special cases to add NOP
padding to code sections. Syntax is next:
.init:
{
KEEP (*(.init))
} =0x90909090
(0x90 is NOP)
This patch implements that functionality.
llvm-svn: 262020
https://docs.oracle.com/cd/E53394_01/html/E54766/u-etext-3c.html
It is said that:
_etext - The address of _etext is the first
location after the last read-only loadable segment.
_edata - The address of _edata is the first
location after the last read-write loadable segment.
_end - If the address of _edata is greater than the address
of _etext, the address of _end is same as the address of _edata.
In real life _end and _edata has different values for that case.
Both gold/bfd set _edata to the end of the last non SHT_NOBITS section.
This patch do the same for consistency.
It should fix the https://llvm.org/bugs/show_bug.cgi?id=26729.
Differential revision: http://reviews.llvm.org/D17601
llvm-svn: 262019
For shared libraries we allow any weak undefined symbol to eventually be
resolved, even if we never see a definition in another .so. This matches
the behavior when handling other undefined symbols in a shared library.
For executables, we require seeing a definition in a .so or resolve it
to zero. This is also similar to how non weak symbols are handled.
llvm-svn: 262017
R_MIPS_GOT16 relocation against local symbol requires index of a local
GOT entry which contains page address corresponds to sum of the symbol
address and addend. The addend in that case is calculated using addends
from the R_MIPS_GOT16 and paired R_MIPS_LO16 relocations.
Differential Revision: http://reviews.llvm.org/D17610
llvm-svn: 261930
This patch implements the same algorithm as LLD/COFF's ICF. I'm
not going to repeat the same description about how it works, so you
want to read the comment in ICF.cpp in this patch if you want to know
the details. This algorithm should be more powerful than the ICF
algorithm implemented in GNU gold. It can even merge mutually-recursive
functions (which is harder than one might think).
ICF is a fairly effective size optimization. Here are some examples.
LLD: 37.14 MB -> 35.80 MB (-3.6%)
Clang: 59.41 MB -> 57.80 MB (-2.7%)
The lacking feature is "safe" version of ICF. This merges all
identical sections. That is not compatible with a C/C++ language
requirement that two distinct functions must have distinct addresses.
But as long as your program do not rely on the pointer equality
(which is in many cases true), your program should work with the
feature. LLD works fine for example.
GNU gold implements so-called "safe ICF" that identifies functions
that are safe to merge by heuristics -- for example, gold thinks
that constructors are safe to merge because there is no way to
take an address of a constructor in C++. We have a different idea
which David Majnemer suggested that we add NOPs at beginning of
merged functions so that two or more pointers can have distinct
values. We can do whichever we want, but this patch does not
include neither.
http://reviews.llvm.org/D17529
llvm-svn: 261912
-r, -relocatable - Generate relocatable output
Currently does not have support for files containing
relocation sections with entries that refer to local
symbols (like rel[a].eh_frame which refer to sections
and not to symbols)
Differential revision: http://reviews.llvm.org/D14382
llvm-svn: 261838
This commit does two related thing. At first, it enumerates supported
absolute MIPS relocations in the `MipsTargetInfo<ELFT>::isRelRelative`
method. In that case the code is shorter and the case switch does not
tend to grow. At second, it prevents R_MIPS_COPY and PLT creation for
relative relocations. For almost all relative MIPS relocations like
R_MIPS_PC19_S2, R_MIPS_PCHI16 etc it does not have a sence. The only
exception is R_MIPS_PC32. GNU linker creates a copy relocation or PLT
entry for it. But I could not find any real test case uses R_MIPS_PC32
with DSO defined symbol as a target. So for now I prefer to skip this
case to simplify the LLD code.
llvm-svn: 261822
This test is flaky for more than half a year or so on buildbots
and has been causing confusion. Remove it while I'm investing the
cause.
llvm-svn: 261709
There is nothing aarch64 specific in here. If a symbol can be preempted,
we need to copy the full relocation to the dynamic linker.
If a symbol cannot be preempted, we can make the dynamic linker life
easier and produce a relative relocation.
This is directly equivalent to R_X86_64_64 to R_x86_64_RELATIVE
conversion.
llvm-svn: 261678
The .tbss section is in the middle of a PT_LOAD. Whatever treatment we
give to its address we must also give to the offset.
We were ignoring it for address computations, but not for offset.
Fixes pr26712.
llvm-svn: 261667
This patch moves BitcodeFile instantiation into createObjectFile.
Previously, we handle bitcode files outside that function and did
not handle for --whole-archive.
http://reviews.llvm.org/D17527
llvm-svn: 261663
This patch fixes the R_AARCH64_ABS64 relocation when used in shared mode,
where it requires a dynamic R_AARCH64_RELATIVE relocation. To correct set
the addend on the dynamic relocation (since it will be used by the dynamic
linker), a new TargetInfo specific hook was created (getDynRelativeAddend)
to get the correct addend based on relocation type.
The patch fixes the issues when creating shared library code against
{init,fini}_array, where it issues R_AARCH64_ABS64 relocation against
local symbols.
llvm-svn: 261651
When link-time garbage collection is in use (-gc-sections), it is
often useful to mark sections that should not be eliminated.
This is accomplished by surrounding an input section's wildcard
entry with KEEP(). Patch implements that command.
Differential revision: http://reviews.llvm.org/D17242
llvm-svn: 261616
A weak undefined should not fetch archive members, so we have to keep
the Lazy symbol.
That means the lazy symbol has to encode information about the original
weak undef.
Fixes pr25762.
llvm-svn: 261591
This reduces the .rodata of scyladb from 4501932 to 4334639 bytes (1.038
times smaller).
I don't think it is critical to support tail merging, just exact
duplicates, but given the code organization it was actually a bit easier
to support both.
llvm-svn: 261327
Each rule in SECTIONS commands is something like ".foo *(.baz.*)",
which instructs the linker to collect all sections whose name matches
".baz.*" from all files and put them into .foo section.
Previously, we didn't recognize the wildcard character. This patch
adds that feature.
Performance impact is a bit concerning because a linker script can
contain hundreds of SECTIONS rules, and doing pattern matching against
each rule would be too expensive. We could merge all patterns into
single DFA so that it takes O(n) to the input size. However, it is
probably too much at this moment -- we don't know whether the
performance of pattern matching matters or not. So I chose to
implement the simplest algorithm in this patch. I hope this simple
pattern matcher is sufficient.
llvm-svn: 260745
This patch adds some TLS relocations and relaxations for AArch64.
Some Global-Dynamic relocation are handled by optimizing them to
Local-Exec (Initial-Exec is not yet supported). They are:
- R_AARCH64_TLSDESC_ADR_PAGE21
- R_AARCH64_TLSDESC_LD64_LO12_NC
- R_AARCH64_TLSDESC_ADD_LO12_NC
- R_AARCH64_TLSDESC_CALL
Also some Init-Exec is optimized to Local-Exec if possible. They are:
- R_AARCH64_TLSIE_ADR_GOTTPREL_PAGE21
- R_AARCH64_TLSIE_LD64_GOTTPREL_LO12_NC
Finally some Local-Exec relocation are handled in relocateOne:
- R_AARCH64_TLSLE_ADD_TPREL_HI12
- R_AARCH64_TLSLE_ADD_TPREL_LO12_NC
This work is mainly for compiler bootstrap, where static binaries is
showing good progress (although shared object still lacking support
from both TLS aarch64 backend and some other issues).
llvm-svn: 260677
Previously, if both A and B are ".ctors", both compCtors(A, B) and
compCtors(B, A) are true, which is a violation of the strict weak
ordering because such function is not antisymmetric.
llvm-svn: 260633
They don't count for the memory or file size, so this is mostly just a
simplification.
The only noticeable difference should be fewer empty program headers.
llvm-svn: 260465
Global constructors and destructors are guaranteed to be called
in the order as they appear in a translation unit. So we don't want
to mess up the order if they have the same priority.
llvm-svn: 260463
The patch adds lazy relocation support for MIPS and R_MIPS_26 relocation
handing.
R_MIPS_26 relocation might require PLT entry creation. In that case it
is fully supported by the patch. But if the relocation target is a local
symbol we need to use a different expression to calculate the relocation
result. This case is not implemented yet because there is no method to
get know the kind of relocation target in the `relocateOne` routine.
Differential Revision: http://reviews.llvm.org/D16982
llvm-svn: 260424
The non lazy atoms generated in the stubs pass use an image cache to
hold all of the pointers. On arm archs, this is the __got section,
but on x86 archs it should be __nl_symbol_ptr.
rdar://problem/24572729
llvm-svn: 260271
ld64 aligns most of the stub's to 2 byte alignment, expect for
the stub helper common atoms which are 4 byte aligned.
This adds a new field to StubInfo which tracks this alignment
and ensures that this is the alignment we get in the final image.
rdar://problem/24570220
llvm-svn: 260248
This is the function equivalent of a copy relocation.
Since functions are expected to change sizes, we cannot use copy
relocations. In situations where one would be needed, what is done
instead is:
* Create a plt entry
* Output an undefined symbol whose addr is the plt entry.
The dynamic linker makes sure any shared library uses the plt entry as
the function address.
llvm-svn: 260224
Also added the defaults for whether to generate this load command, which
the cmdline options are able to override.
There was also a difference to ld64 which is fixed here in that ld64 will
generate an empty data in code command if requested.
rdar://problem/24472630
llvm-svn: 260191
This load command generates data in the LINKEDIT section which
is a list of ULEB128 delta's to all of the functions in the __text section.
It is then 0 terminated and pointer aligned to pad.
ld64 exposes the -function-starts and no-function-starts cmdline options
to override behaviour from the defaults based on file types.
rdar://problem/24472630
llvm-svn: 260188
This was a bug in our handling of these symbols compared to ld64.
Turns out that ld64 always marks these symbols as being not dead stripped.
llvm-svn: 260185
The initial segment protection was also being used to set the maximum
segment protection level. Instead, the maximum should be set according
to the architecture we are linking. For example on Mac OS it should be
RWX on most pages, but on iOS is often on R_X.
rdar://problem/24515136
llvm-svn: 259966
I removed "CIE/FIE size is too large" error because that was not
checking for correct error conditions. [UINT_MAX - 4, UINT_MAX) is
a correct range as a size of a CIE/FDE record. It's just that the
size cannot be larger than the section size.
llvm-svn: 259951
Summary:
LLVM3.3 (and earlier) would fail to include a relocation section in
the group that the section it was relocating is in. Object files
affected by this issue have been encountered in the wild when using LLD.
This would result in a siutation like:
Section {
Index: 5
Name: .text._Z3fooIiEvv (6)
Type: SHT_PROGBITS (0x1)
Flags [ (0x206)
SHF_ALLOC (0x2)
SHF_EXECINSTR (0x4)
SHF_GROUP (0x200)
]
Address: 0x0
Offset: 0x48
Size: 5
Link: 0
Info: 0
AddressAlignment: 1
EntrySize: 0
}
Section {
Index: 6
Name: .rela.text._Z3fooIiEvv (1)
Type: SHT_RELA (0x4)
Flags [ (0x0)
]
Address: 0x0
Offset: 0x3F0
Size: 24
Link: 8
Info: 5
AddressAlignment: 8
EntrySize: 24
}
In LLD, during symbol resolution, we discard the section containing the
weak symbol, but this amounts to replacing it with
InputSection<ELFT>::Discarded.
When we later saw the corresponding relocation section, we would then
end up pusing onto InputSection<ELFT>::Discarded.RelocSections, which is
bogus.
Reviewers: ruiu, rafael
Subscribers: llvm-commits, Bigcheese
Differential Revision: http://reviews.llvm.org/D16898
llvm-svn: 259831
On Mac OS 10.5 and later, with X86_64 and outputting a dynamic executable,
ld64 set the CPU_SUBTYPE_LIB64 mask on the cpusubtype in the mach_header.
This adds the same functionality to lld.
rdar://problem/24507177
llvm-svn: 259826
If relocation against symbol requires GOT entry creation and this symbol
is defined in DSO, the GOT entry should be created in the 'global' part
of the GOT even if we link executable file. Also we do not need to create
a dynamic symbol table entry for global symbol corresponding to the
local GOT entry.
llvm-svn: 259778
ld64 sets both S_ATTR_PURE_INSTRUCTIONS and S_ATTR_SOME_INSTRUCTIONS
on __TEXT, __text. We only had the S_ATTR_PURE_INSTRUCTIONS attribute.
rdar://problem/24495801
llvm-svn: 259744
In the case where we are emitting to an object file, the platform is
possibly unknown, and the source object files contained load commands
for version min, we can take the maximum of those min versions and
emit in in the output object file.
This test also tests r259739.
llvm-svn: 259742
This option is emitted in the min_version load commands.
Note, there's currently a difference in behaviour compared to ld64 in
that we emit a warning if we generate a min_version load command and
didn't give an sdk_version. We need to decide what the correct behaviour
is here as its possible we want to emit an error and force clients to
provide the option.
llvm-svn: 259729
If the command line contains something like -macosx_version_min and we
don't explicitly disable generation with -no_version_load_command then
we generate the LC_VERSION_MIN command in the output file.
There's a couple of FIXME's in here. These will be handled soon with
more tests but I didn't want to grow this patch any more than it already was.
rdar://problem/24472630
llvm-svn: 259718
On some Windows environment, this test did not fail, because opening NUL
with FileOutputBuffer didn't fail. Thanks to George Rimar for reporting.
llvm-svn: 259669
It can fail to open an output file for various reasons, including
lack of permission, too long filename, or the output file is not
a mmap'able file.
llvm-svn: 259596
In r259574 I fixed some of the issues with the mach header symbols
and DSO handles.
This is the next issue whereby the __mh_execute_header has to not
be dead stripped, and (to match ld64) should be dynamically referenced.
The test here should also have been added in r259574 to make sure that
we emit this symbol. But checking that it is not only emitted but also
has the correct reference type is fine.
llvm-svn: 259589
The magic file which contained these symbols inherited from archive
which meant that the resolver didn't add the required atoms as archive
members only get added when referenced. Instead we now inherit from
SimpleFile which always links in the atoms needed.
The second issue was in the handling of these symbols when we emit
the MachO. The mach header symbol needs to be in the atom list as
it gets an offset (0), and being in the atom list makes sure it is
emitted to the symbol table. DSO handles are not emitted to the
symbol table.
rdar://problem/24450654
llvm-svn: 259574
Previously, we used both single quotes and double quotes, and
some single-quoted tokens are concatenated with next tokens because
there were no spaces between them. That may be a cause of test flakiness
on Windows, which is reported as https://llvm.org/bugs/show_bug.cgi?id=26388.
The new test commands are more straightforward than before.
llvm-svn: 259559
This patch adds "Error" field to LinkerScript class. That field
is false by default, and set to true if there is a syntax error
in an input file. The linker script parser is a recursive-descedent
parser. Each function returns if Error is true -- so that
eventually the whole parser returns to a caller.
http://reviews.llvm.org/D16667
llvm-svn: 259557
-Bsymbolic-functions:
When creating a shared library, bind references to global
function symbols to the definition within the shared library, if any.
This patch also fixed behavior of already existent -Bsymbolic:
previously PLT entries were created even if -Bsymbolic was specified.
Differential revision: http://reviews.llvm.org/D16411
llvm-svn: 259481
Some dynamic table tags like RELSZ and PLTRELSZ depens on result of
finalizing corresponding relocation sections. Therefore we have to
finalize .dynamic section at the end.
Differential Revision: http://reviews.llvm.org/D16799
llvm-svn: 259478
If object files are drawn from archive files, the error message should
be something like "conflict symbols in foo.a(bar.o) and baz.o" instead
of "conflict symbols in bar.o and baz.o". This patch implements that.
llvm-svn: 259475
When we parse a MachoFile, we set a number of members from the parsed
file, for example, subsectionsViaSymbols.
However, a number of passes, such as ObjCPass, create local copies of
MachoFile and don't get the benefit of setting flags and other fields in
the parser. Instead we can just give a more sensible default as the parser
will definitely get the correct value from the file anyway.
llvm-svn: 259426
__DATA, __objc_catlist contains a list of pointers to categories.
We want to atomize it so that the ObjC pass can later optimize and remove
categories. That will be a later patch.
llvm-svn: 259386
This avoids the need to have reserve and addString in sync.
We avoid hashing the global symbols again. This means that we don't
merge a global symbol that has the same name as some other string, but
that doesn't seem very common. The string table size is the same in
clang an scylladb with or without hashing global symbols again.
llvm-svn: 259136
Main executable did not export symbols that exist both in the main executable and in DSOs before this patch.
Symbols from object files that override symbols in DSO should be added to .dynsym table.
Differential revision: http://reviews.llvm.org/D16405
llvm-svn: 258672
There was an off by one error because the StringRef.substr functions
second argument is a length, not the end index.
Also updated a few ELF files which failed when run on Jenkins with paths
including the @ character. This is often used in Jenkins for shared
workspace plugin.
Reviewed by Rui Ueyama
llvm-svn: 258583
This option matches the behaviour of ld64, that is it prevents globals
from being dead stripped in executables and dylibs.
Reviewed by Lang Hames
Differential Revision: http://reviews.llvm.org/D16026
llvm-svn: 258554
Some MIPS relocation (for now R_MIPS_GOT16) requires creation of GOT
entries for symbol not included in the dynamic symbol table. They are
local symbols and non-local symbols with 'local' visibility. Local GOT
entries occupy continuous block between GOT header and regular GOT
entries.
The patch adds initial support for handling local GOT entries. The main
problem is allocating local GOT entries for local symbols. Such entries
should be initialized by high 16-bit of the symbol value. In ideal world
there should be no duplicated entries with the same values. But at the
moment of the `Writer::scanRelocs` call we do not know a value of the
symbol. In this patch we create new local GOT entry for each relocation
against local symbol, though we can exhaust GOT quickly. That needs to
be optimized later. When we calculate relocation we know a final symbol
value and request local GOT entry index. To do that we maintain map
between addresses and local GOT entry indexes. If we start to calculate
relocations in parallel we will have to serialize access to this map.
Differential Revision: http://reviews.llvm.org/D16324
llvm-svn: 258388
This pass currently emits an objc image info section if one is required.
This section contains the aggregated version and flags for all of the input
files.
llvm-svn: 258197
Like arch, os, etc, when we know we are going to use a file, we check
that the file has compatible objc constraints to the context, throw
appropriate errors where that is not the case, and hopefully set the
objc constraints on the context for use later.
Added 2 tests to ensure that we don't have incompatibilities between
host and simulator code as both will get x86 based architectures.
llvm-svn: 258173
When generating a relocatable file, its only valid to set this flag if
all of the inputs also had the flag. Otherwise we may atomize incorrectly
when we link the relocatable file again.
Reviewed by Lang Hames.
Differential Revision: http://reviews.llvm.org/D16018
llvm-svn: 257976
The image info struct contains flags for what kind of GC/retain/release is required.
Give an error if we parse GC flags as these are unsupported.
llvm-svn: 257974
This file was failing to build with asan enabled. The reason being that
applyFixupFinal was writing 4-bytes worth of fixup in to an atom only
a single byte in length.
The test case didn't actually need this particular reloc so i've removed
it, although i'll follow up with future commits to actually verify that
relocs are to an address with enough space for the fixup to be applied.
llvm-svn: 257906
Added check for terminator CIE/FDE which has zero data size.
void EHOutputSection<ELFT>::addSectionAux(
...
// If CIE/FDE data length is zero then Length is 4, this
// shall be considered a terminator and processing shall end.
if (Length == 4)
break;
...
After this "Bug 25923 - lld/ELF2 linked application crashes if exceptions were used." is fixed for me. Self link of clang also works.
Initial commit message:
[ELF] - implemented --eh-frame-hdr command line option.
--eh-frame-hdr
Request creation of ".eh_frame_hdr" section and ELF "PT_GNU_EH_FRAME" segment header.
Both gold and the GNU linker support an option --eh-frame-hdr which tell them to construct a header for all the .eh_frame sections. This header is placed in a section named .eh_frame_hdr and also in a PT_GNU_EH_FRAME segment. At runtime the unwinder can find all the PT_GNU_EH_FRAME segments by calling dl_iterate_phdr.
This section contains a lookup table for quick binary search of FDEs.
Detailed info can be found here:
http://www.airs.com/blog/archives/462
Differential revision: http://reviews.llvm.org/D15712
llvm-svn: 257889
This patch makes use of the handleLoadedFile hook added in r257814.
That method is used to check the arch and the OS of the files we are linking
against the arch and OS on the context.
The first test to use this ensures that we do not try to combine i386 Mac OS code
with i386 simulator code.
llvm-svn: 257837
MIPS ABI has relocations like R_MIPS_JALR which is just a hint for
linker to make some code optimization. Such relocations should not be
handled as a regular ones and lead to say dynamic relocation creation.
The patch introduces new virtual `Target::isHintReloc` method, overrides
it in the `MipsTargetInfo` class and calls it in the `Writer<ELFT>::scanRelocs`
method.
Differential Revision: http://reviews.llvm.org/D16193
llvm-svn: 257798
Simon Atanasyan