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
--
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.
