On Sunday, 17 August 2014 at 14:47:57 UTC, Johannes Pfau wrote:
Am Sun, 17 Aug 2014 14:36:53 +0000
schrieb "Timo Sintonen" <t.sinto...@luukku.com>:
But the register corruption is still an issue. My tls function
clearly uses r3 and does not save it.
Johannes, do you know the arm calling system? Is it caller or
callee that should save r3?
In this case it is my function that has one function inlined
that has another function inlined that contains a compiler
generated function call. Could this be a bug in the compiler
that it does not recognize the innermost call and does not
save registers?
r3 is an argument/scratch register, the caller can't rely on its
contents after a function call. This could also be caused by
the inline
ASM.
I have had some weird bugs lately and then I looked my other
object files.
I think there is a bug because I found more like this:
This is a class function (actually a constructor) that writes
constant values into two variables, one is a static class
variable in tls an the other is an instance variable
27 0000 10B5 push {r4, lr}
28 0002 0346 mov r3, r0
29 0004 FFF7FEFF bl __aeabi_read_tp @ load_tp_soft
30 0008 034A ldr r2, .L3
31 000a 41F23421 movw r1, #4660
32 000e 7424 movs r4, #116
33 0010 1150 str r1, [r2, r0]
34 0012 9C60 str r4, [r3, #8]
35 0014 1846 mov r0, r3
36 0016 10BD pop {r4, pc}
37 .L4:
38 .align 2
39 .L3:
40 0018 00000000 .word .LANCHOR0(tpoff)
41
In line 28 the this pointer is saved to r3, then the call in line
29 returns the tls start address in r0. __aeabi_read_tp uses r3
to fetch the address so r3 is corrupted R3 is used in 34 to
store to address this+8 and then r3 is moved back to r0 returning
incorrect value for this.
Is this a gdc or gcc bug?
