[LLVMdev] Remaining Compiler-RT failures in ARM

[Evgeniy Stepanov]

Could this be some kind of linker-generated compatibility magic?

On Fri, Oct 10, 2014 at 6:10 PM, Renato Golin <renato.golin at linaro.org> wrote:
> On 10 October 2014 12:48, Renato Golin <renato.golin at linaro.org> wrote:
>>    0x0014b494 <+192>: andeq r1, r0, r4, asr #23
>>    0x0014b498 <+196>: andseq  r8, r2, r12, lsl #24
>>    0x0014b49c <+200>: andeq r1, r0, r12, ror r7
>>    0x0014b4a0 <+204>:     ; <UNDEFINED> instruction: 0x00128bd0
>> => 0x0014b4a4 <+208>:     ; <UNDEFINED> instruction: 0xfff99bda
>
> For context, the code is:
>
>    0x001d8e5c <+232>: mov r0, r4
>    0x001d8e60 <+236>: bl 0x2ec4f0 <____asan_report_store4_veneer>
>    0x001d8e64 <+240>: str r0, [r4]
>    0x001d8e68 <+244>: bl 0x2ec488 <____asan_handle_no_return_veneer>
>    0x001d8e6c <+248>: andeq r1, r0, r4, asr #23
>    0x001d8e70 <+252>: andseq r0, r10, r12, ror #4
>    0x001d8e74 <+256>: andeq r1, r0, r12, ror r7
>    0x001d8e78 <+260>: andseq r0, r10, r0, lsr r2
> => 0x001d8e7c <+264>: ; <UNDEFINED> instruction: 0xfffa45ba
>
> Inspecting the whole function, there isn't a jump past 0x001d8e68 (the
> final branch), so it's only possible for the PC to be there if
> ____asan_handle_no_return_veneer has indeed returned.
>
> Investigating it further, it seems that the
> ____asan_handle_no_return_veneer *does* return:
>
>   0x00099c72 <+106>: ldr.w pc, [sp], #4
>
> Where is that implemented?
>
> cheers,
> --renato