3rdparty/asmjit: sync with upstream version 1.20

[pmackinlay]

• from asmjit/asmjit@5134d39

[cuavas]

I’m going to have to regression test everything across x86-64, AArch64 and i686 after this is applied, aren’t I.

How urgent is this? What does synchronising with upstream gain?

[cuavas]

One possible risk I can see is that with all the stuff that’s renamed in asmjit, there could be names that are now shadowed so a local symbol takes precedence over one imported from asmjit with a using statement.

[stonedDiscord]

Changelog:
https://asmjit.com/doc/group__asmjit__breaking__changes.html#api_changes

[cuavas]

Changelog: https://asmjit.com/doc/group__asmjit__breaking__changes.html#api_changes

I know how to find a changelog. There’s still a risk:

• Something was renamed in asmjit
• Something in a recompiler back-end already had the new name that the thing in asmjit is now using
• After updating the code to use the new name asmjit is now using, it uses the thing that already used the new name rather than the thing imported from asmjit with a using statement

[cuavas]

OK, this really isn't looking good. Windows arm64 builds pass all the DRC unit tests, but any attempt to actually start a game results in an assertion failure in asmjit:

[asmjit] Assertion failed at ../../../../../3rdparty/asmjit/src/asmjit/./core/../core/codeholder.h (line 584):
[asmjit] is_bound()
(dfc.2914): Security check failure or stack buffer overrun - code c0000409 (!!! second chance !!!)
Subcode: 0x7 FAST_FAIL_FATAL_APP_EXIT 
ucrtbase!abort+0x3c:
00007ffc`3b45ba6c d43e0060 brk         #0xF003

Looking at codeholder.h, line 584 doesn't seem to have an assertion on it at all, so I don't know what's going on.

I made sure stuff really rebuilt by removing objects:

rm -r build/mingw-clang/obj/x64/*/3rdparty/asmjit/src/asmjit/*
find build -name \*.a -delete
rm -r build/mingw-clang/obj/x64/Debug/src/{devices,mame}

I'm at a loss. Can anyone else tell me why this could be happening?

[cuavas]

Anyway, we can't ship with it broken, so it has to be fixed somehow.

[cuavas]

Oh hang on, I was looking at the wrong version of the asmjit source. It thinks it's trying to get the offset of an unbound label.

[cuavas]

And now I'm stuck again - lldb for MSYS clangarm64 won't give me a backtrace (only shows one frame), and WinDbg doesn't support the embedded symbol information that clang produces (it wants external PDB files).

[cuavas]

2ea623d gets us back in business.