On 12/26/2014 04:51 PM, 'Alexander Potapenko' via address-sanitizer wrote:
> How are you going to share the redzone size between all globals in the
> module? They vary depending on the original global size.
Ok, I didn't know that Clang uses adaptive global redzones. AFAIK GCC
does not so it's mu
Plus the bytes saved for each relocation removed from __asan_global
(that's 24 bytes per relocation!)
On Fri, Dec 26, 2014 at 4:40 PM, Alexander Potapenko wrote:
> Here's some experimental data.
>
> I've compiled sqlite3.c, which is a 128KLOC file from Chromium.
>
> The resulting IR file containe
Here's some experimental data.
I've compiled sqlite3.c, which is a 128KLOC file from Chromium.
The resulting IR file contained 3470 __asan_gen_* variables, including
2418 string literals and 1052 __asan_global_source_location structs.
There were 1069 records in the array of __asan_global structur
We can put has_dynamic_init into |size_with_redzone|, which is
supposed to be aligned on at least 32.
|size| may not have spare bits on 32-bit systems, other struct fields
are pointers, so they can't hold additional booleans.
How are you going to share the redzone size between all globals in the
m
On 12/25/2014 05:18 PM, Yury Gribov wrote:
On 12/25/2014 04:58 PM, 'Dmitry Vyukov' via address-sanitizer wrote:
What are the savings? We remove the metadata but add 32 bytes to
redzones. Seems roughly equivalent.
Only for x64 (and for small variables additional 32 bytes are not
necessary becau
On 12/25/2014 04:58 PM, 'Dmitry Vyukov' via address-sanitizer wrote:
What are the savings? We remove the metadata but add 32 bytes to
redzones. Seems roughly equivalent.
Only for x64 (and for small variables additional 32 bytes are not
necessary because we can fit into padding redzone).
The
What are the savings? We remove the metadata but add 32 bytes to
redzones. Seems roughly equivalent.
The bss is a good point. It can be unacceptable to lots of
applications that has multi-megabyte objects in bss. Which is I would
say very frequent.
On Wed, Dec 24, 2014 at 11:41 AM, Yury Gribov
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.co
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
