On Tue Apr 16 06:50:45 2024 +0000, Alexandre Julliard wrote:
UPDATE I am not sure if that possible, but also maybe resetting gsbase
on selector reset to the same value can have some differences between CPUs? Here I tried on one Intel and one AMD cpu reproducing the test failures on both. Is it the exact same failure? Because there's indeed a difference, AMD doesn't reset gsbase on zero selector load.
Yes, looks exactly the same (AMD Ryzen 9 5900HX). A Linux test program similar to the above conirms that setting %gs to 0 clears previously set gsbase to NULL. The same is on "AMD Custom APU 0405" (Steam Deck).
Maybe we can go with restoring %gs in the handler similar to my debug patch (using get_current_teb instead of NtCurrentTeb)? Or, alternatively, just comment out that test (also in debugger tests)? FWIW it seems to me this test doesn't show what it wanted to show. I am guessing the idea under the test was that setting %gs to 0 will cause invalid gsbase and thus gs:0 access will crash. But as it is clear now on modern Windows it is just transparently restored. The test has access violation because that gsbase on 32 bit is invalid from start, regardless of what it is doing with gs selector. The test still gets the expected exception even with my change restoring %gs (when it returns to the same instruction and now faults "properly").