[Bug sanitizer/55309] gcc's address-sanitizer 66% slower than clang's

["kcc at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55309

--- Comment #33 from Kostya Serebryany <kcc at gcc dot gnu.org> 2013-02-12 07:02:40 UTC ---
(In reply to comment #31)
> If the mapping is so flexible, how can you detect mismatches?  Different scale
> or shadow offsets are ABI incompatible...
We don't detect mismatches. 
This has never been a problem for our users (who build everything from scratch)
but we do see it as a coming problem as asan is becoming more popular. 

(in reply to comment from another bug)
> Perhaps instead of global vars defined outside of libasan (which e.g. requires
> GOT accesses to those vars in libasan)

Accessing these vars was never a perf problem (we run asan with perf regularly)

> , it might be better to have the scale
> and offset as arguments of __asan_init?  

We did this in the very early version, but it did not work in general. 
Consider you are linking your program with a third-party object 
not built with asan. It may have constructor functions called before main and
before __asan_init, and those functions call malloc which has to 
call __asan_init, but can not pass arguments. 
In some cases we can use .preinit_array to call __asan_init there, but 
that is not always available (?). 

We were (and still are) thinking about encoding the abi version in the name
of the  init function, e.g. __asan_init_v_123. 
It will help us detect abi mismatches when two objects are instrumented with
different generations of asan. 
This doesn't solve the problem of using different offsets though. 



> Then you could easily test at runtime,
> whether all compilation units agree on the same offset/scale, and complain if
> they don't.  Then __asan_mapping_offset and __asan_mapping_scale or how are the
> vars called could be hidden attribute, used with PC relative addressing and
> avoid one extra indirection, and more importantly have better runtime checking
> of mismatches.