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 structures. Of these 2418 string literals only 346 were unique (duplicate string constants are removed by the linker, so they are of no interest for us), which broke down into: - 212 stack frame IDs - 2 file paths (1 for |module_name| in __asan_global, 1 for |filename| in __asan_global_source_location) - 132 global names The 1052 source locations contained 1049 unique line/column pairs and referenced several instances of a single filename string. We can easily save 8 bytes on each of those 1052 __asan_global_source_location structs. On Fri, Dec 26, 2014 at 3:40 PM, Alexander Potapenko <[email protected]> wrote: > 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 > module? They vary depending on the original global size. > What sounds doable is moving |size_with_redzone| calculation to the > runtime, but this might be too fragile. > > Regarding |module_name| and |location|, I think we can do a better job here. > My hypothesis is that there're unnecessarily many > __asan_global_source_location structures because |line_no| and > |column_no| are almost always unique. > Thus it's better to pull them into __asan_global (we can probably even > squeeze both fields into a single uptr, though we need to be accurate > on 32-but systems). > On the other hand, there're far less unique pairs of module names and > source file names (aka |location->filename|), so it's natural to group > them into a single struct: > > struct __asan_global_module_filename { > const char *module_name; > const char *filename; > }; > struct __asan_global { > uptr beg; > uptr size; > uptr size_with_redzone; > const char *name; > uptr has_dynamic_init; // The above suggestion still applies, we > can store this flag in |size_with_redzone| > __asan_global_module_filename *location; > int line_no; // Or a single uptr for both line_no/column_no. > int column_no; > }; > > This removes one relocation from each __asan_global struct, and the > number of unique __asan_global_module_filename structs will be far > less than that of __asan_global_source_location structs (which I'd > suspect to be close to the number of __asan_global structs). > > On Fri, Dec 26, 2014 at 2:44 PM, Yury Gribov <[email protected]> wrote: >> 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 because we can fit into padding redzone). >>> >>>> 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. >>> >>> >>> Yep, disabling bss is a no-go. >> >> >> Still, what about squeezing __asan_global structs by moving module name and >> redzone size to a separate entry shared by all global vars in a module and >> also storing has_dynamic_init bit in one of other fields? For kernel we >> usually have at least 10K registered globals which results in 3 * 8 * 10K = >> 250K. This gets worse for larger Kconfigs. >> >> >> -Y >> >> -- >> 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 -- 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.
