[PATCH] Implement variable-sized alloca instrumentation (take 2).

Maxim Ostapenko m.ostapenko at partner.samsung.com
Wed Feb 25 14:01:19 PST 2015


> > I did not give much thought to dynamic allocas, but what if we simply replace them with run-time calls somehow?

> 

> 

> We could hide Max's linked lists behind an internal API, something like

> 

>   // Poison redzones and store metadata for new_alloca

>   void asan_poison_alloca(uptr new_alloca, uptr size, uptr prev_alloca);

>   

>   // Unpoison all allocas below bound

>   uptr asan_unpoison_allocas(uptr prev_alloca, uptr bound);

>    


I think this is exactly what we want to do in UAR case. Since we don't know number of allocated regions until runtime (in general), we still need some dynamically growing structure (e.g. linked list) to store allocated regions to be unpoisoned before each ret instruction. We can hide this structure behind internal API, in runtime library, thought. For non-UAR case we can use memset for dynamic section indeed, but I'm not sure this is preferable way.


REPOSITORY
  rL LLVM

http://reviews.llvm.org/D7098

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/






More information about the llvm-commits mailing list