From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugs-return-473979-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 17303 invoked by alias); 20 Jan 2015 08:10:41 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Received: (qmail 17226 invoked by uid 48); 20 Jan 2015 08:10:36 -0000
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug sanitizer/64435] [5 Regression] Bootstrap failure in libsanitizer on AArch64 with Linux kernel <= 3.15
Date: Tue, 20 Jan 2015 08:10: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-Version: 5.0
X-Bugzilla-Keywords: build
X-Bugzilla-Severity: major
X-Bugzilla-Who: jakub at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P1
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-64435-4-gYUmww65Fh@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-64435-4@http.gcc.gnu.org/bugzilla/>
References: <bug-64435-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-01/txt/msg01973.txt.bz2

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64435

--- Comment #22 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Or perhaps we could change SizeClassAllocator64 so that on some architectures
it could use variable bounds.  The fact that they are template parameters makes
this harder, but perhaps we could say that if some template
parameters are zero then some variable is used instead.
Use kSpaceBeg ? kSpaceBeg : kSpaceBegVar instead of kSpaceBeg and
kSpaceSize ? kSpaceSize : kSpaceSizeVar instead of kSpace (perhaps put into
some
method).  For architectures where there is no such big variability of address
space sizes it could stay constant, while for aarch64 we could decide during
asan initialization, after finding out how large address space we have.
So for say the 39-bit VA we could use 0x2000000000 to 0x3fffffffff (i.e. 128GB
for the allocator), which is not possible for 42-bit VA, because that is shadow
gap and high shadow.  And for 42-bit VA we could use say 0x10000000000 to
0x2ffffffffff (i.e. 2TB).