On 2/26/2026 3:15 PM, KENNON J CONRAD wrote:
Hello Eliot,
Yes, that helps a lot. With the frame set to the one for memmove, the RSI
register contains 0xa00035e0e. With the candidates_index address of
0xa00034460, that indicates the RSI register is 0x19AE more than the array
start index and corresponds to index 3287 of the uint16_t array. The array
index of the rightmost element that should be moved is 3359, so RSI holds an
array index that is 72 less than the last index that should be moved. But
since the RSI is already set up for the next iteration of REP MOVSQ, it seems
that 68 array elements should have been moved prior to the REP that gets the
SIGTRAP. So I checked the index array, and found it contains duplicate values
of 2028 at both array indexes 3291 and 3292 (elements 3292 and above have been
copied from elements 3291 and above). There should not be any duplicate values
in the active portion of the array except during the move. So it seems that 17
REP MOVSQ's were completed successfully before the SIGTRAP prevented the
18
th move from being completed. It shouldn't stop until the 767th array
element is moved, so this is pretty early in the desired REP MOVSQ iterations.
Interestingly, the DF is not set in EFLAGS at the point where the SIGTRAP is
issued (eflags 0x246 [ PF ZF IF ]) - I thought it should be set for backward
REP MOVSQ's.
I know it's a low probability for a cause, but I wonder if either the
hardware or the OS have some issue with proper restartability of the
REP MOVSQ under some weird circumstance. If the hardware/firmware
does not save the in-flight register information correct (again, in
some weird and rare situation) then restarting the instruction could
fail. Might be worth:
(a) trolling the web to see if there are reports of issues around this
instruction, Intel firmware fixes, etc. (An instruction like REP
MOVSQ is almost certainly implemented with a microcode loop, etc.)
(b) trying this exact code with a substantially different CPU model
(which might tend to avoid any microcode bug in the model you're
using).
Again, low probability, but ...
Regards - EM
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation: https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
