Patch by Michael Skvortsov!
This change adds a basic support for linking static MSP430 ELF code.
Implemented relocation types are intended to correspond to the BFD.
Differential revision: https://reviews.llvm.org/D56535
llvm-svn: 350819
ARM and AArch64 use TLS variant 1, where the first two words after the
thread pointer are reserved for the TCB, followed by the executable's TLS
segment. Both the thread pointer and the TLS segment are aligned to at
least the TLS segment's alignment.
Android/Bionic historically has not supported ELF TLS, and it has
allocated memory after the thread pointer for several Bionic TLS slots
(currently 9 but soon only 8). At least one of these allocations
(TLS_SLOT_STACK_GUARD == 5) is widespread throughout Android/AArch64
binaries and can't be changed.
To reconcile this disagreement about TLS memory layout, set the minimum
alignment for executable TLS segments to 8 words on ARM/AArch64, which
reserves at least 8 words of memory after the TP (2 for the ABI-specified
TCB and 6 for alignment padding). For simplicity, and because lld doesn't
know when it's targeting Android, increase the alignment regardless of
operating system.
Differential Revision: https://reviews.llvm.org/D53906
llvm-svn: 350681
Fixes https://bugs.llvm.org/show_bug.cgi?id=40134
addWrappedSymbols() must be called before addReservedSymbols() because the
latter only defines reserved symbols when they are undefined in the symbol
table. If addWrappedSymbols() is called after, then addUndefined() is called
which may lazily pull in more object files that could reference reserved
symbols.
Differential Revision: https://reviews.llvm.org/D56110
llvm-svn: 350251
Summary:
If a DSO appears more than once with and without --as-needed, ld.bfd and gold consider --no-as-needed to takes precedence over --as-needed. lld didn't and this patch makes it do so.
This makes it a bit away from the position-dependent behavior (how
different occurrences of the same DSO interact) and protects us from
some mysterious runtime errors: if some interceptor libraries add their
own --no-as-needed dependencies (e.g. librt.so), and the user
application specifies -Wl,--as-needed -lrt , the absence of the
DT_NEEDED entry would make dlsym(RTLD_NEXT, "clock_gettime") return NULL
and would break at runtime.
Reviewers: ruiu, espindola
Reviewed By: ruiu
Subscribers: emaste, arichardson, llvm-commits
Differential Revision: https://reviews.llvm.org/D56089
llvm-svn: 350105
When parsing CU ranges for gdb-index, handle the error (now propagated
up though the API lld is calling here - previously the error was
printed within the libDebugInfo API, not allowing lld to format or
handle the message at all) - including information about the object and
archive name, as well as failing the link.
llvm-svn: 349979
Summary:
For the 2-bit bloom filter, we currently pick the bits Hash%64 and Hash>>6%64 (Shift2=6), but bits [6:...] are also used to select a word, causing a loss of precision.
In this patch, we choose Shift2=26, with is suggested by Ambrose Feinstein.
Note, Shift2 is computed as maskbitslog2 in bfd/elflink.c and gold/dynobj.cc
It is varying with the number of dynamic symbols but we don't
necessarily copy its rule.
Reviewers: ruiu, espindola
Reviewed By: ruiu
Subscribers: emaste, arichardson, llvm-commits
Differential Revision: https://reviews.llvm.org/D55971
llvm-svn: 349966
Summary:
This is a common error, and because many people don't know what the key
function is, it is sometimes very confusing.
The doc was originally written by Brooks Moses and slightly edited by me.
Reviewers: MaskRay, espindola
Subscribers: emaste, llvm-commits, arichardson
Differential Revision: https://reviews.llvm.org/D55968
llvm-svn: 349941
Summary:
In glibc, libc.so is a linker script with an as-needed dependency on ld-linux-x86-64.so.2
GROUP ( /lib/x86_64-linux-gnu/libc.so.6 /usr/lib/x86_64-linux-gnu/libc_nonshared.a AS_NEEDED ( /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 ) )
ld-linux-x86-64.so.2 (as-needed) defines some symbols which resolve undefined references in libc.so.6, it will therefore be added as a DT_NEEDED entry, which isn't necessary.
The test case as-needed-not-in-regular.s emulates the libc.so scenario, where ld.bfd and gold don't add DT_NEEDED for a.so
The relevant code in gold/resolve.cc:
// If we have a non-WEAK reference from a regular object to a
// dynamic object, mark the dynamic object as needed.
if (to->is_from_dynobj() && to->in_reg() && !to->is_undef_binding_weak())
to->object()->set_is_needed();
in_reg() appears to do something similar to IsUsedInRegularObj.
This patch makes lld do the similar thing, but moves the check from
addShared to a later stage MarkLive where all symbols are scanned.
Reviewers: ruiu, pcc, espindola
Reviewed By: ruiu
Subscribers: emaste, arichardson, llvm-commits
Differential Revision: https://reviews.llvm.org/D55902
llvm-svn: 349849
When we report an error for symbols defined in the linker script,
we do not report the location properly.
For example:
ld.lld: error: relocation R_AARCH64_CALL26 cannot refer to absolute symbol: aliasto__text
>>> defined in <internal>
>>> referenced by rtoabs.o:(.text+0x4)
This patch fixes that.
Differential revision: https://reviews.llvm.org/D55360
llvm-svn: 349612
Previously, this code printed out an error message like this
ld.lld: error: --reproduce: failed to open /foo: cannot open /foo
Apparently "failed to open /foo:" part is redundant.
llvm-svn: 349571
Previously, if you pass -static to lld, lld searches for only foo.a
and skips foo.so for -lfoo option. However, it didn't reject .so files
if you directly pass their pathnames via the command line, which is a bug.
Differential Revision: https://reviews.llvm.org/D55845
llvm-svn: 349557
Summary:
Other large sections (e.g. .rela.dyn .dynstr) may push .note.* off the
first page. They won't be available in core files if RLIMIT_CORE is
limited.
This patch gives priority to alloctable SHT_NOTE sections so that they
are assuredly in the first page and will be available in core files.
They are small and contain important information (e.g. .note.gnu.build-id
identifies the origin of the core, .note.tag stores NT_FREEBSD_ABI_TAG).
Note: gold Output_section_order has a similar rule:
// Loadable read-only note sections come next so that the PT_NOTE
// segment is on the first page of the executable.
ORDER_RO_NOTE,
Reviewers: ruiu, pcc, espindola
Subscribers: emaste, arichardson, llvm-commits
Differential Revision: https://reviews.llvm.org/D55800
llvm-svn: 349524
The code here wants the output section offset of the instruction
requiring the errata patch, not the virtual address. Without this
change we can end up placing a patch out of range if the virtual
address of the code section is large enough.
Differential Revision: https://reviews.llvm.org/D55732
llvm-svn: 349386
ARM Architecture v6m is used by the smallest microcontrollers such as the
cortex-m0. It is Thumb only (no Thumb 2) which prevents it from using the
existing Thumb 2 range extension thunks as these use the Thumb 2 movt/movw
instructions. Range extension thunks are not usually needed for
microcontrollers due to the small amount of flash and ram on the device,
however if code is copied from flash into ram then a range extension thunk
is required to call that code.
This change adds support for v6m range extension thunks. The procedure call
standard APCS permits a thunk to corrupt the intra-procedural scratch
register r12 (referred to as ip in the APCS). Most Thumb instructions do
not permit access to high registers (r8 - r15) so the thunks must spill
some low registers (r0 - r7) to perform the control transfer.
Fixes pr39922
Differential Revision: https://reviews.llvm.org/D55555
llvm-svn: 349337
Previously we considered R_ARM_V4BX to be an absolute relocation,
which meant that we rejected it in read-only sections in PIC output
files. Instead, treat it as a hint relocation so that relocation
processing ignores it entirely.
Also fix a problem with the test case where it was never being run
because it has a .yaml extension and we don't run tests with that
extension.
Differential Revision: https://reviews.llvm.org/D55728
llvm-svn: 349216
`--plugin-opt=emit-llvm` is an option for LTO. It makes the linker to
combine all bitcode files and write the result to an output file without
doing codegen. Gold LTO plugin has this option.
This option is being used for some post-link code analysis tools that
have to see a whole program but don't need to see them in the native
machine code.
Differential Revision: https://reviews.llvm.org/D55717
llvm-svn: 349198
In the ABI for the 64-bit Arm architecture the section on weak references
states:
During linking, the symbol value of an undefined weak reference is:
- Zero if the relocation type is absolute
- The address of the place if the relocation type is pc-relative.
The relocations associated with an ADRP are relative so we should resolve
the undefined weak reference to the place instead of 0. This matches GNU
ld.bfd behaviour.
fixes pr34928
Differential Revision: https://reviews.llvm.org/D55599
llvm-svn: 349024
This was a missing piece.
We started to print LMAs and information about assignments,
but did not do that for assignments outside of section declarations yet.
The patch implements it.
Differential revision: https://reviews.llvm.org/D45314
llvm-svn: 348468
This is a part of
https://bugs.llvm.org/show_bug.cgi?id=39885
Linker script specification says:
"You can specify a file name to include sections from a particular file. You would
do this if one or more of your files contain special data that needs to be at a
particular location in memory."
LLD did not accept this syntax. The patch implements it.
Differential revision: https://reviews.llvm.org/D55324
llvm-svn: 348463
Previously, we have a hash table containing strings and their offsets
to manage mergeable strings. Technically we can live without that, because
we can do binary search on a vector of mergeable strings to find a mergeable
strings.
We did have both the hash table and the binary search because we thought
that that is faster.
We recently observed that lld tend to consume more memory than gold when
building an output with debug info. A few percent of memory is consumed by
the hash table. So, we needed to reevaluate whether or not having the extra
hash table is a good CPU/memory tradeoff. I run a few benchmarks with and
without the hash table.
I got a mixed result for the benchmark. We observed a regression for some
programs by removing the hash table (that's what we expected), but we also
observed that performance imrpovements for some programs. This is perhaps
due to reduced memory usage.
Differential Revision: https://reviews.llvm.org/D55234
llvm-svn: 348401
Patch from Andrew Kelley.
For context, see https://bugs.llvm.org/show_bug.cgi?id=39862
The use case is embedded / OS programming where the kernel wants
access to its own debug info via mapped dwarf info. I have a proof of
concept of this working, using this linker script snippet:
.rodata : ALIGN(4K) {
*(.rodata)
__debug_info_start = .;
KEEP(*(.debug_info))
__debug_info_end = .;
__debug_abbrev_start = .;
KEEP(*(.debug_abbrev))
__debug_abbrev_end = .;
__debug_str_start = .;
KEEP(*(.debug_str))
__debug_str_end = .;
__debug_line_start = .;
KEEP(*(.debug_line))
__debug_line_end =
.;
__debug_ranges_start
= .;
KEEP(*(.debug_ranges))
__debug_ranges_end
= .;
}
Differential revision: https://reviews.llvm.org/D55276
llvm-svn: 348291
When linking the linux kernel on ppc64le
ld.lld -EL -m elf64lppc -Bstatic --orphan-handling=warn --build-id -o
.tmp_vmlinux1 -T ./arch/powerpc/kernel/vmlinux.lds --whole-archive
built-in.a --no-whole-archive --start-group lib/lib.a --end-group
ld.lld: error: discarding .rela.plt section is not allowed
The linker script discards with the following matches
*(.glink .iplt .plt .rela* .comment)
Differential Revision: https://reviews.llvm.org/D54871
llvm-svn: 348258
When linking the linux kernel on ppc64 and ppc
ld.lld: error: unrecognized reloc 11
11 is PPC_REL14 and PPC64_REL14
Differential revision: https://reviews.llvm.org/D54868
llvm-svn: 348255
At least on Linux, if a file size given to FileOutputBuffer is greater
than 2^63, it fails with "Invalid argument" error, which is not a
user-friendly error message. With this patch, lld prints out "output
file too large" instead.
llvm-svn: 348153
There is no need to check that In.DynSymTab != nullptr,
because `includeInDynsym` already checks for `!Config->HasDynSymTab`
and `HasDynSymTab` is the pre-condition for In.DynSymTab creation.
llvm-svn: 348143
Now LLD might build the broken/incomplete .gdb_index when some DWARF v5
sections (like .debug_rnglists and .debug_addr) are used.
Particularly, for the case above, we emit an empty address area.
A test case is provided and patch fixes the issue.
Differential revision: https://reviews.llvm.org/D55109
llvm-svn: 348119
The _GLOBAL_OFFSET_TABLE_ is a linker defined symbol that is placed at
some location relative to the .got, .got.plt or .toc section. On some
targets such as Arm the correctness of some code sequences using a
relocation to _GLOBAL_OFFSET_TABLE_ depend on the value of the symbol
being in the linker defined place. Follow the ld.gold example and give
a multiple symbol definition error. The ld.bfd behaviour is to ignore the
definition in the input object and redefine it, which seems like it could
be more surprising.
fixes pr39587
Differential Revision: https://reviews.llvm.org/D54624
llvm-svn: 347854
Summary:
This reinstates what I originally intended to do in D54361.
It removes the assumption that .debug_gnu_pubnames has increasing CuOffset.
Now we do better than gold here: when .debug_gnu_pubnames contains
multiple sets, gold would think every set has the same CU index as the
first set (incorrect).
Reviewed By: ruiu
Reviewers: ruiu, dblaikie, espindola
Subscribers: emaste, arichardson, arphaman, llvm-commits
Differential Revision: https://reviews.llvm.org/D54483
llvm-svn: 347820
This patch also makes getPltEntryOffset a non-member function because
it doesn't depend on any private members of the TargetInfo class.
I tried a few different ideas, and it seems this change fits in best to me.
Differential Revision: https://reviews.llvm.org/D54981
llvm-svn: 347781
The DT_PLTRELSZ dynamic tag is calculated using the size of the
OutputSection containing the In.RelaPlt InputSection. This will work for the
default no linker script case and the majority of linker scripts.
Unfortunately it doesn't work for some 'almost' sensible linker scripts. It
is permitted by ELF to have a single OutputSection containing both
In.RelaDyn, In.RelaPlt and In.RelaIPlt. It is also permissible for the range
of memory [DT_RELA, DT_RELA + DT_RELASZ) and the range
[DT_JMPREL, DT_JMPREL + DT_JMPRELSZ) to overlap as long as the the latter
range is at the end.
To support this type of linker script use the specific InputSection sizes.
Fixes pr39678
Differential Revision: https://reviews.llvm.org/D54759
llvm-svn: 347736
This is https://bugs.llvm.org/show_bug.cgi?id=38074.
The issue is that when calling a function, LLD generates a
.got entry that points to the IFUNC resolver function when
instead, it should use the PLT entries properly for
handling the IFUNC.
So we should create a got entry that points to PLT entry,
which itself loads the value from
.got.plt, relocated with R_*_IRELATIVE to make things work.
Patch do that.
Differential revision: https://reviews.llvm.org/D54314
llvm-svn: 347650
The changes to the instructions performed by TLS relaxation and the errata
patching are performed with relocations. As these are applied so late the
errata scanning won't see the changes in the section data made by the TLS
relaxation. This can lead to a TLS relaxed sequence being patched when it
doesn't need to be.
The fix checks to see if there is a R_RELAX_TLS_IE_TO_LE instruction at the
same address as the ADRP as this indicates the presence of a relaxation
of a sequence that might get recognised as a patch.
Differential Revision: https://reviews.llvm.org/D54854
llvm-svn: 347649
This is https://bugs.llvm.org//show_bug.cgi?id=38978
Spec says that:
"Objects may be built with the -z nodefaultlib option to
suppress any search of the default locations at runtime.
Use of this option implies that all the dependencies of an
object can be located using its runpaths.
Without this option, which is the most common case, no
matter how you augment the runtime linker's library
search path, its last element is always /usr/lib for 32-bit
objects and /usr/lib/64 for 64-bit objects."
The patch implements this option.
Differential revision: https://reviews.llvm.org/D54577
llvm-svn: 347647
On my machine this reduced median link time of lld-speed-test/chrome
from 2.68s to 2.41s. It also reduces link time of Chrome for Android
with a prototype compiler change that causes the compiler to create
large numbers of identical (modulo relocations) sections from >15
minutes to a few seconds.
Differential Revision: https://reviews.llvm.org/D54773
llvm-svn: 347594
When we are in a error state, script parser will not parse the -defsym
expression and hence will not tokenize it. Then ScriptLexer::Pos will be 0
and LLD will assert and crash here:
MemoryBufferRef ScriptLexer::getCurrentMB() {
assert(!MBs.empty() && Pos > 0); // Bang !
Solution - stop parsing the defsym in a error state. That is consistent
with the regular case (when we parse the linker script).
llvm-svn: 347549
We explicitly call finalizeContents() only once for
DynamicSection. The code testing we do not do it twice is
just excessive.
It could be an assert, but we don't do
that for other sections, so does not seem we
should do it here too.
llvm-svn: 347543
Now it returns Symbol. This should be NFC that
avoids doing cast at the caller's sides.
Differential revision: https://reviews.llvm.org/D54627
llvm-svn: 347455
Summary:
This fixes PR39711: -static -z retpolineplt does not produce retpoline PLT header.
-z now is not relevant.
Statically linked executable does not have PLT, but may have IPLT with no header. When -z retpolineplt is specified, however, the repoline PLT header should still be emitted.
I've checked that this fixes the FreeBSD reproduce in PR39711 and a Linux program statically linked against glibc. The programm print "Hi" rather than SIGILL/SIGSEGV.
getPltEntryOffset may look dirty after this patch, but it can be cleaned up later.
Another possible improvement is that when there are non-preemptible IFUNC symbols (rare case, e.g. -Bsymbolic), both In.Plt and In.Iplt can be non-empty and we'll emit the retpoline PLT header twice.
Reviewers: espindola, emaste, chandlerc, ruiu
Reviewed By: emaste
Subscribers: emaste, arichardson, krytarowski, llvm-commits
Differential Revision: https://reviews.llvm.org/D54782
llvm-svn: 347404
Summary:
When --noinhibit-exec is used, ld.bfd/gold emit errors but allow to produce corrupted executable, which is handy for debugging purpose. lld's --noinhibit-exec has a different meaning and changes some errors to warnings. This patch replaces "error" with "errorOrWarn" to exploit that property.
We may revisit this: if we should keep them as errors (as ld.bfd/gold do) but allow to produce a (corrupted) executable.
Reviewers: ruiu, grimar, espindola
Reviewed By: grimar
Subscribers: Timmmm, jhenderson, emaste, arichardson, llvm-commits
Differential Revision: https://reviews.llvm.org/D54651
llvm-svn: 347327
Summary: This patch implementation the handler for ARM_V4BX. This relocation is used by GNU runtime files and other armv4 applications.
Patch by Yin Ma
Reviewers: espindola, MaskRay, ruiu, peter.smith, pcc
Reviewed By: ruiu
Subscribers: yinma, pcc, peter.smith, MaskRay, rovka, efriedma, emaste, javed.absar, arichardson, kristof.beyls, chrib, llvm-commits
Differential Revision: https://reviews.llvm.org/D53444
llvm-svn: 347077
Current value using as a trap instruction (0xefefefef) is not a good choice
for MIPS because it's a valid MIPS instruction `swc3 $15,-4113(ra)`. This
patch replaces 0xefefefef by 0x04170001. For all MIPS ISA revisions before
R6, this value is just invalid instruction. Starting from MIPS R6 it's
a valid instruction `sigrie 1` which signals a Reserved Instruction exception.
mips-traps.s test case is added to test trap encoding. Other test cases
are modified to remove redundant checking.
Differential revision: https://reviews.llvm.org/D54154
llvm-svn: 347029
Remove the default initializer for TrapInstr; all subclasses overwrite
the defaults in their constructors anyway.
This fixes compilation errors like these, with GCC 5.4 on Ubuntu 16.04,
present since SVN r346893:
In file included from ../tools/lld/ELF/Arch/AArch64.cpp:12:0:
../tools/lld/ELF/Target.h:125:49: error: array must be initialized with a brace-enclosed initializer
std::array<uint8_t, 4> TrapInstr = {0, 0, 0, 0};
^
../tools/lld/ELF/Target.h:125:49: error: too many initializers for ‘std::array<unsigned char, 4ul>’
Differential Revision: https://reviews.llvm.org/D54569
llvm-svn: 346934
The uint32_t type does not clearly convey that these fields are interpreted
in the target endianness. Converting them to byte arrays should make this
more obvious and less error-prone.
Patch by James Clarke
Differential Revision: http://reviews.llvm.org/D54207
llvm-svn: 346893
On PowerPC64, when a function call offset is too large to encode in a call
instruction the address is stored in a table in the data segment. A thunk is
used to load the branch target address from the table relative to the
TOC-pointer and indirectly branch to the callee. When linking position-dependent
code the addresses are stored directly in the table, for position-independent
code the table is allocated and filled in at load time by the dynamic linker.
For position-independent code the branch targets could have gone in the .got.plt
but using the .branch_lt section for both position dependent and position
independent binaries keeps it consitent and helps keep this PPC64 specific logic
seperated from the target-independent code handling the .got.plt.
Differential Revision: https://reviews.llvm.org/D53408
llvm-svn: 346877
The R_AARCH64_ADR_PREL_PG_HI21 relocation type is given the R_PAGE_PC
RelExpr. This can be transformed to R_PLT_PAGE_PC via toPlt().
Unfortunately the resolution is identical to R_PAGE_PC so instead of
getting the address of the PLT entry we get the address of the symbol
which may not be correct in the case of static ifuncs. The fix is to
handle the cases separately and use getPltVA() + A with R_PLT_PAGE_PC.
Differential Revision: https://reviews.llvm.org/D54474
llvm-svn: 346863
Summary:
NameTypeEntry::Type is a bit-packed value of CU index+attributes (https://sourceware.org/gdb//onlinedocs/gdb/Index-Section-Format.html), which is named cu_index_and_attrs in a local variable in gdb/dwarf2read.c:dw2_symtab_iter_next
The new name CuIndexAndAttrs is more meaningful.
Reviewers: ruiu, dblaikie, espindola
Reviewed By: dblaikie
Subscribers: emaste, aprantl, arichardson, JDevlieghere, arphaman, llvm-commits
Differential Revision: https://reviews.llvm.org/D54481
llvm-svn: 346794
Summary:
Idx passed to readPubNamesAndTypes was an index into Chunks, not an
index into the CU list. This would be incorrect if some .debug_info
section contained more than 1 DW_TAG_compile_unit.
In real world, glibc Scrt1.o is a partial link of start.os abi-note.o init.o and contains 2 CUs in debug builds.
Without this patch, any application linking such Scrt1.o would have invalid .gdb_index
The issue could be demonstrated by:
(gdb) py print(gdb.lookup_global_symbol('main'))
None
Reviewers: espindola, ruiu
Reviewed By: ruiu
Subscribers: Higuoxing, grimar, dblaikie, emaste, aprantl, arichardson, JDevlieghere, arphaman, llvm-commits
Differential Revision: https://reviews.llvm.org/D54361
llvm-svn: 346747
Summary:
The debug_info_offset value may be relocated.
This is lld side change of D54375.
Reviewers: ruiu, dblaikie, grimar, espindola
Subscribers: emaste, arichardson, JDevlieghere, llvm-commits
Differential Revision: https://reviews.llvm.org/D54376
llvm-svn: 346616
Summary:
D53821 fixed the bogus MSVC (at least 2017) C4146 warning (unary minus applied on unsigned type)
by using std::numeric_limits<int32_t>::min().
The warning was because -2147483648 is incorrectly treated as unsigned long instead of long long)
Let's use INT32_MIN which is arguably more readable.
Note, on GCC or clang, -0x80000000 works fine (ILP64: long, LP64: long long).
Reviewers: ruiu, jhenderson, sfertile, espindola
Reviewed By: sfertile
Subscribers: emaste, nemanjai, arichardson, kbarton, jsji, llvm-commits
Differential Revision: https://reviews.llvm.org/D54200
llvm-svn: 346356
Summary:
D52830 sets sh_link to .symtab in static link, which breaks executable stripped by GNU strip.
It may also be odd that .rela.plt (SHF_ALLOC) points to .symtab (non-SHF_ALLOC).
Change the logic on pcc's suggestion.
Before:
% clang -fuse-ld=lld -static -xc =(printf 'int main(){}') # or gcc
% strip a.out; ./a.out
unexpected reloc type in static binary[1] 61634 segmentation fault ./a.out
Reviewers: ruiu, grimar, emaste, espindola
Reviewed By: ruiu
Subscribers: pcc, arichardson, llvm-commits
Differential Revision: https://reviews.llvm.org/D53993
llvm-svn: 345899
This is https://bugs.llvm.org/show_bug.cgi?id=39493.
We crashed previously because did not handle /DISCARD/ properly
when -r was used. I think it is uncommon to use scripts with -r, though I see
nothing wrong to handle the /DISCARD/ so that we will not crash at least.
Differential revision: https://reviews.llvm.org/D53864
llvm-svn: 345819
Summary:
There are really three different kinds of TLS layouts:
* A fixed TLS-to-TP offset. On architectures like PowerPC, MIPS, and
RISC-V, the thread pointer points to a fixed offset from the start
of the executable's TLS segment. The offset is 0x7000 for PowerPC
and MIPS, which allows a signed 16-bit offset to reach 0x1000 of
per-thread implementation data and 0xf000 of the application's TLS
segment. The size and layout of the TCB isn't relevant to the static
linker and might not be known.
* A fixed TCB size. This is the format documented as "variant 1" in
Ulrich Drepper's TLS spec. The thread pointer points to a 2-word TCB
followed by the executable's TLS segment. The first word is always
the DTV pointer. Used on ARM. The thread pointer must be aligned to
the TLS segment's alignment, possibly creating alignment padding.
* Variant 2. This format predates variant 1 and is also documented in
Drepper's TLS spec. It allocates the executable's TLS segment before
the thread pointer, apparently for backwards-compatibility. It's
used on x86 and SPARC.
Factor out an lld:🧝:getTlsTpOffset() function for use in a
follow-up patch for Android. The TcbSize/TlsTpOffset fields are only used
in getTlsTpOffset, so replace them with a switch on Config->EMachine.
Reviewers: espindola, ruiu, PkmX, jrtc27
Reviewed By: ruiu, PkmX, jrtc27
Subscribers: jyknight, emaste, sdardis, nemanjai, javed.absar, arichardson, kristof.beyls, kbarton, fedor.sergeev, atanasyan, PkmX, jsji, llvm-commits
Differential Revision: https://reviews.llvm.org/D53905
llvm-svn: 345775
Summary: .rela.plt may only contain R_*_{,I}RELATIVE relocations and not need a symbol table link. bfd/gold fallbacks to sh_link=0 in this case. Without this patch, ld.lld --strip-all caused lld to dereference a null pointer.
Reviewers: ruiu, grimar, espindola
Reviewed By: ruiu
Subscribers: emaste, arichardson, llvm-commits
Differential Revision: https://reviews.llvm.org/D53881
llvm-svn: 345648
Visual Studio has a bug where it converts the integer literal 2147483648
into an unsigned int instead of a long long (i.e. it follows C89 rules).
The bug has been reported as:
https://developercommunity.visualstudio.com/content/problem/141813/-2147483648-c4146-error.html.
Because of this bug, we were getting a signed/unsigned comparison
warning in VS2015 from the old code (the subsequent unary negation had
no effect on the type).
Reviewed by: sfertile
Differential Revision: https://reviews.llvm.org/D53821
llvm-svn: 345579
Summary: There are too many reasonable cases that would be considered unorderable.
Reviewers: ruiu, espindola, Bigcheese
Reviewed By: ruiu
Subscribers: grimar, emaste, arichardson, llvm-commits
Differential Revision: https://reviews.llvm.org/D53669
llvm-svn: 345322
Out::DebugInfo was used only by GdbIndex class to determine if
we need to create a .gdb_index section, but we can do the same
check without it.
Added a test that this patch doesn't change the existing behavior.
llvm-svn: 345058
Summary:
During upgrading of the FreeBSD source tree with lld 7.0.0, I noticed
that it started complaining about `crt1.o` having an "index past the
end of the symbol table".
Such a symbol table looks approximately like this, viewed with `readelf
-s` (note the `Ndx` field being messed up):
```
Symbol table '.symtab' contains 4 entries:
Num: Value Size Type Bind Vis Ndx Name
0: 00000000 0 NOTYPE LOCAL DEFAULT UND
1: 00000000 0 SECTION LOCAL DEFAULT 1
2: 00000000 0 NOTYPE WEAK HIDDEN RSV[0xffff] __rel_iplt_end
3: 00000000 0 NOTYPE WEAK HIDDEN RSV[0xffff] __rel_iplt_start
```
At first, it seemed that recent ifunc relocation work had caused this:
<https://reviews.freebsd.org/rS339351>, but it turned out that it was
due to incorrect processing of the object files by lld, when using `-r`
(a.k.a. --relocatable).
Bisecting showed that rL324421 ("Convert a use of Config->Static") was
the commit where this new behavior began. Simply reverting it solved
the issue, and the `__rel_iplt` symbols had an index of `UND` again.
Looking at Rafael's commit message, I think he simply missed the
possibility of `--relocatable` being in effect, so I have added an
additional check for it.
I also added a simple regression test case.
Reviewers: grimar, ruiu, emaste, espindola
Reviewed By: ruiu
Subscribers: arichardson, krytarowski, llvm-commits
Differential Revision: https://reviews.llvm.org/D53515
llvm-svn: 345002
We need this to support 32-bit ARM. Add test cases for emulation
handling for this architecture as well.
Differential Revision: https://reviews.llvm.org/D53539
llvm-svn: 344976
Summary:
Before, superfluous warnings were emitted for the following two cases:
1) When from symbol was in a discarded section.
The profile should be thought of as affiliated to the section.
It makes sense to ignore the profile if the section is discarded.
2) When to symbol was in a shared object.
The object file containing the profile may not know about the to
symbol, which can reside in another object file (useful profile) or a
shared object (not useful as symbols in the shared object are fixed
and unorderable). It makes sense to ignore the profile from the object
file.
Note, the warning when to symbol was undefined was suppressed in
D53044, which is still useful for --symbol-ordering-file=
This patch silences the warnings. The check is actually more relaxed (no
warnings if either From or To is not Defined) for simplicity and I don't
see a compelling reason to warn on more cases.
Reviewers: ruiu, davidxl, espindola, Bigcheese
Reviewed By: ruiu
Subscribers: emaste, arichardson, llvm-commits
Differential Revision: https://reviews.llvm.org/D53470
llvm-svn: 344974
This patch adds a support for OUTPUT_FORMAT linker script directive.
Since I'm not 100% confident with BFD names you can use in the directive
for all architectures, I added only a few in this patch. We can add
other names for other archtiectures later.
We still do not support triple-style OUTPUT_FORMAT directive, namely,
OUTPUT_FORMAT(bfdname, big, little). If you pass -EL (little endian)
or -EB (big endian) to the linker, GNU linkers pick up big or little
as a BFD name, correspondingly, so that you can use a single linker
script for bi-endian processor. I'm not sure if we really need to
support that, so I'll leave it alone for now.
Note that -m takes precedence over OUTPUT_FORAMT, but we always parse
a BFD name given to OUTPUT_FORMAT for error checking. You cannot write
an invalid name in the OUTPUT_FORMAT directive.
Differential Revision: https://reviews.llvm.org/D53495
llvm-svn: 344952
Summary:
SymbolTable::addAbsolute() was removed in rL344305.
To me this is more readable than the lambda named `Add` and in our
out-of-tree CHERI target we use addAbsolute() in another function.
Reviewers: ruiu, espindola
Reviewed By: ruiu
Subscribers: kristina, emaste, llvm-commits
Differential Revision: https://reviews.llvm.org/D53393
llvm-svn: 344842
Adjusted the range check on a call instruction from 24 bits signed to
26 bits signed. While the instruction only encodes 24 bits, the target is
assumed to be 4 byte aligned, and the value that is encoded in the instruction
gets shifted left by 2 to form the offset. Also added a check that the offset is
indeed at least 4 byte aligned.
Differential Revision: https://reviews.llvm.org/D53401
llvm-svn: 344747
Recommitting https://reviews.llvm.org/rL344544 after fixing undefined behavior
from left-shifting a negative value. Original commit message:
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.
llvm-svn: 344622
This reverts commit https://reviews.llvm.org/rL344544, which causes failures on
a undefined behaviour sanitizer bot -->
lld/ELF/Arch/PPC64.cpp:849:35: runtime error: left shift of negative value -1
llvm-svn: 344551
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
George Rimar