Use deduction guides instead of helper functions.
The only non-automatic changes have been:
1. ArrayRef(some_uint8_pointer, 0) needs to be changed into ArrayRef(some_uint8_pointer, (size_t)0) to avoid an ambiguous call with ArrayRef((uint8_t*), (uint8_t*))
2. CVSymbol sym(makeArrayRef(symStorage)); needed to be rewritten as CVSymbol sym{ArrayRef(symStorage)}; otherwise the compiler is confused and thinks we have a (bad) function prototype. There was a few similar situation across the codebase.
3. ADL doesn't seem to work the same for deduction-guides and functions, so at some point the llvm namespace must be explicitly stated.
4. The "reference mode" of makeArrayRef(ArrayRef<T> &) that acts as no-op is not supported (a constructor cannot achieve that).
Per reviewers' comment, some useless makeArrayRef have been removed in the process.
This is a follow-up to https://reviews.llvm.org/D140896 that introduced
the deduction guides.
Differential Revision: https://reviews.llvm.org/D140955
This patch mechanically replaces None with std::nullopt where the
compiler would warn if None were deprecated. The intent is to reduce
the amount of manual work required in migrating from Optional to
std::optional.
This is part of an effort to migrate from llvm::Optional to
std::optional:
https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
Extends the Asm reader/writer to support reading and writing the
'.memtag' directive (including allowing it on internal global
variables). Also add some extra tooling support, including objdump and
yaml2obj/obj2yaml.
Test that the sanitize_memtag IR attribute produces the expected asm
directive.
Uses the new Aarch64 MemtagABI specification
(https://github.com/ARM-software/abi-aa/blob/main/memtagabielf64/memtagabielf64.rst)
to identify symbols as tagged in object files. This is done using a
R_AARCH64_NONE relocation that identifies each tagged symbol, and these
relocations are tagged in a special SHT_AARCH64_MEMTAG_GLOBALS_STATIC
section. This signals to the linker that the global variable should be
tagged.
Reviewed By: fmayer, MaskRay, peter.smith
Differential Revision: https://reviews.llvm.org/D128958
.addrsig_sym forces registering the symbol regardless whether it is otherwise
registered. This creates an undefined symbol which is inconvenient/undesired:
* `extern int x; void f() { (void)x; }` has inconsistent behavior whether `x` is emitted as an undefined symbol.
`-O0 -faddrsig` makes `x` undefined while other -O levels and -fno-addrsig eliminate the symbol.
* In ThinLTO, after a non-prevailing linkonce_odr definition is converted to available_externally, and then a declaration,
the addrsig code emits a symbol while the symbol is otherwise unseen.
D135427 fixed a bug that a non-prevailing `__cxx_global_var_init` was
incorrectly retained. However, the IR declaration causes an undesired
`.addrsig_sym __cxx_global_var_init`. This can be addressed in a way similar
to D101512 (`isTransitiveUsedByMetadataOnly`) but the increased
`OutStreamer->emitAddrsigSym(getSymbol(&GV));` complexity makes me nervous.
Just ignoring unregistered symbols circumvents the problem.
Reviewed By: rnk
Differential Revision: https://reviews.llvm.org/D135642
"Z" was so named when we had both gABI ELFCOMPRESS_ZLIB and the legacy .zdebug support.
Now we have just one zlib format, we should use the more descriptive name.
This reverts commit 19dc3cff0f771bb8933136ef68e782553e920d04.
This reverts commit 5b19a1f8e88da9ec92b995bfee90043795c2c252.
This reverts commit 9397648ac8ad192f7e6e6a8e6894c27bf7e024e9.
This reverts commit 10842b44759f987777b08e7714ef77da2526473a.
Breaks the GCC build, as reported here:
https://reviews.llvm.org/D130506#3776415
It's more natural to use uint8_t * (std::byte needs C++17 and llvm has
too much uint8_t *) and most callers use uint8_t * instead of char *.
The functions are recently moved into `llvm::compression::zlib::`, so
downstream projects need to make adaption anyway.
* Refactor compression namespaces across the project, making way for a possible
introduction of alternatives to zlib compression.
Changes are as follows:
* Relocate the `llvm::zlib` namespace to `llvm::compression::zlib`.
Reviewed By: MaskRay, leonardchan, phosek
Differential Revision: https://reviews.llvm.org/D128953
The __llvm_addrsig section is a section that the linker needs for safe icf.
This was not yet implemented for MachO - this is the implementation.
It has been tested with a safe deduplication implementation inside lld.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D123751
`.symver foo, foo@ver` creates the MCSymbolELF `foo@ver` whose almost all
attributes (including st_size) should inherit from `foo` (GNU as behavior).
a041ef1bd8905f0d58e301c6830b183002ff1847 added st_size propagation which works
for many cases but fails for the following one:
```
.set __GLIBC_2_12_sys_errlist, _sys_errlist_internal
.type __GLIBC_2_12_sys_errlist,@object
.size __GLIBC_2_12_sys_errlist, 1080
.symver __GLIBC_2_12_sys_errlist, sys_errlist@GLIBC_2.12
...
_sys_errlist_internal:
.size _sys_errlist_internal, 1072
```
`sys_errlist@GLIBC_2.12`'s st_size is 1072 (incorrect), which does not match
`__GLIBC_2_12_sys_errlist`'s st_size: 1080.
The problem is that `Base` is (the final) `_sys_errlist_internal` while we want
to respect (the intermediate) `__GLIBC_2_12_sys_errlist`'s st_size.
Fix this by following the MCSymbolRefExpr assignment chain and finding
the closest non-null `getSize()`, which covers most needs. Notably MCBinaryExpr
is not handled, but it is rare enough to matter.
Reviewed By: peter.smith
Differential Revision: https://reviews.llvm.org/D123283
STB_GNU_UNIQUE should be treated in a way similar to STB_GLOBAL.
This fixes an "Invalid Binding" failure in an LLVM_ENABLE_ASSERTIONS=on build
for source files like glibc elf/tst-unique1mod1.c .
This bug has been benign so far because (a) Clang does not produce
%gnu_unique_object by itself (b) a non-assertion build likely picks the
STB_GLOBAL code path anyway.
With a sufficiently large output buffer, the only failure is Z_MEM_ERROR.
Check it and call the noreturn report_bad_alloc_error if applicable.
resize_for_overwrite may call report_bad_alloc_error as well.
Now that there is no other error type, we can replace the return type with void
and simplify call sites.
Reviewed By: ikudrin
Differential Revision: https://reviews.llvm.org/D121512
The opt-out from rL236267 (2015) is untested and seems no longer needed (or not
needed when rL236267 was committed): there is nothing special with uncompressed
alignment. This brings us in line with GCC which compresses .debug_frame .
Checked that -g -fno-asynchronous-unwind-tables + objcopy
--decompress-debug-sections output is identical to -g
-fno-asynchronous-unwind-tables -gz + objcopy --decompress-debug-sections
output.
There's a few relevant forward declarations in there that may require downstream
adding explicit includes:
llvm/MC/MCContext.h no longer includes llvm/BinaryFormat/ELF.h, llvm/MC/MCSubtargetInfo.h, llvm/MC/MCTargetOptions.h
llvm/MC/MCObjectStreamer.h no longer include llvm/MC/MCAssembler.h
llvm/MC/MCAssembler.h no longer includes llvm/MC/MCFixup.h, llvm/MC/MCFragment.h
Counting preprocessed lines required to rebuild llvm-project on my setup:
before: 1052436830
after: 1049293745
Which is significant and backs up the change in addition to the usual benefits of
decreasing coupling between headers and compilation units.
Discourse thread: https://discourse.llvm.org/t/include-what-you-use-include-cleanup
Differential Revision: https://reviews.llvm.org/D119244
For tagged-globals, we only need to disable relaxation for globals that
we actually tag. With this patch function pointer relocations, which
we do not instrument, can be relaxed.
This patch also makes tagged-globals work properly with LTO, as
-Wa,-mrelax-relocations=no doesn't work with LTO.
Reviewed By: pcc
Differential Revision: https://reviews.llvm.org/D113220
sh_info links to a section, therefore SHF_INFO_LINK should be set as GNU as
does. The issue has been benign because linkers kindly combines relocation
sections w/ and w/o the flag.
... even on targets preferring RELA. The section is only consumed by ld.lld
which can handle REL.
Follow-up to D104080 as I explained in the review. There are two advantages:
* The D104080 code only handles RELA, so arm/i386/mips32 etc may warn for -fprofile-use=/-fprofile-sample-use= usage.
* Decrease object file size for RELA targets
While here, change the relocation to relocate weights, instead of 0,1,2,3,..
I failed to catch the issue during review.
Currently when .llvm.call-graph-profile is created by llvm it explicitly encodes the symbol indices. This section is basically a black box for post processing tools. For example, if we run strip -s on the object files the symbol table changes, but indices in that section do not. In non-visible behavior indices point to wrong symbols. The visible behavior indices point outside of Symbol table: "invalid symbol index".
This patch changes the format by using R_*_NONE relocations to indicate the from/to symbols. The Frequency (Weight) will still be in the .llvm.call-graph-profile, but symbol information will be in relocation section. In LLD information from both sections is used to reconstruct call graph profile. Relocations themselves will never be applied.
With this approach post processing tools that handle relocations correctly work for this section also. Tools can add/remove symbols and as long as they handle relocation sections with this approach information stays correct.
Doing a quick experiment with clang-13.
The size went up from 107KB to 322KB, aggregate of all the input sections. Size of clang-13 binary is ~118MB. For users of -fprofile-use/-fprofile-sample-use the size of object files will go up slightly, it will not impact final binary size.
Reviewed By: jhenderson, MaskRay
Differential Revision: https://reviews.llvm.org/D104080
This fixes PR49821, and avoids "ld.lld: error: test.o:(.rodata.str1.1):
offset is outside the section" errors when linking MIPS objects with
negative R_MIPS_LO16 implicit addends.
ld.lld handles R_MIPS_HI16/R_MIPS_LO16 separately, not as a whole, so it
doesn't know that an R_MIPS_HI16 with implicit addend 1 and an
R_MIPS_LO16 with implicit addend -32768 represents 32768, which is in
range of a MergeInputSection. We could introduce a new RelExpr member
(like R_RISCV_PC_INDIRECT for R_RISCV_PCREL_HI20 / R_RISCV_PCREL_LO12)
but the complexity is unnecessary given that GNU as keeps the original
symbol for this case as well.
Adds a new test case for PR49821, and also updates two other test cases
that are affected by this change.
Reviewed By: atanasyan, MaskRay
Differential Revision: https://reviews.llvm.org/D101773
This reverts commit ab40c027f0ce9492919a72ad339de40bdb84b354.
Some additional test cases are influenced by the workaround, and I need
to do a complete test run to identify and check them all.
This fixes PR49821, and avoids "ld.lld: error: test.o:(.rodata.str1.1):
offset is outside the section" errors when linking MIPS objects with
negative R_MIPS_LO16 implicit addends.
ld.lld handles R_MIPS_HI16/R_MIPS_LO16 separately, not as a whole, so it
doesn't know that an R_MIPS_HI16 with implicit addend 1 and an
R_MIPS_LO16 with implicit addend -32768 represents 32768, which is in
range of a MergeInputSection. We could introduce a new RelExpr member
(like R_RISCV_PC_INDIRECT for R_RISCV_PCREL_HI20 / R_RISCV_PCREL_LO12)
but the complexity is unnecessary given that GNU as keeps the original
symbol for this case as well.
Reviewed By: atanasyan, MaskRay
Differential Revision: https://reviews.llvm.org/D101773
As a resolution to https://sourceware.org/bugzilla/show_bug.cgi?id=25295 , GNU as
from binutils 2.35 supports the optional third argument for the .symver directive.
'remove' for a non-default version is useful:
`.symver def_v1, def@v1, remove` => def_v1 is not retained in the symbol table.
Previously the user has to strip the original symbol or specify a `local:`
version node in a version script to localize the symbol.
`.symver def, def@@v1, remove` and `.symver def, def@@@v1, remove` are supported
as well, though they are identical to `.symver def, def@@@v1`.
local/hidden are not useful so this patch does not implement them.
This change introduces support for zero flag ELF section groups to LLVM.
LLVM already supports COMDAT sections, which in ELF are a special type
of ELF section groups. These are generally useful to enable linker GC
where you want a group of sections to always travel together, that is to
be either retained or discarded as a whole, but without the COMDAT
semantics. Other ELF assemblers already support zero flag ELF section
groups and this change helps us reach feature parity.
Differential Revision: https://reviews.llvm.org/D95851
As we don't sort local symbols, don't sort non-local symbols. This makes
non-local symbols appear in their register order, which matches GNU as. The
register order is nice in that you can write tests with interleaved CHECK
prefixes, e.g.
```
// CHECK: something about foo
.globl foo
foo:
// CHECK: something about bar
.globl bar
bar:
```
With the lexicographical order, the user needs to place lexicographical smallest
symbol first or keep CHECK prefixes in one place.
GNU as does not sort local symbols. This has several advantages:
* The .symtab order is roughly the symbol occurrence order.
* The closest preceding STT_SECTION symbol is the definition of a local symbol.
* The closest preceding STT_FILE symbol is the defining file of a local symbol, if there are multiple default-version .file directives. (Not implemented in MC.)
This relands D64327 with a more specific workaround for R_386_GOTOFF
(gold<2.34 bug https://sourceware.org/bugzilla/show_bug.cgi?id=16794)
.debug_info has quite a few .debug_str relocations (R_386_32/R_ARM_ABS32).
The original workaround was too general and introduced too many .L symbols
used just as relocation targets.
From the original review:
... it reduced the size of a big ARM-32 debug image by 33%. It contained ~68M
of relocations symbols out of total ~71M symbols (96% of symbols table was
generated for relocations with symbol).
This reverts commit b497665d98ad5026b1d3d67d5793a28fefe27bea.
Spent some time trying to reproduce this locally, reverting in a
desparate attempt to fix the sanitizer buildbot:
- http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux/builds/28828
I don't know exactly why or how this patch breaks the bots, but it seems
pretty concrete that it's the culprit.
Part of https://bugs.llvm.org/show_bug.cgi?id=41734
LTO can drop externally available definitions. Such AssociatedSymbol is
not associated with a symbol. ELFWriter::writeSection() will assert.
Allow a SHF_LINK_ORDER section to have sh_link=0.
We need to give sh_link a syntax, a literal zero in the linked-to symbol
position, e.g. `.section name,"ao",@progbits,0`
Reviewed By: pcc
Differential Revision: https://reviews.llvm.org/D72899
This drops a GNU gold workaround and reverts the revert commit rL366708.
Before binutils 2.34, gold -O2 and above did not correctly handle R_386_GOTOFF to
SHF_MERGE|SHF_STRINGS sections: https://sourceware.org/bugzilla/show_bug.cgi?id=16794
From the original review:
... it reduced the size of a big ARM-32 debug image by 33%. It contained ~68M
of relocations symbols out of total ~71M symbols (96% of symbols table was
generated for relocations with symbol).
-Wl,-O2 (and -Wl,-O3) is so rare that we should just lower the
optimization level for LLVM_LINKER_IS_GOLD rather than pessimizing all users.
