[PATCH 2/2] sparc: Fix mistakenly cleared PSR[EF] bit.

[Sebastian Huber]

On 06/06/2019 18:11, Maksim Kozlov wrote:
> Hello, Sebastian
>
> I think that this patch is necessary in two reasons.
>
> In general view, if we have a conditional branch, we want, obviously, to
> invoke two instruction siquences with different results. Without this
> patch we clear EF bit in conditional branch in any case and I think this
> is not that we want regardless if this causes error or not.

The patch makes the code more clear, so I will check it in with a 
modified commit message. However, I don't think it fixes a bug. I check 
the instruction trace with SIS:

*** BEGIN OF TEST SPCONTEXT 1 ***
*** TEST VERSION: 5.0.0.a38187051863cf4a423c4f00669c6786bc8ff60d
*** TEST STATE: EXPECTED-PASS
*** TEST BUILD: RTEMS_DEBUG RTEMS_NETWORKING RTEMS_POSIX_API
*** TEST TOOLS: 7.4.1 20190514 (RTEMS 5, RSB 
e047d64adf806d37393eb12d02a7ce26633d2eba, Newlib 5c2a3661c)
Test configuration N N N... done
Test configuration N N F... sis> tra
  40380837  0200e434  a02c0015  andn  %l0, %l5, %l0

Here the %l0 is superfluously modified, however, it has no effect, since ...

  40380837  0200e438  10800006  b  0x000000000200e450
  40380838  0200e43c  c021a004  clr  [ %g6 + 4 ]
  40380842  0200e450  91d02009  ta  9
  40380842  02000890  a1480000  rd  %psr, %l0
  40380845  02000894  2900803d  sethi  %hi(0x200f400), %l4
  40380846  02000898  81c52080  jmp  %l4 + 0x80
  40380847  0200089c  a6142f00  or  %l0, 0xf00, %l3
  40380849  0200f480  81880013  wr  %l3, %psr
  40380850  0200f484  82142020  or  %l0, 0x20, %g1
  40380852  0200f488  01000000  nop
  40380852  0200f48c  81c48000  jmp  %l2
  40380853  0200f490  81cca004  rett  %l2 + 4
  40380855  0200e454  ee09a01c  ldub  [ %g6 + 0x1c ], %l7
  40380857  0200e458  8095c000  tst  %l7
  40380859  0200e45c  12bfffe9  bne  0x000000000200e400
  40380862  0200e460  92102000  clr  %o1
  40380862  0200e464  c021a014  clr  [ %g6 + 0x14 ]
  40380863  0200e468  ea07a0a8  ld  [ %fp + 0xa8 ], %l5
  40380866  0200e46c  81856000  wr  %l5, %y
  40380868  0200e470  e01fa060  ldd  [ %fp + 0x60 ], %l0

... here it is loaded from the stack.

>
> More specific technical reason is that there is a real situation - I have
> debugging info and instruction trace (which was got with hardware 
> debugging
> module DSU on LEON3) where I see that sometimes we return from interrupt
> with cleared PSR[EF] flag in the floating point task (I described this a
> bit in my first message) and this causes excessive lazy fp switch
> (previously I had system crash before fixing lazy fp switch syscall).
>
> Just now I can't give very detail description why and how this happens,
> but bellow I put part of LEON3 DSU trace for mentioned above situation
>
> This is part of code which I use to investigate problem which we talk 
> about
>
> ...
> 4f102d8c:       95 a2 88 58     faddd  %f10, %f24, %f10
> 4f102d90:       80 a3 00 09     cmp  %o4, %o1
> 4f102d94:       91 a2 09 54     fmuld  %f8, %f20, %f8
> 4f102d98:       95 a0 05 4a     fsqrtd  %f10, %f10
> 4f102d9c:       d5 3b bf f8     std  %f10, [ %sp + -8 ]
> 4f102da0:       01 00 00 00     nop
> 4f102da4:       91 a2 08 4a     faddd  %f8, %f10, %f8
> 4f102da8:       95 a4 89 c8     fdivd  %f18, %f8, %f10
> 4f102dac:       d5 3b bf f8     std  %f10, [ %sp + -8 ]
> 4f102db0:       01 00 00 00     nop
> 4f102db4:       d1 38 7f 70     std  %f8, [ %g1 + -144 ]
> 4f102db8:       d1 18 80 00     ldd  [ %g2 ], %f8  <--- Interrupt
> 4f102dbc:       91 a2 08 ce     fsubd  %f8, %f14, %f8
> 4f102dc0:       91 a2 09 4a     fmuld  %f8, %f10, %f8
> 4f102dc4:       d1 38 7f 58     std  %f8, [ %g1 + -168 ]
> 4f102dc8:       d1 18 a0 08     ldd  [ %g2 + 8 ], %f8
> 4f102dcc:       91 a2 08 cc     fsubd  %f8, %f12, %f8
> ...
>
> Part of trace
>
>
> 463493523  4F06D6A0  restore                       [00000000]
> 463493524  4F06D6A4  ldd  [%g1], %l0               [0000000C 4F57C348]

%l0 is loaded here  from the stack and ...

> 463493526  4F06D6A8  ldd  [%g1 + 0x8], %l2         [0406CE9C 0406CE78]
> 463493528  4F06D6AC  ldd  [%g1 + 0x10], %l4        [0406CE54 0406CE30]
> 463493530  4F06D6B0  ldd  [%g1 + 0x18], %l6        [4F57C528 0406CE84]
> 463493533  4F06D6B4  ldd  [%g1 + 0x20], %i0        [0406CF78 4F534BB0]
> 463493610  4F06D6B8  ldd  [%g1 + 0x28], %i2        [0408CDC0 0406CE24]
> 463493612  4F06D6BC  ldd  [%g1 + 0x30], %i4        [00000001 00000003]
> 463493616  4F06D6C0  ldd  [%g1 + 0x38], %fp        [4F534B40 4F103868]
> 463493620  4F06D6C4  save                          [00000000]
> 463493622  4F06D6C8  mov  %l0, %psr                [F34000C6] <-- (1)

... here it is moved to the %psr. This is unrelated to the %l0 
modification in the patch.


> 463493625  4F06D6CC  nop                           [00000000]
> 463493702  4F06D6D0  nop                           [00000000]
> 463493703  4F06D6D4  nop                           [00000000]
> 463493717  4F06D6D8  ld  [%g1 + 0x6C], %g1         [0408D148]
> 463493718  4F06D6DC  jmp  %l1                      [4F06D6DC]
> 463493719  4F06D6E0  rett  %l2                     [4F102DC0]
> 463493722  4F102DBC  fsubd  %f8, %f14, %f8         [  TRAP  ] <-- (2)
> 463493728  04000040  mov  %psr, %l0                [F34000C6]
> 463493729  04000044  sethi  %hi(0x4F06D800), %l4   [4F06D800]
> 463493730  04000048  jmp  %l4 + 0x20               [04000048]
> 463493731  0400004C  sethi  %hi(0x1000), %l3       [00001000]
>
>
> Here (1) we see that restored PSR[EF] == 0 and directly after return from
> interrupt (2) we fall in lazy fp switch syscall
>
> To be honest, I cant say that I fully understand how _ISR_Handler 
> procedure
> works, therefore your help would be very desirable.
>
> When I get more debugging information, I'll provide it. But it takes some
> time.

-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.