From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17688 invoked by alias); 23 Jan 2013 13:50:50 -0000 Received: (qmail 17645 invoked by uid 48); 23 Jan 2013 13:50:33 -0000 From: "kcc at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug sanitizer/55975] asan does not work with 46 bit address space on PowerPC64 Date: Wed, 23 Jan 2013 13:50: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: normal 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-01/txt/msg02164.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975 --- Comment #34 from Kostya Serebryany 2013-01-23 13:50:31 UTC --- > Do you really want to make kHighMemEnd dynamic always? Shouldn't it be dynamic > only when needed (i.e. for configurations like ppc64 which now require it)? If we make this dynamic on PPC and constant elsewhere, we risk breaking PPC frequently because we typically don't test on PPC (we don't even have a bot!). We can easily introduce a change that will assume kHighMemEnd is a constant. > Otherwise it will slow down many of the inlines that use this heavily. Hopefully, not that bad. unless an application is malloc-bound, we don't enter asan-rt too often. If it is malloc-bound, we are in trouble anyway, because the allocator is very expensive in all other parts. > Furthermore, in configurations where kHighMemEnd is dynamic, also IMHO all > asan_mapping.h defines that are based on it should also be global variables > to avoid unnecessary runtime computations everywhere. > I mean kHighMemBeg, kHighShadowBeg, kHighShadowEnd, kShadowGapEnd. Hm... I would not change that w/o some proof (benchmarks results). When e.g. we access two of these variables, we will be doing two loads instead of one load and arithmetic. Not a clear choice.