starred/shadPS4

Fork 0

mirror of https://github.com/shadps4-emu/shadPS4.git synced 2026-04-26 08:15:59 +03:00

[GH-ISSUE #1047] Unhandled illegal instruction wrgsbase #321

New issue

Closed

opened 2026-02-27 21:05:42 +03:00 by kerem · 6 comments

kerem commented

2026-02-27 21:05:42 +03:00

Owner

Originally created by @elxkot on GitHub (Sep 23, 2024).
Original GitHub issue: https://github.com/shadps4-emu/shadPS4/issues/1047

Trying to launch any game i tried results in crash with this log:

[Core] <Error> cpu_patches.cpp:TryExecuteIllegalInstruction:903: Unhandled illegal instruction at code address 0x56323c01f420: wrgsbase [Debug] <Critical> signals.cpp:SignalHandler:82: Unreachable code! Unhandled illegal instruction at code address 0x56323c01f420: wrgsbase rdi
Tried to use release AppImage build and also compiled latest master - same result.

I'm using intel Xeon E5-1650 CPU (6-core Sandy Bridge)
AMD RX580 4GB
16 GB RAM
Kernel: 6.10.10-zen1-1-zen (Also tried mainline kernel and LTS)
Mesa Version: 24.2.3

Originally created by @elxkot on GitHub (Sep 23, 2024). Original GitHub issue: https://github.com/shadps4-emu/shadPS4/issues/1047 Trying to launch any game i tried results in crash with this log: `[Core] <Error> cpu_patches.cpp:TryExecuteIllegalInstruction:903: Unhandled illegal instruction at code address 0x56323c01f420: wrgsbase [Debug] <Critical> signals.cpp:SignalHandler:82: Unreachable code! Unhandled illegal instruction at code address 0x56323c01f420: wrgsbase rdi ` Tried to use release AppImage build and also compiled latest master - same result. I'm using intel Xeon E5-1650 CPU (6-core Sandy Bridge) AMD RX580 4GB 16 GB RAM Kernel: 6.10.10-zen1-1-zen (Also tried mainline kernel and LTS) Mesa Version: 24.2.3

kerem closed this issue

2026-02-27 21:05:42 +03:00

kerem commented

2026-02-27 21:05:43 +03:00

Author

Owner

@squidbus commented on GitHub (Sep 23, 2024):

Your CPU is too old, Sandy Bridge is missing a number of extensions that are needed for PS4 games.

@squidbus commented on GitHub (Sep 23, 2024): Your CPU is too old, Sandy Bridge is missing a number of extensions that are needed for PS4 games.

kerem commented

2026-02-27 21:05:43 +03:00

Author

Owner

@elxkot commented on GitHub (Sep 23, 2024):

As far as i can google there is no actual necessity in this partucullar instruction set. Maybe there is possibility to catch this instructions and replace with analogues?

@elxkot commented on GitHub (Sep 23, 2024): As far as i can google there is no actual necessity in this partucullar instruction set. Maybe there is possibility to catch this instructions and replace with analogues?

kerem commented

2026-02-27 21:05:43 +03:00

Author

Owner

@elxkot commented on GitHub (Sep 25, 2024):

UPD: I was able to bypass architecture restrictions by launching ShadPS4 with official intel SDE utility, which emulates new instruction sets on old CPU's, and i even was able to launch Sonic Mania with kind of playable framerate with occasional stutters here and there. So i think it's entirely possible to emulate PS4 on this architecture with decent performance, but it would take effort to make it emulate this "new" instructions and add another layer of complexity to project. Still no luck in launching bloodborne though: it freezes on black screen with message:
[Kernel.Vmm] <Info> memory_management.cpp:sceKernelMapNamedDirectMemory:150: addr = 0x0, len = 0x7400000, prot = 0x3, flags = 0x0, directMemoryStart = 0x0, alignment = 0x200000

@elxkot commented on GitHub (Sep 25, 2024): UPD: I was able to bypass architecture restrictions by launching ShadPS4 with official intel SDE utility, which emulates new instruction sets on old CPU's, and i even was able to launch Sonic Mania with kind of playable framerate with occasional stutters here and there. So i think it's entirely possible to emulate PS4 on this architecture with decent performance, but it would take effort to make it emulate this "new" instructions and add another layer of complexity to project. Still no luck in launching bloodborne though: it freezes on black screen with message: `[Kernel.Vmm] <Info> memory_management.cpp:sceKernelMapNamedDirectMemory:150: addr = 0x0, len = 0x7400000, prot = 0x3, flags = 0x0, directMemoryStart = 0x0, alignment = 0x200000`

kerem commented

2026-02-27 21:05:43 +03:00

Author

Owner

@Hermiten commented on GitHub (Oct 1, 2024):

I'm closing it because this is not planned to support old CPU. This emulator is too complex for it.
Thanks for the report

@Hermiten commented on GitHub (Oct 1, 2024): I'm closing it because this is not planned to support old CPU. This emulator is too complex for it. Thanks for the report

kerem commented

2026-02-27 21:05:43 +03:00

Author

Owner

@v-fox commented on GitHub (Feb 5, 2025):

Your CPU is too old, Sandy Bridge is missing a number of extensions that are needed for PS4 games.

I'm closing it because this is not planned to support old CPU. This emulator is too complex for it.
Thanks for the report

Just finally made a successful build for my 12-core Xeon E5-2697 v2 (Ivy Bridge with f16c) and got one of these errors but about andn instruction which seems to be part of BMI1 set. In fact, it seems that it's the only thing that E5v2 is missing (other than avx2 for some games that compiled with it).

However, there is already a workaround for Apple's ARM CPUs for it in: github.com/shadps4-emu/shadPS4@131b6f90e0/src/core/cpu_patches.cpp (L868-L891)

These v2 CPUs are still as good as mid-to-high Ryzen from zen v1/v2 days but system with them cost 10-20 times less than "new" equivalent (you can bet they are more powerful than what's on SteamDeck or most <1k$ laptops). Ironically, AMD's older, pre-Sandy Bulldozer CPUs do have this instruction set but that series is actually old, weak and almost useless (speaking from experience).

So, is there any way to port that ARM workaround for x86?
It seems like it needs its own implementation under TryPatchAot instead of TryPatchJit.

I've tried mindlessly forcing it but then it fails to launch with:

[Core.Linker] <Info> module.cpp:98 Start: Module started : libSceS3DConversion
[Core.Linker] <Info> module.cpp:98 Start: Module started : libc
[Debug] <Critical> signals.cpp:85 SignalHandler: Unreachable code!
Unhandled access violation in thread 'GAME_MainThread' at code address 0x7ee4640d4012: Write to address 0xfffffffffffffff8

And running via intel-sde gets stuck with black screen at:

[Lib.Ajm] <Info> ajm.cpp:137 sceAjmInitialize: called reserved = 0
[Lib.Ajm] <Info> ajm.cpp:199 sceAjmModuleRegister: called context = 1, codec_type = 1
[Lib.AudioOut] <Info> audioout.cpp:313 sceAudioOutOpen: id = 255 port_type = Main index = 0 length = 256 sample_rate = 48000 param_type = Float_8CH attr = None

Even looked into emulating Haswell/v3 in qemu but it seems like it only allows doing it for preceding generations with less instructions. I would gladly even get a real v3 at this point if not for the price of motherboard+memory kit for it that is no better in features/quality than what I have now (which is still way better than newest cut-down "consumer-grade" crap).

@v-fox commented on GitHub (Feb 5, 2025): > Your CPU is too old, Sandy Bridge is missing a number of extensions that are needed for PS4 games. > I'm closing it because this is not planned to support old CPU. This emulator is too complex for it. > Thanks for the report Just finally made a successful build for my 12-core Xeon E5-2697 v2 (Ivy Bridge with f16c) and got one of these errors but about `andn` instruction which seems to be part of BMI1 set. In fact, it seems that it's the only thing that E5v2 is missing (other than avx2 for some games that compiled with it). *However*, there is already a workaround for Apple's ARM CPUs for it in: https://github.com/shadps4-emu/shadPS4/blob/131b6f90e0a15ace346dcfe64189cb4e2363c5f5/src/core/cpu_patches.cpp#L868-L891 These v2 CPUs are still as good as mid-to-high Ryzen from zen v1/v2 days but system with them cost 10-20 times less than "new" equivalent (you can bet they are more powerful than what's on SteamDeck or most <1k$ laptops). Ironically, AMD's older, pre-Sandy Bulldozer CPUs do have this instruction set but that series is actually old, weak and almost useless (speaking from experience). So, is there any way to port that ARM workaround for x86? It seems like it needs its own implementation under TryPatchAot instead of TryPatchJit. I've tried mindlessly forcing it but then it fails to launch with: ```journal [Core.Linker] <Info> module.cpp:98 Start: Module started : libSceS3DConversion [Core.Linker] <Info> module.cpp:98 Start: Module started : libc [Debug] <Critical> signals.cpp:85 SignalHandler: Unreachable code! Unhandled access violation in thread 'GAME_MainThread' at code address 0x7ee4640d4012: Write to address 0xfffffffffffffff8 ``` And running via `intel-sde` gets stuck with black screen at: ``` [Lib.Ajm] <Info> ajm.cpp:137 sceAjmInitialize: called reserved = 0 [Lib.Ajm] <Info> ajm.cpp:199 sceAjmModuleRegister: called context = 1, codec_type = 1 [Lib.AudioOut] <Info> audioout.cpp:313 sceAudioOutOpen: id = 255 port_type = Main index = 0 length = 256 sample_rate = 48000 param_type = Float_8CH attr = None ``` Even looked into emulating Haswell/v3 in qemu but it seems like it only allows doing it for preceding generations with less instructions. I would gladly even get a real v3 at this point if not for the price of motherboard+memory kit for it that is no better in features/quality than what I have now (which is still way better than newest cut-down "consumer-grade" crap).

kerem commented

2026-02-27 21:05:43 +03:00

Author

Owner

@squidbus commented on GitHub (Feb 5, 2025):

The patches written for Rosetta 2 work in a way that depends on the TLS layout of macOS, being able to switch stacks into a TLS slot variable without using any registers, so that we can save and restore temp registers before and after the patch. They would need to be altered to fit any other OS.

@squidbus commented on GitHub (Feb 5, 2025): The patches written for Rosetta 2 work in a way that depends on the TLS layout of macOS, being able to switch stacks into a TLS slot variable without using any registers, so that we can save and restore temp registers before and after the patch. They would need to be altered to fit any other OS.