[PATCH 1/1] Cygwin: Fix SEH and signal handling on AArch64

[Corinna Vinschen]

Hi Evgeny,

On Mar 31 18:49, Evgeny Karpov wrote:
> On Mon, Mar 30, 2026, Corinna Vinschen wrote:
> > On Mar 27 12:43, Igor Podgainoi wrote:
> > > This patch adds the SEH_CODE macro (defined in exception.h), allowing
> > > a single EXCEPTION_HANDLER_DATA metadata definition to be used on both
> > > AArch64 and x86_64 architectures.
> > >
> > > It also fixes an issue related to stack replacement in _dll_crt0 that
> > > impacts SEH and signal handling, where due to an epilogue optimization
> > > on AArch64 the epilogue might appear before _main_tls->call. However,
> > > after the stack replacement this optimization becomes broken.
> >
> > Can you explain why this problem only affects aarch64 and not x86_64
> > as well?
> 
> It looks like the x86_64 epilogue is also optimized and appears before
> _main_tls->call.
> However, the x86_64 epilogue uses the shadow stack which was allocated after
> the stack replacement. It means if _dll_crt0 is modified, it might bring more
> operations for unwinding, and that might access the stack outside of the shadow
> space. It will lead to the same issue as on AArch64. Potentially, the compiler
> barrier should be enabled also on x86_64. And the shadow space concept does not
> apply to AArch64.

Thanks for the explanation, I think I see what you mean.  Right now we
subtract 16 bytes from the stacklimit as startaddress for the new stack,
see https://sourceware.org/cgit/newlib-cygwin/tree/winsup/cygwin/create_posix_thread.cc#n270

So... since we're setting up an entirely new stack anyway, would it
make sense to subtract, say, 256 bytes from the stack for both targets
instead of just the 16 bytes?  That way there should always be enough
space for the epilogue, isn't it?


Thanks,
Corinna