This approach has a serious drawback: because you're going to keep data in the redzones, all your globals will be moved from .bss to .data. This may increase the amount of memory used by the program. I've considered a somewhat similar solution for the -gc-section problem (see https://code.google.com/p/address-sanitizer/issues/detail?id=260).
On Wed, Dec 24, 2014 at 11:41 AM, Yury Gribov <[email protected]> wrote: > Hi all, > > Has anyone considered moving global variables metadata (struct > __asan_global) to redzone? I expect this to save quite some RAM. > > This would require us to > (1) extend redzone on x64 from 32 to 64 bytes (sizeof(__asan_global) == > sizeof(uptr) * 7 == 56 bytes) > (2) add one more pointer 'next' to keep address of next __asan_global in > current module > (3) remove pointer to module name from __asan_global and keep it at the end > of linked list instead > > Note that (1) will only be needed for globals which are larger than 4 bytes > (we'll be able to reuse 32-byte padding). We could squeeze up even more > space by moving has_dynamic_init bit to lower bits of > __asan_global.size_with_redzone. > > Best regards, > Yury > > -- > You received this message because you are subscribed to the Google Groups > "address-sanitizer" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. -- Alexander Potapenko Software Engineer Google Moscow -- You received this message because you are subscribed to the Google Groups "address-sanitizer" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
