Testing

[cmb69]

No description provided.

[cmb69]

The first attempt is based on observations from https://blog.lazym.io/2020/09/21/Unicorn-Devblog-setjmp-longjmp-on-Windows/. Since I haven't been able to patch setjmp(), I've patched longjpm(). Now a lot of tests are failing (bad) with STATUS_FAIL_FAST_EXCEPTION (maybe not so bad).

The second attempt builds with /GS-, but this time without any external dependency libraries (these may not use this setting, and might be the reasons for the STATUS_FAIL_FAST_EXCEPTION issues).

[nielsdos]

FWIW I think the issue is indeed SEH; I've had the same idea to disable SEH unwinding, but probably did something wrong: nielsdos#118
EDIT: please ignore me, I just get the same exception you already mentioned

[cmb69]

I think this is indeed related to RtlUnwindEx(); the STATUS_FAIL_FAST_EXCEPTIONs might come from some C++ code (possibly intl/ICU). So even if this can be solved by working around RtlUnwindEx(), that wouldn't be a proper solution (would skip destructors). I guess it's finally something to fix in the JIT code generation. But I wouldn't even have an idea where to start looking there.

[cmb69]

May be relevant: https://learn.microsoft.com/en-us/cpp/build/exception-handling-x64

[nielsdos]

The JIT is supposed to follow the Winx64 calling convention, so it may be worth checking the generated code to see if something in there is wrong. It could even be very subtle like alignment etc

[nielsdos]

Or we're supposed to emit some exception-related data structures is what you're saying?

[cmb69]

Or we're supposed to emit some exception-related data structures is what you're saying?

Yes, I think so. https://learn.microsoft.com/en-us/cpp/build/exception-handling-x64 says:

For dynamically generated functions [JIT compilers], the runtime to support these functions must either use RtlInstallFunctionTableCallback or RtlAddFunctionTable to provide this information to the operating system. Failure to do so will result in unreliable exception handling and debugging of processes.

Anyhow, /GS- got rid of the STATUS_BAD_STACK, but not the STATUS_BAD_FUNCTION_TABLE and now we see some segfaults, too.