[Bug sanitizer/55975] New: FAIL: c-c++-common/asan/global-overflow-1.c -O0 output pattern test

[Bug sanitizer/55975] New: FAIL: c-c++-common/asan/global-overflow-1.c -O0 output pattern test

[schwab@linux-m68k.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975

             Bug #: 55975
           Summary: FAIL: c-c++-common/asan/global-overflow-1.c  -O0
                    output pattern test
    Classification: Unclassified
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: sanitizer
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: schwab@linux-m68k.org
                CC: dodji@gcc.gnu.org, dvyukov@gcc.gnu.org,
                    jakub@gcc.gnu.org, kcc@gcc.gnu.org
            Target: powerpc64-*-*


==4629== AddressSanitizer CHECK failed:
../../../../../libsanitizer/asan/asan_thread.cc:74
"((AddrIsInMem(stack_bottom_))) != (0)" (0x0, 0x0)
=================================================================
==4629== ERROR: AddressSanitizer: unknown-crash on address 0x3fffdcef88d0 at pc
0x3fffae6bcb1c bp 0x3fffdcef7400 sp 0x3fffdcef7470
WRITE of size 1 at 0x3fffdcef88d0 thread T0
==4629== AddressSanitizer: while reporting a bug found another one.Ignoring.

This only fails with -m64, the -m32 test works.

[Bug sanitizer/55975] FAIL: c-c++-common/asan/global-overflow-1.c -O0 output pattern test

[kcc at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975

--- Comment #1 from Kostya Serebryany <kcc at gcc dot gnu.org> 2013-01-15 06:12:27 UTC ---
[DISCLAIMER] I don't have access nor any experience with powerpc. 

Could you please insert various debugging Printf calls before the assertion in
asan_thread.cc:74?
Basically, print all local variables and also show the contents of
/proc/self/maps.

[Bug sanitizer/55975] FAIL: c-c++-common/asan/global-overflow-1.c -O0 output pattern test

[schwab@linux-m68k.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975

--- Comment #2 from Andreas Schwab <schwab@linux-m68k.org> 2013-01-15 19:59:47 UTC ---
Breakpoint 1, __asan::AsanThread::Init (
    this=this@entry=0x3fffb751d8f8 <__asan::asan_thread_registry+33554432>)
    at ../../../../../libsanitizer/asan/asan_thread.cc:74
74        CHECK(AddrIsInMem(stack_bottom_));
(gdb) l
69        UnmapOrDie(this, size);
70      }
71
72      void AsanThread::Init() {
73        SetThreadStackTopAndBottom();
74        CHECK(AddrIsInMem(stack_bottom_));
75        CHECK(AddrIsInMem(stack_top_));
76        ClearShadowForThreadStack();
77        if (flags()->verbosity >= 1) {
78          int local = 0;
(gdb) s
#0  AddrIsInMem (a=0x3fffff800000)
    at ../../../../../libsanitizer/asan/asan_mapping.h:95
95        return AddrIsInLowMem(a) || AddrIsInHighMem(a);
(gdb) s
AddrIsInHighMem (a=0x3fffff800000)
    at ../../../../../libsanitizer/asan/asan_mapping.h:91
91        return a >= kHighMemBeg && a <= kHighMemEnd;
(gdb) p kHighMemEnd 
$6 = 0xfffffffffff
(gdb) i proc mappings 
process 2581
Mapped address spaces:

          Start Addr           End Addr       Size     Offset objfile
          0x10000000         0x10002000     0x2000        0x0
/daten/gcc/gcc-20130113/Build/gcc/testsuite/g++/global-overflow-1.exe
          0x10011000         0x10012000     0x1000     0x1000
/daten/gcc/gcc-20130113/Build/gcc/testsuite/g++/global-overflow-1.exe
          0x10012000         0x10013000     0x1000     0x2000
/daten/gcc/gcc-20130113/Build/gcc/testsuite/g++/global-overflow-1.exe
       0x1fffffff000      0x24000000000 0x4000001000        0x0 
       0x24000000000      0x28000000000 0x4000000000        0x0 
       0x28000000000      0x40000000000 0x18000000000        0x0 
      0x3fffb5258000     0x3fffb525c000     0x4000        0x0
/lib64/libdl-2.15.so
      0x3fffb525c000     0x3fffb526b000     0xf000     0x4000
/lib64/libdl-2.15.so
      0x3fffb526b000     0x3fffb526c000     0x1000     0x3000
/lib64/libdl-2.15.so
      0x3fffb526c000     0x3fffb526d000     0x1000     0x4000
/lib64/libdl-2.15.so
      0x3fffb526d000     0x3fffb528c000    0x1f000        0x0
/lib64/libpthread-2.15.so
      0x3fffb528c000     0x3fffb529b000     0xf000    0x1f000
/lib64/libpthread-2.15.so
      0x3fffb529b000     0x3fffb529c000     0x1000    0x1e000
/lib64/libpthread-2.15.so
      0x3fffb529c000     0x3fffb529e000     0x2000    0x1f000
/lib64/libpthread-2.15.so
      0x3fffb529e000     0x3fffb52a3000     0x5000        0x0 
      0x3fffb52a3000     0x3fffb544c000   0x1a9000        0x0
/lib64/libc-2.15.so
      0x3fffb544c000     0x3fffb545b000     0xf000   0x1a9000
/lib64/libc-2.15.so
      0x3fffb545b000     0x3fffb545f000     0x4000   0x1a8000
/lib64/libc-2.15.so
      0x3fffb545f000     0x3fffb5472000    0x13000   0x1ac000
/lib64/libc-2.15.so
      0x3fffb5472000     0x3fffb5476000     0x4000        0x0 
      0x3fffb5476000     0x3fffb548b000    0x15000        0x0
/daten/gcc/gcc-20130113/Build/gcc/64/libgcc_s.so.1
      0x3fffb548b000     0x3fffb549a000     0xf000    0x15000
/daten/gcc/gcc-20130113/Build/gcc/64/libgcc_s.so.1
      0x3fffb549a000     0x3fffb549b000     0x1000    0x14000
/daten/gcc/gcc-20130113/Build/gcc/64/libgcc_s.so.1
      0x3fffb549b000     0x3fffb549d000     0x2000    0x15000
/daten/gcc/gcc-20130113/Build/gcc/64/libgcc_s.so.1
      0x3fffb549d000     0x3fffb54ca000    0x2d000        0x0
/daten/gcc/gcc-20130113/Build/powerpc64-linux/64/libsanitizer/asan/.libs/libasan.so.0.0.0
      0x3fffb54ca000     0x3fffb54d9000     0xf000    0x2d000
/daten/gcc/gcc-20130113/Build/powerpc64-linux/64/libsanitizer/asan/.libs/libasan.so.0.0.0
      0x3fffb54d9000     0x3fffb54da000     0x1000    0x2c000
/daten/gcc/gcc-20130113/Build/powerpc64-linux/64/libsanitizer/asan/.libs/libasan.so.0.0.0
      0x3fffb54da000     0x3fffb54dd000     0x3000    0x2d000
/daten/gcc/gcc-20130113/Build/powerpc64-linux/64/libsanitizer/asan/.libs/libasan.so.0.0.0
      0x3fffb54dd000     0x3fffb7d27000  0x284a000        0x0 
      0x3fffb7d27000     0x3fffb7dd3000    0xac000        0x0
/lib64/libm-2.15.so
      0x3fffb7dd3000     0x3fffb7de3000    0x10000    0xac000
/lib64/libm-2.15.so
      0x3fffb7de3000     0x3fffb7de4000     0x1000    0xac000
/lib64/libm-2.15.so
      0x3fffb7de4000     0x3fffb7ded000     0x9000    0xad000
/lib64/libm-2.15.so
      0x3fffb7e13000     0x3fffb7e17000     0x4000        0x0 
      0x3fffb7e1b000     0x3fffb7f80000   0x165000        0x0
/daten/gcc/gcc-20130113/Build/powerpc64-linux/64/libstdc++-v3/src/.libs/libstdc++.so.6.0.18
      0x3fffb7f80000     0x3fffb7f90000    0x10000   0x165000
/daten/gcc/gcc-20130113/Build/powerpc64-linux/64/libstdc++-v3/src/.libs/libstdc++.so.6.0.18
      0x3fffb7f90000     0x3fffb7f96000     0x6000   0x165000
/daten/gcc/gcc-20130113/Build/powerpc64-linux/64/libstdc++-v3/src/.libs/libstdc++.so.6.0.18
      0x3fffb7f96000     0x3fffb7fa7000    0x11000   0x16b000
/daten/gcc/gcc-20130113/Build/powerpc64-linux/64/libstdc++-v3/src/.libs/libstdc++.so.6.0.18
      0x3fffb7fa7000     0x3fffb7fc0000    0x19000        0x0 
      0x3fffb7fc0000     0x3fffb7fc3000     0x3000        0x0 [vdso]
      0x3fffb7fc3000     0x3fffb7fec000    0x29000        0x0 /lib64/ld-2.15.so
      0x3fffb7fef000     0x3fffb7ffc000     0xd000        0x0 
      0x3fffb7ffc000     0x3fffb7ffd000     0x1000    0x29000 /lib64/ld-2.15.so
      0x3fffb7ffd000     0x3fffb8000000     0x3000    0x2a000 /lib64/ld-2.15.so
      0x3ffffffde000     0x400000000000    0x22000        0x0 [stack]

[Bug sanitizer/55975] FAIL: c-c++-common/asan/global-overflow-1.c -O0 output pattern test

[kcc at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975

Kostya Serebryany <kcc at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bergner at vnet dot ibm.com

--- Comment #3 from Kostya Serebryany <kcc at gcc dot gnu.org> 2013-01-16 10:01:24 UTC ---
+bergner@vnet.ibm.com, who changed kHighMemEnd to 0x00000fffffffffffUL

>From the proc mappings in the prev comment it looks like kHighMemEnd should be
0x400000000000-1


[Please forgive my complete ignorance in PowerPC, I will try to educate myself]

[Bug sanitizer/55975] FAIL: c-c++-common/asan/global-overflow-1.c -O0 output pattern test

[kcc at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975

--- Comment #4 from Kostya Serebryany <kcc at gcc dot gnu.org> 2013-01-16 10:14:03 UTC ---
Btw, the mapping I see on my PPC linux box ends with 0x100000000000

(with ASLR off)
ffffffd0000-100000000000 rw-p 00000000 00:00 0              [stack]

(with ASLR on)
fffe4c90000-fffe4cc0000 rw-p 00000000 00:00 0               [stack]

Are you using some special kernel settings to get stack at 0x400000000000?

[Bug sanitizer/55975] FAIL: c-c++-common/asan/global-overflow-1.c -O0 output pattern test

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-01-16 10:38:01 UTC ---
Sounds like a recent change:
http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=commitdiff;h=048ee0993ec8360abb0b51bdf8f8721e9ed62ec4
The question is what to do about that on the libasan side.
Can we keep + (1ULL << 41) asan_shadow_offset for both 44-bit and 46-bit user
address spaces?  If we just increase kHighMemEnd to 0x00003fffffffffffUL, it
will mean that on older kernels half of the user address space will be the
shadow memory (from 0x20000000000 to 0x9ffffffffff).  Perhaps that is still
acceptable, but if ever the address space grows again, we'd need to make size
of shadow memory region and kHighMemEnd dynamic.

[Bug sanitizer/55975] asan does not work with 46 bit address space on PowerPC64

[kcc at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975

Kostya Serebryany <kcc at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|FAIL:                       |asan does not work with 46
                   |c-c++-common/asan/global-ov |bit address space on
                   |erflow-1.c  -O0  output     |PowerPC64
                   |pattern test                |

--- Comment #6 from Kostya Serebryany <kcc at gcc dot gnu.org> 2013-01-16 11:47:38 UTC ---
>>  we'd need to make size of shadow memory region and kHighMemEnd dynamic.

Probably so. 
We already have a macro ASAN_FLEXIBLE_MAPPING_AND_OFFSET that makes the 
SHADOW_SCALE and SHADOW_OFFSET dynamic. 
We'll soon make this the default since we want to use the zero base for asan 
on linux more widely (under a flag). 

What is the best way to compute kHighMemEnd at startup (anything better than
reading proc maps?)

[Bug sanitizer/55975] asan does not work with 46 bit address space on PowerPC64

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-01-16 11:50:47 UTC ---
I think for 44->46 bits we can still make it constant.  But generally, the
constructors of libasan are usually run from the stack of the initial thread,
so it should be enough to look at address of any local variable and check if it
is around (1 << 44) - epsilon or (1 << 46) - epsilon.

[Bug sanitizer/55975] asan does not work with 46 bit address space on PowerPC64

[kcc at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975

--- Comment #8 from Kostya Serebryany <kcc at gcc dot gnu.org> 2013-01-16 11:54:36 UTC ---
Sounds good for both. 

Andreas, could you please try replacing 
kHighMemEnd = 0x00000fffffffffffUL
with 
kHighMemEnd = 0x00003fffffffffffUL
and see if it helps?

[Bug sanitizer/55975] asan does not work with 46 bit address space on PowerPC64

[schwab@linux-m68k.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975

--- Comment #9 from Andreas Schwab <schwab@linux-m68k.org> 2013-01-16 19:12:01 UTC ---
-FAIL: c-c++-common/asan/global-overflow-1.c  -O0  output pattern test, is
==9876== AddressSanitizer CHECK failed:
../../../../../gcc/libsanitizer/asan/asan_thread.cc:74
"((AddrIsInMem(stack_bottom_))) != (0)" (0x0, 0x0)
+FAIL: c-c++-common/asan/global-overflow-1.c  -O0  output pattern test, is
ASAN:SIGSEGV
 =================================================================
-==9876== ERROR: AddressSanitizer: unknown-crash on address 0x3fffc266bcc0 at
pc 0x3fff8c011b1c bp 0x3fffc266a7f0 sp 0x3fffc266a860
-WRITE of size 1 at 0x3fffc266bcc0 thread T0
-==9876== AddressSanitizer: while reporting a bug found another one.Ignoring.
+==15643== ERROR: AddressSanitizer: SEGV on unknown address 0x020002002471 (pc
0x000010000a4c sp 0x3fffe508dba0 bp 0x3fffe508dba0 T0)
+AddressSanitizer can not provide additional info.
+    #0 0x10000a48 in main
/home/andreas/src/gcc/gcc/gcc/testsuite/c-c++-common/asan/global-overflow-1.c:15
+Stats: 0M malloced (0M for red zones) by 0 calls
+Stats: 0M realloced by 0 calls
+Stats: 0M freed by 0 calls
+Stats: 0M really freed by 0 calls
+Stats: 0M (0M-0M) mmaped; 0 maps, 0 unmaps
+  mmaps   by size class: 
+  mallocs by size class: 
+  frees   by size class: 
+  rfrees  by size class: 
+Stats: malloc large: 0 small slow: 0
+Stats: StackDepot: 0 ids; 0M mapped
+==15643== ABORTING


         === gcc Summary for unix/-m64 ===

-# of expected passes        210
-# of unexpected failures    91
+# of expected passes        214
+# of unexpected failures    87
 # of unsupported tests        17

[Bug sanitizer/55975] asan does not work with 46 bit address space on PowerPC64

[kcc at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975

--- Comment #10 from Kostya Serebryany <kcc at gcc dot gnu.org> 2013-01-17 08:30:05 UTC ---
Since I can't reproduce the failure,
please help me debug this (basically, print all local variables around the
assertion and the proc maps) or suggest me how to reproduce. 

I've got access to a ppc machine with 3.3.8 Linux, but it uses 
44 bit address space and basic asan functionality seems to work 
(I am working with LLVM trunk, not with GCC version, but that should not
matter)

[Bug sanitizer/55975] asan does not work with 46 bit address space on PowerPC64

[schwab@linux-m68k.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975

--- Comment #11 from Andreas Schwab <schwab@linux-m68k.org> 2013-01-17 23:23:47 UTC ---
There are two off-by-one:

diff --git a/libsanitizer/asan/asan_poisoning.cc
b/libsanitizer/asan/asan_poisoning.cc
index a00baff..bbbaf0a 100644
--- a/libsanitizer/asan/asan_poisoning.cc
+++ b/libsanitizer/asan/asan_poisoning.cc
@@ -23,7 +23,7 @@ void PoisonShadow(uptr addr, uptr size, u8 value) {
   CHECK(AddrIsAlignedByGranularity(addr));
   CHECK(AddrIsAlignedByGranularity(addr + size));
   uptr shadow_beg = MemToShadow(addr);
-  uptr shadow_end = MemToShadow(addr + size);
+  uptr shadow_end = MemToShadow(addr + size - 1) + 1;
   CHECK(REAL(memset) != 0);
   REAL(memset)((void*)shadow_beg, value, shadow_end - shadow_beg);
 }
diff --git a/libsanitizer/asan/asan_thread.cc
b/libsanitizer/asan/asan_thread.cc
index cc2e777..02f49dd 100644
--- a/libsanitizer/asan/asan_thread.cc
+++ b/libsanitizer/asan/asan_thread.cc
@@ -72,7 +72,7 @@ void AsanThread::Destroy() {
 void AsanThread::Init() {
   SetThreadStackTopAndBottom();
   CHECK(AddrIsInMem(stack_bottom_));
-  CHECK(AddrIsInMem(stack_top_));
+  CHECK(AddrIsInMem(stack_top_ - 1));
   ClearShadowForThreadStack();
   if (flags()->verbosity >= 1) {
     int local = 0;

[Bug sanitizer/55975] asan does not work with 46 bit address space on PowerPC64

[schwab@linux-m68k.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975

--- Comment #12 from Andreas Schwab <schwab@linux-m68k.org> 2013-01-17 23:52:39 UTC ---
Created attachment 29199
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29199
make check-gcc RUNTESTFLAGS='--target_board=unix/-m64 asan.exp'

diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index 46bb0b4..23c8c7f 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -27609,7 +27609,7 @@ rs6000_final_prescan_insn (rtx insn, rtx *operand
ATTRIBUTE_UNUSED,
 static unsigned HOST_WIDE_INT
 rs6000_asan_shadow_offset (void)
 {
-  return (unsigned HOST_WIDE_INT) 1 << (TARGET_64BIT ? 41 : 29);
+  return (unsigned HOST_WIDE_INT) 1 << (TARGET_64BIT ? 43 : 29);
 }
 #endif

diff --git a/libsanitizer/asan/asan_mapping.h
b/libsanitizer/asan/asan_mapping.h
index 54e21b7..6c22709 100644
--- a/libsanitizer/asan/asan_mapping.h
+++ b/libsanitizer/asan/asan_mapping.h
@@ -32,7 +32,7 @@ extern SANITIZER_INTERFACE_ATTRIBUTE uptr
__asan_mapping_offset;
 #   define SHADOW_OFFSET (1 << 29)
 #  else
 #   if defined(__powerpc64__)
-#    define SHADOW_OFFSET (1ULL << 41)
+#    define SHADOW_OFFSET (1ULL << 43)
 #   else
 #    define SHADOW_OFFSET (1ULL << 44)
 #   endif
@@ -46,7 +46,7 @@ extern SANITIZER_INTERFACE_ATTRIBUTE uptr
__asan_mapping_offset;

 #if SANITIZER_WORDSIZE == 64
 # if defined(__powerpc64__)
-  static const uptr kHighMemEnd = 0x00000fffffffffffUL;
+  static const uptr kHighMemEnd = 0x00003fffffffffffUL;
 # else
   static const uptr kHighMemEnd = 0x00007fffffffffffUL;
 # endif

[Bug sanitizer/55975] asan does not work with 46 bit address space on PowerPC64

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975

--- Comment #13 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-01-18 08:19:45 UTC ---
Why do you need to change shadow offset?  That might make trouble in the 44-bit
address space case.

[Bug sanitizer/55975] asan does not work with 46 bit address space on PowerPC64

[kcc at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975

--- Comment #14 from Kostya Serebryany <kcc at gcc dot gnu.org> 2013-01-18 08:26:00 UTC ---
Because of this: 
#define kLowShadowBeg   SHADOW_OFFSET
#define kLowShadowEnd   MEM_TO_SHADOW(kLowMemEnd)

If we leave kLowShadowEnd as before, we will have too little shadow for the 44
bit address space. 

Maybe it's still better to make kHighMemEnd dynamic...

[Bug sanitizer/55975] asan does not work with 46 bit address space on PowerPC64

[kcc at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975

--- Comment #15 from Kostya Serebryany <kcc at gcc dot gnu.org> 2013-01-18 11:40:57 UTC ---
>> There are two off-by-one:

In LLVM trunk: http://llvm.org/viewvc/llvm-project?rev=172807&view=rev

Initially I wanted to do a merge to gcc this week, but I think I better wait a
bit -- there were too many intrusive changes in the trunk last week. 

BTW, many things will get simpler if PowerPC-specific bugs are 
tracked against the upstream version (file bugs in 
https://code.google.com/p/address-sanitizer/issues/list against the LLVM
version of the run-time)

[Bug sanitizer/55975] asan does not work with 46 bit address space on PowerPC64

[kcc at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975

--- Comment #16 from Kostya Serebryany <kcc at gcc dot gnu.org> 2013-01-18 12:30:11 UTC ---
-#    define SHADOW_OFFSET (1ULL << 41)
+#    define SHADOW_OFFSET (1ULL << 43)

On my ppc box which uses 44 bit address space this does not work: 

% ASAN_OPTIONS=verbosity=1 ./a.out
|| `[0x100000000000, 0x3fffffffffff]` || HighMem    ||
|| `[0x0a0000000000, 0x0fffffffffff]` || HighShadow ||
|| `[0x090000000000, 0x09ffffffffff]` || ShadowGap  ||
|| `[0x080000000000, 0x08ffffffffff]` || LowShadow  ||
|| `[0x000000000000, 0x07ffffffffff]` || LowMem     ||
==36991== Shadow memory range interleaves with an existing memory mapping. ASan
cannot proceed correctly. ABORTING.
==36991== Process memory map follows:
...
        0x0ffff4ad0000-0x0ffff4b00000   [stack]


Note: 
0x0fffffffffff HighShadow
0x0ffff4b00000 [stack]

So, we need a bit more flexible solution.

[Bug sanitizer/55975] asan does not work with 46 bit address space on PowerPC64

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975

--- Comment #17 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-01-18 13:02:41 UTC ---
But why doesn't the 1 << 41 version work with both 44 and 46-bit VA?
It should be:
   || `[0x0a0000000000, 0x3fffffffffff]` || HighMem    ||
   || `[0x034000000000, 0x09ffffffffff]` || HighShadow ||
   || `[0x024000000000, 0x033fffffffff]` || ShadowGap  ||
   || `[0x020000000000, 0x023fffffffff]` || LowShadow  ||
   || `[0x000000000000, 0x01ffffffffff]` || LowMem     ||
then, which IMHO should work just fine even if 0x100000000000 through
0x3fffffffffff is unavailable.

[Bug sanitizer/55975] asan does not work with 46 bit address space on PowerPC64

[schwab@linux-m68k.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975

--- Comment #18 from Andreas Schwab <schwab@linux-m68k.org> 2013-01-18 13:21:02 UTC ---
(In reply to comment #15)
> In LLVM trunk: http://llvm.org/viewvc/llvm-project?rev=172807&view=rev

That only happens when running under gdb which appears to disable address
randomisation.

[Bug sanitizer/55975] asan does not work with 46 bit address space on PowerPC64

[schwab@linux-m68k.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975

--- Comment #19 from Andreas Schwab <schwab@linux-m68k.org> 2013-01-18 13:25:42 UTC ---
MEM_TO_SHODOW does not work when (SHADOW_OFFSET << SHADOW_SHIFT) is less than
kHighMemEnd.

$ ASAN_OPTIONS=verbosity=1 ./clone-test-1.exe
==16778== Parsed ASAN_OPTIONS: verbosity=1
==16778== AddressSanitizer: libc interceptors initialized
|| `[0x080000000000, 0x3fffffffffff]` || HighMem    ||
|| `[0x030000000000, 0x07ffffffffff]` || HighShadow ||
|| `[0x024000000000, 0x02ffffffffff]` || ShadowGap  ||
|| `[0x020000000000, 0x023fffffffff]` || LowShadow  ||
|| `[0x000000000000, 0x01ffffffffff]` || LowMem     ||
MemToShadow(shadow): 0x024000000000 0x0247ffffffff 0x026000000000
0x02ffffffffff
red_zone=128
malloc_context_size=30
SHADOW_SCALE: 3
SHADOW_GRANULARITY: 8
SHADOW_OFFSET: 20000000000
==16778== Installed the sigaction for signal 11
==16778== T0: stack [0x3fffcebc9000,0x3fffcf3c9000) size 0x800000;
local=0x3fffcf3c6990
==16778== AddressSanitizer Init done
ASAN:SIGSEGV
=================================================================
==16778== ERROR: AddressSanitizer: SEGV on unknown address 0x09fff9e78d62 (pc
0x000010000d10 sp 0x3fffcf3c6a70 bp 0x3fffcf3c6a70 T0)
AddressSanitizer can not provide additional info.
    #0 0x10000d0c
(/home/andreas/src/gcc/ppc/gcc/testsuite/gcc/clone-test-1.exe+0x10000d0c)
Stats: 0M malloced (0M for red zones) by 0 calls
Stats: 0M realloced by 0 calls
Stats: 0M freed by 0 calls
Stats: 0M really freed by 0 calls
Stats: 0M (0M-0M) mmaped; 0 maps, 0 unmaps
  mmaps   by size class: 
  mallocs by size class: 
  frees   by size class: 
  rfrees  by size class: 
Stats: malloc large: 0 small slow: 0
Stats: StackDepot: 0 ids; 0M mapped
==16778== ABORTING

[Bug sanitizer/55975] asan does not work with 46 bit address space on PowerPC64

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975

--- Comment #20 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-01-18 13:52:02 UTC ---
Ah yes, it can't be | SHADOW_OFFSET then, but has to be + SHADOW_OFFSET.  + is
what gcc emits (the reason for that was primarily that it resulted in better
code on x86_64/i686).  So perhaps for targets where SHADOW_OFFSET is non-zero
and below (or equal to) 12.5% of maximum user address space, we are free to use
either | or +, but for other targets (for now ppc64) it must use +?

[Bug sanitizer/55975] asan does not work with 46 bit address space on PowerPC64

[kcc at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975

--- Comment #21 from Kostya Serebryany <kcc at gcc dot gnu.org> 2013-01-18 15:33:33 UTC ---
While we are at it... 
It is possible to use zero shadow offset of powerpc somehow? 

on x86_64 linux, when I build the code with -fPIC -pie
the mapping looks like this: 

7fb6dda49000-7fb6ddbfe000 r-xp 00000000 fc:00 1208459                   
/lib/x86_64-linux-gnu/libc-2.15.so
...
7fff01eba000-7fff01edb000 rw-p 00000000 00:00 0                         
[stack]
7fff01f15000-7fff01f16000 r-xp 00000000 00:00 0                          [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                 
[vsyscall]

which allows us to occupy 16T of memory starting from zero for the shadow. 

On my power pc box, however, I get this mapping: 
36ec0000-36ed0000 r-xp 00000000 08:02 3213429                           
/tmp/a.out
36ed0000-36ee0000 rw-p 00000000 08:02 3213429                           
/tmp/a.out
fff7f360000-fff7f370000 rw-p 00000000 00:00 0 
...
fffe70d0000-fffe7100000 rw-p 00000000 00:00 0                           
[stack]

So, I can't use zero-based shadow. 

On x86_64 using zero-based shadow gives 5% speedup. It's worth trying on ppc as
well, I think.

[Bug sanitizer/55975] asan does not work with 46 bit address space on PowerPC64

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975

--- Comment #22 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-01-18 15:41:09 UTC ---
Forcing everything to be built as -pie is a non-starter.  The 5% just aren't
worth the trouble.  Especially, how are you going to deal with say a
-fsanitize=address shared library built with 1 << 44 shadow offset and a PIE
binary built with 0 shadow offset?

[Bug sanitizer/55975] asan does not work with 46 bit address space on PowerPC64

[kcc at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975

--- Comment #23 from Kostya Serebryany <kcc at gcc dot gnu.org> 2013-01-18 15:46:00 UTC ---
in our use-case 5% of run-time (and code size too) is a lot. 
We are currently in the process of migrating the chrome builds to zero based
offset (chrome already uses -pie).

Mixing objects build with different options is, of course, not supported. 

On Android (where we are especially restricted with code size and address
space, but where we also control our destiny) the zero based shadow is the only
choice.

[Bug sanitizer/55975] asan does not work with 46 bit address space on PowerPC64

[kcc at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975

--- Comment #24 from Kostya Serebryany <kcc at gcc dot gnu.org> 2013-01-21 09:11:22 UTC ---
I've tried adding the offset instead of OR-ing it and got 2%-5% slowdown and
same code size increase on SPEC on x86_64 (using fresh clang -02). 
So, yes, if we want to keep the shadow offset 2^41 on PPC, we need to add the
offset, while still OR-ing it on other architectures. 

It's sad we can't use zero base on PPC.

[Bug sanitizer/55975] asan does not work with 46 bit address space on PowerPC64

[kcc at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975

--- Comment #25 from Kostya Serebryany <kcc at gcc dot gnu.org> 2013-01-23 12:21:51 UTC ---
So, what is our decision? 

Are we just doing 
-  static const uptr kHighMemEnd = 0x00000fffffffffffUL;
+  static const uptr kHighMemEnd = 0x00003fffffffffffUL;
, leaving SHADOW_OFFSET=(1ULL << 41)
and using ADD instead of OR when applying SHADOW_OFFSET? 

This seems to work on my ppc box (44-bit) with LLVM
(I've changed it to use ADD on PPC)

[Bug sanitizer/55975] asan does not work with 46 bit address space on PowerPC64

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975

--- Comment #26 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-01-23 12:26:30 UTC ---
(In reply to comment #25)
> So, what is our decision? 
> 
> Are we just doing 
> -  static const uptr kHighMemEnd = 0x00000fffffffffffUL;
> +  static const uptr kHighMemEnd = 0x00003fffffffffffUL;
> , leaving SHADOW_OFFSET=(1ULL << 41)
> and using ADD instead of OR when applying SHADOW_OFFSET? 
> 
> This seems to work on my ppc box (44-bit) with LLVM
> (I've changed it to use ADD on PPC)

If that works, it is my preference.  But needs testing, also with GCC, and with
both 44-bit and 46-bit AS.

BTW, I wonder why clang generates larger and slower code with ADD instead of
OR, at least gcc seems to generate generally better code with ADD, plus on
i?86/x86_64 it even has better HW support for that (for ADD can use both
add{l,q} and leal, allowing RA to generate better code).  GCC for asan
generates always ADD, on all architectures, right now.

[Bug sanitizer/55975] asan does not work with 46 bit address space on PowerPC64

[kcc at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975

--- Comment #27 from Kostya Serebryany <kcc at gcc dot gnu.org> 2013-01-23 12:51:40 UTC ---
>> BTW, I wonder why clang generates larger and slower code with ADD instead of OR
I did not investigate. I noticed that the code size with OR is smaller than
with ADD. 

One more thing to take care of with powerpc: the new allocator needs a change
like this:
--- asan/asan_allocator2.cc    (revision 173248)
+++ asan/asan_allocator2.cc    (working copy)
@@ -57,7 +57,11 @@
 };

 #if SANITIZER_WORDSIZE == 64
+#if defined(__powerpc64__)
+const uptr kAllocatorSpace =  0xa0000000000ULL;
+#else
 const uptr kAllocatorSpace = 0x600000000000ULL;
+#endif
 const uptr kAllocatorSize  =  0x10000000000ULL;  // 1T.
 typedef DefaultSizeClassMap SizeClassMap;
 typedef SizeClassAllocator64<kAllocatorSpace, kAllocatorSize, 0 /*metadata*/,


And one more thing: if we set kHighMemEnd = 0x00003fffffffffffUL
asan will stop working in 44-bit AS with unlimited stack: 

% (ulimit -s unlimited; clang -fsanitize=address use-after-free.cc ;
ASAN_OPTIONS=verbosity=1 ./a.out )
==37704== Parsed ASAN_OPTIONS: verbosity=1
==37704== AddressSanitizer: libc interceptors initialized
|| `[0x0a0000000000, 0x3fffffffffff]` || HighMem    ||
|| `[0x034000000000, 0x09ffffffffff]` || HighShadow ||
|| `[0x024000000000, 0x033fffffffff]` || ShadowGap  ||
|| `[0x020000000000, 0x023fffffffff]` || LowShadow  ||
|| `[0x000000000000, 0x01ffffffffff]` || LowMem     ||
MemToShadow(shadow): 0x024000000000 0x0247ffffffff 0x026800000000
0x033fffffffff
red_zone=16
malloc_context_size=30
SHADOW_SCALE: 3
SHADOW_GRANULARITY: 8
SHADOW_OFFSET: 20000000000
==37704== Shadow memory range interleaves with an existing memory mapping. ASan
cannot proceed correctly. ABORTING.
==37704== Process memory map follows:
        0x000010000000-0x000010030000   /tmp/a.out
        0x000010030000-0x000010050000   /tmp/a.out
        0x000010050000-0x000012db0000   
        0x040000000000-0x040000030000   /lib64/ld-2.13.so
        0x040000030000-0x040000040000   /lib64/ld-2.13.so
        0x040000040000-0x040000060000   [vdso]
        0x040000070000-0x040000090000   /lib64/libpthread-2.13.so
        0x040000090000-0x0400000a0000   /lib64/libpthread-2.13.so
        0x0400000a0000-0x0400000b0000   
        0x0400000b0000-0x0400000c0000   /lib64/libdl-2.13.so
        0x0400000c0000-0x0400000d0000   /lib64/libdl-2.13.so
        0x0400000d0000-0x0400000f0000   /lib64/libgcc_s.so.1
        0x0400000f0000-0x040000100000   /lib64/libgcc_s.so.1
        0x040000100000-0x040000290000   /lib64/libc-2.13.so
        0x040000290000-0x0400002a0000   /lib64/libc-2.13.so
        0x0400002a0000-0x0400002c0000   /lib64/libc-2.13.so
        0x0400002c0000-0x040000320000   
        0x0fffd2df0000-0x0fffd2e20000   [stack]
==37704== End of process memory map.

So, perhaps we still need dynamic kHighMemEnd.

[Bug sanitizer/55975] asan does not work with 46 bit address space on PowerPC64

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975

--- Comment #28 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-01-23 13:05:57 UTC ---
Why doesn't it error for unlimited stack say on x86_64?  If the stack mapping
size is unlimited, it also potentially overlaps with the shadow memory.  If you
have a growsdown mapping, it simply needs to be capped by the end of the shadow
memory area resp. start of the high memory region.

[Bug sanitizer/55975] asan does not work with 46 bit address space on PowerPC64

[kcc at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975

--- Comment #29 from Kostya Serebryany <kcc at gcc dot gnu.org> 2013-01-23 13:19:30 UTC ---
>> Why doesn't it error for unlimited stack say on x86_64? 
Because on x86_64 the stack is still high enough (we are lucky). 

Note: I would not generally care about unlimited stack, 
but for some obscure reason GNU make spawns its sub-processes with unlimited
stack.

[Bug sanitizer/55975] asan does not work with 46 bit address space on PowerPC64

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975

--- Comment #30 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-01-23 13:30:19 UTC ---
What I mean, is a stack PROT_GROWSDOWN RLIM_INFINITY RLIMIT_STACK mapping is
defined to be a mapping from the top of that mapping down to the first mapping
of something else below it.  Whether it is the shadow memory or something else
doesn't matter.  There is just no overlap in that case, so the error looks
wrong to me.

[Bug sanitizer/55975] asan does not work with 46 bit address space on PowerPC64

[kcc at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975

--- Comment #31 from Kostya Serebryany <kcc at gcc dot gnu.org> 2013-01-23 13:32:11 UTC ---
I've committed an upstream change
http://llvm.org/viewvc/llvm-project?view=rev&revision=173260 that makes
kHighMemEnd dynamic. 
Hopefully, it will simplify further changes. 

I'd appreciate if someone who has access to a 46-bit AS machine 
propose a patch that works for both 44 and 46 AS w/ and w/o unlimited stack.

[Bug sanitizer/55975] asan does not work with 46 bit address space on PowerPC64

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975

--- Comment #32 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-01-23 13:33:45 UTC ---
I take it back, seems it is because the kernel mmaps the shared libraries in
that range in this case.  So indeed, you probably need a dynamic mapping, sorry
for the noise.  All that just to grow VA by 2 bits?  Urgh.  On x86_64 at least
the address space was growing much more many years ago.

[Bug sanitizer/55975] asan does not work with 46 bit address space on PowerPC64

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975

--- Comment #33 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-01-23 13:40:57 UTC ---
(In reply to comment #31)
> I've committed an upstream change
> http://llvm.org/viewvc/llvm-project?view=rev&revision=173260 that makes
> kHighMemEnd dynamic. 
> Hopefully, it will simplify further changes. 
> 
> I'd appreciate if someone who has access to a 46-bit AS machine 
> propose a patch that works for both 44 and 46 AS w/ and w/o unlimited stack.

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)?
Otherwise it will slow down many of the inlines that use this heavily.
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.

[Bug sanitizer/55975] asan does not work with 46 bit address space on PowerPC64

[kcc at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975

--- Comment #34 from Kostya Serebryany <kcc at gcc dot gnu.org> 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.

[Bug sanitizer/55975] asan does not work with 46 bit address space on PowerPC64

[wschmidt at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975

William J. Schmidt <wschmidt at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |wschmidt at gcc dot gnu.org

--- Comment #35 from William J. Schmidt <wschmidt at gcc dot gnu.org> 2013-01-23 16:25:27 UTC ---
(In reply to comment #34)
> 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!).

Well, although the ppc64 LNT bot is not quite functional yet, there are many of
us who run the LLVM unit test suite several times a day.  So as long as the
changes are covered with tests in Instrumentation/{Address,Thread}Sanitizer,
we'll definitely notice PPC64 breakage and let you know. ;)

Bill

[Bug sanitizer/55975] asan does not work with 46 bit address space on PowerPC64

[kcc at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975

--- Comment #36 from Kostya Serebryany <kcc at gcc dot gnu.org> 2013-01-24 07:19:00 UTC ---
> Well, although the ppc64 LNT bot is not quite functional yet, there are many of
> us who run the LLVM unit test suite several times a day.  So as long as the
> changes are covered with tests in Instrumentation/{Address,Thread}Sanitizer,
> we'll definitely notice PPC64 breakage and let you know. ;)

Bill, tests in Instrumentation/AddressSanitizer are compiler-only tests
and thus are mostly platform independent.
The interesting part is the run-time tests that can be run with "make
check-asan"
(only in cmake build)
These build on PPC64 today and some of them even pass, but not all.

[Bug sanitizer/55975] asan does not work with 46 bit address space on PowerPC64

[wschmidt at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975

--- Comment #37 from William J. Schmidt <wschmidt at gcc dot gnu.org> 2013-01-24 13:30:53 UTC ---
(In reply to comment #36)
> Bill, tests in Instrumentation/AddressSanitizer are compiler-only tests
> and thus are mostly platform independent.
> The interesting part is the run-time tests that can be run with "make
> check-asan"
> (only in cmake build)
> These build on PPC64 today and some of them even pass, but not all.

OK.  Please let me know if we can assist setting up a PPC bot in the future, to
help maintain compatibility.

[Bug sanitizer/55975] asan does not work with 46 bit address space on PowerPC64

[kcc at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975

--- Comment #38 from Kostya Serebryany <kcc at gcc dot gnu.org> 2013-01-24 13:46:17 UTC ---
> OK.  Please let me know if we can assist setting up a PPC bot in the future, to
> help maintain compatibility.

Oh, that'll be great even now.
If you can setup a bot that builds asan-runtime for PPC32 and PPC64 
and runs the test, it will be awesome! 

Just let the bot execute these steps in order: 
make -j 64 clang_rt.asan-powerpc64
make -j 64 clang_rt.asan-powerpc
make -j 64 Asan-powerpc64-Test
make -j 64 Asan-powerpc-Test
make -j 64 check-asan 

The last step is red now, but we'll fix it eventually. 

We may even need two bots, for 44-bit and 46-bit AS. 

(as it's taking us away from this bug, perhaps we could continue by e-mail)