- User Since
- Dec 10 2017, 12:26 PM (93 w, 6 h)
Feb 24 2018
I can verify that if execution enters the kernel via trap or otherwise from a program in ARM mode on WinRT or Winphone 8.1 using the default MSVC compilers no ARM->Thumb2 switch occurs and the kernel's Thumb2 code executes in ARM mode, usually causing the system to black screen or hard lock with no dump / bugcheck. The kernel doesn't make any attempt to change the mode on entry or exit. It's been years since I did the research on that but I suspect it hasn't changed extensively and in any event makes the earlier devices flat out disastrous to execute ARM code on from a system perspective; It really doesn't support the mode.
I have a couple of questions (along with a nitpicky inline comment).
Feb 23 2018
I'm not seeing any problems with this.
Feb 12 2018
Looks like a short-circuit gone wrong to me, but it got me wondering if there's a usage of ISD::AND that doesn't cover X86ISD::AND entirely. May have just been an artifact. The getResNo() == 0 I'm not familiar with. I can look into it if someone else doesn't get eyes on it first.
Feb 11 2018
It appears that sub reg, 0 clears the flags it normally modifies, but that's not really the situation being tested for and is already modeled. There might be weird code floating around that relies on that for some reason, but I kind of doubt it.