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: 0xfff99bdaFor 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
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
On 10 October 2014 15:30, Evgeniy Stepanov <eugenis at google.com> wrote:> Could this be some kind of linker-generated compatibility magic?I'm not sure. Searching for "____asan_handle_no_return_veneer" on Google gets me this thread. :) I'm tempted to disable that test on ARM+Linux, since we use EHABI instead of SjLj... At least for now... --renato