From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14330 invoked by alias); 12 Feb 2013 07:03:10 -0000 Received: (qmail 14166 invoked by uid 48); 12 Feb 2013 07:02:43 -0000 From: "kcc at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug sanitizer/55309] gcc's address-sanitizer 66% slower than clang's Date: Tue, 12 Feb 2013 07:03:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: sanitizer X-Bugzilla-Keywords: X-Bugzilla-Severity: enhancement X-Bugzilla-Who: kcc at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2013-02/txt/msg01129.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55309 --- Comment #33 from Kostya Serebryany 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.