public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
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	[thread overview]
Message-ID: <bug-64435-4-58AcOHW7TS@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-64435-4@http.gcc.gnu.org/bugzilla/>

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?


  parent reply	other threads:[~2015-01-19 21:49 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-29 15:41 [Bug sanitizer/64435] New: [5.0.0 " david.abdurachmanov at gmail dot com
2014-12-29 18:21 ` [Bug sanitizer/64435] " david.abdurachmanov at gmail dot com
2014-12-29 18:25 ` david.abdurachmanov at gmail dot com
2015-01-09 11:20 ` rguenth at gcc dot gnu.org
2015-01-09 11:54 ` david.abdurachmanov at gmail dot com
2015-01-13 11:24 ` [Bug sanitizer/64435] [5 " rguenth at gcc dot gnu.org
2015-01-13 15:45 ` jakub at gcc dot gnu.org
2015-01-13 21:17 ` clyon at gcc dot gnu.org
2015-01-18 12:38 ` jakub at gcc dot gnu.org
2015-01-18 19:07 ` david.abdurachmanov at gmail dot com
2015-01-18 19:11 ` jakub at gcc dot gnu.org
2015-01-18 19:37 ` pinskia at gcc dot gnu.org
2015-01-18 19:51 ` clyon at gcc dot gnu.org
2015-01-19  8:40 ` jakub at gcc dot gnu.org
2015-01-19 16:53 ` jakub at gcc dot gnu.org
2015-01-19 17:29 ` jakub at gcc dot gnu.org
2015-01-19 17:55 ` pinskia at gcc dot gnu.org
2015-01-19 17:56 ` jakub at gcc dot gnu.org
2015-01-19 18:01 ` jakub at gcc dot gnu.org
2015-01-19 18:33 ` jakub at gcc dot gnu.org
2015-01-19 20:13 ` clyon at gcc dot gnu.org
2015-01-19 21:49 ` jakub at gcc dot gnu.org [this message]
2015-01-20  8:10 ` jakub at gcc dot gnu.org
2015-01-20 16:53 ` kcc at gcc dot gnu.org
2015-01-21 21:22 ` jakub at gcc dot gnu.org
2015-01-21 22:09 ` jakub at gcc dot gnu.org
2015-01-26 15:18 ` jakub at gcc dot gnu.org

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-64435-4-58AcOHW7TS@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).