[Qemu-devel] Re: [BUG] Possible bug in sparc64 emulation of SAVE/RESTORE

[Jakub Jermar]

Blue Swirl wrote:
> On 1/11/09, Jakub Jermar <address@hidden> wrote:
>> Hi,
>>
>>  I've just noticed that functions:
>>
>>  helper_save()
>>  helper_restore()
>>  cpu_cwp_inc()
>>  cpu_cwp_dec
>>
>>  assume that CWP moves counter-clock-wise on sparc64.
>>  I am pretty sure it moves clock-wise on sparc64
>>  (contrary to the situation on sparc32).
> 
> True, but internally we use V8 way to make register window handling
> simpler. Outside world should see CWP acting as specified.
> 
> There is a comment about this somewhere, maybe it is unclear.

Aha, so it is me who was actually confused :-)

I am tracking some kind of a corruption:

GDB loses control on the RETRY instruction
of the fill_0_normal_tl0 handler. QEMU continues
to execute and ends up in Error state.

qemu: fatal: Trap 0x0008 while trap level (5) >= MAXTL (5), Error state
pc: 000000000040c100  npc: 000000000040c104
General Registers:
%g0: 0000000000000000   %g1: 0000000000000000   %g2: 0000000000000000   %g3: 
0000000000000000   
%g4: 0000000000000000   %g5: 0000000000000000   %g6: 0000000000000000   %g7: 
0000000000000000   
Current Register Window:
%o0: 0000000000000046   %o1: 0000000000717dc0   %o2: 0000000000717f50   %o3: 
0000000000000000   
%o4: 000000000000000a   %o5: 0000000000717cff   %o6: 0000000000717521   %o7: 
0000000000432198   
%l0: 0000000000000004   %l1: 000000000005c980   %l2: 000000000043d888   %l3: 
000000000005c000   
%l4: 0000000000000001   %l5: 000000000043e5f8   %l6: 0000000000000001   %l7: 
000000000045e368   
%i0: 000000000005c980   %i1: 0000000000000000   %i2: 0000000000000000   %i3: 
000000000042d120   
%i4: 000000000042d100   %i5: 0000000000000005   %i6: 00000000007175f1   %i7: 
0000000000421db8   

Floating Point Registers:
%f00: 000000000.000000 000000000.000000 000000000.000000 000000000.000000
%f04: 000000000.000000 000000000.000000 000000000.000000 000000000.000000
%f08: 000000000.000000 000000000.000000 000000000.000000 000000000.000000
%f12: 000000000.000000 000000000.000000 000000000.000000 000000000.000000
%f16: 000000000.000000 000000000.000000 000000000.000000 000000000.000000
%f20: 000000000.000000 000000000.000000 000000000.000000 000000000.000000
%f24: 000000000.000000 000000000.000000 000000000.000000 000000000.000000
%f28: 000000000.000000 000000000.000000 000000000.000000 000000000.000000
pstate: 0x00000414 ccr: 0x00 asi: 0x58 tl: 5 fprs: 0
cansave: 4 canrestore: 2 otherwin: 0 wstate 0 cleanwin 7 cwp 2
fsr: 0x00000000
Aborted

The interesting thing is that GDB doesn't break into the debugger when it
starts executing the function which has its address in pc (i.e.
instruction_access_exception_tl1), even though I set a breakpoint for it.
(I set breakpoints for all MMU-related traps, but didn't hit any).

Jakub