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
On 10/10/14 2:12 PM, Renato Golin wrote:> 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. :)Sounds like an arm-thumb interworking veneer, generated by the linker... the real function should be called 'asan_handle_no_return' (with some number of '_' prefixing it. I don't remember how many get added). Jon> > I'm tempted to disable that test on ARM+Linux, since we use EHABI > instead of SjLj... At least for now... > > --renato > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-- Jon Roelofs jonathan at codesourcery.com CodeSourcery / Mentor Embedded
On 10 October 2014 21:31, Jonathan Roelofs <jonathan at codesourcery.com> wrote:> Sounds like an arm-thumb interworking veneer, generated by the linker... the > real function should be called 'asan_handle_no_return' (with some number of '_' > prefixing it. I don't remember how many get added).It is a veneer which has just a jump and a word after it, which points to a place in memory that had which I believe was the implementation of the asan check. I was wondering if the no_return on that veneer was meant to jump to a no_return function or just that the veneer itself doesn't return (which would be silly). It's possible that the asan check has a no_return attribute but for some reason it returns? Wouldn't the compiler warn/err on that? --renato