summary refs log tree commit diff stats
path: root/gitlab/issues_text/target_sparc/host_missing/accel_TCG/2773
blob: 1e1d8be99c86a7b6d2014386feeab16dcc724283 (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
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
qemu-system-sparc64 sometimes generates endless loops
Description of problem:
Sometimes emulation "stops" in a busy loop hogging 1 cpu completely.
gdb says:

```
0x00007d5805460ac5 in code_gen_buffer ()
(gdb) info thread
  Id   Target Id                     Frame 
* 1    LWP 9166 of process 12669 ""  0x00007d5805460ac5 in code_gen_buffer ()
  2    LWP 19293 of process 12669 "" 0x00007d584680803a in ____sigtimedwait50
    () from /usr/lib/libc.so.12
  3    LWP 20202 of process 12669 "" 0x00007d58468249ba in ___lwp_park60 ()
   from /usr/lib/libc.so.12
  4    LWP 12669 of process 12669 "" 0x00007d58467b72ca in _sys___pollts50 ()
   from /usr/lib/libc.so.12
(gdb) up
#1  0x00000000007b3a0f in cpu_tb_exec (cpu=cpu@entry=0x7d58041ac680, 
    itb=<optimized out>, tb_exit=tb_exit@entry=0x7d58037ffde8)
    at ../accel/tcg/cpu-exec.c:458
458	    ret = tcg_qemu_tb_exec(cpu_env(cpu), tb_ptr);

(gdb) down
#0  0x00007d5805460ac5 in code_gen_buffer ()
(gdb) x/16i $pc
=> 0x7d5805460ac5 <code_gen_buffer+19401368>:	mov    %r15,0x68(%rbp)
   0x7d5805460ac9 <code_gen_buffer+19401372>:	xor    %r12,%r14
   0x7d5805460acc <code_gen_buffer+19401375>:	mov    %r14,0x80(%rbp)
   0x7d5805460ad3 <code_gen_buffer+19401382>:	mov    %r12,%rbx
   0x7d5805460ad6 <code_gen_buffer+19401385>:	mov    %rbx,0x70(%rbp)
   0x7d5805460ada <code_gen_buffer+19401389>:	mov    %r12,0x78(%rbp)
   0x7d5805460ade <code_gen_buffer+19401393>:	mov    %r14,%r12
   0x7d5805460ae1 <code_gen_buffer+19401396>:	shr    $0x20,%r12
   0x7d5805460ae5 <code_gen_buffer+19401400>:	and    $0x1,%r12d
   0x7d5805460ae9 <code_gen_buffer+19401404>:	dec    %r12
   0x7d5805460aec <code_gen_buffer+19401407>:	and    %rbx,%r12
   0x7d5805460aef <code_gen_buffer+19401410>:	mov    %r12d,%ebx
   0x7d5805460af2 <code_gen_buffer+19401413>:	movb   $0x1,-0x4(%rbp)
   0x7d5805460af6 <code_gen_buffer+19401417>:	cmp    %r13,%rbx
   0x7d5805460af9 <code_gen_buffer+19401420>:	
    je     0x7d5805460b20 <code_gen_buffer+19401459>
   0x7d5805460aff <code_gen_buffer+19401426>:	
    jmp    0x7d5805460b04 <code_gen_buffer+19401431>
(gdb) list
453	    if (qemu_loglevel_mask(CPU_LOG_TB_CPU | CPU_LOG_EXEC)) {
454	        log_cpu_exec(log_pc(cpu, itb), cpu, itb);
455	    }
456	
457	    qemu_thread_jit_execute();
458	    ret = tcg_qemu_tb_exec(cpu_env(cpu), tb_ptr);
459	    cpu->neg.can_do_io = true;
460	    qemu_plugin_disable_mem_helpers(cpu);
461	    /*
462	     * TODO: Delay swapping back to the read-write region of the TB
```
Steps to reproduce:
Unfortunately I have not been able to find a way to reliably reproduce this.
Happens "often" to me, but not always.

If you have any idea (like: what traces to enable) how to debug this I'll try to gather more information