The SymContentsTargetCommon kind introduced by
https://reviews.llvm.org/D61493 lackes significant and should be treated
as a regular common symbol with a different section index.
Update ELFObjectWriter to respect the specified section index.
The new representation also works with Hexagon's SHN_HEXAGON_SCOMMON.
The object file format specific derived classes are used in context
where the type is statically known. We don't use isa/dyn_cast and we
want to eliminate MCSymbol::Kind in the base class.
The object file format specific derived classes are used in context
where the type is statically known. We don't use isa/dyn_cast and we
want to eliminate MCSymbol::Kind in the base class.
Reland #150574 with a MCStreamer::changeSection change:
In Mach-O, DWARF sections use Begin as a temporary label, requiring a label
definition, unlike section symbols in other file formats.
(Tested by dec978036ef1037753e7de5b78c978e71c49217b)
---
13a79bbfe583e1d8cc85d241b580907260065eb8 (2017) introduced fragment
creation in MCContext for createELFSectionImpl, which was inappropriate.
Fragments should only be created when using MCSteramer, not during
`MCContext::get*Section` calls.
`initMachOMCObjectFileInfo` defines multiple sections, some of which may
not be used by the code generator. This caused symbol names matching
these sections to be incorrectly marked as undefined (see
https://reviews.llvm.org/D55173).
The fragment code was later replicated in other file formats, such as
WebAssembly (see https://reviews.llvm.org/D46561), XCOFF, and GOFF.
This patch fixes the problem by moving initial fragment allocation from
MCContext::createSection to MCStreamer::changeSection.
While MCContext still creates a section symbol, the symbol is not
attached to the initial fragment. In addition,
* Move `emitLabel`/`setFragment` from `switchSection*` and
overridden changeSection to `MCObjectStreamer::changeSection` for
consistency.
* De-virtualize `switchSectionNoPrint`.
* test/CodeGen/XCore/section-name.ll now passes. XCore doesn't support
MCObjectStreamer. I don't think the MCAsmStreamer output behavior
change matters.
Pull Request: https://github.com/llvm/llvm-project/pull/150574
The object file format specific derived classes are used in context like
MCStreamer and MCObjectTargetWriter where the type is statically known.
We don't use isa/dyn_cast and we want to eliminate
MCSection::SectionVariant in the base class.
13a79bbfe583e1d8cc85d241b580907260065eb8 (2017) introduced fragment
creation in MCContext for createELFSectionImpl, which was inappropriate.
Fragments should only be created when using MCSteramer, not during
`MCContext::get*Section` calls.
`initMachOMCObjectFileInfo` defines multiple sections, some of which may
not be used by the code generator. This caused symbol names matching
these sections to be incorrectly marked as undefined (see
https://reviews.llvm.org/D55173).
The fragment code was later replicated in other file formats, such as
WebAssembly (see https://reviews.llvm.org/D46561), XCOFF, and GOFF.
This patch fixes the problem by moving initial fragment allocation from
MCContext::createSection to MCStreamer::changeSection.
While MCContext still creates a section symbol, the symbol is not
attached to the initial fragment.
In addition, move `emitLabel`/`setFragment` from `switchSection*` and
overridden changeSection to `MCObjectStreamer::changeSection` for
consistency.
* test/CodeGen/XCore/section-name.ll now passes. XCore doesn't support
MCObjectStreamer. I don't think the MCAsmStreamer output behavior
change matters.
Pull Request: https://github.com/llvm/llvm-project/pull/150574
This reverts commit 1108cf64196a056aa350baba98e3fab6d7529a59.
Caused a regression for a weird but interesting case (STT_SECTION symbol
as group signature). We no longer define `sec`
```
.section sec,"ax"
.section .foo,"axG",@progbits,sec
nop
```
Fix#146581
... due to their close relationship. MCSection's inline functions (e.g.
iterator) access MCFragment, and we want MCFragment's inline functions
to access MCSection similarly (#146307).
Pull Request: https://github.com/llvm/llvm-project/pull/146315
GNU Assembler supports symbol reassignment via .set, .equ, or =.
However, LLVM's integrated assembler only allows reassignment for
MCConstantExpr cases, as it struggles with scenarios like:
```
.data
.set x, 0
.long x // reference the first instance
x = .-.data
.long x // reference the second instance
.set x,.-.data
.long x // reference the third instance
```
Between two assignments binds, we cannot ensure that a reference binds
to the earlier assignment. We use MCSymbol::IsUsed and other conditions
to reject potentially unsafe reassignments, but certain MCConstantExpr
uses could be unsafe as well.
This patch enables reassignment by cloning the symbol upon reassignment
and updating the symbol table. Existing references to the original
symbol remain unchanged, and the original symbol is excluded from the
emitted symbol table.
Use a variable symbol without any specifier instead of VK_WEAKREF.
Add code in ELFObjectWriter::executePostLayoutBinding to check
whether the target should be made an undefined weak symbol.
This change fixes several issues:
* Unreferenced `.weakref alias, target` no longer creates an undefined `target`.
* When `alias` is already defined, report an error instead of crashing.
.weakref is specific to ELF. llvm-ml has reused the VK_WEAKREF name for
a different concept. wasm incorrectly copied the ELF implementation.
Remove it.
Replace MCSymbol argument with MCValue::AddSym. The minor difference in
.weakref handling is negligible, as our implementation may not fully
align with GAS, and .weakref is not used in practice.
* Remove the MCAssembler * argument. Change subclasses to use MCAssembler *MCObjectWriter::Asm.
* Remove pure specifier and add an empty implementation
* Change MCFragment * to MCFragment &
Introduce MCAsmBackend::addReloc to manage relocation appending.
The default implementation uses shouldForceRelocation to check
unresolved fixups and calls recordRelocation to append a relocation when
needed.
RISCV and LoongArch override addReloc to handle ADD/SUB relocations,
with potential support for RELAX relocations in the future.
AVR overrides addReloc to customize shouldForceRelocation behavior
(#121498).
applyFixup is moved into evaluateFixup.
Add two helper functions to simplify checks for relocation types,
replacing direct comparisons with FirstRelocationKind and
FirstLiteralRelocationKind. Note: Some targets haven't utilized
isRelocation yet.
Also, update RelaxFixupKind to use 0 as the sentinel value.
... to match GNU Assembler. This generalizes the
SHT_LLVM_CALL_GRAPH_PROFILE special case (which uses .reloc with
BFD_RELOC_NONE https://reviews.llvm.org/D104080).
Targets that want STT_SECTION adjustment cannot use
FirstLiteralRelocationKind derived fixup kinds.
Depends on the fix of #135521
Pull Request: https://github.com/llvm/llvm-project/pull/135519
The current implementation of R_LARCH_SUB{8,16,32,64} and TLS relocation types relies on fixup kinds FirstLiteralRelocationKind + offset (originally intended for .reloc directives). While this is clever and prevents switch cases like
```
case fixup_...sub8:
return ELF::R_LARCH_SUB8;
```
it needs revision.
GNU Assembler treats .reloc directives differently from standard relocations, notably by skipping
* Skipping STT_SECTION adjustments (when a referenced symbol is local and satisfies certain conditions, it can be redirected to a section symbol).
* Skipping STT_TLS symbol type setting for TLS relocations.
Encode relocatin type t with FirstRelocationKind+t instead of
FirstLiteralRelocationKind+t. The new value is less than
FirstLiteralRelocationKind and will not be treated as a .reloc
directive.
Close#135521
Move `Fixup.getKind() >= FirstLiteralRelocationKind` from target hooks
to ELFObjectWriter::recordRelocation.
Currently, getRelocType cannot be skipped for LoongArch due to #135519
And introduce MCValue::getAddSym & MCValue::getSubSym to simplify code.
We do not utilize the MCSymbol argument of needsRelocateWithSymbol
as it will go away in the future.
It's the decision of backend needsRelocateWithSymbol whether the
STT_SECTION adjustment should be suppressed.
test/MC/AArch64/data-directive-specifier.s demonstrates how to test this
property.
Finish the migration started by
eea7d32bd262bb5f61790c42ebaa147aa26c3979.
STT_TLS setting has been moved to backend getRelocType.
75f5a4f0dc7d96134cca86543ef3f86ef218ce77 migrated the last target, VE.
Similar to previous migration done for other targets (PowerPC, X86, ARM,
etc). Switch from the confusing VariantKind to Specifier, which aligns
with Arm and IBM AIX's documentation.
In addition, rename *MCExpr::getKind, which confusingly shadows the base class getKind.
In the future, relocation specifiers should be encoded as part of
SystemZMCExpr instead of MCSymbolRefExpr.
Move target-specific members outside of MCSymbolRefExpr::VariantKind
(a legacy interface I am eliminating). Most changes are mechanic,
except:
* ELFObjectWriter::shouldRelocateWithSymbol
* The legacy generic code uses `ELFObjectWriter::fixSymbolsInTLSFixups`
to set `STT_TLS` (and use an unnecessary expression walk). The better
way is to do this in `getRelocType`, which I have done for
AArch64, PowerPC, and RISC-V.
In the future, we should encode expressions with a relocation specifier
as X86MCExpr and use MCValue::RefKind to hold the specifier of the
relocatable expression.
https://maskray.me/blog/2025-03-16-relocation-generation-in-assemblers
While here, rename "Modifier' to "Specifier":
> "Relocation modifier", though concise, suggests adjustments happen during the linker's relocation step rather than the assembler's expression evaluation. I landed on "relocation specifier" as the winner. It's clear, aligns with Arm and IBM’s usage, and fits the assembler's role seamlessly.
Pull Request: https://github.com/llvm/llvm-project/pull/132149
Most changes are mechanic, except:
* ELFObjectWriter::shouldRelocateWithSymbol: .TOC.@tocbase does not
register the undefined symbol. Move the handling into the
Sym->isUndefined() code path.
* ELFObjectWriter::fixSymbolsInTLSFixups's VK_PPC* cases are moved to
PPCELFObjectWriter::getRelocType. We should do similar refactoring
for other targets and eventually remove fixSymbolsInTLSFixups.
In the future, we should classify PPCMCExpr similar to AArch64MCExpr.
so that we only need to do it once during recordRelocation. In the
future, we should change fixSymbolsInTLSFixups to apply to MCValue
instead of MCExpr, similar to GNU assembler.
