| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
|
|
MCFixupKind is now a type alias (fixup kinds are inherently
target-specific). getTargetKind is no longer necessary.
|
|
to align with targets that have made the transition.
|
|
Prepare for removing PPCMCExpr. Adopt the newer naming convention with
AMDGPU/WebAssembly/VE/M68k.
|
|
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.
|
|
MCValue
Prepare for removing the MCSymbol argument
|
|
Additionally, swap MCFixup/MCValue order to match addReloc/recordRelocation.
|
|
Prepare for removing MCContext from getRelocType functions.
|
|
Remove FK_PCRel_* kinds from the generic fixup list, as they are not
generic like FK_Data_*. In getRelocType, FK_PCRel_* can be replaced with
FK_Data_* by leveraging the IsPCRel argument. Their inclusion in the
generic kind list caused confusion for PowerPC, RISCV, and VE targets.
The X86/M68k uses can be implemented as target-specific fixups.
|
|
|
|
Move `Fixup.getKind() >= FirstLiteralRelocationKind` from target hooks
to ELFObjectWriter::recordRelocation.
Currently, getRelocType cannot be skipped for LoongArch due to #135519
|
|
Report a proper error and fix de1dc9c98f9ce74d38aceb44e00d258370d1bb34
|
|
Generalize the test from https://reviews.llvm.org/D83255
Replace getAccessVariant with MCValue::getSpecifier
Simplify code after MCValue improvement 94821ce45fe93aa78cc5ea03cd9deac91b7af127
|
|
The relocation specifier should be accessed via MCValue::Specifier.
However, some targets encode the relocation specifier within SymA using
MCSymbolRefExpr::SubclassData and access it via getAccessVariant(), though
this method is now deprecated.
This change stores the SymA specifier at Specifier as well, unifying the
two code paths.
* CSKY: GOT- and PLT- relocations now suppress the STT_SECTION
conversion.
* AArch64: https://reviews.llvm.org/D156505 added `getRefkind` check to
prevent folding. This is a hack and is now removed.
MCValue: Unify relocation specifier storage by storing SymA specifier at Specifier
The relocation specifier is accessed via MCValue::Specifier, but some
targets encoded it within SymA using MCSymbolRefExpr::SubclassData and
retrieved it through the now-deprecated getAccessVariant() method. This
commit unifies the two approaches by storing the SymA specifier at
`Specifier` as well.
Additional changes:
- CSKY: GOT- and PLT- relocations now suppress STT_SECTION conversion.
- AArch64: Removed the `getRefkind` check hack (introduced in https://reviews.llvm.org/D156505) that prevented folding.
Removed the assertion from `getRelocType`.
- RISCV: Removed the assertion from `getRelocType`.
Future plans:
- Replace MCSymbolRefExpr members with MCSymbol within MCValue.
- Remove `getSymSpecifier` (added for migration).
|
|
We will replace the MCSymbolRefExpr member in MCValue with MCSymbol.
This change reduces dependence on MCSymbolRefExpr.
|
|
In addition, rename *MCExpr::getKind, which confusingly shadows the base class getKind.
|
|
Follow the X86 and Mips renaming.
> "Relocation modifier" suggests adjustments happen during the linker's relocation step rather than the assembler's expression evaluation.
> "Relocation specifier" is clear, aligns with Arm and IBM’s usage, and fits the assembler's role seamlessly.
In addition, rename *MCExpr::getKind, which confusingly shadows the base class getKind.
|
|
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.
|
|
Make the name conciser. PPC-specific MCSymbolRefExpr::VariantKind
members will be moved to PPCMCExpr and we will not ue
MCSymbolRefExpr::VariantKind's "generic" members, so there won't be
mix-and-match.
|
|
This cleans up @l @ha optimization in PPCAsmParser and is also the first
step toward removing VK_PPC_* from the generic MCSymbolRefExpr::VariantKind.
Basically we ensure that @l @ha family modifiers always lead to
PPCMCExpr and avoid MCSymbolRefExpr::VariantKind. This allows us
to delete a lot of switch statements that involve a long list of VK_PPC_LO/VK_PPC_HI/...
|
|
52cf8e44880bcf614068b66b63393aa8da1edd76 (2013) introduced the
VK_PPC_TLSGD workaround to prevent unconditional reference to
_GLOBAL_OFFSET_TABLE_ in ELFObjectWriter.
e2b355d651ed8f2cbe61672c4c39b6419e471265 (2015) removed the
`_GLOBAL_OFFSET_TABLE_` hack for the generic VK_TLSGD,
making the VK_PPC_TLSGD workaround unneeded.
|
|
Identified with misc-include-cleaner.
|
|
Assemblers change certain relocations referencing a local symbol to
reference the section symbol instead. This conversion is disabled for
many conditions (`shouldRelocateWithSymbol`), e.g. TLS symbol, for most
targets (including AArch32, x86, PowerPC, and RISC-V) GOT-generating
relocations.
However, AArch64 encodes the GOT-generating intent in MCValue::RefKind
instead of MCSymbolRef::Kind (see commit
0999cbd0b9ed8aa893cce10d681dec6d54b200ad (2014)), therefore not affected
by the code `case MCSymbolRefExpr::VK_GOT:`. As GNU ld and ld.lld
create GOT entries based on the symbol, ignoring addend, the two ldr
instructions will share the same GOT entry, which is not expected:
```
ldr x1, [x1, :got_lo12:x] // converted to .data+0
ldr x1, [x1, :got_lo12:y] // converted to .data+4
.data
// .globl x, y would suppress STT_SECTION conversion
x:
.zero 4
y:
.long 42
```
This patch changes AArch64 to suppress local symbol to STT_SECTION
conversion for GOT relocations, matching most other targets. x and y
will use different GOT entries, which IMO is the most sensable behavior.
With this change, the ABI decision on https://github.com/ARM-software/abi-aa/issues/217
will only affect relocations explicitly referencing STT_SECTION symbols, e.g.
```
ldr x1, [x1, :got_lo12:(.data+0)]
ldr x1, [x1, :got_lo12:(.data+4)]
// I consider this unreasonable uses
```
IMO all reasonable use cases are unaffected.
Link: https://github.com/llvm/llvm-project/issues/63418
GNU assembler PR: https://sourceware.org/bugzilla/show_bug.cgi?id=30788
Reviewed By: peter.smith
Differential Revision: https://reviews.llvm.org/D158577
|
|
This patch emits the relocation type R_PPC_DTPREL32 for tls variables,
which was previously emitting R_PPC_ADDR32 in power-pc 32bit.
Differential Revision: https://reviews.llvm.org/D156953
|
|
The Linux kernel build uses absolute expressions suffixed with @lo/@ha
relocations. This currently doesn't work for DS/DQ form instructions and
there is no reason for it not to. It also works with GAS.
This patch allows this as long as the value is a multiple of 4/16
for DS/DQ form.
Differential revision: https://reviews.llvm.org/D115419
|
|
This patch is the initial support for the Local Dynamic Thread Local Storage
model to produce code sequence and relocation correct to the ABI for the model
when using PC relative memory operations.
Differential Revision: https://reviews.llvm.org/D87721
|
|
This patch is the initial support for the Local Exec Thread Local
Storage model to produce code sequence and relocations correct
to the ABI for the model when using PC relative memory operations.
Patch by: Kamau Bridgeman
Differential Revision: https://reviews.llvm.org/D83404
|
|
This patch is the initial support for the Intial Exec Thread Local
Local Storage model to produce code sequence and relocations correct
to the ABI for the model when using PC relative memory operations.
Reviewed By: stefanp
Differential Revision: https://reviews.llvm.org/D81947
|
|
This patch is the initial support for the General Dynamic Thread Local
Local Storage model to produce code sequence and relocations correct
to the ABI for the model when using PC relative memory operations.
Patch by: NeHuang
Reviewed By: stefanp
Differential Revision: https://reviews.llvm.org/D82315
|
|
Currently the instruction paddi always takes s34imm as the type for the
34 bit immediate. However, the PC Relative form of the instruction should
not produce the same fixup as the non PC Relative form.
This patch splits the s34imm type into s34imm and s34imm_pcrel so that two
different fixups can be emitted.
Reviewed By: nemanjai, #powerpc, kamaub
Differential Revision: https://reviews.llvm.org/D83255
|
|
as it was failing in Release+Asserts mode with an assert.
This reverts commit bd2068031121adf5a0e28d9306a1741d6f0bbd87.
|
|
Currently the instruction paddi always takes s34imm as the type for the
34 bit immediate. However, the PC Relative form of the instruction should
not produce the same fixup as the non PC Relative form.
This patch splits the s34imm type into s34imm and s34imm_pcrel so that two
different fixups can be emitted.
Reviewed By: kamaub, nemanjai
Differential Revision: https://reviews.llvm.org/D83255
|
|
Add initial support for PC Relative addressing for global values that
require GOT indirect addressing. This patch adds PCRelative support for
global addresses that may not be known at link time and may require
access through the GOT.
Differential Revision: https://reviews.llvm.org/D76064
|
|
Add initial support for PC Relative addressing for constant pool loads.
This includes adding a new relocation for @pcrel and adding a new PowerPC flag
to identify PC relative addressing.
Differential Revision: https://reviews.llvm.org/D74486
|
|
On PowerPC most functions require a valid TOC pointer.
This is the case because either the function itself needs to use this
pointer to access the TOC or because other functions that are called
from that function expect a valid TOC pointer in the register R2.
The main exception to this is leaf functions that do not access the TOC
since they are guaranteed not to need a valid TOC pointer.
This patch introduces a feature that will allow more functions to not
require a valid TOC pointer in R2.
Differential Revision: https://reviews.llvm.org/D73664
|
|
Generalizes ad7199f3e60a49db023099dcb879fcc9cdf94a2e (R_PPC_NONE/R_PPC64_NONE).
|
|
Prefer `MCFixupKind` where possible and add getTargetKind() to
convert to `unsigned` when needed rather than scattering cast
operators around the place.
Differential Revision: https://reviews.llvm.org/D59890
llvm-svn: 369720
|
|
Now that we've moved to C++14, we no longer need the llvm::make_unique
implementation from STLExtras.h. This patch is a mechanical replacement
of (hopefully) all the llvm::make_unique instances across the monorepo.
llvm-svn: 369013
|
|
This can be used to create references among sections. When --gc-sections
is used, the referenced section will be retained if the origin section
is retained.
llvm-svn: 360990
|
|
to reflect the new license.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
llvm-svn: 351636
|
|
Enables using the high and high-adjusted symbol modifiers on thread local
storage modifers in powerpc assembly. Needed to be able to support 64 bit
thread-pointer and dynamic-thread-pointer access sequences.
Differential Revision: https://reviews.llvm.org/D47754
llvm-svn: 334856
|
|
Add support for the "@high" and "@higha" symbol modifiers in powerpc64 assembly.
The modifiers represent accessing the segment consiting of bits 16-31 of a
64-bit address/offset.
Differential Revision: https://reviews.llvm.org/D47729
llvm-svn: 334855
|
|
writer. NFCI.
With this we gain a little flexibility in how the generic object
writer is created.
Part of PR37466.
Differential Revision: https://reviews.llvm.org/D47045
llvm-svn: 332868
|
|
functions.
This makes the ownership of the resulting MCObjectWriter clear, and allows us
to remove one instance of MCObjectStreamer's bizarre "holding ownership via
someone else's reference" trick.
llvm-svn: 315327
|
|
ELFObjectWriter's constructor.
Fixes the same ownership issue for ELF that r315245 did for MachO:
ELFObjectWriter takes ownership of its MCELFObjectTargetWriter, so we want to
pass this through to the constructor via a unique_ptr, rather than a raw ptr.
llvm-svn: 315254
|
|
I did this a long time ago with a janky python script, but now
clang-format has built-in support for this. I fed clang-format every
line with a #include and let it re-sort things according to the precise
LLVM rules for include ordering baked into clang-format these days.
I've reverted a number of files where the results of sorting includes
isn't healthy. Either places where we have legacy code relying on
particular include ordering (where possible, I'll fix these separately)
or where we have particular formatting around #include lines that
I didn't want to disturb in this patch.
This patch is *entirely* mechanical. If you get merge conflicts or
anything, just ignore the changes in this patch and run clang-format
over your #include lines in the files.
Sorry for any noise here, but it is important to keep these things
stable. I was seeing an increasing number of patches with irrelevant
re-ordering of #include lines because clang-format was used. This patch
at least isolates that churn, makes it easy to skip when resolving
conflicts, and gets us to a clean baseline (again).
llvm-svn: 304787
|
|
Differential Revision: http://reviews.llvm.org/D17038
llvm-svn: 260401
|
|
Fixes PR25944.
llvm-svn: 257697
|
