From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23362 invoked by alias); 12 Feb 2013 08:40:00 -0000 Received: (qmail 21557 invoked by uid 48); 12 Feb 2013 08:39:35 -0000 From: "jakub 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 08:40: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: jakub 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/msg01134.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55309 --- Comment #34 from Jakub Jelinek 2013-02-12 08:39:33 UTC --- (In reply to comment #32) > Good news, 0x7fff8000 seems great: > There is another suggestion (from dvyukov) to use -Wl,-Ttext-segment=0x40000000 > together with zerobase (pie is not required) which is worth investigating. Glad to hear that. The disadvantage of -Wl,-Ttext-segment=0x40000000 is that it requires special command line option for building the executable, i.e. you can't e.g. just build some shared library with -fsanitize=address and leave the main executable non-instrumented. Plus, I don't see how can -Wl,-Ttext-segment=0x40000000 be used for x86_64, where you need 16TB of shadow memory for >> 3 scale. For zero shadow offset you'd need to place the executable above 16TB, and that implies non-small model. If -Ttext-segment is meant for 32-bit programs, then it could allow zero shadow offset, but with the disadvantage of special building of executables, and on i?86 the offset already fits into the immediates, so it is basically the 0x7fff8000 case for x86_64 already. (In reply to comment #33) > > , 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. I see, but then you could use the global vars (perhaps weak ones in libasan with some default), combined together with arguments to __asan_init (or some alternative name of the same function for compatibility). All that it would do beyond normal initialization would be complain if the requested scale/offset pair is different from the chosen one.