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
- Make mergeSymbolRecords a method of PDBLinker to reduce the number of
parameters it needs.
- Remove a stale FIXME comment about error handling. We already drop
unknown symbol records, log them, and continue.
- Update a comment about why we're copying the symbol record. We do it
to realign the record. We can already mutate the symbol record memory,
it's memory allocated by relocateDebugChunk.
- Avoid the extra `CVSymbol NewSym` variable. We can mutate Sym in
place, which is best, since we're mutating the underlying record anyway.
llvm-svn: 346817
gdb-index-multiple-cu-2.s puts the symbol in question to another object file %t1.o, so that its CuIndex is affected by the number of CUs in %t.o
Also change `Kind:` in a comment to `Attributes:` as a follow-up of D54480 and D54481
llvm-svn: 346796
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
`--no-demangle` now also applies to the name section. This change
was motivated by the rust team that have a slightly different name
mangling scheme to the standard C++ itanium one and prefer to do their
de-mangling as a post-link setp.
Patch by Alex Crichton!
Differential Revision: https://reviews.llvm.org/D54279
llvm-svn: 346516
Summary:
Reuse the "referenced by" note diagnostic code that we already use for
undefined symbols. In my case, it turned this:
lld-link: error: relocation against symbol in discarded section: .text
lld-link: error: relocation against symbol in discarded section: .text
...
Into this:
lld-link: error: relocation against symbol in discarded section: .text
>>> referenced by libANGLE.lib(CompilerGL.obj):(.SCOVP$M)
>>> referenced by libANGLE.lib(CompilerGL.obj):(.SCOVP$M)
...
lld-link: error: relocation against symbol in discarded section: .text
>>> referenced by obj/third_party/angle/libGLESv2/entry_points_egl_ext.obj:(.SCOVP$M)
>>> referenced by obj/third_party/angle/libGLESv2/entry_points_egl_ext.obj:(.SCOVP$M)
...
I think the new output is more useful.
Reviewers: ruiu, pcc
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D54240
llvm-svn: 346427
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
Used for WebAssembly threads proposal. Add a flag --shared-memory
which sets the IS_SHARED bit in WasmLimits
Differential Revision: https://reviews.llvm.org/D54130
llvm-svn: 346248
Summary: llvm-readobj/readelf accepts both -s and -S as aliases for --sections. However with GNU readelf only -S means --section, and -s means --symbols. I would like to make llvm-readelf more compatible.
Reviewers: MaskRay, espindola
Reviewed By: MaskRay
Subscribers: emaste, arichardson, steven_wu, dexonsmith, llvm-commits
Differential Revision: https://reviews.llvm.org/D54118
llvm-svn: 346164
This change allows for link-time merging of debugging information from
Microsoft precompiled types OBJs compiled with cl.exe /Z7 /Yc and /Yu.
This fixes llvm.org/PR34278
Differential Revision: https://reviews.llvm.org/D45213
llvm-svn: 346154
Summary:
It is difficult to touch a file with a relative mtime across different OSes as POSIX touch -d is rigid. While we may construct relative timestamps with `date`, POSIX date is inadequate to do so as various OSes' date do not agree on a common format (OpenBSD uses `date -r seconds`, FreeBSD uses `date -v-2M` while GNU accepts `-d '-2 min'`)
Just use python os.utime()
Original description:
The case may randomly fail if we test it with command "
while llvm-lit tools/lld/test/ELF/lto/cache.ll; do true; done". It is because the llvmcache-foo file is younger than llvmcache-349F039B8EB076D412007D82778442BED3148C4E and llvmcache-A8107945C65C2B2BBEE8E61AA604C311D60D58D6. But due to timestamp precision reason their timestamp is the same. Given the same timestamp, the file prune policy is to remove bigger size file first, so mostly foo file is removed for its bigger size. And the files size is under threshold after deleting foo file. That's what test case expect.
However sometimes, the precision is enough to measure that timestamp of llvmcache-349F039B8EB076D412007D82778442BED3148C4E and llvmcache-A8107945C65C2B2BBEE8E61AA604C311D60D58D6 are smaller than foo, so llvmcache-349F039B8EB076D412007D82778442BED3148C4E and llvmcache-A8107945C65C2B2BBEE8E61AA604C311D60D58D6 are deleted first. Since the files size is still above the file size threshold after deleting the 2 files, the foo file is also deleted. And then the test case fails, because it expect only one file should be deleted instead of 3.
The fix is to change the timestamp of llvmcache-foo file to meet the thinLTO prune policy.
The same fix is applied to llvm code at https://reviews.llvm.org/D52452.
Patch by Luo Yuanke.
Reviewers: ruiu, craig.topper, smaslov, Jianping, espindola, LuoYuanke, tejohnson
Reviewed By: tejohnson
Subscribers: sbc100, krytarowski, aheejin, llvm-commits, dexonsmith, steven_wu, arichardson, inglorion, emaste, bjope, rupprecht
Differential Revision: https://reviews.llvm.org/D54039
llvm-svn: 346006
Summary:
The case may randomly fail if we test it with command "
while llvm-lit tools/lld/test/ELF/lto/cache.ll; do true; done". It is because the llvmcache-foo file is younger than llvmcache-349F039B8EB076D412007D82778442BED3148C4E and llvmcache-A8107945C65C2B2BBEE8E61AA604C311D60D58D6. But due to timestamp precision reason their timestamp is the same. Given the same timestamp, the file prune policy is to remove bigger size file first, so mostly foo file is removed for its bigger size. And the files size is under threshold after deleting foo file. That's what test case expect.
However sometimes, the precision is enough to measure that timestamp of llvmcache-349F039B8EB076D412007D82778442BED3148C4E and llvmcache-A8107945C65C2B2BBEE8E61AA604C311D60D58D6 are smaller than foo, so llvmcache-349F039B8EB076D412007D82778442BED3148C4E and llvmcache-A8107945C65C2B2BBEE8E61AA604C311D60D58D6 are deleted first. Since the files size is still above the file size threshold after deleting the 2 files, the foo file is also deleted. And then the test case fails, because it expect only one file should be deleted instead of 3.
The fix is to change the timestamp of llvmcache-foo file to meet the thinLTO prune policy.
The same fix is applied to llvm code at https://reviews.llvm.org/D52452.
Patch by Luo Yuanke.
Reviewers: ruiu, craig.topper, smaslov, Jianping, espindola, LuoYuanke
Subscribers: rupprecht, bjope, emaste, inglorion, arichardson, steven_wu, dexonsmith, llvm-commits
Differential Revision: https://reviews.llvm.org/D53123
llvm-svn: 345977
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 patch should not introduce any behavior changes. It consists of
mostly one of two changes:
1. Replacing fall through comments with the LLVM_FALLTHROUGH macro
2. Inserting 'break' before falling through into a case block consisting
of only 'break'.
We were already using this warning with GCC, but its warning behaves
slightly differently. In this patch, the following differences are
relevant:
1. GCC recognizes comments that say "fall through" as annotations, clang
doesn't
2. GCC doesn't warn on "case N: foo(); default: break;", clang does
3. GCC doesn't warn when the case contains a switch, but falls through
the outer case.
I will enable the warning separately in a follow-up patch so that it can
be cleanly reverted if necessary.
Reviewers: alexfh, rsmith, lattner, rtrieu, EricWF, bollu
Differential Revision: https://reviews.llvm.org/D53950
llvm-svn: 345882
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
Fangrui Song