Hi Eric, 13.12.2022 00:36, Eric W. Biederman пишет:
Stas, in your github report you mention that you believe this is a regression https://github.com/dosemu2/dosemu2/pull/1830. Can you tell us the last kernel this worked on?
The only thing I actually think is a regression, is the return of 0 as an error code for GPF. I am pretty sure it used to work, because I was reporting the zeroed-out err code to @amluto and he fixed it. But that was something like 5 years ago. These days @amluto seems to be inactive, does anyone know what have happened? He was always providing a very quick help in the past (and well, he wrote all that 64-32 switching code in sigreturn for us). Other problems I've found, are likely not a regressions. I.e. I never tried such tests under gdb before and I never tried to set high dword of RIP to non-zero. In fact, reliable err code is what I care most. If things can't be fixed under gdb or if I should always clear high part of RIP before switching to 32bit segment - fine. But zero error code is bad.
Which kernel you tested that this fails on?
5.19.0-26-generic from ubuntu.
It would be awesome if you could bisect this to the commit that is broken but at least knowing kernel's you have tried that work and don't work would be very useful.
Perhaps I'll look into setting up the test env under qemu if everything else fails.
Dosemu is old enough that anything it has down historically that no longer works certainly counts as a regression and should be fixed.
dosemu2 nowadays is using Andy's sigreturn new code, which is now about 10 years old. Historic dosemu afaik is not using anything like that, switching to 32bit by hands with iret.
