Remove redundaunt virtual specifiers (NFC)

Identified with tidy-modernize-use-override.

[MC] Delete dead zlib-gnu code and simplify writeSectionData

Remove zlibgnu support in llvm-mc

The feature's been removed from most other tools in LLVM at this point.

[Support] Change compression::zlib::{compress,uncompress} to use uint8_t *

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 * i

[Support] Change compression::zlib::{compress,uncompress} to use uint8_t *

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.

show more ...

[NFC] Refactor llvm::zlib namespace

* Refactor compression namespaces across the project, making way for a possible
introduction of alternatives to zlib compression.
Changes are as follows:
*

[NFC] Refactor llvm::zlib namespace

* 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

show more ...

Implement support for __llvm_addrsig for MachO in llvm-mc

The __llvm_addrsig section is a section that the linker needs for safe icf.
This was not yet implemented for MachO - this is the implementat

Implement support for __llvm_addrsig for MachO in llvm-mc

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

show more ...

[MC][ELF] Improve st_size propagation rule

`.symver foo, foo@ver` creates the MCSymbolELF `foo@ver` whose almost all
attributes (including st_size) should inherit from `foo` (GNU as behavior).

a041

[MC][ELF] Improve st_size propagation rule

`.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

show more ...

[MC] Fix llvm_unreachable when a STB_GNU_UNIQUE symbol needs a relocation

STB_GNU_UNIQUE should be treated in a way similar to STB_GLOBAL.
This fixes an "Invalid Binding" failure in an LLVM_ENABLE_A

[MC] Fix llvm_unreachable when a STB_GNU_UNIQUE symbol needs a relocation

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.

show more ...

[Support] Change zlib::compress to return void

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_f

[Support] Change zlib::compress to return void

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

show more ...

[MC] Remove unneeded zlib opt-out for .debug_frame

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

[MC] Remove unneeded zlib opt-out for .debug_frame

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.

show more ...

Cleanup LLVMMC headers

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, llv

Cleanup LLVMMC headers

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

show more ...

[X86] Selective relocation relaxation for +tagged-globals

For tagged-globals, we only need to disable relaxation for globals that
we actually tag. With this patch function pointer relocations, whic

[X86] Selective relocation relaxation for +tagged-globals

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

show more ...

[MC] Set SHF_INFO_LINK on SHT_REL/SHT_RELA sections

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 reloca

[MC] Set SHF_INFO_LINK on SHT_REL/SHT_RELA sections

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.

show more ...

[MC][ELF] Change SHT_LLVM_CALL_GRAPH_PROFILE relocations from SHT_RELA to SHT_REL

... even on targets preferring RELA. The section is only consumed by ld.lld
which can handle REL.

Follow-up to D104

[MC][ELF] Change SHT_LLVM_CALL_GRAPH_PROFILE relocations from SHT_RELA to SHT_REL

... 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.

show more ...

[LLD][LLVM] CG Graph profile using relocations

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 pro

[LLD][LLVM] CG Graph profile using relocations

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

show more ...

Reland "[MC][ELF] Work around R_MIPS_LO16 relocation handling problem"

This fixes PR49821, and avoids "ld.lld: error: test.o:(.rodata.str1.1):
offset is outside the section" errors when linking MIPS

Reland "[MC][ELF] Work around R_MIPS_LO16 relocation handling problem"

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

show more ...

Revert "[MC][ELF] Work around R_MIPS_LO16 relocation handling problem"

This reverts commit ab40c027f0ce9492919a72ad339de40bdb84b354.

Some additional test cases are influenced by the workaround, and

Revert "[MC][ELF] Work around R_MIPS_LO16 relocation handling problem"

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.

show more ...

[MC][ELF] Work around R_MIPS_LO16 relocation handling problem

This fixes PR49821, and avoids "ld.lld: error: test.o:(.rodata.str1.1):
offset is outside the section" errors when linking MIPS objects

[MC][ELF] Work around R_MIPS_LO16 relocation handling problem

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

show more ...

[MC][ELF] Fix "enumeral and non-enumeral type in conditional expression" warning (NFC)

GCC warning:
```
/llvm-project/llvm/lib/MC/ELFObjectWriter.cpp: In member function ‘void {anonymous}::ELFWriter

[MC][ELF] Fix "enumeral and non-enumeral type in conditional expression" warning (NFC)

GCC warning:
```
/llvm-project/llvm/lib/MC/ELFObjectWriter.cpp: In member function ‘void {anonymous}::ELFWriter::writeHeader(const llvm::MCAssembler&)’:
/llvm-project/llvm/lib/MC/ELFObjectWriter.cpp:421:20: warning: enumeral and non-enumeral type in conditional expression [-Wextra]
420 | W.OS << char(OSABI == ELF::ELFOSABI_NONE && OWriter.seenGnuAbi()
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
421 | ? ELF::ELFOSABI_GNU
| ^~~~~~~~~~~~~~~~~~~
422 | : OSABI);
| ~~~~~~~
```

show more ...

[MC] Change ELFOSABI_NONE to ELFOSABI_GNU for SHF_GNU_RETAIN

GNU ld does not give SHF_GNU_RETAIN GC root semantics for ELFOSABI_NONE.
(https://sourceware.org/pipermail/binutils/2021-March/115581.htm

[MC] Change ELFOSABI_NONE to ELFOSABI_GNU for SHF_GNU_RETAIN

GNU ld does not give SHF_GNU_RETAIN GC root semantics for ELFOSABI_NONE.
(https://sourceware.org/pipermail/binutils/2021-March/115581.html)

This allows GNU ld to interpret SHF_GNU_RETAIN and avoids a gold quirk
https://sourceware.org/bugzilla/show_bug.cgi?id=27490

Because ELFObjectWriter is in an anonymous namespace, I have to place
`markGnuAbi` in the parent MCObjectWriter.

Differential Revision: https://reviews.llvm.org/D97976

show more ...

[MC] Support .symver *, *, remove

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.

[MC] Support .symver *, *, remove

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.

show more ...

[MC][ELF] Fix gcc "enumeral and non-enumeral type in conditional expression" warning (NFC)

GCC warning:
```
/llvm-project/llvm/lib/MC/ELFObjectWriter.cpp: In member function ‘uint64_t {anonymous}::E

[MC][ELF] Fix gcc "enumeral and non-enumeral type in conditional expression" warning (NFC)

GCC warning:
```
/llvm-project/llvm/lib/MC/ELFObjectWriter.cpp: In member function ‘uint64_t {anonymous}::ELFWriter::writeObject(llvm::MCAssembler&, const llvm::MCAsmLayout&)’:
/llvm-project/llvm/lib/MC/ELFObjectWriter.cpp:1137:38: warning: enumeral and non-enumeral type in conditional expression [-Wextra]
1137 | write(uint32_t(Group->isComdat() ? ELF::GRP_COMDAT : 0));
| ~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~
```

show more ...

[MC][ELF] Support for zero flag section groups

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

[MC][ELF] Support for zero flag section groups

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

show more ...

ELFObjectWriter: Simplify

* Delete unused ELFSymbolData::operator<
* Inline createStringTable
* Fix a comment
* Change align to return uint64_t

ELFObjectWriter: Delete redundant registerSymbol

MCELFStreamer::changeSection has registered the group signature symbol.