wmjb wrote: Thanks for the clarification — and yes, I agree that the question of whether LLVM should support ARM mode on Windows is a separate discussion. I’m not trying to derail the SEH work here. My point is narrower:
Even if LLVM only emits Thumb today, Windows ARM32 absolutely supports ARM mode, and MSVC‑built binaries can contain ARM‑mode functions. That’s not speculation — it’s observable behaviour in real MSVC output, especially around: compiler‑generated helper functions certain runtime thunks older MSVC toolchains targeting Windows RT mixed‑mode object files linked into modern binaries I can provide concrete examples in a separate issue if needed, but the only reason I raised it here is because SEH unwind correctness depends on the actual instruction mode of the function, not on what LLVM currently chooses to emit. So my concern is simply this: If the SEH implementation assumes Thumb‑only semantics, it should explicitly document that assumption and assert on ARM‑mode cases, because Windows itself does not enforce Thumb‑only. That avoids silent mis‑unwinds later if/when LLVM grows ARM‑mode support or encounters ARM‑mode objects from external libraries. To be clear: I’m not asking this patch to implement ARM‑mode support. I’m asking that the implementation be explicit about the assumption so future contributors don’t accidentally rely on behaviour that only holds in Thumb‑only codegen. If you’d like, I can open a separate issue with concrete MSVC ARM‑mode examples and the historical context (including vcalls, C++ EH, and the _rt_sdiv linker quirk), but I wanted to keep the SEH review grounded in the practical ABI implications. https://github.com/llvm/llvm-project/pull/184953 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
