Hello ! When building 2.6.10, the assembler (2.13.2.1) gets confused by a "b target2" (compiler generated) immediately following a "beqzl target1" (inline assembly macro), and reorders these instructions (with wrong address calculation too) to an infinite loop. (Well, not really infinite - after about ten minutes some timer interrupt makes an end to it by a null-pointer dereference in __queue_work() ;-) This bug is rather unreliable though, going away with minimal, unintentional code changes, unexpectedly reappearing after some later rebuild... Was this behaviour already observed elsewhere ? Is it fixed in some newer assembler version ? Or should i just be content with it and work around with appropriate "nop"s in the concerned inline-assembly macros ? ... ? as -EB -G 0 -mips4 -O2 -g0 -64 -mcpu=r8000 -v -64 -non_shared -64 -march=r8000 -mips4 --trap -o kernel/.tmp_fork.o GNU assembler version 2.13.2.1 (mips64-ip28-linux-gnu) using BFD version 2.13.2.1 GNU assembler version 2.13.2.1 (mips64-linux) using BFD version 2.13.2.1 Here are examples of what the assembler receives from the compiler, and what it produces: a80000002003a6c0 <copy_process>: ... .set macro .set reorder cache 0x14,0($sp) # Cache Barrier #APP 1: lld $3, 256($4) # atomic64_add addu $3, $2 scd $3, 256($4) beqzl $3, 1b #NO_APP b $L5881 $L5887: # Cache Barrier omitted. move $5,$0 $L5881: ... a80000002003a944: bfb40000 cache 0x14,0(sp) a80000002003a948: d0830100 lld v1,256(a0) a80000002003a94c: 00621821 addu v1,v1,v0 a80000002003a950: f0830100 scd v1,256(a0) a80000002003a954 <!>: 1000ffff b a80000002003a954 <$L6939+0xe4> a80000002003a958: 00000000 nop a80000002003a95c: 50600000 beqzl v1,a80000002003a960 <$L5887> a80000002003a960 <$L5887>: a80000002003a960: 0000282d move a1,zero a80000002003a964 <$L5881>: ... #APP 1: ll $5, 0($2) # atomic_add addu $5, $3 sc $5, 0($2) beqzl $5, 1b #NO_APP b $L6092 $L6057: ... $L6092: ... a80000002003abe4: c0450000 ll a1,0(v0) a80000002003abe8 <!>: 00a32821 addu a1,a1,v1 a80000002003abec: e0450000 sc a1,0(v0) a80000002003abf0: 1000fffd b a80000002003abe8 <$L6045+0x70> a80000002003abf4: 00000000 nop a80000002003abf8: 50a00000 beqzl a1,a80000002003abfc <$L6057> a80000002003abfc <$L6057>: ... #APP 1: ll $5, 4($2) # atomic_add addu $5, $3 sc $5, 4($2) beqzl $5, 1b #NO_APP b $L6480 $L6411: ... $L6480: ... a80000002003aedc: c0450004 ll a1,4(v0) a80000002003aee0: 00a32821 addu a1,a1,v1 a80000002003aee4 <!>: e0450004 sc a1,4(v0) a80000002003aee8: 1000fffe b a80000002003aee4 <$L6401+0x54> a80000002003aeec: 00000000 nop a80000002003aef0: 50a00000 beqzl a1,a80000002003aef4 <$L6411> a80000002003aef4 <$L6411>: ... with kind regards pf
