Hello Alex, Thanks for the hint. It was actually not the -O flag that created the problem. But it pointed me in the right direction, when I passed -fno-experimental-new-pass-manager it started to show the error. My guess is that the new pass manager is more aggressive in removing UB? Thanks, Tobias On Mon, Feb 3, 2020 at 5:29 PM Alex Brachet-Mialot <alexbrachetmialot at gmail.com> wrote:> > I haven’t looked at the code gen yet because I’m not on my computer right now but I suspect that at -Os the compiler is optimizing this away because it knows it to be undefined behavior. Try with -O0. > > On Mon, Feb 3, 2020 at 10:53 AM Tobias Hieta via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> Hello, >> >> I am building sanitizers for our different platforms and trying to use >> it in an example program, but while it seems like ASAN is running it's >> init functions (see stdout below with ASAN_OPTIONS=verbosity=1) it >> never catches anything in the program. This is LLVM 8.0.1 btw. >> >> I was using this small test case: >> >> int main(int argc, char** argv) { >> int *array = new int[100]; >> delete [] array; >> return array[argc]; // BOOM >> } >> >> I am compiling with: >> >> >> clang++ -resource-dir <path to sanitizers> -fsanitize=address >> -shared-libasan -fno-omit-frame-pointer -Os -g -Wl,-rpath,<path to >> sanitizers> -o hello hello.cpp >> >> This is the output from setting verbosity=1 - how can I debug this issue? >> >> ==3401806==AddressSanitizer: libc interceptors initialized >> || `[0x10007fff8000, 0x7fffffffffff]` || HighMem || >> || `[0x02008fff7000, 0x10007fff7fff]` || HighShadow || >> || `[0x00008fff7000, 0x02008fff6fff]` || ShadowGap || >> || `[0x00007fff8000, 0x00008fff6fff]` || LowShadow || >> || `[0x000000000000, 0x00007fff7fff]` || LowMem || >> MemToShadow(shadow): 0x00008fff7000 0x000091ff6dff 0x004091ff6e00 0x02008fff6fff >> redzone=16 >> max_redzone=2048 >> quarantine_size_mb=256M >> thread_local_quarantine_size_kb=1024K >> malloc_context_size=30 >> SHADOW_SCALE: 3 >> SHADOW_GRANULARITY: 8 >> SHADOW_OFFSET: 0x7fff8000 >> ==3401806==Installed the sigaction for signal 11 >> ==3401806==Installed the sigaction for signal 7 >> ==3401806==Installed the sigaction for signal 8 >> ==3401806==T0: stack [0x7fff3bf5c000,0x7fff3c75c000) size 0x800000; >> local=0x7fff3c759244 >> ==3401806==AddressSanitizer Init done >> >> ➜ readelf -d hello >> >> Dynamic section at offset 0xe18 contains 25 entries: >> Tag Type Name/Value >> 0x0000000000000001 (NEEDED) Shared library: [libclang_rt.asan-x86_64.so] >> 0x0000000000000001 (NEEDED) Shared library: [libstdc++.so.6] >> 0x0000000000000001 (NEEDED) Shared library: [libm.so.6] >> 0x0000000000000001 (NEEDED) Shared library: [libgcc_s.so.1] >> 0x0000000000000001 (NEEDED) Shared library: [libc.so.6] >> 0x000000000000000c (INIT) 0x400570 >> 0x000000000000000d (FINI) 0x4007b8 >> 0x0000000000000004 (HASH) 0x400278 >> 0x0000000000000005 (STRTAB) 0x400318 >> 0x0000000000000006 (SYMTAB) 0x4002a0 >> 0x000000000000000a (STRSZ) 462 (bytes) >> 0x000000000000000b (SYMENT) 24 (bytes) >> 0x0000000000000015 (DEBUG) 0x0 >> 0x0000000000000003 (PLTGOT) 0x601000 >> 0x0000000000000002 (PLTRELSZ) 72 (bytes) >> 0x0000000000000014 (PLTREL) RELA >> 0x0000000000000017 (JMPREL) 0x400528 >> 0x0000000000000007 (RELA) 0x400510 >> 0x0000000000000008 (RELASZ) 24 (bytes) >> 0x0000000000000009 (RELAENT) 24 (bytes) >> 0x000000006ffffffe (VERNEED) 0x4004f0 >> 0x000000006fffffff (VERNEEDNUM) 1 >> 0x000000006ffffff0 (VERSYM) 0x4004e6 >> 0x0000000000000000 (NULL) 0x0 >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
After experimenting a bit with godbolt it seems like asan is removed from the codegen when the new pass manager is used: https://godbolt.org/z/ccrMiN But this also seems fixed if you switch to clang 9.0.0. On Mon, Feb 3, 2020 at 8:38 PM Tobias Hieta <tobias at plexapp.com> wrote:> > Hello Alex, > > Thanks for the hint. It was actually not the -O flag that created the > problem. But it pointed me in the right direction, when I passed > -fno-experimental-new-pass-manager it started to show the error. My > guess is that the new pass manager is more aggressive in removing UB? > > Thanks, > Tobias > > On Mon, Feb 3, 2020 at 5:29 PM Alex Brachet-Mialot > <alexbrachetmialot at gmail.com> wrote: > > > > I haven’t looked at the code gen yet because I’m not on my computer right now but I suspect that at -Os the compiler is optimizing this away because it knows it to be undefined behavior. Try with -O0. > > > > On Mon, Feb 3, 2020 at 10:53 AM Tobias Hieta via llvm-dev <llvm-dev at lists.llvm.org> wrote: > >> > >> Hello, > >> > >> I am building sanitizers for our different platforms and trying to use > >> it in an example program, but while it seems like ASAN is running it's > >> init functions (see stdout below with ASAN_OPTIONS=verbosity=1) it > >> never catches anything in the program. This is LLVM 8.0.1 btw. > >> > >> I was using this small test case: > >> > >> int main(int argc, char** argv) { > >> int *array = new int[100]; > >> delete [] array; > >> return array[argc]; // BOOM > >> } > >> > >> I am compiling with: > >> > >> > >> clang++ -resource-dir <path to sanitizers> -fsanitize=address > >> -shared-libasan -fno-omit-frame-pointer -Os -g -Wl,-rpath,<path to > >> sanitizers> -o hello hello.cpp > >> > >> This is the output from setting verbosity=1 - how can I debug this issue? > >> > >> ==3401806==AddressSanitizer: libc interceptors initialized > >> || `[0x10007fff8000, 0x7fffffffffff]` || HighMem || > >> || `[0x02008fff7000, 0x10007fff7fff]` || HighShadow || > >> || `[0x00008fff7000, 0x02008fff6fff]` || ShadowGap || > >> || `[0x00007fff8000, 0x00008fff6fff]` || LowShadow || > >> || `[0x000000000000, 0x00007fff7fff]` || LowMem || > >> MemToShadow(shadow): 0x00008fff7000 0x000091ff6dff 0x004091ff6e00 0x02008fff6fff > >> redzone=16 > >> max_redzone=2048 > >> quarantine_size_mb=256M > >> thread_local_quarantine_size_kb=1024K > >> malloc_context_size=30 > >> SHADOW_SCALE: 3 > >> SHADOW_GRANULARITY: 8 > >> SHADOW_OFFSET: 0x7fff8000 > >> ==3401806==Installed the sigaction for signal 11 > >> ==3401806==Installed the sigaction for signal 7 > >> ==3401806==Installed the sigaction for signal 8 > >> ==3401806==T0: stack [0x7fff3bf5c000,0x7fff3c75c000) size 0x800000; > >> local=0x7fff3c759244 > >> ==3401806==AddressSanitizer Init done > >> > >> ➜ readelf -d hello > >> > >> Dynamic section at offset 0xe18 contains 25 entries: > >> Tag Type Name/Value > >> 0x0000000000000001 (NEEDED) Shared library: [libclang_rt.asan-x86_64.so] > >> 0x0000000000000001 (NEEDED) Shared library: [libstdc++.so.6] > >> 0x0000000000000001 (NEEDED) Shared library: [libm.so.6] > >> 0x0000000000000001 (NEEDED) Shared library: [libgcc_s.so.1] > >> 0x0000000000000001 (NEEDED) Shared library: [libc.so.6] > >> 0x000000000000000c (INIT) 0x400570 > >> 0x000000000000000d (FINI) 0x4007b8 > >> 0x0000000000000004 (HASH) 0x400278 > >> 0x0000000000000005 (STRTAB) 0x400318 > >> 0x0000000000000006 (SYMTAB) 0x4002a0 > >> 0x000000000000000a (STRSZ) 462 (bytes) > >> 0x000000000000000b (SYMENT) 24 (bytes) > >> 0x0000000000000015 (DEBUG) 0x0 > >> 0x0000000000000003 (PLTGOT) 0x601000 > >> 0x0000000000000002 (PLTRELSZ) 72 (bytes) > >> 0x0000000000000014 (PLTREL) RELA > >> 0x0000000000000017 (JMPREL) 0x400528 > >> 0x0000000000000007 (RELA) 0x400510 > >> 0x0000000000000008 (RELASZ) 24 (bytes) > >> 0x0000000000000009 (RELAENT) 24 (bytes) > >> 0x000000006ffffffe (VERNEED) 0x4004f0 > >> 0x000000006fffffff (VERNEEDNUM) 1 > >> 0x000000006ffffff0 (VERSYM) 0x4004e6 > >> 0x0000000000000000 (NULL) 0x0 > >> _______________________________________________ > >> LLVM Developers mailing list > >> llvm-dev at lists.llvm.org > >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
I believe this is just because asan wasn't ported into the new PM until the clang 9 release which is why there's no asan instrumentation when using the new PM for older releases. On Mon, Feb 3, 2020 at 11:47 AM Tobias Hieta via llvm-dev < llvm-dev at lists.llvm.org> wrote:> After experimenting a bit with godbolt it seems like asan is removed > from the codegen when the new pass manager is used: > https://godbolt.org/z/ccrMiN > > But this also seems fixed if you switch to clang 9.0.0. > > On Mon, Feb 3, 2020 at 8:38 PM Tobias Hieta <tobias at plexapp.com> wrote: > > > > Hello Alex, > > > > Thanks for the hint. It was actually not the -O flag that created the > > problem. But it pointed me in the right direction, when I passed > > -fno-experimental-new-pass-manager it started to show the error. My > > guess is that the new pass manager is more aggressive in removing UB? > > > > Thanks, > > Tobias > > > > On Mon, Feb 3, 2020 at 5:29 PM Alex Brachet-Mialot > > <alexbrachetmialot at gmail.com> wrote: > > > > > > I haven’t looked at the code gen yet because I’m not on my computer > right now but I suspect that at -Os the compiler is optimizing this away > because it knows it to be undefined behavior. Try with -O0. > > > > > > On Mon, Feb 3, 2020 at 10:53 AM Tobias Hieta via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > >> > > >> Hello, > > >> > > >> I am building sanitizers for our different platforms and trying to use > > >> it in an example program, but while it seems like ASAN is running it's > > >> init functions (see stdout below with ASAN_OPTIONS=verbosity=1) it > > >> never catches anything in the program. This is LLVM 8.0.1 btw. > > >> > > >> I was using this small test case: > > >> > > >> int main(int argc, char** argv) { > > >> int *array = new int[100]; > > >> delete [] array; > > >> return array[argc]; // BOOM > > >> } > > >> > > >> I am compiling with: > > >> > > >> > > >> clang++ -resource-dir <path to sanitizers> -fsanitize=address > > >> -shared-libasan -fno-omit-frame-pointer -Os -g -Wl,-rpath,<path to > > >> sanitizers> -o hello hello.cpp > > >> > > >> This is the output from setting verbosity=1 - how can I debug this > issue? > > >> > > >> ==3401806==AddressSanitizer: libc interceptors initialized > > >> || `[0x10007fff8000, 0x7fffffffffff]` || HighMem || > > >> || `[0x02008fff7000, 0x10007fff7fff]` || HighShadow || > > >> || `[0x00008fff7000, 0x02008fff6fff]` || ShadowGap || > > >> || `[0x00007fff8000, 0x00008fff6fff]` || LowShadow || > > >> || `[0x000000000000, 0x00007fff7fff]` || LowMem || > > >> MemToShadow(shadow): 0x00008fff7000 0x000091ff6dff 0x004091ff6e00 > 0x02008fff6fff > > >> redzone=16 > > >> max_redzone=2048 > > >> quarantine_size_mb=256M > > >> thread_local_quarantine_size_kb=1024K > > >> malloc_context_size=30 > > >> SHADOW_SCALE: 3 > > >> SHADOW_GRANULARITY: 8 > > >> SHADOW_OFFSET: 0x7fff8000 > > >> ==3401806==Installed the sigaction for signal 11 > > >> ==3401806==Installed the sigaction for signal 7 > > >> ==3401806==Installed the sigaction for signal 8 > > >> ==3401806==T0: stack [0x7fff3bf5c000,0x7fff3c75c000) size 0x800000; > > >> local=0x7fff3c759244 > > >> ==3401806==AddressSanitizer Init done > > >> > > >> ➜ readelf -d hello > > >> > > >> Dynamic section at offset 0xe18 contains 25 entries: > > >> Tag Type Name/Value > > >> 0x0000000000000001 (NEEDED) Shared library: [ > libclang_rt.asan-x86_64.so] > > >> 0x0000000000000001 (NEEDED) Shared library: [libstdc++.so.6] > > >> 0x0000000000000001 (NEEDED) Shared library: [libm.so.6] > > >> 0x0000000000000001 (NEEDED) Shared library: [libgcc_s.so.1] > > >> 0x0000000000000001 (NEEDED) Shared library: [libc.so.6] > > >> 0x000000000000000c (INIT) 0x400570 > > >> 0x000000000000000d (FINI) 0x4007b8 > > >> 0x0000000000000004 (HASH) 0x400278 > > >> 0x0000000000000005 (STRTAB) 0x400318 > > >> 0x0000000000000006 (SYMTAB) 0x4002a0 > > >> 0x000000000000000a (STRSZ) 462 (bytes) > > >> 0x000000000000000b (SYMENT) 24 (bytes) > > >> 0x0000000000000015 (DEBUG) 0x0 > > >> 0x0000000000000003 (PLTGOT) 0x601000 > > >> 0x0000000000000002 (PLTRELSZ) 72 (bytes) > > >> 0x0000000000000014 (PLTREL) RELA > > >> 0x0000000000000017 (JMPREL) 0x400528 > > >> 0x0000000000000007 (RELA) 0x400510 > > >> 0x0000000000000008 (RELASZ) 24 (bytes) > > >> 0x0000000000000009 (RELAENT) 24 (bytes) > > >> 0x000000006ffffffe (VERNEED) 0x4004f0 > > >> 0x000000006fffffff (VERNEEDNUM) 1 > > >> 0x000000006ffffff0 (VERSYM) 0x4004e6 > > >> 0x0000000000000000 (NULL) 0x0 > > >> _______________________________________________ > > >> LLVM Developers mailing list > > >> llvm-dev at lists.llvm.org > > >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200203/2a170513/attachment.html>