<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr"><div style="font-family:monospace,monospace" class="gmail_default">Hi, <span class="gmail_default" style="font-family:monospace,monospace"></span>Sebastian</div></div><div dir="ltr" class="gmail_attr"><br></div><div dir="ltr" class="gmail_attr">On Fri, 7 Jun 2019 at 08:33, <span class="gmail_default" style="font-family:monospace,monospace"></span>Sebastian Huber <<a href="mailto:sebastian.huber@embedded-brains.de">sebastian.huber@embedded-brains.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 06/06/2019 18:11, Maksim Kozlov wrote:<br>
> Hello, Sebastian<br>
><br>
> I think that this patch is necessary in two reasons.<br>
><br>
> In general view, if we have a conditional branch, we want, obviously, to<br>
> invoke two instruction siquences with different results. Without this<br>
> patch we clear EF bit in conditional branch in any case and I think this<br>
> is not that we want regardless if this causes error or not.<br>
<br>
The patch makes the code more clear, so I will check it in with a <br>
modified commit message. However, I don't think it fixes a bug. I check <br>
the instruction trace with SIS:<br>
<br>
*** BEGIN OF TEST SPCONTEXT 1 ***<br>
*** TEST VERSION: 5.0.0.a38187051863cf4a423c4f00669c6786bc8ff60d<br>
*** TEST STATE: EXPECTED-PASS<br>
*** TEST BUILD: RTEMS_DEBUG RTEMS_NETWORKING RTEMS_POSIX_API<br>
*** TEST TOOLS: 7.4.1 20190514 (RTEMS 5, RSB <br>
e047d64adf806d37393eb12d02a7ce26633d2eba, Newlib 5c2a3661c)<br>
Test configuration N N N... done<br>
Test configuration N N F... sis> tra<br>
40380837 0200e434 a02c0015 andn %l0, %l5, %l0<br>
<br>
Here the %l0 is <span class="gmail_default" style="font-family:monospace,monospace"></span>superfluously modified, however, it has no effect, since ...<br>
<br>
40380837 0200e438 10800006 b 0x000000000200e450<br>
40380838 0200e43c c021a004 clr [ %g6 + 4 ]<br>
40380842 0200e450 91d02009 ta 9<br>
40380842 02000890 a1480000 rd %psr, %l0<br>
40380845 02000894 2900803d sethi %hi(0x200f400), %l4<br>
40380846 02000898 81c52080 jmp %l4 + 0x80<br>
40380847 0200089c a6142f00 or %l0, 0xf00, %l3<br>
40380849 0200f480 81880013 wr %l3, %psr<br>
40380850 0200f484 82142020 or %l0, 0x20, %g1<br>
40380852 0200f488 01000000 nop<br>
40380852 0200f48c 81c48000 jmp %l2<br>
40380853 0200f490 81cca004 rett %l2 + 4<br>
40380855 0200e454 ee09a01c ldub [ %g6 + 0x1c ], %l7<br>
40380857 0200e458 8095c000 tst %l7<br>
40380859 0200e45c 12bfffe9 bne 0x000000000200e400<br>
40380862 0200e460 92102000 clr %o1<br>
40380862 0200e464 c021a014 clr [ %g6 + 0x14 ]<br>
40380863 0200e468 ea07a0a8 ld [ %fp + 0xa8 ], %l5<br>
40380866 0200e46c 81856000 wr %l5, %y<br>
40380868 0200e470 e01fa060 ldd [ %fp + 0x60 ], %l0<br>
<br>
... here it is loaded from the stack.<br>
<br>
><br>
> More specific technical reason is that there is a real situation - I have<br>
> debugging info and instruction trace (which was got with hardware <br>
> debugging<br>
> module DSU on LEON3) where I see that sometimes we return from interrupt<br>
> with cleared PSR[EF] flag in the floating point task (I described this a<br>
> bit in my first message) and this causes excessive lazy fp switch<br>
> (previously I had system crash before fixing lazy fp switch syscall).<br>
><br>
> Just now I can't give very detail description why and how this happens,<br>
> but bellow I put part of LEON3 DSU trace for mentioned above situation<br>
><br>
> This is part of code which I use to investigate problem which we talk <br>
> about<br>
><br>
> ...<br>
> 4f102d8c: 95 a2 88 58 faddd %f10, %f24, %f10<br>
> 4f102d90: 80 a3 00 09 cmp %o4, %o1<br>
> 4f102d94: 91 a2 09 54 fmuld %f8, %f20, %f8<br>
> 4f102d98: 95 a0 05 4a fsqrtd %f10, %f10<br>
> 4f102d9c: d5 3b bf f8 std %f10, [ %sp + -8 ]<br>
> 4f102da0: 01 00 00 00 nop<br>
> 4f102da4: 91 a2 08 4a faddd %f8, %f10, %f8<br>
> 4f102da8: 95 a4 89 c8 fdivd %f18, %f8, %f10<br>
> 4f102dac: d5 3b bf f8 std %f10, [ %sp + -8 ]<br>
> 4f102db0: 01 00 00 00 nop<br>
> 4f102db4: d1 38 7f 70 std %f8, [ %g1 + -144 ]<br>
> 4f102db8: d1 18 80 00 ldd [ %g2 ], %f8 <--- Interrupt<br>
> 4f102dbc: 91 a2 08 ce fsubd %f8, %f14, %f8<br>
> 4f102dc0: 91 a2 09 4a fmuld %f8, %f10, %f8<br>
> 4f102dc4: d1 38 7f 58 std %f8, [ %g1 + -168 ]<br>
> 4f102dc8: d1 18 a0 08 ldd [ %g2 + 8 ], %f8<br>
> 4f102dcc: 91 a2 08 cc fsubd %f8, %f12, %f8<br>
> ...<br>
><br>
> Part of trace<br>
><br>
><br>
> 463493523 4F06D6A0 restore [00000000]<br>
> 463493524 4F06D6A4 ldd [%g1], %l0 [0000000C 4F57C348]<br>
<br>
%l0 is loaded here from the stack and ...<br>
<br>
> 463493526 4F06D6A8 ldd [%g1 + 0x8], %l2 [0406CE9C 0406CE78]<br>
> 463493528 4F06D6AC ldd [%g1 + 0x10], %l4 [0406CE54 0406CE30]<br>
> 463493530 4F06D6B0 ldd [%g1 + 0x18], %l6 [4F57C528 0406CE84]<br>
> 463493533 4F06D6B4 ldd [%g1 + 0x20], %i0 [0406CF78 4F534BB0]<br>
> 463493610 4F06D6B8 ldd [%g1 + 0x28], %i2 [0408CDC0 0406CE24]<br>
> 463493612 4F06D6BC ldd [%g1 + 0x30], %i4 [00000001 00000003]<br>
> 463493616 4F06D6C0 ldd [%g1 + 0x38], %fp [4F534B40 4F103868]<br>
> 463493620 4F06D6C4 save [00000000]<br>
> 463493622 4F06D6C8 mov %l0, %psr [F34000C6] <-- (1)<br>
<br>
... here it is moved to the %psr. This is unrelated to the %l0 <br>
modification in the patch.<br>
<br></blockquote><div><span class="gmail_default" style="font-family:monospace,monospace"></span> <br></div><div><div style="font-family:monospace,monospace" class="gmail_default">Yes, now I see that my situation is not so clear as I</div><div style="font-family:monospace,monospace" class="gmail_default">thought before. I listed instruction trace above just</div><div style="font-family:monospace,monospace" class="gmail_default">to show that there is a situation when we return from</div><div style="font-family:monospace,monospace" class="gmail_default">interrupt with cleared EF bit, and before your comments</div><div style="font-family:monospace,monospace" class="gmail_default">I thought that cause of that is superfluous `andn' <br></div><div style="font-family:monospace,monospace" class="gmail_default">instruction. Now I should investigate more carefully what</div><div style="font-family:monospace,monospace" class="gmail_default">happens between `andn %l0, %l5, %l0' and `mov %l0, %psr'</div><div style="font-family:monospace,monospace" class="gmail_default">instruction. And even more, now I'm not sure that this <br></div><div style="font-family:monospace,monospace" class="gmail_default">situation is abnormal.</div><div style="font-family:monospace,monospace" class="gmail_default"><br></div><div style="font-family:monospace,monospace" class="gmail_default">Thanks for your comments.</div><div style="font-family:monospace,monospace" class="gmail_default"><br></div><div style="font-family:monospace,monospace" class="gmail_default">--</div><div style="font-family:monospace,monospace" class="gmail_default">Best regards,</div><div style="font-family:monospace,monospace" class="gmail_default">Maksim Kozlov<br></div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> 463493625 4F06D6CC nop [00000000]<br>
> 463493702 4F06D6D0 nop [00000000]<br>
> 463493703 4F06D6D4 nop [00000000]<br>
> 463493717 4F06D6D8 ld [%g1 + 0x6C], %g1 [0408D148]<br>
> 463493718 4F06D6DC jmp %l1 [4F06D6DC]<br>
> 463493719 4F06D6E0 rett %l2 [4F102DC0]<br>
> 463493722 4F102DBC fsubd %f8, %f14, %f8 [ TRAP ] <-- (2)<br>
> 463493728 04000040 mov %psr, %l0 [F34000C6]<br>
> 463493729 04000044 sethi %hi(0x4F06D800), %l4 [4F06D800]<br>
> 463493730 04000048 jmp %l4 + 0x20 [04000048]<br>
> 463493731 0400004C sethi %hi(0x1000), %l3 [00001000]<br>
><br>
><br>
> Here (1) we see that restored PSR[EF] == 0 and directly after return from<br>
> interrupt (2) we fall in lazy fp switch syscall<br>
><br>
> To be honest, I cant say that I fully understand how _ISR_Handler <br>
> procedure<br>
> works, therefore your help would be very desirable.<br>
><br>
> When I get more debugging information, I'll provide it. But it takes some<br>
> time.<br>
<br>
-- <br>
Sebastian Huber, embedded brains GmbH<br>
<br>
Address : Dornierstr. 4, D-82178 Puchheim, Germany<br>
Phone : +49 89 189 47 41-16<br>
Fax : +49 89 189 47 41-09<br>
E-Mail : <a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a><br>
PGP : Public key available on request.<br>
<br>
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.<br>
<br>
</blockquote></div></div>