[OE-core] kernel miscompilation with gcc 4.8 for ARMv5

[Enrico Scholz]

Bruce Ashfield <bruce.ashfield-Re5JQEeQqe8AvxtiuMwx3w at public.gmane.org>
writes:

>> Applying two upstream kernel commits
>> 455bd4c430b0c0a361f38e8658a0d6cb469942b5 (ARM: 7668/1: fix
>> memset-related crashes caused by recent GCC (4.7.2) optimizations) and
>> 418df63adac56841ef6b0f1fcf435bc64d4ed177 (ARM: 7670/1: fix the memset
>> fix) seem to fix the problem for me.
>
> Correct. Those are the same commits you'll see on linux-yocto-3.8,
> we've been soaking them for a while. I was waiting for LTSI and -stable
> to pick up the changes before updating linux-yocto-3.4, but that hasn't
> happened yet.
>
> If you are using linux-yocto-3.4 and can confirm that it boots for you
> with those patches,

Sorry, I am using a more or less vanilla 3.4 kernel.  Patches fix
the problem there (device boots) and (after knowing about them) the
problematic code is easy to spot:

$ arm-linux-gnueabi-objdump  -d mm/slub.o

000014c4 <init_object>:
    ...
    14fc:       e1a00001        mov     r0, r1
    1500:       e3a0106b        mov     r1, #107        ; 0x6b
    1504:       ebfffffe        bl      0 <memset>
    1508:       e1a03000        mov     r3, r0          <<<<<<<
    150c:       e5942010        ldr     r2, [r4, #16]
    1510:       e3e0105a        mvn     r1, #90 ; 0x5a
    1514:       e0832002        add     r2, r3, r2
    1518:       e5421001        strb    r1, [r2, #-1]

With unpatched memset, 'r0' points to end of buffer.


Enrico