This support is slightly different then the X86_64 implementation in that calls
to __morestack don't need to get rewritten to calls to __moresatck_non_split
when a split-stack caller calls a non-split-stack callee. Instead the size of
the stack frame requested by the caller is adjusted prior to the call to
__morestack. The size the stack-frame will be adjusted by is tune-able through a
new --split-stack-adjust-size option.
Differential Revision: https://reviews.llvm.org/D52099
llvm-svn: 344544
This is https://bugs.llvm.org/show_bug.cgi?id=39289.
Currently both gold and bfd report errors about invalid options values
even with -v/-versions. But LLD does not.
This makes complicated to check the options available when LLD is used.
Patch makes LLD behavior to be consistent with GNU linkers.
Differential revision: https://reviews.llvm.org/D53278
llvm-svn: 344514
`Type` parameter was used only to check for TLS attribute mismatch,
but we can do that when we actually replace symbols, so we don't need
to type as an argument. This change should simplify the interface of
the symbol table a bit.
llvm-svn: 344394
Android uses a compressed relocation format, which means the size of the
relocation section isn't predictable based on the number of relocations,
and can vary if the layout changes in any way. To deal with this, the
linker normally runs multiple passes until the layout converges.
The layout should converge if the size of the compressed
relocation section increases monotonically: if the size of an encoded
offset increases by one byte, the larget value which can be encoded is
multiplied by 128, so the representable offsets grow much faster than
the size of the section itself.
The problem here is that there is no code to ensure the size of the
section doesn't decrease. If the size of the relocation section
decreases, the relative offsets can increase due to alignment
restrictions, so that can force the size of the relocation section to
increase again. The end result is an infinite loop; the loop gets cut
off after 10 iterations with the message "thunk creation not
converged".
To avoid this issue, this patch adds padding to the end of the
relocation section if its size would decrease. The extra
padding is harmless because of the way the format is defined:
decoding stops after it reaches the number of relocations specified
in the section's header.
Differential Revision: https://reviews.llvm.org/D53003
llvm-svn: 344300
This is https://bugs.llvm.org/show_bug.cgi?id=37538,
Currently, LLD may set both sh_link and sh_info for
.rela.plt section to zero when we have only .rela.iplt section part used.
ELF spec (https://docs.oracle.com/cd/E19683-01/816-1386/chapter6-94076/index.html)
says that for SHT_REL and SHT_RELA, sh_link references the associated symbol table
and sh_info the "section to which the relocation applies."
When we set the sh_link field, for the regular case we use the .dynsym index.
For .rela.iplt sections, it is unclear what is the associated symbol table,
because R_*_RELATIVE relocations do not use symbol names and we might have no
.dynsym section at all so this patch uses .symtab section index.
Differential revision: https://reviews.llvm.org/D52830
llvm-svn: 344226
Summary:
Add a condition UnresolvedPolicy::Ignore to elf::warnUnorderedSymbol to suppress Sym->isUndefined() warnings from both
1) --symbol-ordering-file=
2) .llvm.call-graph-profile
If --unresolved-symbols=ignore-all is used,
no "undefined symbol" error/warning is emitted. It makes sense to not warn unorderable symbols.
Otherwise,
If an executable is linked, the default policy UnresolvedPolicy::ErrorOrWarn will issue a "undefined symbol" error. The unorderable symbol warning is redundant.
If a shared object is linked, it is possible that only part of object files are used and some symbols are left undefined. The warning is not very necessary.
In particular for .llvm.call-graph-profile, when linking a shared object, a call graph profile may contain undefined symbols. This case generated a warning before but it will be suppressed by this patch.
Reviewers: ruiu, davidxl, espindola
Reviewed By: ruiu
Subscribers: grimar, emaste, arichardson, llvm-commits
Differential Revision: https://reviews.llvm.org/D53044
llvm-svn: 344195
Summary: Before, OptTable::PrintHelp append "[options] <inputs>" to its parameter `Help`. It is more flexible to change its semantic to `Usage` and let user customize the usage line.
Reviewers: rupprecht, ruiu, espindola
Reviewed By: rupprecht
Subscribers: emaste, sbc100, arichardson, aheejin, llvm-commits
Differential Revision: https://reviews.llvm.org/D53054
llvm-svn: 344099
Previously, we cast a pointer to Elf{32,64}_Chdr like this
auto *Hdr = reinterpret_cast<const ELF64_Chdr>(Ptr);
and read from its members like this
read32(&Hdr->ch_size);
I was thinking that this does not violate alignment requirement,
since &Hdr->ch_size doesn't really access memory, but seems like
it is a violation in terms of C++ spec (?)
In this patch, I use a different struct that allows unaligned access.
llvm-svn: 344083
`SymbolTable` is a singleton class and is a global variable for the
unique instance, so we can always refer the symtab by `Symtab->`.
However, we don't need to use the global varaible from member functions
of SymbolTable class.
llvm-svn: 344075
Previously, we uncompress all compressed sections before doing anything.
That works, and that is conceptually simple, but that could results in
a waste of CPU time and memory if uncompressed sections are then
discarded or just copied to the output buffer.
In particular, if .debug_gnu_pub{names,types} are compressed and if no
-gdb-index option is given, we wasted CPU and memory because we
uncompress them into newly allocated bufers and then memcpy the buffers
to the output buffer. That temporary buffer was redundant.
This patch changes how to uncompress sections. Now, compressed sections
are uncompressed lazily. To do that, `Data` member of `InputSectionBase`
is now hidden from outside, and `data()` accessor automatically expands
an compressed buffer if necessary.
If no one calls `data()`, then `writeTo()` directly uncompresses
compressed data into the output buffer. That eliminates the redundant
memory allocation and redundant memcpy.
This patch significantly reduces memory consumption (20 GiB max RSS to
15 Gib) for an executable whose .debug_gnu_pub{names,types} are in total
5 GiB in an uncompressed form.
Differential Revision: https://reviews.llvm.org/D52917
llvm-svn: 343979
The GOT is referenced through the symbol _GLOBAL_OFFSET_TABLE_ .
The relocation added calculates the offset into the global offset table for
the entry of a symbol. In order to get the correct TargetVA I needed to
create an new relocation expression, HEXAGON_GOT. It does
Sym.getGotVA() - In.GotPlt->getVA().
Differential Revision: https://reviews.llvm.org/D52744
llvm-svn: 343784
r320770 made LLD handle invalid DSOs where local symbols were found in
the global part of the symbol table. Unfortunately, it didn't handle the
case where those local symbols were also undefined, and r326242 exposed
an assertion failure in that case. Just warn on that case instead of
crashing, by moving the local binding check before the undefined symbol
addition.
The input file for the test is crafted by hand, since I don't know of
any tool that would produce such a broken DSO. I also don't understand
what it even means for a symbol to be undefined but have STB_LOCAL
binding - I don't think that combination makes any sense - but we have
found broken DSOs of this nature that we were linking against. I've
included detailed instructions on how to produce the DSO in the test.
Differential Revision: https://reviews.llvm.org/D52815
llvm-svn: 343745
This patch splits ThunkCreator::mergeThunks into two smaller functions.
Also adds blank lines to various places so that the code doesn't look
too dense.
llvm-svn: 343732
This is the fix for
"Bug 39104 - LLD links incorrect ELF executable if version script contains "local: *;"
(https://bugs.llvm.org/show_bug.cgi?id=39104).
The issue happens when we have non-PIC program call to function in a shared library.
(for example, the PR above has R_X86_64_PC32 relocation against __libc_start_main)
LLD converts symbol to Defined in that case with the use of replaceWithDefined()
The issue is that after above we create a broken relocation because do not
include the symbol into .dynsym.
That happens when the version script is used because we treat the symbol as
STB_LOCAL if the following condition match:
VersionId == VER_NDX_LOCAL && isDefined() and do not include it to
.dynsym because of that. Patch fixes the issue.
Differential revision: https://reviews.llvm.org/D52724
llvm-svn: 343668
Imagine we have the following code:
int foo();
int main() { return foo(); }
It will crash if you try to compile it with
`clang -O0 -gdwarf-5 test.cpp -o test -g -fuse-ld=lld`
The crash happens inside the LLVM DWARF parser because LLD does not provide
the .debug_line_str section. At the same time for correct parsing and reporting,
we anyways need to provide this section from our side.
The patch fixes the issue.
llvm-svn: 343667
Summary:
This patch adds a new flag, --warn-ifunc-textrel, to work around a glibc bug. When a code with ifunc symbols is used to produce an object file with text relocations, lld always succeeds. However, if that object file is linked using an old version of glibc, the resultant binary just crashes with segmentation fault when it is run (The bug is going to be corrected as of glibc 2.19).
Since there is no way to tell beforehand what library the object file will be linked against in the future, there does not seem to be a fool-proof way for lld to give an error only in cases where the binary will crash. So, with this change (dated 2018-09-25), lld starts to give a warning, contingent on a new command line flag that does not have a gnu counter part. The default value for --warn-ifunc-textrel is false, so lld behaviour will not change unless the user explicitly asks lld to give a warning. Users that link with a glibc library with version 2.19 or newer, or does not use ifunc symbols, or does not generate object files with text relocations do not need to take any action. Other users may consider to start passing warn-ifunc-textrel to lld to get early warnings.
Reviewers: ruiu, espindola
Reviewed By: ruiu
Subscribers: grimar, MaskRay, markj, emaste, arichardson, llvm-commits
Differential Revision: https://reviews.llvm.org/D52430
llvm-svn: 343628
This uses the call graph profile embedded in the object files to construct the call graph.
This is read from a SHT_LLVM_CALL_GRAPH_PROFILE (0x6fff4c02) section as (uint32_t, uint32_t, uint64_t) tuples as (from symbol index, to symbol index, weight).
Differential Revision: https://reviews.llvm.org/D45850
llvm-svn: 343552
Summary: The convenience wrapper in STLExtras is available since rL342102.
Reviewers: ruiu, espindola
Subscribers: emaste, arichardson, mgrang, llvm-commits
Differential Revision: https://reviews.llvm.org/D52569
llvm-svn: 343146
Summary:
An AArch64 LE relocation is a positive ("variant 1") offset. This
relocation is used to write the upper 12 bits of a 24-bit offset into an
add instruction:
add x0, x0, :tprel_hi12:v1
The comment in the ARM docs for R_AARCH64_TLSLE_ADD_TPREL_HI12 is:
"Set an ADD immediate field to bits [23:12] of X; check 0 <= X < 2^24."
Reviewers: javed.absar, espindola, ruiu, peter.smith, zatrazz
Reviewed By: ruiu
Subscribers: emaste, arichardson, kristof.beyls, llvm-commits
Differential Revision: https://reviews.llvm.org/D52525
llvm-svn: 343144
This is https://bugs.llvm.org//show_bug.cgi?id=38919.
Currently, LLD may report "unsupported relocation target while parsing debug info"
when parsing the debug information.
At the same time LLD does that for zeroed R_X86_64_NONE relocations,
which obviously has "invalid" targets.
The nature of R_*_NONE relocation assumes them should be ignored.
This patch teaches LLD to stop reporting the debug information parsing errors for them.
Differential revision: https://reviews.llvm.org/D52408
llvm-svn: 343078
When we write a struct to a mmap'ed buffer, we usually use
write16/32/64, but we didn't for VersionDefinitionSection, so
we needed to template that class.
llvm-svn: 343024
Previously, if you invoke lld's `main` more than once in the same process,
the second invocation could fail or produce a wrong result due to a stale
pointer values of the previous run.
Differential Revision: https://reviews.llvm.org/D52506
llvm-svn: 343009
Summary:
As for x86_64, the default image base for AArch64 and i386 should be
aligned to a superpage appropriate for the architecture.
On AArch64, this is 2 MiB, on i386 it is 4 MiB.
Reviewers: emaste, grimar, javed.absar, espindola, ruiu, peter.smith, srhines, rprichard
Reviewed By: ruiu, peter.smith
Subscribers: jfb, markj, arichardson, krytarowski, kristof.beyls, llvm-commits
Differential Revision: https://reviews.llvm.org/D50297
llvm-svn: 342746
Non-member functions are generally preferred over member functions
because it is clear that non-member functions don't depend on an
internal state of an object.
llvm-svn: 342695
The PPC64 elf V2 abi defines 2 entry points for a function. There are a few
places we need to calculate the offset from the global entry to the local entry
and how this is done is not straight forward. This patch adds a helper function
mostly for documentation purposes, explaining how the 2 entry points differ and
why we choose one over the other, as well as documenting how the offsets are
encoded into a functions st_other field.
Differential Revision: https://reviews.llvm.org/D52231
llvm-svn: 342603
The access sequence for global variables in the medium and large code models use
2 instructions to add an offset to the toc-pointer. If the offset fits whithin
16-bits then the instruction that sets the high 16 bits is redundant.
This patch adds the --toc-optimize option, (on by default) and enables rewriting
of 2 instruction global variable accesses into 1 when the offset from the
TOC-pointer to the variable (or .got entry) fits in 16 signed bits. eg
addis %r3, %r2, 0 --> nop
addi %r3, %r3, -0x8000 --> addi %r3, %r2, -0x8000
This rewriting can be disabled with the --no-toc-optimize flag
Differential Revision: https://reviews.llvm.org/D49237
llvm-svn: 342602
Summary:
For --pack-dyn-relocs=android, finalizeSections calls
LinkerScript::assignAddresses and
AndroidPackedRelocationSection::updateAllocSize in a loop,
where assignAddresses lays out the ELF image, then updateAllocSize
determines the size of the Android packed relocation table by encoding it.
Encoding the table requires knowing the values of relocation addends.
To get the addend of a TLS relocation, updateAllocSize can call getSymVA
on a TLS symbol before setPhdrs has initialized Out::TlsPhdr, producing an
error:
<file> has an STT_TLS symbol but doesn't have an SHF_TLS section
Fix the problem by initializing Out::TlsPhdr immediately after the program
headers are created. The segment's p_vaddr field isn't initialized until
setPhdrs, so use FirstSec->Addr, which is what setPhdrs would use.
FirstSec will typically refer to the .tdata or .tbss output section, whose
(tentative) address was computed by assignAddresses.
Android currently avoids this problem because it uses emutls and doesn't
support ELF TLS. This problem doesn't apply to --pack-dyn-relocs=relr
because SHR_RELR only handles relative relocations without explicit addends
or info.
Fixes https://bugs.llvm.org/show_bug.cgi?id=37841.
Reviewers: ruiu, pcc, chh, javed.absar, espindola
Subscribers: emaste, arichardson, llvm-commits, srhines
Differential Revision: https://reviews.llvm.org/D51671
llvm-svn: 342432
A General-dynamic tls access can be written using a R_PPC64_TLSGD16 relocation
if the target got entry is within 16 bits of the TOC-base. This patch adds
support for R_PPC64_TLSGD16 by relaxing it the same as a R_PPC64_GOT_TLSGD16_LO.
Differential Revision: https://reviews.llvm.org/D52055
llvm-svn: 342411
There are a growing number of places when we either want to read or write an
instruction when handling a half16 relocation type. On big-endian the buffer
pointer is pointing into the middle of the word we want and on little-endian it
is pointing to the start of the word. These 2 helpers are to simplify reading
and writing in these contexts.
Differential Revision: https://reviews.llvm.org/D52115
llvm-svn: 342410
tolower() has some overhead because current locale is considered (though in lld the default "C" locale is used which does not matter too much). llvm::toLower is more efficient as it compiles to a compare and a conditional jump, as opposed to a libc call if tolower is used.
Disregarding locale also matches gdb's behavior (gdb/minsyms.h):
#define SYMBOL_HASH_NEXT(hash, c) \
((hash) * 67 + TOLOWER ((unsigned char) (c)) - 113)
where TOLOWER (include/safe-ctype.h) is a macro that uses a lookup table under the hood which is similar to llvm::toLower.
Reviewers: ruiu, espindola
Subscribers: emaste, arichardson, llvm-commits
Differential Revision: https://reviews.llvm.org/D52128
llvm-svn: 342342
These files used to contain classes and functions for .gdb_index,
but they are moved to SyntheticSections.{cpp,h}, so the name is now
irrelevant.
llvm-svn: 342299
Once we create .gdb_index contents, .zdebug_gnu_pub{names,types}
are useless, so there's no need to keep their uncompressed data
in memory.
I observed that for a test case in which lld creates a 3GB .gdb_index
section, the maximum resident set size reduced from 43GB to 29GB after
this patch.
Differential Revision: https://reviews.llvm.org/D52126
llvm-svn: 342297
-z interpose sets the DF_1_INTERPOSE flag, marking the object as an
interposer.
Via FreeBSD PR 230604, linking Valgrind with lld failed.
Differential Revision: https://reviews.llvm.org/D52094
llvm-svn: 342239
If --just-syms is used the mapping symbols from the ELF file will be
absolute symbols with no section. The code to process mapping symbols in
--fix-cortex-a53-843419 assumes that these symbols have a defining section
so a crash will result when --just-syms is used. The simple fix is to not
process the symbol when it doesn't have a section.
Fixes PR37971
Differential Revision: https://reviews.llvm.org/D52038
llvm-svn: 342146
Summary: This protects lld from a null pointer dereference when a faulty input file has such invalid sh_link fields.
Reviewers: ruiu, espindola
Reviewed By: ruiu
Subscribers: emaste, arichardson, llvm-commits
Differential Revision: https://reviews.llvm.org/D51743
llvm-svn: 341611
section will not have an input file. Don't crash under those circumstances.
Neither clang nor llvm-mc generates R_X86_64_PC32 relocations due to
https://reviews.llvm.org/D43383, which makes it hard to write a test case.
However, gcc does generate such relocations. I want to get a fix in now,
but will figure out a way to actually exercise this code path as soon
as I can.
llvm-svn: 341408
This patch moves the checking for too large offsets into merge sections
earlier.
Without this change the large offset generated in the added test-case
will cause an assert (as it happens to be a value reserved as a
"tombstone" in the DenseMap implementation) when OffsetMap is queried in
getSectionPiece().
To simplify the code and avoid future mistakes I have refactored so that
there is only one function that looks up offsets in the OffsetMap.
Differential Revision: https://reviews.llvm.org/D51180
llvm-svn: 341206
These symbols are declared early with the same value, so they otherwise
appear identical to ICF.
Differential Revision: https://reviews.llvm.org/D51376
llvm-svn: 340998
With this patch, lld creates a .note.GNU_stack and adds that to an
output file if it is creating a re-linkable object file (i.e. if -r
is given). If we don't do this, and if you use GNU linkers as a final
linker, they create an executable whose stack area is executable,
which is considered pretty bad these days.
Differential Revision: https://reviews.llvm.org/D51400
llvm-svn: 340902
Relanding r340564, original commit message:
Fixes the handling of *_DS relocations used on DQ-form instructions where we
were overwriting some of the extended opcode bits. Also adds an alignment check
so that the user will receive a diagnostic error if the value we are writing
is not properly aligned.
Differential Revision: https://reviews.llvm.org/D51124
llvm-svn: 340832
Looking at the current implementation and algorithm description,
it does not seem we need to keep vector with all edges for
each cluster and can just remember the best one. This is NFC change.
Differential revision: https://reviews.llvm.org/D50609
llvm-svn: 340806
This reverts commit 5125b44dbb5d06b715213e4bec75c7346bfcc7d3.
ppc64-dq.s and ppc64-error-missaligned-dq.s fail on several of the build-bots.
Reverting to investigate.
llvm-svn: 340568
Fixes the handling of *_DS relocations used on DQ-form instructions where we
were overwriting some of the extended opcode bits. Also adds an alignment check
so that the user will receive a diagnostic error if the value we are writing
is not properly aligned.
Differential Revision: https://reviews.llvm.org/D51124
llvm-svn: 340564
This is a minor follow-up to https://reviews.llvm.org/D49189. On Windows, lld
used to print "lld-link.exe: error: ...". Now it just prints "lld-link: error:
...". This matches what link.exe does (it prints "LINK : ...") and makes lld's
output less dependent on the host system.
https://reviews.llvm.org/D51133
llvm-svn: 340487
We have an issue with -wrap that the option doesn't work well when
renamed symbols get PLT entries. I'll explain what is the issue and
how this patch solves it.
For one -wrap option, we have three symbols: foo, wrap_foo and real_foo.
Currently, we use memcpy to overwrite wrapped symbols so that they get
the same contents. This works in most cases but doesn't when the relocation
processor sets some flags in the symbol. memcpy'ed symbols are just
aliases, so they always have to have the same contents, but the
relocation processor breaks that assumption.
r336609 is an attempt to fix the issue by memcpy'ing again after
processing relocations, so that symbols that are out of sync get the
same contents again. That works in most cases as well, but it breaks
ASan build in a mysterious way.
We could probably fix the issue by choosing symbol attributes that need
to be copied after they are updated. But it feels too complicated to me.
So, in this patch, I fixed it once and for all. With this patch, we no
longer memcpy symbols. All references to renamed symbols point to new
symbols after wrapSymbols() is done.
Differential Revision: https://reviews.llvm.org/D50569
llvm-svn: 340387
Summary:
For -thinlto-object-suffix-replace=old\;new, in
tools/gold/gold-plugin.cpp, the thinlto object filename is Path minus
optional old suffix.
static std::string getThinLTOObjectFileName(StringRef Path, StringRef OldSuffix,
StringRef NewSuffix) {
if (OldSuffix.empty() && NewSuffix.empty())
return Path;
StringRef NewPath = Path;
NewPath.consume_back(OldSuffix);
std::string NewNewPath = NewPath;
NewNewPath += NewSuffix;
return NewNewPath;
}
Currently lld will error that the path does not end with old suffix.
This patch makes lld accept such paths but only add new suffix if Path
ends with old suffix. This fixes a link error where bitcode members in
an archive are regular LTO objects without old suffix.
Acording to tejohnson, this will "enable supporting mix and match of
minimized ThinLTO bitcode files with normal ThinLTO bitcode files in a
single link (where we want to apply the suffix replacement to the
minimized files, and just ignore it for the normal ThinLTO files)."
Reviewers: ruiu, pcc, tejohnson, espindola
Reviewed By: tejohnson
Subscribers: emaste, inglorion, arichardson, eraman, steven_wu, dexonsmith, llvm-commits
Differential Revision: https://reviews.llvm.org/D51055
llvm-svn: 340364
This patch adds the target call back relaxTlsIeToLe to support TLS relaxation
from initial exec to local exec model.
Differential Revision: https://reviews.llvm.org/D48091
llvm-svn: 340281
Our code in LazyObjFile::parse() has an ELFT switch and
adds a lazy object by its ELFT kind.
Though it might be possible to add a file using a different
architecture and make LLD to silently accept it (if the file
is empty or contains only week symbols). That itself, not a
huge issue perhaps (because the error would be reported later
if the file is fetched), but still does not look clean and correct.
It is possible to report an error earlier and clean up the
code. That is what the patch does.
Ideally, we might want to reuse isCompatible from SymbolTable.cpp,
but it is static and accepts a file as an argument, what is not
convenient. Since such a situation should be rare, I think it
should be OK to go with the way chosen in this patch.
Differential revision: https://reviews.llvm.org/D50899
llvm-svn: 340257
This fixes the following warning when compiling with gcc version 8.0.1 20180319 (experimental) (GCC):
/home/umb/LLVM/llvm/tools/lld/ELF/SyntheticSections.cpp:1951:46: warning: enumeral and non-enumeral type in conditional expression [-Wextra]
return OS->SectionIndex >= SHN_LORESERVE ? SHN_XINDEX : OS->SectionIndex;
llvm-svn: 340164
Older Arm architectures do not support the MOVT and MOVW instructions so we
must use an alternative sequence of instructions to transfer control to the
destination.
Assuming at least Armv5 this patch adds support for Thunks that load or add
to the program counter. Note that there are no Armv5 Thumb Thunks as there
is no Thumb branch instruction in Armv5 that supports Thunks. These thunks
will not work for Armv4t (arm7tdmi) as this architecture cannot change state
from using the LDR or ADD instruction.
Differential Revision: https://reviews.llvm.org/D50077
llvm-svn: 340160
The Thumb BL and BLX instructions on older Arm Architectures such as v5 and
v6 have a constrained encoding J1 and J2 must equal 1, later Architectures
relaxed this restriction allowing J1 and J2 to be used to calculate a larger
immediate.
This patch adds support for the old encoding, it is used when the build
attributes for the input objects only contain older architectures.
Differential Revision: https://reviews.llvm.org/D50076
llvm-svn: 340159
Summary: This makes it conform to what the comment says. Otherwise when getErrPlace() is called afterwards, cast<InputSection>(D) will cause incompatible cast as MergeInputSection is not a subclass of InputSection.
Reviewers: ruiu, grimar, espindola, pcc
Reviewed By: grimar
Subscribers: emaste, arichardson, llvm-commits
Differential Revision: https://reviews.llvm.org/D50742
llvm-svn: 339904
Sean Fertile