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 <[email protected]> wrote: > 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 -- 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.
