The new gdb (7.5.1) did not change anything. The program behaves one way inside gdb and one way outside. The behaviour inside gdb is surely incorrect.
I think the behaviour outside of gdb is also incorrect, but I haven't spent much time thinking about it. To repdoduce curious behaviour: Compile the attached programs and link them.
foo.c
Description: Binary data
x.s
Description: Binary data
Execute. I believe correct behaviour is to print: 000000000000000d 000000000000000d 040000000000000b 000000000000000a The program under your special qemu instead prints: 000000000000000e 000000000000000d 040000000000000b 000000000000000a Perhaps I am being silly and the program is behaving correctly. But now fire up gdb. Set a breakpoint at __gmpn_addmul_1. Run. Single-step to just before the first adox. Then look at eflags: (gdb) info reg eflags eflags 0x246 [ PF ZF IF ] We're about to read the 10 from the main program's a[4]: (gdb) p *(unsigned long *)($rdi+8*$rcx) $3 = 10 Single-step over the adox. Again look at eflags: (gdb) info reg eflags eflags 0x3a0ede [ PF #3 AF ZF SF IF DF OF VM VIF VIP ID ] Oops. Lots of undesirable things happened to the flags. Now continuing will lock up in the jo . insn, unsurprisingly. Guest uname -a: FreeBSD hwl.gmplib.org 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243825: Tue Dec 4 09:23:10 UTC 2012 r...@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 -- Torbjörn