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.
