On Wed, 8 Jan 2025, Jacek Caban wrote:
On 8.01.2025 22:45, Martin Storsjö wrote:
On Wed, 8 Jan 2025, Jacek Caban wrote:
This is necessary to accommodate ARM64EC, under which CONTEXT refers to
the
X86_64 context structure but the regular ARM64 context structure is still
exposed as ARM64_NT_CONTEXT.
Based on patch by Billy Laws.
Signed-off-by: Jacek Caban <ja...@codeweavers.com>
---
v3: Better split.
Sorry, one detail I missed to point out last time:
+ typedef struct DECLSPEC_ALIGN(16)
+#ifdef _ARM64_
+ _CONTEXT
+#else
+ _ARM64_NT_CONTEXT
+#endif
+ {
Why is this being conditional here? For e.g. _ARM64_NT_NEON128 above, we
unconditionally name the type _ARM64_NT_NEON128, and then add a typedef if
we want to use a shorter form.
Is this because there may be code out there that does "struct _CONTEXT",
and this doesn't work if we rename the actual underlying (non-typedef)
struct name? But there's less risk of anybody doing this with "union
_NEON128"?
That would be my guess, yes. "struct _CONTEXT" is used even winnt.h itself,
so that one seems important to preserve.
Ok - understandable.
I changed that compared to Billy's patch to match winsdk, which does such
trick for CONTEXT struct, but not for others. In winsdk,
push_macro+#undef+#define+pop_macro tricks are used, but I think an #ifdef
like I used is nicer to read.
Hmm, maybe - no strong opinion here. Initially I thought that the #define
route would allow users to use both "struct _CONTEXT" and "struct
_ARM64_NT_CONTEXT", but as the #define is #undefed again directly
afterwards, I don't think it does, so I guess there's no such benefit to
that approach either.
// Martin
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
