search for: __asan_handle_no_return

Specifically, the test is causing a link to occur for CGO stuff. It has been running 8 minutes now with Gold, and is producing a 400mb .o file afaict: % du -hs /tmp/go-build703430446/ llvm.org/llvm/bindings/go/llvm/_test/_obj_test/_cgo_.o 397M /tmp/go-build703430446/ llvm.org/llvm/bindings/go/llvm/_test/_obj_test/_cgo_.o What am I doing wrong here? -------------- next part -------------- An

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

Hi Kostya. Thanks for the quick feedback. I will work on addressing your comments. In regard to initialization checks, I can eliminate most of them by initializing the shadow memory very early, but I still need to do something in two places, __asan_handle_no_return and GetFakeStackFast. Would it be ok to have guards for those two places only? Walter On Fri, May 4, 2018 at 6:10 PM Kostya Serebryany <kcc at google.com> wrote: > Hi Walter, > I've done a first quick scan. > Overall looks reasonable, but I'd like to try reducing the numb...

...the quick feedback. I will work on addressing your > comments. > > In regard to initialization checks, I can eliminate most of them by > initializing the shadow memory very early, This will be a very good way to handle this. > but I still need to do something > in two places, __asan_handle_no_return I think it might be fine. Let me look at the code once the rest is done. > and GetFakeStackFast. Not sure. Why don't just disable stack-use-after-return? > Would it be > ok to have guards for those two places only? > > Walter > On Fri, May 4, 2018 at 6:10 PM Kostya Ser...

Hi Walter, I've done a first quick scan. Overall looks reasonable, but I'd like to try reducing the number of newly introduced platform-specific ifs. Vitaly, please also take a look (once my initial comments are addressed). One outstanding issue is your problem with initialization vs checking, which requires you to insert so many ifs. Is there any chance you can avoid this? If you

I have ported ASan in LLVM to Myriad RTEMS, and I would like to upstream the port. Below is the design doc. Feedback welcome. https://docs.google.com/document/d/1oxmk0xUojybDaQDAuTEVpHVMi5xQX74cJPyMJbaSaRM The port is expected to work with modified versions of RTEMS and newlib. I have a git repo with changes to those projects, that I can make available if there is interest. Here is the patch