Is there some concurrency going on? Maybe some other part of the program is flipping the direction flag?
-Dimitry > On 26 Feb 2026, at 21:15, KENNON J CONRAD <[email protected]> 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 1 8th 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. > > Best Regards, > > Kennon > > > > >> On 02/26/2026 5:25 AM PST Eliot Moss <[email protected]> wrote: >> >> >> On 2/26/2026 6:02 AM, KENNON J CONRAD via Cygwin wrote: >> >>> Thanks for checking and sharing your thoughts. This is what I would >>> expect, so at least I'm not crazy :) >>> I really need to see the values of the registers in memmove, hopefully it's >>> just a matter of continuing to learn gdb. >> >> The command is "info registers", of "info r" for short. You can also print >> an >> individual register using (say) "print $rax" (prefix the register name by $) >> or "info r rax". If you're stepping, you can set up a *layout* that shows >> all >> the register values as you step along. >> >> You also might consider using a reverse debugging tool like the "undo" >> debugger. >> They track enough information to allow them to (effectively) execute >> backwards >> from a point. Not sure if any work under cygwin, though. >> >> By the way, I got the commands for printing individual registers with a >> simple >> web search :-) ... >> >> HTH -- Eliot Moss -- 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
