Support/jitlink coff seh by ikappaki · Pull Request #5 · lhames/llvm-project

ikappaki · 2026-05-21T20:20:20Z

This PR promotes the WindowsEasyEHPlugin to a library level plugin and fixes the prerequisite JITLink COFF bugs needed to make C++ exceptions work end to end through LLJIT on msys2/mingw.

The fixes were developed iteratively using jank as the test driver. Each iteration: run jank's test suite, hit a crash or link error, write a minimal lit test that reproduces the failure, diagnose the root cause, implement the fix, confirm the lit test passes, then move on to the next failure.

Tests were written with AI assistance and verified with the fail before/pass after principle. Mentioning for transparency, they could benefit from an expert eye. Feedback welcome. I leave it to you whether you'd like to keep them.

The implementation code includes comments at the API level and inside functions where the reasoning isn't obvious from the code alone.

Changes:

Enable JITLink for COFF x86_64 (2019be527937) - Previously LLJIT explicitly excluded COFF (UseJITLink = !TT.isOSBinFormatCOFF()), falling back to RTDyld. Test: coff-imagebase-resolution.ll (basic JITLink linking).
Resolve __ImageBase before ADDR32NB lowering (8fcef754b66c) - __ImageBase was left at address 0, so .pdata/.xdata image-relative offsets were computed as absolute addresses overflowing 32 bits and crashing the unwinder. Test: coff-imagebase-resolution.ll.
Add GOT/PLT stubs for external calls (5bb976340d29) - External DLL calls use 32bit PC relative branches that can't reach targets beyond 2GB. Without stubs, calls to DLL functions (e.g. puts) crash with out of range relocations. Test: coff-plt-stubs.ll.
Add ADDR32NB stubs for image relative external references (f9f8a22050de) - .xdata references the personality function via a 32bit image relative offset, but externals in DLLs are too far away. An executable stub near JIT'd code bridges the gap. Test: coff-addr32nb-stubs.ll.
Fix COMDAT section-definition symbol registration (59c2bca9d561) - The first symbol in a COMDAT pair wasn't registered in the graph symbol table, so .pdata relocations referencing it by index failed with "Could not find symbol at given index." Test: coff-comdat-relocation.ll.
Set OverrideObjectFlags for JITLink on COFF (f226c46abf37) - COFF has no hidden visibility, all externals become Exported. Without the override, hidden visibility IR symbols (e.g. __lljit_run_atexits) trigger a "Resolving symbol with incorrect flags" assertion. Test: trivial-return-zero.ll (existing test now passes).
Add SEHFrameRegistrationPlugin (8327fd89a8a3) — Promotes WindowsEasyEHPlugin into a library level plugin, wired into setUpGenericLLVMIRPlatform so all LLJIT users get SEH registration automatically. Test: coff-seh-registration.ll.
Add filtered DLLImportDefinitionGenerator (905aef3d2517) - Only forwards __imp_ prefixed symbols. Without the filter, the generator intercepts personality function lookups and creates conflicting null stubs, crashing the unwinder. Test: coff-dllimport-filter.ll.
Extend SEHFrameKeepAlivePass for COMDAT .pdata$* (4198c1650b54) - The pass only matched the exact name .pdata, so COMDAT sections like .pdata$comdat_fn were dead-stripped and their unwind info lost. Test: coff-comdat-pdata-keepalive.ll.
Remove dead findDefinedSymbolByName from GetImageBaseSymbol (1b574b035c62) - __ImageBase is always external or absolute, never defined. The scan over all defined symbols was unnecessary dead code. Test: coff-imagebase-lookup-perf.ll.
Add end-to-end integration tests (13c2f438225e) - C++ throw/catch through multiple JIT'd frames (with and without frame pointers), exercising the full SEH pipeline. Tests: throw-catch-mingw-seh.ll, throw-catch-mingw-seh-no-fp.ll.

Happy to answer any follow up questions regarding any of the fixes.

Thanks

Tested by (with assertions enabled): test/ExecutionEngine/Orc/trivial-return-zero.ll

…AT .pdata$* sections

…eBaseSymbol

lhames · 2026-06-02T03:06:34Z

Sorry for the delayed reply -- I'm looking at this now.

Fix llvm#201615. Fix the issue that non atomic operations race in waiting queue, which causes missed futex wakeup signals. Confirmed by TSAN: ``` ================== WARNING: ThreadSanitizer: data race (pid=388518) Write of size 4 at 0x7ffd21cf98e4 by thread T23: #0 __llvm_libc_23_0_0_git::RawRwLock::notify_pending_threads() ./libc/src/__support/threads/raw_rwlock.h:443:44 #1 __llvm_libc_23_0_0_git::RawRwLock::unlock() ./libc/src/__support/threads/raw_rwlock.h:520:5 #2 randomized_thread_operation(SharedData*) ./libc/test/integration/src/__support/threads/tsan_full_rwlock.cpp:104:18 #3 thread_runner(void*) ./libc/test/integration/src/__support/threads/tsan_full_rwlock.cpp:148:5 Previous atomic read of size 4 at 0x7ffd21cf98e4 by thread T4: #0 __llvm_libc_23_0_0_git::cpp::Atomic<unsigned int>::load(...) ./libc/src/__support/CPP/atomic.h:115:5 #1 __llvm_libc_23_0_0_git::Futex::wait(...) ./libc/src/__support/threads/linux/futex_utils.h:43:17 #2 __llvm_libc_23_0_0_git::cpp::expected<int, int> __llvm_libc_23_0_0_git::rwlock::WaitingQueue::wait<Role::Reader>(...) ./libc/src/__support/threads/raw_rwlock.h:101:35 #3 __llvm_libc_23_0_0_git::rwlock::LockResult __llvm_libc_23_0_0_git::RawRwLock::lock_slow<Role::Reader>(...) ./libc/src/__support/threads/raw_rwlock.h:402:34 #4 __llvm_libc_23_0_0_git::RawRwLock::read_lock(...) ./libc/src/__support/threads/raw_rwlock.h:485:12 #5 randomized_thread_operation(SharedData*) ./libc/test/integration/src/__support/threads/tsan_full_rwlock.cpp:79:16 swiftlang#6 thread_runner(void*) ./libc/test/integration/src/__support/threads/tsan_full_rwlock.cpp:148:5 Thread T23 (tid=388553, running) created by main thread at: #0 pthread_create ... #1 main ./libc/test/integration/src/__support/threads/tsan_full_rwlock.cpp:166:5 Thread T4 (tid=388533, running) created by main thread at: #0 pthread_create ... #1 main ./libc/test/integration/src/__support/threads/tsan_full_rwlock.cpp:166:5 SUMMARY: ThreadSanitizer: data race ./libc/src/__support/threads/raw_rwlock.h:443:44 in __llvm_libc_23_0_0_git::RawRwLock::notify_pending_threads() ================== ``` AI wrote the detection script. Manually fixed.

lhames

More review coming, but I have to crash out for the night.

lhames · 2026-06-19T12:31:09Z


+// Create GOT entries and PLT stubs in G for calls to external
+// symbols. Returns Error::success() unconditionally.
+Error buildTables_COFF_x86_64(LinkGraph &G) {


You may want to use llvm#203906 rather than this.

If we decide to keep both (a case could be made for that) then both should be declared in COFF_x86_64.h, and the comments should clearly call out the default, the alternative, and the difference in their behaviours.

Adopted llvm#203906. It replaces the ORC layer DLLImportDefinitionGenerator filter I had in LLJIT.cpp. The IAT synthesis pass now runs at the JITLink level, which is cleaner.

Both passes are needed though. They handle different codegen patterns:

synthesizeIATEntries_COFF_x86_64 handles __imp_X references (indirect calls/loads through named IAT slots), which appear when code uses __declspec(dllimport).

buildTables_COFF_x86_64 handles direct callq foo references (REL32 relocations to undefined externals), which is what mingw emits by default for libc/runtime functions without explicit dllimport annotations. These need PLT stubs when the target is beyond ±2GB.

Mingw objects typically have both patterns in the same module. Direct calls to things like puts or __gxx_personality_seh0, and __imp_ references for explicitly imported symbols. coff-plt-stubs.ll tests the direct-call case, coff-dllimport-filter.ll tests the __imp_ case.

Moved both declarations to COFF_x86_64.h with comments distinguishing their roles.

lhames · 2026-06-19T12:33:03Z

      break;
    case Triple::x86_64:
-      UseJITLink = !TT.isOSBinFormatCOFF();
+      UseJITLink = true;


I like this, but it will impact other clients: we should expect to have to revert and reapply a few times before this sticks, and we should definitely call it out in the release notes next release.

Release notes updated.

lhames · 2026-06-19T13:21:24Z

+class COFFImageBaseResolution_x86_64 {
+public:
+  // Resolves __ImageBase to the lowest allocated section address in G
+  Error operator()(LinkGraph &G) {
+    GetImageBaseSymbol GetImageBase;
+
+    auto ImageBase = GetImageBase(G);
+    if (ImageBase) {
+      orc::ExecutorAddr Base(~uint64_t(0));
+      for (auto &Sec : G.sections()) {
+        if (Sec.empty())
+          continue;
+        SectionRange SR(Sec);
+        Base = std::min(Base, SR.getStart());
+      }
+      assert(ImageBase && "__ImageBase symbol must be defined");
+      ImageBase->getAddressable().setAddress(Base);
+    }
+    return Error::success();
+  }
+};


I've been looking at how Windows handles __ImageBase and I think I've convinced myself that we should handle this via the memory manager (and maybe a custom materialisation unit), rather than a pass.

E.g. the memory manager could define (and resolve) __ImageBase in each object as it passes through the allocate method. @jaredwy -- what do you think?

My thought was a postallocation pass. That way we can ensure that its in the right place and maybe +-2gb of relevant sections. But I guess same idea, just different approach, yours does give us a bit more control over the way things layout I suppose?

Hi @lhames,

Which direction would you like me to follow? I've quickly tested @jaredwy's PostAllocationPass idea and it works.

Happy to investigate the memory manager approach instead if you'd prefer that.

Thanks

Eventually we should use the memory manager: objects in the same JITDylib should agree on __ImageBase, and the memory manager is the system that's in a position to decide what address it is.

That said this should be easy to change later: I think it's fine if we land with a PostAllocationPass.

Updated to use PostAllocationPass

… .pdata sections

ikappaki · 2026-06-29T06:32:37Z

HI @lhames,

thanks for taking the time to comment on the code. I haven't had a chance to go through your feedback in detail yet, but I'm hoping to do so soon.

In the meantime, I've pushed two follow up commits that recently came out of running jank's full compilation pipeline against the SEH patches:

Add GOT/Stubs optimizer pass for COFF x86_64 (137a555) - Registers x86_64::optimizeGOTAndStubAccesses as a PreFixupPass, bypassing PLT stubs when the target is within +/-2GB. Mirrors what ELF x86_64 already does.
Fix crash in SEHFrameRegistrationPlugin on dead-stripped COMDAT .pdata sections (45b892f) - After pruning, empty .pdata$* sections remain in the graph with no blocks. Skip them to avoid registering invalid entries with RtlAddFunctionTable. Test: SEHFrameRegistrationPluginTest.SkipsEmptyPDataSections (AI assisted, as with the other tests).

Note: the first commit in the series (296a6d1) applies MSYS2 distro patches (host triple detection, zstd, pthread) needed to build and test under MSYS2/CLANG64. These are not part of the SEH changes and won't be included in any upstream submission.

…6_64 enum

Adds a default COFF/x86_64 JITLink pass that synthesizes `__imp_` Import Address Table (IAT) entries for dllimport references. This allows COFF objects using dllimport to be JIT-linked without a hand-built import library or a special generator. On COFF, `__declspec(dllimport)` codegen emits indirect accesses through a named `__imp_X` symbol (`callq *__imp_bar(%rip)`; `movq __imp_g(%rip)` for data), with `__imp_X` left undefined. JITLink had no handling for this. The new pass — the COFF counterpart of the ELF/Mach-O GOT builder — defines each undefined external `__imp_X` over an 8-byte slot holding the address of `X`, and leaves `X` as an ordinary external to be resolved normally (import library, dynamic-library search generator, etc.). Both the call and data-access forms then resolve indirectly through the slot. Rather than the `GOTTableManager` pattern (anonymous entry + edge redirection), the pass defines the *named* `__imp_X` symbol over the slot. ELF GOT references are nameless edge kinds, so that builder must create an anonymous entry and redirect edges; COFF references `__imp_X` by name, so defining it is simpler — no edge rewriting, no orphaned-external cleanup, sharing is automatic, and the call/data-access forms are handled identically. x86_64 only (runs in the COFF/x86_64 backend's default pass pipeline). New lit test `COFF_dllimport_iat.s`: assembles an object referencing `__imp_bar` (call) and `__imp_foo` (data load), supplies `foo`/`bar` via `-abs`, links with `-noexec`, and uses `jitlink-check` to verify each `__imp_` slot holds the target's address and that the references resolve through the slot. Partly implements github issue: llvm#190122 In the comment section of the github issue there is this comment llvm#190122 (comment) This PR implements point 2 Synthesis IAT entries.

…nk IAT synthesis

…x86_64.h

ikappaki · 2026-08-08T09:07:08Z

Hi @lhames,

I've addressed all the review comments and replied inline. Could you take another look when you get a chance?

New commits addressing the feedback:

14. Migrate COFF edge kinds to generic EdgeKind_x86_64 enum (713a692c) - Removed the private EdgeKind_coff_x86_64 enum. Added Pointer32NB, SecRel32, SectionIdx16 to x86_64.h. Graph builder emits generic kinds directly.

15. Adopt synthesizeIATEntries_COFF_x86_64 from llvm#203906 (5b0d3320, 0022615e, ba9c7117) - Cherry-picked @mkovacevic99's IAT synthesis pass, removed the ORC-layer DLLImportDefinitionGenerator filter it supersedes, declared both passes in COFF_x86_64.h.

Thanks

(cc @jeaye)

lhames

Partial review comments. I've run out of time for more tonight.

From what I've read so far this looks good, but it would be great to break it up before it lands. Can you split out PRs for some of the parts that I flagged? (You'll need other reviewers on the Clang and CMake changes, but I can review the switch to generic JITLInk edge kinds).

lhames · 2026-08-09T11:59:15Z

+class COFFImageBaseResolution_x86_64 {
+public:
+  // Resolves __ImageBase to the lowest allocated section address in G
+  Error operator()(LinkGraph &G) {
+    GetImageBaseSymbol GetImageBase;
+
+    auto ImageBase = GetImageBase(G);
+    if (ImageBase) {
+      orc::ExecutorAddr Base(~uint64_t(0));
+      for (auto &Sec : G.sections()) {
+        if (Sec.empty())
+          continue;
+        SectionRange SR(Sec);
+        Base = std::min(Base, SR.getStart());
+      }
+      assert(ImageBase && "__ImageBase symbol must be defined");
+      ImageBase->getAddressable().setAddress(Base);
+    }
+    return Error::success();
+  }
+};


Eventually we should use the memory manager: objects in the same JITDylib should agree on __ImageBase, and the memory manager is the system that's in a position to decide what address it is.

That said this should be easy to change later: I think it's fine if we land with a PostAllocationPass.

lhames · 2026-08-09T12:28:58Z

+; Test that __ImageBase resolves to the correct base address so that
+; image-relative (ADDR32NB) relocations in .pdata/.xdata produce valid
+; 32-bit offsets. Without the fix, __ImageBase is zero and the offsets
+; overflow, causing a link failure.
+;
+; The test compiles a non-leaf function (one that calls another) with the
+; uwtable attribute. Non-leaf functions require unwind info, so the compiler
+; emits .pdata/.xdata with ADDR32NB relocations that reference __ImageBase.
+;
+; We use llvm-jitlink -noexec to test linking in isolation — verifying that
+; __ImageBase resolves correctly and all ADDR32NB edges fit in 32 bits.
+;
+; REQUIRES: system-windows && host-unwind-supports-jit
+; RUN: llc -mtriple=x86_64-w64-windows-gnu -filetype=obj -o %t.obj %s
+; RUN: llvm-jitlink -noexec -entry entry %t.obj
+
+define i32 @helper() #0 {
+  ret i32 42
+}
+
+define i32 @entry() #0 {
+  %val = call i32 @helper()
+  ret i32 0
+}
+
+attributes #0 = { nounwind uwtable }


This should probably be a yaml2obj test so that we test ADDR32NB directly, rather than indirectly through IR compilation.

Replaced with an assembly test (COFF_imagebase_addr32nb.s) that hand-crafts .pdata with @IMGREL relocations and uses jitlink-check to verify the fixup values directly. Same approach as COFF_dllimport_iat.s (disclaimer: written in collaboration with AI)

lhames · 2026-08-09T12:51:35Z

+/// Create stubs in G for external references: PLT stubs for calls (PCRel32)
+/// and ADDR32NB stubs for image-relative pointers (Pointer32NB). Always succeeds.
+Error buildTables_COFF_x86_64(LinkGraph &G);
+
+/// Synthesize IAT entries for undefined __imp_X externals in G. Always succeeds.
+Error synthesizeIATEntries_COFF_x86_64(LinkGraph &G);
+


Looks good, but we should try to share the logic here with COFFAutoImportGenerator.cpp if possible (CC @mkovacevic99, who wrote that class).

What did you have in mind to merge here? The only possibility I see here is to create a shared function that will create and IAT pointer slot and call it instead of CreatePointer(*G, Sec, &Target, 0)/createAnonymousPointer(G, IATSec, Target).
This pattern is also called inside DLLImportDefinitionGenerator (I have added a FIXME comment for COFFAutoImportGenerator)

lhames · 2026-08-09T12:54:26Z

+
+  /// A 32-bit section-relative relocation.
+  ///
+  /// The value written is the target's offset from the start of its
+  /// containing section.
+  ///
+  /// Fixup expression:
+  ///   Fixup <- Target + Addend : uint32
+  ///
+  SecRel32,
+
+  /// A 16-bit section index relocation.
+  ///
+  /// The value written is the 1-based index of the section containing the
+  /// target symbol.
+  ///
+  /// Fixup expression:
+  ///   Fixup <- Target + Addend : uint16
+  ///
+  SectionIdx16,
+


What are these used for? Will sections need to have a consistent index across object files?

I note that SectionIdx16 gets mapped below back to Pointer16. If that's happening on all paths, is there any point to having a separate SectionIdx16 value?

Both support debugging info. SecRel32 additionally supports static TLS (PE Format spec).

You're right about SectionIdx16, the index is baked into an absolute symbol at build time, so the lowering is a no-op. Removed it and emitting Pointer16 directly now.

lhames · 2026-08-09T12:55:43Z

-enum EdgeKind_coff_x86_64 : Edge::Kind {
-  PCRel32 = x86_64::FirstPlatformRelocation,
-  Pointer32NB,
-  Pointer64,
-  SectionIdx16,
-  SecRel32,
-};


It's fantastic to see this updated to use the generic edge kinds. Are you able to break that out into its own PR? That could land independently of the rest of this.

lhames · 2026-08-09T13:06:56Z

+    return nullptr;
+  };
+
+  Section &IATSec = G.createSection("$__IAT", orc::MemProt::Read);


We should name the IAT section in JITLink/COFF.h, then use the named constant in this and COFFAutoImportGenerator.cpp.

Added COFFIATSectionName in COFF.h. COFFAutoImportGenerator doesn't exist in this tree yet but the constant is ready for it.

lhames · 2026-08-09T13:07:39Z

+Error buildTables_COFF_x86_64(LinkGraph &G) {
+  LLVM_DEBUG(dbgs() << "Visiting edges in graph:\n");
+
+  x86_64::GOTTableManager GOT(G);


The GOT and IAT on Windows are functionally the same, right? We should make sure that they end up being the same section with shared entries.

They are functionally the same (both 8 byte pointer slots). I've tested sharing a section and it works. However I'm not sure what shared entries would look like in practice: GOTTableManager creates anonymous entries while synthesizeIATEntries defines named __imp_X symbols over its slots. @mkovacevic99 @lhames any guidance on what the unified approach should look like?

Sorry for the late reply from my side.
I think that it's possible for GOT and IAT to share one GOTTableManager, and that would mean IAT synthesis would need to do something like this:

Symbol &Entry = GOT.getEntryForTarget(G, *Target); G.makeDefined(*Imp, Entry.getBlock(), 0, G.getPointerSize(), Linkage::Strong, Scope::Local, /*IsLive=*/true);

but that would mean that the slot will end up with two symbols (which could be solved by letting entry creation take a name directly) and it also means that the two passes can't stay fully independent, which is not something we want I guess. Maybe Lang has a better idea

…-check test

ikappaki · 2026-08-22T12:04:37Z

Hi @lhames,

Pushed further commits addressing the review feedback:

16. Revert MSYS2 distro patches (9405b95) - Removed from branch as requested. Applied locally as uncommitted changes for building.

17. Move __ImageBase resolution to PostAllocationPass (8b79c2b) - Changed __ImageBase from external to absolute symbol. Resolved in PostAllocationPass per @jaredwy's suggestion.

18. Add release note for JITLink default on COFF x86_64 (4f138de)

19. Replace IR imagebase test with assembly jitlink-check test (ea9e72f) - Assembly .pdata with @IMGREL relocations, verifies fixup values directly.

20. Remove SectionIdx16 edge kind (f098c39) - Emit Pointer16 directly from the graph builder as suggested.

21. Define COFFIATSectionName constant in COFF.h (b2d3965).

I've replied to the inline comments. Will split into standalone PRs once the review is complete, if you don't mind.

ikappaki added 13 commits May 13, 2026 07:53

apply msys2 patches, correct plugin windows.h header

296a6d1

[ORC] Enable JITLink by default for x86_64 COFF targets

2019be5

[JITLink][COFF] Resolve __ImageBase before ADDR32NB lowering

8fcef75

[JITLink][COFF] Add GOT/PLT stub support for ext calls in COFFx86_64

5bb9763

[JITLink][COFF] Add ADDR32NB stubs for image rel refs to externals

f9f8a22

fixup! [JITLink][COFF] Resolve __ImageBase before ADDR32NB lowering

aa807e6

[JITLink][COFF] Fix missing symbol reg for COMDAT sect def symbols

59c2bca

[ORC] Set OverrideObjectFlags for JITLink on COFF

f226c46

Tested by (with assertions enabled): test/ExecutionEngine/Orc/trivial-return-zero.ll

[ORC] Add SEHFrameRegistrationPlugin for Windows COFF x86_64

8327fd8

[ORC] Add filterd DLLImportDefinitionGenerator for COFF gen platform

905aef3

[JITLink][ORC] Extend SEHFrameKeepAlivePass and registration for COMD…

4198c16

…AT .pdata$* sections

[JITLink][COFF] Remove dead findDefinedSymbolByName call from GetImag…

1b574b0

…eBaseSymbol

[ORC] Add end-to-end SEH integration tests for COFF x86_64

13c2f43

This was referenced May 21, 2026

Supporting Windows SEH without the ORC runtime llvm/llvm-project#163503

Open

Support/jitlink coff seh llvm 22 jank-lang/llvm-project#3

Closed

lhames reviewed Jun 19, 2026

View reviewed changes

ikappaki added 2 commits June 28, 2026 19:16

[JITLink][COFF] Add GOT/Stubs optimizer pass for COFF x86_64

137a555

[ORC] Fix crash in SEHFrameRegistrationPlugin on dead-stripped COMDAT…

45b892f

… .pdata sections

ikappaki and others added 4 commits July 27, 2026 17:47

[JITLink][COFF] Migrate COFF x86_64 edge kinds to generic EdgeKind_x8…

713a692

…6_64 enum

[ORC] Remove DLLImportDefinitionGenerator filter, superseded by JITLi…

0022615

…nk IAT synthesis

[JITLink][COFF] Declare buildTables and synthesizeIATEntries in COFF_…

ba9c711

…x86_64.h

lhames reviewed Aug 9, 2026

View reviewed changes

ikappaki added 3 commits August 14, 2026 13:00

Revert MSYS2 distro patches (out of scope for upstream)

9405b95

[JITLink][COFF] Move __ImageBase resolution to PostAllocationPass

8b79c2b

[ORC] Add release note for JITLink default on COFF x86_64

4f138de

ikappaki added 3 commits August 22, 2026 11:18

[JITLink][COFF][test] Replace IR imagebase test with assembly jitlink…

ea9e72f

…-check test

[JITLink][COFF] Remove SectionIdx16 edge kind, emit Pointer16 directly

f098c39

[JITLink][COFF] Define COFFIATSectionName constant in COFF.h

b2d3965

Conversation

ikappaki commented May 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

lhames commented Jun 2, 2026

Uh oh!

lhames left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ikappaki commented Jun 29, 2026

Uh oh!

ikappaki commented Aug 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

lhames left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ikappaki commented Aug 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

ikappaki commented May 21, 2026 •

edited

Loading

ikappaki commented Aug 8, 2026 •

edited

Loading

ikappaki commented Aug 22, 2026 •

edited

Loading