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

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

[Jakub Jermar]

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).

Regards,
Jakub

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

[Blue Swirl]

On 1/11/09, Jakub Jermar <jakub@jermar.eu> 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.

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

[Jakub Jermar]

Blue Swirl wrote:
> On 1/11/09, Jakub Jermar <jakub@jermar.eu> 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