search for: getfakestackfast

On Mon, May 7, 2018 at 2:05 PM Kostya Serebryany <kcc at google.com> wrote: > > >> and GetFakeStackFast. > > > Not sure. Why don't just disable stack-use-after-return? > Yeah originally I was going to do that, but: 1. We had a stack use-after-return last month that people had to debug by hand. that would have been caught by ASan with stack-use-after-return. So it seems like a worth...

On Mon, May 7, 2018 at 12:35 PM Walter Lee <waltl at google.com> wrote: > On Mon, May 7, 2018 at 2:05 PM Kostya Serebryany <kcc at google.com> wrote: > >> >> >>> and GetFakeStackFast. >> >> >> Not sure. Why don't just disable stack-use-after-return? >> > > Yeah originally I was going to do that, but: > I probably misunderstood. You are not disabling UAR completely, just disabling the fast-path getter? Hmm. Maybe let's leave this one ou...

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 number of newly introduce...

...s, 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 Serebryany <kcc at google.com> wrote: > > > Hi Walter, > > > I've done a first...

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