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
