This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug sanitizer/55309] gcc's address-sanitizer 66% slower than clang's
- From: "kcc at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Tue, 12 Feb 2013 07:02:40 +0000
- Subject: [Bug sanitizer/55309] gcc's address-sanitizer 66% slower than clang's
- Auto-submitted: auto-generated
- References: <bug-55309-4@http.gcc.gnu.org/bugzilla/>
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.