This is a ld64 option equivalent to `-sectcreate seg sect /dev/null`
that's useful for creating sections like the RESTRICT section.
Differential Revision: https://reviews.llvm.org/D117749
Previously functions that aren't included in the symtab were also
excluded from the function starts. Symbols missing from function starts
degrades the debugger experience in the case you don't have debug info
for them.
Differential Revision: https://reviews.llvm.org/D114275
* `RelocationBaseSection::addReloc` increases `numRelativeRelocs`, which
duplicates the work done by RelocationSection<ELFT>::writeTo.
* --pack-dyn-relocs=android has inappropropriate DT_RELACOUNT.
AndroidPackedRelocationSection does not necessarily place relative relocations
in the front and DT_RELACOUNT might cause semantics error (though our
implementation doesn't and Android bionic doesn't use DT_RELACOUNT anyway.)
Move `llvm::partition` to a new function `partitionRels` and compute
`numRelativeRelocs` there. Now `RelocationBaseSection::addReloc` is trivial and
can be moved to the header to enable inlining.
The rest of DynamicReloc and `-z combreloc` handling is moved to the
non-template `RelocationBaseSection::computeRels` to decrease code size. My
x86-64 lld executable is 44+KiB smaller.
While here, rename `sort` to `combreloc`.
When processing dependent libraries, if there's a directory of the same
name as the library being searched for, either in the current directory
or earlier in the search order, LLD will try to open it and report an
error. This is because LLD uses file existence check. To address this
issue we reverse the order, searching the library by basename first
and only considering search paths later, and current directory last.
Differential Revision: https://reviews.llvm.org/D118498
Close#52781: for LTO, the inline asm diagnostic uses `<inline asm>` as the file
name (lib/CodeGen/AsmPrinter/AsmPrinterInlineAsm.cpp) and it is unclear which
module has the issue.
With this patch, we will see the module name (say `asm.o`) before `<inline asm>` with ThinLTO.
```
% clang -flto=thin -c asm.c && myld.lld asm.o -e f
ld.lld: error: asm.o <inline asm>:1:2: invalid instruction mnemonic 'invalid'
invalid
^~~~~~~
```
For regular LTO, unfortunately the original module name is lost and we only get
ld-temp.o.
Reviewed By: #lld-macho, ychen, Jez Ng
Differential Revision: https://reviews.llvm.org/D118434
In older versions of llvm (e.g. llvm 13), symbols were not individually
flagged as TLS. In this case, the indent was to implicitly mark any
symbols defined in TLS segments as TLS. However, we were not performing
this implicit conversion if the segment was explicitly marked as TLS
As it happens, llvm 13 was branched between the addition of the segment
flag and the addition of the symbol flag. See:
- segment flag added: https://reviews.llvm.org/D102202
- symbol flag added: https://reviews.llvm.org/D109426
Testing this is tricky because the assembler will imply the TLS status
of the symbol based on the segment its declared in, so we are forced to
use a yaml file here.
Fixes: https://github.com/emscripten-core/emscripten/issues/15891
Differential Revision: https://reviews.llvm.org/D118414
This reverts commit ef82063207.
- It conflicts with the existing llvm::size in STLExtras, which will now
never be called.
- Calling it without llvm:: breaks C++17 compat
To fix
../../chromeclang/bin/../include/c++/v1/__algorithm/min.h:39:1: note: candidate template ignored: deduced conflicting types for parameter '_Tp' ('unsigned long' vs. 'unsigned long long')
on macOS arm64.
In start-end.s there is a lit check line `# SEG: _main` to begin the
check at the start of the function main where `_main` is the Darwin name
mangling for C main. Because the text file that FileCheck is getting as
input has the path of the compiler build in it from llvm-mc and
llvm-objdump, and because of the lack of a trailing colon in this check
line we end up inadvertently matching against the line of text with the
compiler path in it in the case where said path contains "_main" some
place. This can be very likely if the compiler branch has "main" or
"_main" in it.
To fix this I include the training : since that will match on the
function label and not the path line.
When linking a Debug build clang (265MiB SHF_ALLOC sections, 920MiB uncompressed
debug info), in a --threads=1 link "Compress debug sections" takes 2/3 time and
in a --threads=8 link "Compress debug sections" takes ~70% time.
This patch splits a section into 1MiB shards and calls zlib `deflake` parallelly.
DEFLATE blocks are a bit sequence. We need to ensure every shard starts
at a byte boundary for concatenation. We use Z_SYNC_FLUSH for all shards
but the last to flush the output to a byte boundary. (Z_FULL_FLUSH can
be used as well, but Z_FULL_FLUSH clears the hash table which just
wastes time.)
The last block requires the BFINAL flag. We call deflate with Z_FINISH
to set the flag as well as flush the output to a byte boundary. Under
the hood, all of Z_SYNC_FLUSH, Z_FULL_FLUSH, and Z_FINISH emit a
non-compressed block (called stored block in zlib). RFC1951 says "Any
bits of input up to the next byte boundary are ignored."
In a --threads=8 link, "Compress debug sections" is 5.7x as fast and the total
speed is 2.54x. Because the hash table for one shard is not shared with the next
shard, the output is slightly larger. Better compression ratio can be achieved
by preloading the window size from the previous shard as dictionary
(`deflateSetDictionary`), but that is overkill.
```
# 1MiB shards
% bloaty clang.new -- clang.old
FILE SIZE VM SIZE
-------------- --------------
+0.3% +129Ki [ = ] 0 .debug_str
+0.1% +105Ki [ = ] 0 .debug_info
+0.3% +101Ki [ = ] 0 .debug_line
+0.2% +2.66Ki [ = ] 0 .debug_abbrev
+0.0% +1.19Ki [ = ] 0 .debug_ranges
+0.1% +341Ki [ = ] 0 TOTAL
# 2MiB shards
% bloaty clang.new -- clang.old
FILE SIZE VM SIZE
-------------- --------------
+0.2% +74.2Ki [ = ] 0 .debug_line
+0.1% +72.3Ki [ = ] 0 .debug_str
+0.0% +69.9Ki [ = ] 0 .debug_info
+0.1% +976 [ = ] 0 .debug_abbrev
+0.0% +882 [ = ] 0 .debug_ranges
+0.0% +218Ki [ = ] 0 TOTAL
```
Bonus in not using zlib::compress
* we can compress a debug section larger than 4GiB
* peak memory usage is lower because for most shards the output size is less
than 50% input size (all less than 55% for a large binary I tested, but
decreasing the initial output size does not decrease memory usage)
Reviewed By: ikudrin
Differential Revision: https://reviews.llvm.org/D117853
This is in preparation for moving the code that parses and processes
order files into this file.
See https://reviews.llvm.org/D117354 for context and discussion.
Notation: dst is `t->getThunkTargetSym()->getVA()`
On AArch64, when `src-0x8000000-r_addend <= dst < src-0x8000000`, the condition
`target->inBranchRange(rel.type, src, rel.sym->getVA(rel.addend))` may
incorrectly consider a thunk reusable.
`rel.addend = -getPCBias(rel.type)` resets the addend to 0 for AArch64/PPC
and the zero addend is used by `rel.sym->getVA(rel.addend)` to check
out-of-range relocations.
See the test for a case this computation is wrong:
`error: a.o:(.text_high+0x4): relocation R_AARCH64_JUMP26 out of range: -134217732 is not in [-134217728, 134217727]`
I have seen a real world case with r_addend=19960.
Reviewed By: peter.smith
Differential Revision: https://reviews.llvm.org/D117734
Only using that change in StringRef already decreases the number of
preoprocessed lines from 7837621 to 7776151 for LLVMSupport
Perhaps more interestingly, it shows that many files were relying on the
inclusion of StringRef.h to have the declaration from STLExtras.h. This
patch tries hard to patch relevant part of llvm-project impacted by this
hidden dependency removal.
Potential impact:
- "llvm/ADT/StringRef.h" no longer includes <memory>,
"llvm/ADT/Optional.h" nor "llvm/ADT/STLExtras.h"
Related Discourse thread:
https://llvm.discourse.group/t/include-what-you-use-include-cleanup/5831
D54759 introduced aarch64-combined-dynrel.s and
aarch64-combined-dynrel-ifunc.s . Unfortunately the requires line
at the top was AArch64 instead of aarch64 which means they were never
run. Update the tests to use aarch64 and fix to match current lld output.
Differential Revision: https://reviews.llvm.org/D117896
Unresolved symbols are not currently reported when building with
`-shared` or `-pie` so setting unresolvedSymbols doesn't have any
effect.
Differential Revision: https://reviews.llvm.org/D117737
Keith Smiley