aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/MC/MCELFStreamer.cpp
AgeCommit message (Collapse)AuthorFilesLines
2025-08-17[llvm] Remove unused includes (NFC) (#154051)Kazu Hirata1-1/+0
These are identified by misc-include-cleaner. I've filtered out those that break builds. Also, I'm staying away from llvm-config.h, config.h, and Compiler.h, which likely cause platform- or compiler-specific build failures.
2025-08-03MCSymbolELF: Migrate away from classofFangrui Song1-2/+2
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.
2025-08-03MCSymbolELF: Migrate away from classofFangrui Song1-6/+6
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.
2025-08-03MCSymbolELF: Migrate away from classofFangrui Song1-1/+1
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.
2025-07-26MC: Allocate initial fragment and define section symbol in changeSectionFangrui Song1-1/+3
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
2025-07-25Revert "MC: Allocate initial fragment and define section symbol in ↵dyung1-3/+1
changeSection" (#150736) Reverts llvm/llvm-project#150574 This is causing a test failure on AArch64 MacOS bots: https://lab.llvm.org/buildbot/#/builders/190/builds/24187
2025-07-24MC: Allocate initial fragment and define section symbol in changeSectionFangrui Song1-1/+3
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
2025-07-20MCObjectStreamer: Remove changeSectionImplFangrui Song1-1/+1
2025-07-17MC: Rework .reloc directive and fix the offset when it evaluates to a constantFangrui Song1-11/+10
* Fix `.reloc constant` to mean section_symbol+constant instead of .+constant . The initial .reloc support from MIPS incorrectly interpreted the offset. * Delay the evaluation of the offset expression after MCAssembler::layout, deleting a lot of code working with MCFragment. * Delete many FIXME from https://reviews.llvm.org/D79625 * Some lld/ELF/Arch/LoongArch.cpp relaxation tests rely on .reloc ., R_LARCH_ALIGN generating ALIGN relocations at specific location. Sort the relocations.
2025-07-15MC: Restructure MCFragment as a fixed part and a variable tailFangrui Song1-1/+1
Refactor the fragment representation of `push rax; jmp foo; nop; jmp foo`, previously encoded as `MCDataFragment(nop); MCRelaxableFragment(jmp foo); MCDataFragment(nop); MCRelaxableFragment(jmp foo)`, to ``` MCFragment(fixed: push rax, variable: jmp foo) MCFragment(fixed: nop, variable: jmp foo) ``` Changes: * Eliminate MCEncodedFragment, moving content and fixup storage to MCFragment. * The new MCFragment contains a fixed-size content (similar to previous MCDataFragment) and an optional variable-size tail. * The variable-size tail supports FT_Relaxable, FT_LEB, FT_Dwarf, and FT_DwarfFrame, with plans to extend to other fragment types. dyn_cast/isa should be avoided for the converted fragment subclasses. * In `setVarFixups`, source fixup offsets are relative to the variable part's start. Stored fixup (in `FixupStorage`) offsets are relative to the fixed part's start. A lot of code does `getFragmentOffset(Frag) + Fixup.getOffset()`, expecting the fixup offset to be relative to the fixed part's start. * HexagonAsmBackend::fixupNeedsRelaxationAdvanced needs to know the associated instruction for a fixup. We have to add a `const MCFragment &` parameter. * In MCObjectStreamer, extend `absoluteSymbolDiff` to apply to FT_Relaxable as otherwise there would be many more FT_DwarfFrame fragments in -g compilations. https://llvm-compile-time-tracker.com/compare.php?from=28e1473e8e523150914e8c7ea50b44fb0d2a8d65&to=778d68ad1d48e7f111ea853dd249912c601bee89&stat=instructions:u ``` stage2-O0-g instructins:u geomeon (-0.07%) stage1-ReleaseLTO-g (link only) max-rss geomean (-0.39%) ``` ``` % /t/clang-old -g -c sqlite3.i -w -mllvm -debug-only=mc-dump &| awk '/^[0-9]+/{s[$2]++;tot++} END{print "Total",tot; n=asorti(s, si); for(i=1;i<=n;i++) print si[i],s[si[i]]}' Total 59675 Align 2215 Data 29700 Dwarf 12044 DwarfCallFrame 4216 Fill 92 LEB 12 Relaxable 11396 % /t/clang-new -g -c sqlite3.i -w -mllvm -debug-only=mc-dump &| awk '/^[0-9]+/{s[$2]++;tot++} END{print "Total",tot; n=asorti(s, si); for(i=1;i<=n;i++) print si[i],s[si[i]]}' Total 32287 Align 2215 Data 2312 Dwarf 12044 DwarfCallFrame 4216 Fill 92 LEB 12 Relaxable 11396 ``` Pull Request: https://github.com/llvm/llvm-project/pull/148544
2025-07-15MC: Remove bundle alignment modeFangrui Song1-150/+0
The being-removed PNaCl has a Software Fault Isolation mechanism, which requires that certain instructions and groups of instructions do not cross a bundle boundary. When `.bundle_align_mode` is in effect, each instruction is placed in its own fragment, allowing flexible NOP padding. This feature has significantly complicated our refactoring of MCStreamer and MCFragment, leading to considerable effort spent untangling it (including flushPendingLabels (75006466296ed4b0f845cbbec4bf77c21de43b40), MCAssembler iteration improvement, and recent MCFragment refactoring). * Make MCObjectStreamer::emitInstToData non-virtual and delete MCELFStreamer::emitInstTodata * Delete MCELFStreamer::emitValueImpl and emitValueToAlignment Minor instructions:u decrease for both -O0 -g and -O3 builds https://llvm-compile-time-tracker.com/compare.php?from=c06d3a7b728293cbc53ff91239d6cd87c0982ffb&to=9b078c7f228bc5b6cdbfe839f751c9407f8aec3e&stat=instructions:u Pull Request: https://github.com/llvm/llvm-project/pull/148781
2025-07-13MCAlignFragment: Rename fields and use uint8_t FillLenFangrui Song1-1/+1
* Rename the vague `Value` to `Fill`. * FillLen is at most 8. Making the field smaller to facilitate encoding MCAlignFragment as a MCFragment union member. * Replace an unreachable report_fatal_error with assert.
2025-07-01MC: Store fragment content and fixups out-of-lineFangrui Song1-5/+8
Moved `Contents` and `Fixups` SmallVector storage to MCSection, enabling trivial destructors for most fragment subclasses and eliminating the need for MCFragment::destroy in ~MCSection. For appending content to the current section, use getContentsForAppending. During assembler relaxation, prefer setContents/setFixups, which may involve copying and reduce the benefits of https://reviews.llvm.org/D145791. Moving only Contents out-of-line caused a slight performance regression (Alexis Engelke's 2024 prototype). By also moving Fragments out-of-line, fragment destructors become trivial, resulting in neglgible instructions:u increase for "stage2-O0-g" and [large max-rss decrease](https://llvm-compile-time-tracker.com/compare.php?from=84e82746c3ff63ec23a8b85e9efd4f7fccf92590&to=555a28c0b2f8250a9cf86fd267a04b0460283e15&stat=max-rss&linkStats=on) for the "stage1-ReleaseLTO-g (link only)" benchmark. ( An older version using fewer inline functions: https://llvm-compile-time-tracker.com/compare.php?from=bb982e733cfcda7e4cfb0583544f68af65211ed1&to=f12d55f97c47717d438951ecddecf8ebd28c296b&linkStats=on ) Now using plain SmallVector in MCSection for storage, with potential for future allocator optimizations, such as allocating `Contents` as the trailing object of MCDataFragment. (GNU Assembler uses gnulib's obstack for fragment management.) Co-authored-by: Alexis Engelke <engelke@in.tum.de> Pull Request: https://github.com/llvm/llvm-project/pull/146307
2025-06-30MC: Merge MCFragment.h into MCSection.hFangrui Song1-1/+0
... 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
2025-05-25MC: Rework .weakrefFangrui Song1-5/+10
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.
2025-05-23RISCV: Remove shouldForceRelocation and unneeded relocationsFangrui Song1-1/+3
Follow-up to #140494 `shouldForceRelocation` is conservative and produces redundant relocations. For example, RISCVAsmBackend::ForceRelocs (introduced to support mixed relax/norelax code) leads to redundant relocations in the following example adapted from #77436 ``` .option norelax j label // For assembly input, RISCVAsmParser::ParseInstruction sets ForceRelocs (https://reviews.llvm.org/D46423). // For direct object emission, RISCVELFStreamer sets ForceRelocs (#77436) .option relax call foo // linker-relaxable .option norelax j label // redundant relocation due to ForceRelocs .option relax label: ``` Root problem: The `isSymbolRefDifferenceFullyResolvedImpl` condition in MCAssembler::evaluateFixup does not check whether two locations are separated by a fragment whose size can be indeterminate due to linker instruction (e.g. MCDataFragment with relaxation, or MCAlignFragment due to indeterminate start offst). This patch * Updates the fragment walk code in `attemptToFoldSymbolOffsetDifference` to treat MCRelaxableFragment (for --riscv-asm-relax-branches) as fixed size after finishLayout. * Adds a condition in `addReloc` to complement `isSymbolRefDifferenceFullyResolvedImpl`. * Removes the no longer needed `shouldForceRelocation`. This fragment walk code path handles nicely handles mixed relax/norelax case from https://discourse.llvm.org/t/possible-problem-related-to-subtarget-usage/75283 and allows us to remove `MCSubtargetInfo` argument (#73721) as a follow-up. This fragment walk code should be avoided in the absence of linker-relaxable fragments within the current section. Adjust two bolt/test/RISCV tests (#141310) Pull Request: https://github.com/llvm/llvm-project/pull/140692
2025-05-19RISCV,LoongArch: Encode RELAX relocation implicitlyFangrui Song1-4/+4
When linker relaxation is enabled, relaxable relocations are followed by a R_RISCV_RELAX/R_LARCH_RELAX relocation. They are encoded as two fixups by CodeEmitter and expected to have the same `IsResolved` value within MCAssembler::evaluateFixup (they must lead to either 0 or 2 relocations). This scheme wasite space and requires RISCVAsmBackend::shouldForceRelocation to be conservative. This patch introduces MCFixup::NeedsRelax to encode the RELAX relocation implicitly. The fixup will lead to either 0 or 2 relocations. Pull Request: https://github.com/llvm/llvm-project/pull/140494
2025-05-18[MC][AArch64][ARM][X86] Push target-dependent assembler flags into targets ↵Jessica Clarke1-5/+0
(#139844) The .syntax unified directive and .codeX/.code X directives are, other than some simple common printing code, exclusively implemented in the targets themselves. Thus, remove the corresponding MCAF_* flags and reimplement the directives solely within the targets. This avoids exposing all targets to all other targets' flags. Since MCAF_SubsectionsViaSymbols is all that remains, convert it to its own function like other directives, simplifying its implementation. Note that, on X86, we now always need a target streamer when parsing assembly, as it's now used for directives that aren't COFF-specific. It still does not however need to do anything when producing a non-COFF object file, so this commit does not introduce any new target streamers. There is some churn in test output, and corresponding UTC regex changes, due to comments no longer being flushed by these various directives (and EmitEOL is not exposed outside MCAsmStreamer.cpp so we couldn't do so even if we wanted to), but that was a bit odd to be doing anyway. This is motivated by Morello LLVM, which adds yet another assembler flag to distinguish A64 and C64 instruction sets, but did not update every switch and so emits warnings during the build. Rather than fix those warnings it seems better to instead make the problem not exist in the first place via this change.
2025-04-10MCStreamer: Remove Mach-O specific functions from derived MCObjectStreamerFangrui Song1-15/+0
2025-03-12[MC] Move fixSymbolsInTLSFixups to ELFObjectWriterFangrui Song1-98/+1
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.
2025-03-05[MC] Remove unneeded VK_None argument from MCSymbolRefExpr::create. NFCFangrui Song1-2/+1
2025-03-02[PowerPC] Remove VK_PPC_TLSGD and VK_PPC_TLSLDFangrui Song1-2/+0
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.
2025-02-10[ARM] Move MCStreamer::emitThumbFunc to ARMTargetStreamerFangrui Song1-4/+0
MCStreamer should not declare arch-specific functions. Such functions should go to MCTargetStreamer. Move MCMachOStreamer::emitThumbFunc to ARMTargetMachOStreamer, which is a new subclass of ARMTargetStreamer. (The new class is just placed in ARMMachObjectWriter.cpp. The conventional split like ARMELFObjectWriter.cpp/ARMELFObjectWriter.cpp is overkill.) `emitCFILabel`, called by ARMWinCOFFStreamer.cpp, has to be made public. Pull Request: https://github.com/llvm/llvm-project/pull/126199
2025-01-23[LLVM][Clang][AArch64] Implement AArch64 build attributes (#123990)SivanShani-Arm1-2/+63
- Added support for AArch64-specific build attributes. - Print AArch64 build attributes to assembly. - Emit AArch64 build attributes to ELF. Specification: https://github.com/ARM-software/abi-aa/pull/230
2025-01-22Revert "[LLVM][Clang][AArch64] Implement AArch64 build attributes (#118771)"Kazu Hirata1-63/+2
This reverts commit d7fb4a275c98f4035d1083b5eb3edd2ffb2da00e. Buildbots failing: https://lab.llvm.org/buildbot/#/builders/169/builds/7671 https://lab.llvm.org/buildbot/#/builders/65/builds/11046
2025-01-22[LLVM][Clang][AArch64] Implement AArch64 build attributes (#118771)SivanShani-Arm1-2/+63
- Added support for AArch64-specific build attributes. - Print AArch64 build attributes to assembly. - Parse AArch64 build attributes from assembly. - Emit AArch64 build attributes to ELF. Specification: https://github.com/ARM-software/abi-aa/pull/230
2024-11-15[MC] Remove unused includes (NFC) (#116317)Kazu Hirata1-2/+0
Identified with misc-include-cleaner.
2024-07-30[MC] Forward declare ELFObjectWriter (#100989)Sergei Barannikov1-0/+1
2024-07-22MCAssembler: Move SubsectionsViaSymbols; to MCObjectWriterFangrui Song1-12/+0
2024-07-22MCAssembler: Move CGProfile to MCObjectWriterFangrui Song1-4/+4
2024-07-22MCAssembler: Move Symvers to ELFObjectWriterFangrui Song1-1/+1
Similar to c473e75adeaf2998e4fb444b0bdbf2dd19312e50
2024-07-22[MC] Export llvm::ELFObjectWriterFangrui Song1-3/+7
Similar to commit 28fcafb50274be2520117eacb0a886adafefe59d (2011) for MachObjectWriter and commit 9539a7796094ff5fb59d9c685140ea2e214b945c for WinCOFFObjectWriter. MCELFStreamer can now access ELFObjectWriter directly without adding ELF-specific markGnuAbi (https://reviews.llvm.org/D97976) and setOverrideABIVersion to MCObjectWriter. A few member variables have to be made public since we cannot use a friend declaration for ELFWriter.
2024-07-12[MC] Use range-based for loops (NFC) (#98604)Kazu Hirata1-7/+5
2024-07-04[MC][ELF] Emit instructions directly into fragment (#94950)Alexis Engelke1-23/+10
Avoid needless copying of instructions and fixups and directly emit into the fragment small vectors. This (optionally, second commit) also removes the single use of the MCCompactEncodedInstFragment to simplify code.
2024-06-27[MC] Optimize getCurrentSectionOnly using CurFrag and make it non-nullableFangrui Song1-1/+1
Follow-up to e48c4011ca80385573f1b92793c75dc98abb228f ("[MC] Cache current fragment in MCStreamer"). Prerequisite: a few commits that removed nullable getCurrentSectionOnly calls.
2024-06-27[MC] Remove nullable getCurrentSectionOnly use from AsmParserFangrui Song1-6/+7
We will implement getCurrentSectionOnly with `CurFrag->getParent()`, which is non-null. Eliminate a nullable use.
2024-06-27[MC] Replace one nullable getCurrentSectionOnly with CurFragFangrui Song1-2/+2
We will implement getCurrentSectionOnly with `CurFrag->getParent()`, which is non-null. Eliminate a nullable use.
2024-06-22[MC] Change Subsection parameters from const MCExpr * to uint32_tFangrui Song1-2/+1
Follow-up to 05ba5c0648ae5e80d5afce270495bf3b1eef9af4. uint32_t is preferred over const MCExpr * in the section stack uses because it should only be evaluated once. Change the paramter type to match.
2024-06-21[MC] emitLabelAtPos: change parameter to MCDataFragment &. NFCFangrui Song1-1/+1
emitLabelAtPos is only called by ARMELFStreamer with MCDataFragment.
2024-06-14[MC] Aligned bundling: remove special handling for RelaxAllFangrui Song1-86/+3
When both aligned bundling and RelaxAll are enabled, bundle padding is directly written into fragments (https://reviews.llvm.org/D8072). (The original motivation was memory usage, which has been achieved from different angles with recent assembler improvement). The code presents challenges with the work to replace fragment representation (e.g. #94950 #95077). This patch removes the special handling. RelaxAll still works but the behavior seems slightly different as revealed by 2 changed tests. However, most `-mc-relax-all` tests are unchanged. RelaxAll used to be the default for clang -O0. This mode has significant code size drawbacks and newer Clang doesn't use it (#90013). --- flushPendingLabels: The FOffset parameter can be removed: pending labels will be assigned to the incoming fragment at offset 0. Pull Request: https://github.com/llvm/llvm-project/pull/95188
2024-06-14[MC] Add MCFragment allocation helpersFangrui Song1-4/+5
`allocFragment` might be changed to a placement new when the allocation strategy changes. `allocInitialFragment` is to deduplicate the following pattern ``` auto *F = new MCDataFragment(); Result->addFragment(*F); F->setParent(Result); ``` Pull Request: https://github.com/llvm/llvm-project/pull/95197
2024-04-25[MC] Remove RelaxAll parameters from create*StreamerFangrui Song1-2/+1
Related to clean-up opportunities discussed at #90013. After these cleanups, the `RelaxAll` parameter from `createMCObjectStreamer` can be removed as well. As `createMCObjectStreamer` is a more user-facing API and used by two files in mlir/, we postpone the cleanup to the future.
2024-04-25[MC] Move setRelaxAll() calls to MCObjectStreamerFangrui Song1-2/+0
Related to clean-up opportunities discussed at #90013.
2023-12-07[MC] .reloc: register used symbolsFangrui Song1-1/+0
When `sym` in `.reloc ., BFD_RELOC_NONE, sym` is not referenced elsewhere, `sym` is not in the symbol table and the relocation references the null symbol. Visit the expression to fix the issue.
2023-06-29[RISCV] Make linker-relaxable instructions terminate MCDataFragmentFangrui Song1-0/+3
`MCExpr::evaluateAsAbsolute` has a longstanding bug. When the MCAssembler is non-null and the MCAsmLayout is null, it may incorrectly fold A-B even if A and B are separated by a linker-relaxable instruction. This behavior can suppress some ADD/SUB relocations and lead to wrong results if the linker performs relaxation. To fix the bug, ensure that linker-relaxable instructions only appear at the end of an MCDataFragment, thereby making them terminate the fragment. When computing A-B, suppress folding if A and B are separated by a linker-relaxable instruction. * `.subsection` now correctly give errors for non-foldable expressions. * gen-dwarf.s will pass even if we add back the .debug_line or .eh_frame/.debug_frame code from D150004 * This will fix suppressed relocation when we add R_RISCV_SET_ULEB128/R_RISCV_SUB_ULEB128. In the future, we should investigate the desired behavior for `MCExpr::evaluateAsAbsolute` when both MCAssembler and MCAsmLayout are non-null. (Note: MCRelaxableFragment is only for assembler-relaxation. If we ever need linker-relaxable MCRelaxableFragment, we would need to adjust RISCVMCExpr.cpp (D58943/D73211).) Depends on D153096 Differential Revision: https://reviews.llvm.org/D153097
2023-06-07[COFF] Add MC support for emitting IMAGE_WEAK_EXTERN_ANTI_DEPENDENCY symbolsEli Friedman1-0/+1
This is mostly useful for ARM64EC, which uses such symbols extensively. One interesting quirk of ARM64EC is that we need to be able to emit weak symbols that point at each other (so if either symbol is defined elsewhere, both symbols point at the definition). This handling is currently restricted to weak_anti_dep symbols, because we depend on the current behavior of resolving weak symbols in some cases. Differential Revision: https://reviews.llvm.org/D145208
2023-04-27Revert "[COFF] Add MC support for emitting IMAGE_WEAK_EXTERN_ANTI_DEPENDENCY ↵Zequan Wu1-1/+0
symbols" This reverts commit 10c17c97ebaf81ac26f6830e51a7a57ddcf63cd2. It causes undefined symbol error on chromium windows build. A small repro was uploaded to the code review.
2023-04-17[COFF] Add MC support for emitting IMAGE_WEAK_EXTERN_ANTI_DEPENDENCY symbolsEli Friedman1-0/+1
This is mostly useful for ARM64EC, which uses such symbols extensively. One interesting quirk of ARM64EC is that we need to be able to emit weak symbols that point at each other (so if either symbol is defined elsewhere, both symbols point at the definition). This required a few changes to the way we handle weak symbols on Windows. Differential Revision: https://reviews.llvm.org/D145208
2023-04-13Revert "[COFF] Add MC support for emitting IMAGE_WEAK_EXTERN_ANTI_DEPENDENCY ↵Arthur Eubanks1-1/+0
symbols" This reverts commit fffdb7eac58b4efde5e23c1281e7a7f93a42d280. Causes crashes, see https://reviews.llvm.org/D145208
2023-04-07[COFF] Add MC support for emitting IMAGE_WEAK_EXTERN_ANTI_DEPENDENCY symbolsEli Friedman1-0/+1
This is mostly useful for ARM64EC, which uses such symbols extensively. One interesting quirk of ARM64EC is that we need to be able to emit weak symbols that point at each other (so if either symbol is defined elsewhere, both symbols point at the definition). This required a few changes to the way we handle weak symbols on Windows. Differential Revision: https://reviews.llvm.org/D145208
generated by cgit v1.1 at 2025-09-29 04:38:58 +0000