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?
next prev 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: linkBe 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).