From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugs-return-473910-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 8597 invoked by alias); 19 Jan 2015 21:49:17 -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 8300 invoked by uid 48); 19 Jan 2015 21:49:10 -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: Mon, 19 Jan 2015 21:49: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-58AcOHW7TS@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/msg01904.txt.bz2

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

--- Comment #21 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Ugh, there is also this junk:
// By default we allow to use SizeClassAllocator64 on 64-bit platform.
// But in some cases (e.g. AArch64's 39-bit address space) SizeClassAllocator64
// does not work well and we need to fallback to SizeClassAllocator32.
// For such platforms build this code with -DSANITIZER_CAN_USE_ALLOCATOR64=0 or
// change the definition of SANITIZER_CAN_USE_ALLOCATOR64 here.
#ifndef SANITIZER_CAN_USE_ALLOCATOR64
# if defined(__aarch64__) || defined(__mips64)
#  define SANITIZER_CAN_USE_ALLOCATOR64 0
# else
#  define SANITIZER_CAN_USE_ALLOCATOR64 (SANITIZER_WORDSIZE == 64)
# endif
#endif

It would be nice to know why that has been added.
Was that just because
#if SANITIZER_CAN_USE_ALLOCATOR64
# if defined(__powerpc64__)
const uptr kAllocatorSpace =  0xa0000000000ULL;
const uptr kAllocatorSize  =  0x20000000000ULL;  // 2T.
# else
const uptr kAllocatorSpace = 0x600000000000ULL;
const uptr kAllocatorSize  =  0x40000000000ULL;  // 4T.
# endif
has not been adjusted for the port?
What is the minimum kAllocatorSize that would work?  Given the very small
39-bit VA option on aarch64, I think if the allocator64 memory has to be normal
memory with shadow, we could only use say something like
kAllocatorSpace 0x800000000 and kAllocatorSize the same value, i.e. 32GB. 
Would that be enough?

There is also the:
// The range of addresses which can be returned my mmap.
// FIXME: this value should be different on different platforms,
// e.g. on AArch64 it is most likely (1ULL << 39). Larger values will still
work
// but will consume more memory for TwoLevelByteMap.
#if defined(__aarch64__)
# define SANITIZER_MMAP_RANGE_SIZE FIRST_32_SECOND_64(1ULL << 32, 1ULL << 39)
#else
# define SANITIZER_MMAP_RANGE_SIZE FIRST_32_SECOND_64(1ULL << 32, 1ULL << 47)
#endif
which is again wrong for aarch64.  Does it really has to be compile time
constant?  The 1ULL << 47 is also wrong ppc64, mips64, isn't it?