[LLVMdev] Remaining Compiler-RT failures in ARM

Renato Golin renato.golin at linaro.org
Fri Oct 10 07:10:24 PDT 2014

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?


More information about the llvm-dev mailing list