summary refs log tree commit diff stats
path: root/results/classifier/deepseek-r1:32b/output/instruction/1915327
blob: 5651f2a1f78310c45ddf5e6131f82f06ef6a06ff (plain) (blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
x86_64 cmpxchg behavior in qemu tcg does not match the real CPU

QEMU version:
1214d55d1c (HEAD, origin/master, origin/HEAD) Merge remote-tracking branch 'remotes/nvme/tags/nvme-next-pull-request' into staging

Consider the following little program:

$ cat 1.c
#include <stdio.h>
int main() {
  int mem = 0x12345678;
  register long rax asm("rax") = 0x1234567812345678;
  register int edi asm("edi") = 0x77777777;
  asm("cmpxchg %[edi],%[mem]"
      : [ mem ] "+m"(mem), [ rax ] "+r"(rax)
      : [ edi ] "r"(edi));
  long rax2 = rax;
  printf("rax2 = %lx\n", rax2);
}

According to the Intel Manual, cmpxchg should not touch the accumulator in case the values are equal, which is indeed the case on the real CPU:

$ gcc 1.c
$ ./a.out 
rax2 = 1234567812345678

However, QEMU appears to zero extend EAX to RAX:

$ qemu-x86_64 ./a.out 
rax2 = 12345678

This is also the case for lock cmpxchg.

Found in BPF development context: https://lore<email address hidden>