[Bug sanitizer/84250] Symbol collision when using both Address and Undefined Behavior sanitizers (-fsanitize=address,undefined)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84250 --- Comment #3 from Maxim Ostapenko --- (In reply to Martin Liška from comment #2) > Maxim I've just seen your patch: > https://github.com/google/sanitizers/issues/912#issuecomment-363525012 > > Would it be possible to merge a solution to GCC trunk in next stage1? Sure, if no objections from Jakub.
[Bug sanitizer/81697] Incorrect ASan global variables alignment on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81697 --- Comment #5 from Maxim Ostapenko --- Fixed on trunk.
[Bug sanitizer/81923] [ASAN] gcc emites wrong odr asan instrumentation for glibc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81923 --- Comment #5 from Maxim Ostapenko --- (In reply to Maxim Ostapenko from comment #4) > Created attachment 42071 [details] > Untested fix > > The patch I'm testing now. It works on attached testcase. Yeeks, this patch is wrong, especially for C++. Please ignore it.
[Bug sanitizer/81923] [ASAN] gcc emites wrong odr asan instrumentation for glibc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81923 --- Comment #4 from Maxim Ostapenko --- Created attachment 42071 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42071&action=edit Untested fix The patch I'm testing now. It works on attached testcase.
[Bug sanitizer/81923] [ASAN] gcc emites wrong odr asan instrumentation for glibc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81923 Maxim Ostapenko changed: What|Removed |Added CC||m.ostapenko at samsung dot com --- Comment #1 from Maxim Ostapenko --- Could you please post a compilation command here?
[Bug target/81861] [8.0 Regression] ASan pr64820.c testcase segfaults with LTO and -fstack-protector-strong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81861 Maxim Ostapenko changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from Maxim Ostapenko --- Fixed on trunk.
[Bug lto/81861] [8.0 Regression] ASan pr64820.c testcase segfaults with LTO and -fstack-protector-strong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81861 --- Comment #6 from Maxim Ostapenko --- Created attachment 41990 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41990&action=edit Untested fix The problem is that LTO doesn't propagate changed ix86_stack_protector_guard_reg value: 6654 /* Save the initial options in case the user does function specific 6655 options. */ 6656 if (main_args_p) 6657 target_option_default_node = target_option_current_node 6658 = build_target_option_node (opts); <== save flags 6659 ... 6695 ix86_stack_protector_guard_reg = DEFAULT_TLS_SEG_REG; <== missed change Thus ix86_stack_protector_guard_reg becomes left ADDR_SPACE_GENERIC in ltrans stage that confuses optimizer later (wrong constant propagation in this case). Moving options saving down fixes the issue, although I'm not sure this is a correct fix.
[Bug tree-optimization/81861] ASan pr64820.c testcase segfaults with LTO and -fstack-protector-strong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81861 --- Comment #3 from Maxim Ostapenko --- (In reply to Uroš Bizjak from comment #1) > You didn't specify compile flags, but using: > > -O2 -fstack-protector-strong -fsanitize=address, I get: Sorry, here they are: $ /home/max/build/master/gcc/xgcc -B/home/max/build/master/gcc/ /home/max/workspace/downloads/gcc/gcc/testsuite/c-c++-common/asan/pr64820.c -B/home/max/build/master/x86_64-unknown-linux-gnu/./libsanitizer/ -B/home/max/build/master/x86_64-unknown-linux-gnu/./libsanitizer/asan/ -L/home/max/build/master/x86_64-unknown-linux-gnu/./libsanitizer/asan/.libs -fsanitize=address -g -I/home/max/workspace/downloads/gcc/gcc/testsuite/../../libsanitizer/include -fno-diagnostics-show-caret -fdiagnostics-color=never -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects -fstack-protector-strong -lm -o ./pr64820.exe $ /home/max/build/master/gcc/xgcc -v Using built-in specs. COLLECT_GCC=/home/max/build/master/gcc/xgcc Target: x86_64-unknown-linux-gnu Configured with: /home/max/workspace/downloads/gcc/configure --enable-multilib --enable-checking --target=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu --build=x86_64-unknown-linux-gnu --prefix=/home/max/install/master --disable-bootstrap --enable-languages=c,c++ CFLAGS='-g -g3 -O0' CXXFLAGS='-g -g3 -O0' : (reconfigured) /home/max/workspace/downloads/gcc/configure --enable-multilib --enable-checking --target=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu --build=x86_64-unknown-linux-gnu --prefix=/home/max/install/master --disable-bootstrap CFLAGS='-g -g3 -O0' CXXFLAGS='-g -g3 -O0' build_alias=x86_64-unknown-linux-gnu host_alias=x86_64-unknown-linux-gnu target_alias=x86_64-unknown-linux-gnu --enable-languages=c,c++,lto --no-create --no-recursion : (reconfigured) /home/max/workspace/downloads/gcc/configure --enable-multilib --enable-checking --target=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu --build=x86_64-unknown-linux-gnu --prefix=/home/max/install/master --disable-bootstrap CFLAGS='-g -g3 -O0' CXXFLAGS='-g -g3 -O0' build_alias=x86_64-unknown-linux-gnu host_alias=x86_64-unknown-linux-gnu target_alias=x86_64-unknown-linux-gnu --enable-languages=c,c++,lto --no-create --no-recursion : (reconfigured) /home/max/workspace/downloads/gcc/configure --enable-multilib --enable-checking --target=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu --build=x86_64-unknown-linux-gnu --prefix=/home/max/install/master --disable-bootstrap CFLAGS='-g -g3 -O0' CXXFLAGS='-g -g3 -O0' build_alias=x86_64-unknown-linux-gnu host_alias=x86_64-unknown-linux-gnu target_alias=x86_64-unknown-linux-gnu --enable-languages=c,c++,lto --no-create --no-recursion : (reconfigured) /home/max/workspace/downloads/gcc/configure --enable-multilib --enable-checking --target=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu --build=x86_64-unknown-linux-gnu --prefix=/home/max/install/master --disable-bootstrap CFLAGS='-g -g3 -O0' CXXFLAGS='-g -g3 -O0' build_alias=x86_64-unknown-linux-gnu host_alias=x86_64-unknown-linux-gnu target_alias=x86_64-unknown-linux-gnu --enable-languages=c,c++,lto --no-create --no-recursion : (reconfigured) /home/max/workspace/downloads/gcc/configure --enable-multilib --enable-checking --target=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu --build=x86_64-unknown-linux-gnu --prefix=/home/max/install/master --disable-bootstrap CFLAGS='-g -g3 -O0' CXXFLAGS='-g -g3 -O0' build_alias=x86_64-unknown-linux-gnu host_alias=x86_64-unknown-linux-gnu target_alias=x86_64-unknown-linux-gnu --enable-languages=c,c++,lto --no-create --no-recursion : (reconfigured) /home/max/workspace/downloads/gcc/configure --enable-multilib --enable-checking --target=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu --build=x86_64-unknown-linux-gnu --prefix=/home/max/install/master --disable-bootstrap CFLAGS='-g -g3 -O0' CXXFLAGS='-g -g3 -O0' build_alias=x86_64-unknown-linux-gnu host_alias=x86_64-unknown-linux-gnu target_alias=x86_64-unknown-linux-gnu --enable-languages=c,c++,lto --no-create --no-recursion Thread model: posix gcc version 8.0.0 20170808 (experimental) (GCC) > > 51: c7 82 00 80 ff 7f f1movl $0xf1f1f1f1,0x7fff8000(%rdx) > 58: f1 f1 f1 > 5b: c7 82 04 82 ff 7f f3movl $0xf3f3f3f3,0x7fff8204(%rdx) > 62: f3 f3 f3 > 65: 64 48 8b 04 25 28 00mov%fs:0x28,%rax > 6c: 00 00 > 6e: 48 89 84 24 58 10 00mov%rax,0x1058(%rsp) > 75: 00 > 76: 31 c0 xor%eax,%eax > > The insn in question is: > > #(insn:TI 35 19 40 3 (parallel [ > #(set (mem/v/f/c:DI (plus:DI (reg/f:DI 7 sp) > #(const_int 4184 [0x1058])) [2 D.2177+0 S8 A64]) > #(unspec:DI [ > #(mem/f:DI (const_int 40 [0x28]) [4 > MEM[( long unsigned int *)40B]+0 S8 A64 AS1]) > #] UNSPEC_SP_SET)) > #(set (reg:DI 0 ax [97]) > #(const_int 0 [0])) > #
[Bug tree-optimization/81861] New: ASan pr64820.c testcase segfaults with LTO and -fstack-protector-strong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81861 Bug ID: 81861 Summary: ASan pr64820.c testcase segfaults with LTO and -fstack-protector-strong Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: m.ostapenko at samsung dot com CC: ubizjak at gmail dot com Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu After r250965 the ASan's pr64820.c tescase fails with: ASAN:DEADLYSIGNAL = ==15720==ERROR: AddressSanitizer: SEGV on unknown address 0x (pc 0x004009e5 bp 0x7fff5fca17c0 sp 0x7fff5fca17c0 T0) ==15720==The signal is caused by a READ memory access. ==15720==Hint: address points to the zero page. #0 0x4009e4 in Func1 /home/max/workspace/downloads/gcc/gcc/testsuite/c-c++-common/asan/pr64820.c:13 #1 0x40080a in main /home/max/workspace/downloads/gcc/gcc/testsuite/c-c++-common/asan/pr64820.c:23 #2 0x2b7622799f44 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21f44) #3 0x40085a (/home/max/build/master/gcc/testsuite/gcc/pr64820.exe+0x40085a) AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV /home/max/workspace/downloads/gcc/gcc/testsuite/c-c++-common/asan/pr64820.c:13 in Func1 ==15720==ABORTING The code in resuting binary looks like this: 00400910 : 400910: 41 54 push %r12 400912: 55 push %rbp 400913: 53 push %rbx 400914: 48 81 ec 60 10 00 00sub$0x1060,%rsp 40091b: 8b 05 5f 06 20 00 mov0x20065f(%rip),%eax# 600f80 <__TMC_END__> 400921: 48 89 e3mov%rsp,%rbx 400924: 48 89 ddmov%rbx,%rbp 400927: 85 c0 test %eax,%eax 400929: 0f 85 8a 00 00 00 jne4009b9 40092f: 48 89 damov%rbx,%rdx 400932: 48 8d 7b 20 lea0x20(%rbx),%rdi 400936: 48 c7 03 b3 8a b5 41movq $0x41b58ab3,(%rbx) 40093d: 48 c1 ea 03 shr$0x3,%rdx 400941: 48 c7 43 08 08 0b 40movq $0x400b08,0x8(%rbx) 400948: 00 400949: 48 c7 43 10 10 09 40movq $0x400910,0x10(%rbx) 400950: 00 400951: c7 82 00 80 ff 7f f1movl $0xf1f1f1f1,0x7fff8000(%rdx) 400958: f1 f1 f1 40095b: c7 82 04 82 ff 7f f3movl $0xf3f3f3f3,0x7fff8204(%rdx) 400962: f3 f3 f3 Segfault here==> 400965: 48 8b 04 25 00 00 00mov0x0,%rax 40096c: 00 40096d: 48 89 84 24 58 10 00mov%rax,0x1058(%rsp) 400974: 00 400975: 31 c0 xor%eax,%eax 400977: e8 84 ff ff ff callq 400900
[Bug sanitizer/81697] Incorrect ASan global variables alignment on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81697 Maxim Ostapenko changed: What|Removed |Added CC||m.ostapenko at samsung dot com --- Comment #2 from Maxim Ostapenko --- Same for PPC that also uses section anchors.
[Bug sanitizer/61771] Test failures in ASan testsuite on ARM Linux due to FP format mismatch between libasan and GCC.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61771 Maxim Ostapenko changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #11 from Maxim Ostapenko --- Yes, fixed.
[Bug sanitizer/80953] Support libsanitizer on Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80953 Maxim Ostapenko changed: What|Removed |Added CC||m.ostapenko at samsung dot com --- Comment #6 from Maxim Ostapenko --- (In reply to Rainer Orth from comment #5) > Created attachment 41484 [details] > Merge libsanitizer from compiler-rt r304722 > > I've now completed a merge of llvm r304722 into gcc trunk libsanitizer. > Most of > it was straightforward, but a couple of issues may save others work: > > * Two bugs in sanitizer_common/sanitizer_symbolizer_libbacktrace.cc have > already > been reported upstream: https://reviews.llvm.org/D33933 > > * In libubsan, __ubsan_handle_type_mismatch has been renamed to > __ubsan_handle_type_mismatch_v1, and likewise for > __ubsan_handle_type_mismatch_abort__ubsan_handle_type_mismatch_v1_abort > > The sanitizer.def and ubsan.c changes reflect this. Worse, however, > the former uptr Alignment member of ubsan/ubsan_handlers.h was changed to > unsigned char LogAlignment. This needs a corresponding gcc change to pass > log2(align) instead of just align. > > * Many (all) */float-cast-overflow-*.c tests FAILed initially because of a > message change: > > runtime error: value -133 is outside the range of representable values of > type 'signed char' > > lost the leading "value" > > With these gcc side changes, testresults on x86_64-pc-linux-gnu are identical > to those with current gcc trunk, with the exception of > > +FAIL: c-c++-common/asan/pr63888.c -O2 execution test > +FAIL: c-c++-common/asan/pr63888.c -O2 -flto execution test > +FAIL: c-c++-common/asan/pr63888.c -O2 -flto -flto-partition=none > execution t > est > +FAIL: c-c++-common/asan/pr63888.c -O3 -g execution test > +FAIL: c-c++-common/asan/pr63888.c -Os execution test > > I get here > > = > ==4734==ERROR: AddressSanitizer: odr-violation (0x004009e0): > [1] size=12 'CSWTCH.1' > /vol/gcc/src/hg/trunk/solaris-asan/gcc/testsuite/c-c++-common/asan/pr63888.c: > 8:3 > [2] size=12 'CSWTCH.3' > /vol/gcc/src/hg/trunk/solaris-asan/gcc/testsuite/c-c++-common/asan/pr63888.c: > 21:3 > These globals were registered at these points: > [1]: > #0 0x7f2c9c48fb88 in __asan_register_globals > /vol/gcc/src/hg/trunk/solaris-asan/libsanitizer/asan/asan_globals.cc:356 > #1 0x40097c in __libc_csu_init > (/var/scratch/gcc/gcc-8.0.0-20170531/4.10.10-gcc-gas-gld-asan/gcc/testsuite/ > gcc17/pr63888.exe+0x40097c) > > [2]: > #0 0x7f2c9c48fb88 in __asan_register_globals > /vol/gcc/src/hg/trunk/solaris-asan/libsanitizer/asan/asan_globals.cc:356 > #1 0x40097c in __libc_csu_init > (/var/scratch/gcc/gcc-8.0.0-20170531/4.10.10-gcc-gas-gld-asan/gcc/testsuite/ > gcc17/pr63888.exe+0x40097c) > > ==4734==HINT: if you don't care about these errors you may set > ASAN_OPTIONS=detect_odr_violation=0 > SUMMARY: AddressSanitizer: odr-violation: global 'CSWTCH.1' at > /vol/gcc/src/hg/trunk/solaris-asan/gcc/testsuite/c-c++-common/asan/pr63888.c: > 8:3 > ==4734==ABORTING > > Someone who knows that code way better needs to look into this. > > Rainer For ODR violation bug we have a local patch in libsanitizer. Could you check whether you applied all local patches listed in libsanitizer/LOCAL_PATCHES file?
[Bug objc/80798] Dynamic stack buffer (alloca) overflow in ObjC compiler.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80798 --- Comment #1 from Maxim Ostapenko --- Created attachment 41372 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41372&action=edit Trivial fix
[Bug objc/80798] New: Dynamic stack buffer (alloca) overflow in ObjC compiler.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80798 Bug ID: 80798 Summary: Dynamic stack buffer (alloca) overflow in ObjC compiler. Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: objc Assignee: unassigned at gcc dot gnu.org Reporter: m.ostapenko at samsung dot com Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Build: x86_64-pc-linux-gnu Not sure anybody interested, but while testing a patch for ASan alloca/VLA instrumentation, I encountered the following report: $ /home/max/build/master/gcc/xgcc -B/home/max/build/master/gcc/ /home/max/workspace/downloads/gcc/gcc/testsuite/objc.dg/property/synthesize-8.m -fno-diagnostics-show-caret -fdiagnostics-color=never -fgnu-runtime -I/home/max/workspace/downloads/gcc/gcc/testsuite/../../libobjc -B/home/max/build/master/x86_64-unknown-linux-gnu/./libobjc/.libs -L/home/max/build/master/x86_64-unknown-linux-gnu/./libobjc/.libs -S -o synthesize-8.s = ==18068==ERROR: AddressSanitizer: dynamic-stack-buffer-overflow on address 0x7fff1efd5085 at pc 0x00688a0c bp 0x7fff1efd5050 sp 0x7fff1efd4800 WRITE of size 6 at 0x7fff1efd5085 thread T0 #0 0x688a0b in __interceptor_strcpy /home/max/workspace/downloads/gcc/libsanitizer/asan/asan_interceptors.cc:546 #1 0x779b70 in finish_class /home/max/workspace/downloads/gcc/gcc/objc/objc-act.c:8000 #2 0x77d26f in objc_finish_interface() /home/max/workspace/downloads/gcc/gcc/objc/objc-act.c:648 #3 0x9af768 in c_parser_translation_unit /home/max/workspace/downloads/gcc/gcc/c/c-parser.c:1349 #4 0x9af768 in c_parse_file() /home/max/workspace/downloads/gcc/gcc/c/c-parser.c:18103 #5 0xaaece4 in c_common_parse_file() /home/max/workspace/downloads/gcc/gcc/c-family/c-opts.c:1107 #6 0x19dcecb in compile_file /home/max/workspace/downloads/gcc/gcc/toplev.c:467 #7 0x63a6da in do_compile /home/max/workspace/downloads/gcc/gcc/toplev.c:2003 #8 0x63a6da in toplev::main(int, char**) /home/max/workspace/downloads/gcc/gcc/toplev.c:2137 #9 0x644784 in main /home/max/workspace/downloads/gcc/gcc/main.c:39 #10 0x7f6cdadd0f44 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21f44) #11 0x64591d (/home/max/build/master/gcc/cc1obj+0x64591d) Address 0x7fff1efd5085 is located in stack of thread T0 SUMMARY: AddressSanitizer: dynamic-stack-buffer-overflow /home/max/workspace/downloads/gcc/libsanitizer/asan/asan_interceptors.cc:546 in __interceptor_strcpy Shadow bytes around the buggy address: 0x100063df29c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x100063df29d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x100063df29e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x100063df29f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x100063df2a00: 00 00 00 00 00 00 00 00 00 00 00 00 ca ca ca ca =>0x100063df2a10:[05]cb cb cb cb cb cb cb 00 00 00 00 00 00 00 00 0x100063df2a20: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1 0x100063df2a30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f2 0x100063df2a40: f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 0x100063df2a50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 0x100063df2a60: f1 f1 f8 f8 f2 f2 f2 f2 f2 f2 00 00 00 00 00 00 Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user:f7 Container overflow: fc Array cookie:ac Intra object redzone:bb ASan internal: fe Left alloca redzone: ca Right alloca redzone:cb Looking to corresponding code: size_t length = strlen (full_setter_name); char *setter_name = (char *) alloca (length); tree ret_type, selector, arg_type, arg_name; strcpy (setter_name, full_setter_name); // BOOM It seems that author just forgot about terminating '\0', so the fix is trivial.
[Bug sanitizer/80027] ASAN breaks DT_RPATH $ORIGIN in dlopen()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80027 --- Comment #4 from Maxim Ostapenko --- (In reply to Michael Thayer from comment #3) > Seems my mistake. I think the ASAN library was still getting loaded > dynamically. Now I have the following problem, which I think means that > code (constructors?) getting called before ASAN is initialised is getting > hold of memory map areas which ASAN is hard-coded to use. So probably no > static ASAN for me. > > ==10420==Shadow memory range interleaves with an existing memory mapping. > ASan cannot proceed correctly. ABORTING. > ==10420==ASan shadow was supposed to be located in the > [0x7fff7000-0x10007fff7fff] range. > ==10420==Process memory map follows: > 0x7fff7000-0x8fff7000 > 0x8fff7000-0x02008fff7000 > 0x02008fff7000-0x10007fff8000 > [...] This usually happens when your executable isn't linked with libasan but some shared library is. Check that your test binary is properly linked with libasan.
[Bug sanitizer/80027] ASAN breaks DT_RPATH $ORIGIN in dlopen()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80027 Maxim Ostapenko changed: What|Removed |Added CC||m.ostapenko at samsung dot com --- Comment #1 from Maxim Ostapenko --- It seems that the bug is the same as https://bugs.llvm.org//show_bug.cgi?id=27790 so it should be fixed in compiler-rt first. The problem exists only if use shared libasan.so because it clobbers RPATH, static libasan should be fine. I don't know whether there is a general recipe how to deal with this issue, but for now you can try to link ASan runtime statically (via -static-libasan option) or use LD_LIBRARY_PATH.
[Bug sanitizer/78663] [7 Regression] Hundreds of asan failures on x86_64-apple-darwin10 at r243019
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78663 --- Comment #7 from Maxim Ostapenko --- Created attachment 40646 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40646&action=edit Fix 2 Iain, could you test the following patch? This one is likely to be applied upstream. As a side note, LLVM folks are not very happy with these patches (they lack of buildbots to test them). Thus I suspect that for future releases we'll need a) apply Darwin 10 patches locally or b) disable ASan for Darwin 10.
[Bug sanitizer/78663] [7 Regression] Hundreds of asan failures on x86_64-apple-darwin10 at r243019
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78663 --- Comment #6 from Maxim Ostapenko --- (In reply to Maxim Ostapenko from comment #5) > (In reply to Iain Sandoe from comment #4) > > (In reply to Jakub Jelinek from comment #3) > > > Have you raised this with compiler-rt upstream already? > > > > I don't believe that upstream supports the sanitisers for Darwin < 11. > > > > However, as seen, they are quite capable of function with a little TLC. I > > don't have a chance to progress this until at least mid-Feb, if it's more > > urgent, then (a) please adopt some version of the patch locally, or (b) > > disable for Darwin < 11. > > They don't, but they can actually accept the patch for Darwin 10 (I used to > commit such patches after previous merge). > I can post attached fix upstream, but than I'll ask you (or Dominique) for > help in testing if they won't accept the patch as it is (most likely they > won't). I've initiated discussion upstream: https://reviews.llvm.org/D29287
[Bug sanitizer/78663] [7 Regression] Hundreds of asan failures on x86_64-apple-darwin10 at r243019
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78663 Maxim Ostapenko changed: What|Removed |Added CC||m.ostapenko at samsung dot com --- Comment #5 from Maxim Ostapenko --- (In reply to Iain Sandoe from comment #4) > (In reply to Jakub Jelinek from comment #3) > > Have you raised this with compiler-rt upstream already? > > I don't believe that upstream supports the sanitisers for Darwin < 11. > > However, as seen, they are quite capable of function with a little TLC. I > don't have a chance to progress this until at least mid-Feb, if it's more > urgent, then (a) please adopt some version of the patch locally, or (b) > disable for Darwin < 11. They don't, but they can actually accept the patch for Darwin 10 (I used to commit such patches after previous merge). I can post attached fix upstream, but than I'll ask you (or Dominique) for help in testing if they won't accept the patch as it is (most likely they won't).
[Bug lto/79061] [7 Regression][LTO][ASAN] LTO plus ASAN fails with "AddressSanitizer: initialization-order-fiasco"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79061 --- Comment #28 from Maxim Ostapenko --- (In reply to Jakub Jelinek from comment #27) > I think the problem is in the vnode->dynamically_initialized handling, as > well as in get_translation_unit_decl being totally unreliable. > When LTO merges VAR_DECLs from multiple TUs, it either should clear the > dynamically_initialized flag, or should make sure that the decl that is used > for the vnode actually is going to have get_translation_unit_decl the TU > that it contained the definition. > The #c20 testcase has in the end 3 globals: > name = "__ioinit", module_name = 0x400f3c "/tmp/ccoQRMfD.ltrans0.o", > has_dynamic_init = 1 > name = 0x400f5d "xptimer_clean", module_name = 0x400de0 "xptimer.cc", > has_dynamic_init = 1 > name = 0x400f6b "xptimer_sweep", module_name = 0x400de0 "xptimer.cc", > has_dynamic_init = 1 > > xptimer_clean and xptimer_sweep are both defined in xptiming.cc and declared > in xptiming.h, xptimer.cc TU doesn't see any traces of it, yet > get_translation_unit_decl returns for it the xptimer.cc TU, because > DECL_CONTEXT of those 2 vars is a NAMESPACE_DECL and LTO merges > NAMESPACE_DECLs too. > Similarly, __ioinit has DECL_CONTEXT of std namespace and that, being > prebuilt by the compiler, doesn't have surrounding TU. > Even when considering only VAR_DECLs that have DECL_CONTEXT of > TRANSLATION_UNIT_DECL directly, I believe this doesn't work right: > 1) if the VAR_DECL has more than one definition (comdat, inline var, ...?), > then I think we'd need to merge the two definitions with > dynamically_initialized 1 as dynamically_initialized 0 > 2) wonder if we ever merge external decl with decl definition using the > external decl's context > > In short, the easiest fix is just to disable the initialization order > checking altogether for LTO (by forcing dynamically_initialized = 0 in LTO). Yeah, that's what I thought about. Should I revert the whole bunch of related patches or just force vnode->dynamically_initialized = 0 for LTO leaving a comment with link to this PR? > Or at least clear it when merging multiple varpool nodes that have > dynamically_initialized = 1, and otherwise (if there is just one TU with > vnode->dynamically_initialized == 1), make sure get_translation_unit_decl > will return that TU for it and if we can't ensure that, clear > dynamically_initialized too. Which can be done e.g. by clearing it whenever > DECL_CONTEXT actually isn't a TRANSLATION_UNIT_DECL directly or is some > other TU, or by say adding TRANSLATION_UNIT_DECL tree into the vnode (grows > memory usage though!) and looking it up from there.
[Bug lto/79061] [7 Regression][LTO][ASAN] LTO plus ASAN fails with "AddressSanitizer: initialization-order-fiasco"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79061 --- Comment #26 from Maxim Ostapenko --- (In reply to Maxim Ostapenko from comment #24) > (In reply to Tobias Burnus from comment #23) > > (In reply to Tobias Burnus from comment #22) > > > As I recently did some incremental builds, I will retry it after a full > > > bootstrap. > > > > Didn't make a difference - I still see the ASAN run-time fail. I wonder > > what's different between our systems. > > Perhaps you use strict_init_order=true option (e.g. > ASAN_OPTIONS=check_initialization_order=true:report_globals=3: > strict_init_order=true)? > max@max:~/test-lto/test-2/test$ > ASAN_OPTIONS=check_initialization_order=true:report_globals=3: > strict_init_order=true ./a.out > #0 0x41d885 in __asan_register_globals > /home/max/workspace/downloads/gcc/libsanitizer/asan/asan_globals.cc:326 > #1 0x58a3b6 in _GLOBAL__sub_I_00099_1_main.4497 > (/home/max/test-lto/test-2/test/a.out+0x58a3b6) > #2 0x58a40c in __libc_csu_init > (/home/max/test-lto/test-2/test/a.out+0x58a40c) > #3 0x7fb4c6568ed4 in __libc_start_main > (/lib/x86_64-linux-gnu/libc.so.6+0x21ed4) > #4 0x405f38 (/home/max/test-lto/test-2/test/a.out+0x405f38) > > === ID 1015021569; 0x007c7f60 0x007c8120 > ==26120==Added Global[0x007c7f60]: beg=0x005a5960 size=1/64 > name=piecewise_construct module=/tmp/ccS8KlYh.ltrans0.o dyn_init=0 > ==26120== location (0x007c7f20): > name=/home/max/install/master/include/c++/7.0.1/bits/stl_pair. > h[0x005a5aa0], 79 35 > ==26120==Added Global[0x007c7fa0]: beg=0x0142cf20 size=1/64 > name=__ioinit module=/tmp/ccS8KlYh.ltrans0.o dyn_init=1 > ==26120== location (0x007c7f30): > name=/home/max/install/master/include/c++/7.0.1/iostream[0x005a5ae0], 74 > 25 > ==26120==Added Global[0x007c7fe0]: beg=0x0142cfa0 size=16/64 > name=xptimer_clean module=xptimer.cc dyn_init=1 > ==26120== location (0x007c7f40): name=xptiming.cc[0x005a59e0], 7 9 > ==26120==Added Global[0x007c8020]: beg=0x0142cf60 size=16/64 > name=xptimer_sweep module=xptimer.cc dyn_init=1 > ==26120== location (0x007c7f50): name=xptiming.cc[0x005a59e0], 6 9 > ==26120==Added Global[0x007c8060]: beg=0x005a5a60 size=14/64 > name=*.LC3 module=/tmp/ccS8KlYh.ltrans0.o dyn_init=0 > ==26120==Added Global[0x007c80a0]: beg=0x005a59e0 size=12/64 > name=*.LC1 module=/tmp/ccS8KlYh.ltrans0.o dyn_init=0 > ==26120==Added Global[0x007c80e0]: beg=0x005a59a0 size=11/64 > name=*.LC0 module=/tmp/ccS8KlYh.ltrans0.o dyn_init=0 > ==26120==Added Global[0x007c8120]: beg=0x005a5a20 size=14/64 > name=*.LC2 module=/tmp/ccS8KlYh.ltrans0.o dyn_init=0 > DynInitPoison module: xptimer.cc > DynInitPoison module: xptiming.cc > = > ==26120==Search Global[0x007c8120]: beg=0x005a5a20 size=14/64 > name=*.LC2 module=/tmp/ccS8KlYh.ltrans0.o dyn_init=0 > ==26120==Search Global[0x007c80e0]: beg=0x005a59a0 size=11/64 > name=*.LC0 module=/tmp/ccS8KlYh.ltrans0.o dyn_init=0 > ==26120==Search Global[0x007c80a0]: beg=0x005a59e0 size=12/64 > name=*.LC1 module=/tmp/ccS8KlYh.ltrans0.o dyn_init=0 > ==26120==Search Global[0x007c8060]: beg=0x005a5a60 size=14/64 > name=*.LC3 module=/tmp/ccS8KlYh.ltrans0.o dyn_init=0 > ==26120==Search Global[0x007c8020]: beg=0x0142cf60 size=16/64 > name=xptimer_sweep module=xptimer.cc dyn_init=1 > ==26120== location (0x007c7f50): name=xptiming.cc[0x005a59e0], 6 9 > ==26120==Search Global[0x007c7fe0]: beg=0x0142cfa0 size=16/64 > name=xptimer_clean module=xptimer.cc dyn_init=1 > ==26120== location (0x007c7f40): name=xptiming.cc[0x005a59e0], 7 9 > ==26120==Search Global[0x007c7fa0]: beg=0x0142cf20 size=1/64 > name=__ioinit module=/tmp/ccS8KlYh.ltrans0.o dyn_init=1 > ==26120== location (0x007c7f30): > name=/home/max/install/master/include/c++/7.0.1/iostream[0x005a5ae0], 74 > 25 > ==26120==Search Global[0x007c7f60]: beg=0x005a5960 size=1/64 > name=piecewise_construct module=/tmp/ccS8KlYh.ltrans0.o dyn_init=0 > ==26120== location (0x007c7f20): > name=/home/max/install/master/include/c++/7.0.1/bits/stl_pair. > h[0x005a5aa0], 79 35 > ==26120==ERROR: AddressSanitizer: initialization-order-fiasco on address > 0x0142cf68 at pc 0x0058a25c bp 0x7ffc44459250 sp 0x7ffc44459230 > WRITE of size 1 at 0x0142cf68 thread T0 > #0 0x58a25b in __base_ctor /home/max/test-lto/test-2/test/xptimer.cc:12 > #1 0x58a349 in __static_initialization_and_destruction_0 > /home/max/test-lto/test-2/test/xptiming.cc:6 > #2 0x58a377 in _GLOBAL__sub_I__ZN6xp_aux13xptimer_sweepE > /home/max/test-lto/test-2/test/xptiming.cc:9 > #3 0x58a40c in __libc_csu_init > (/home/max/test-lto/test-2/test/a.out+0x58a40c) > #4 0x7fb4c6568ed4 in __libc_start_main > (/lib/x86_64-linux-gnu/libc.so.6+0x21ed4) > #5 0x405f38 (/home/max/test-lto/test-2/test/a.out+0x405f38) > > 0x
[Bug lto/79061] [7 Regression][LTO][ASAN] LTO plus ASAN fails with "AddressSanitizer: initialization-order-fiasco"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79061 --- Comment #24 from Maxim Ostapenko --- (In reply to Tobias Burnus from comment #23) > (In reply to Tobias Burnus from comment #22) > > As I recently did some incremental builds, I will retry it after a full > > bootstrap. > > Didn't make a difference - I still see the ASAN run-time fail. I wonder > what's different between our systems. Perhaps you use strict_init_order=true option (e.g. ASAN_OPTIONS=check_initialization_order=true:report_globals=3:strict_init_order=true)? max@max:~/test-lto/test-2/test$ ASAN_OPTIONS=check_initialization_order=true:report_globals=3:strict_init_order=true ./a.out #0 0x41d885 in __asan_register_globals /home/max/workspace/downloads/gcc/libsanitizer/asan/asan_globals.cc:326 #1 0x58a3b6 in _GLOBAL__sub_I_00099_1_main.4497 (/home/max/test-lto/test-2/test/a.out+0x58a3b6) #2 0x58a40c in __libc_csu_init (/home/max/test-lto/test-2/test/a.out+0x58a40c) #3 0x7fb4c6568ed4 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21ed4) #4 0x405f38 (/home/max/test-lto/test-2/test/a.out+0x405f38) === ID 1015021569; 0x007c7f60 0x007c8120 ==26120==Added Global[0x007c7f60]: beg=0x005a5960 size=1/64 name=piecewise_construct module=/tmp/ccS8KlYh.ltrans0.o dyn_init=0 ==26120== location (0x007c7f20): name=/home/max/install/master/include/c++/7.0.1/bits/stl_pair.h[0x005a5aa0], 79 35 ==26120==Added Global[0x007c7fa0]: beg=0x0142cf20 size=1/64 name=__ioinit module=/tmp/ccS8KlYh.ltrans0.o dyn_init=1 ==26120== location (0x007c7f30): name=/home/max/install/master/include/c++/7.0.1/iostream[0x005a5ae0], 74 25 ==26120==Added Global[0x007c7fe0]: beg=0x0142cfa0 size=16/64 name=xptimer_clean module=xptimer.cc dyn_init=1 ==26120== location (0x007c7f40): name=xptiming.cc[0x005a59e0], 7 9 ==26120==Added Global[0x007c8020]: beg=0x0142cf60 size=16/64 name=xptimer_sweep module=xptimer.cc dyn_init=1 ==26120== location (0x007c7f50): name=xptiming.cc[0x005a59e0], 6 9 ==26120==Added Global[0x007c8060]: beg=0x005a5a60 size=14/64 name=*.LC3 module=/tmp/ccS8KlYh.ltrans0.o dyn_init=0 ==26120==Added Global[0x007c80a0]: beg=0x005a59e0 size=12/64 name=*.LC1 module=/tmp/ccS8KlYh.ltrans0.o dyn_init=0 ==26120==Added Global[0x007c80e0]: beg=0x005a59a0 size=11/64 name=*.LC0 module=/tmp/ccS8KlYh.ltrans0.o dyn_init=0 ==26120==Added Global[0x007c8120]: beg=0x005a5a20 size=14/64 name=*.LC2 module=/tmp/ccS8KlYh.ltrans0.o dyn_init=0 DynInitPoison module: xptimer.cc DynInitPoison module: xptiming.cc = ==26120==Search Global[0x007c8120]: beg=0x005a5a20 size=14/64 name=*.LC2 module=/tmp/ccS8KlYh.ltrans0.o dyn_init=0 ==26120==Search Global[0x007c80e0]: beg=0x005a59a0 size=11/64 name=*.LC0 module=/tmp/ccS8KlYh.ltrans0.o dyn_init=0 ==26120==Search Global[0x007c80a0]: beg=0x005a59e0 size=12/64 name=*.LC1 module=/tmp/ccS8KlYh.ltrans0.o dyn_init=0 ==26120==Search Global[0x007c8060]: beg=0x005a5a60 size=14/64 name=*.LC3 module=/tmp/ccS8KlYh.ltrans0.o dyn_init=0 ==26120==Search Global[0x007c8020]: beg=0x0142cf60 size=16/64 name=xptimer_sweep module=xptimer.cc dyn_init=1 ==26120== location (0x007c7f50): name=xptiming.cc[0x005a59e0], 6 9 ==26120==Search Global[0x007c7fe0]: beg=0x0142cfa0 size=16/64 name=xptimer_clean module=xptimer.cc dyn_init=1 ==26120== location (0x007c7f40): name=xptiming.cc[0x005a59e0], 7 9 ==26120==Search Global[0x007c7fa0]: beg=0x0142cf20 size=1/64 name=__ioinit module=/tmp/ccS8KlYh.ltrans0.o dyn_init=1 ==26120== location (0x007c7f30): name=/home/max/install/master/include/c++/7.0.1/iostream[0x005a5ae0], 74 25 ==26120==Search Global[0x007c7f60]: beg=0x005a5960 size=1/64 name=piecewise_construct module=/tmp/ccS8KlYh.ltrans0.o dyn_init=0 ==26120== location (0x007c7f20): name=/home/max/install/master/include/c++/7.0.1/bits/stl_pair.h[0x005a5aa0], 79 35 ==26120==ERROR: AddressSanitizer: initialization-order-fiasco on address 0x0142cf68 at pc 0x0058a25c bp 0x7ffc44459250 sp 0x7ffc44459230 WRITE of size 1 at 0x0142cf68 thread T0 #0 0x58a25b in __base_ctor /home/max/test-lto/test-2/test/xptimer.cc:12 #1 0x58a349 in __static_initialization_and_destruction_0 /home/max/test-lto/test-2/test/xptiming.cc:6 #2 0x58a377 in _GLOBAL__sub_I__ZN6xp_aux13xptimer_sweepE /home/max/test-lto/test-2/test/xptiming.cc:9 #3 0x58a40c in __libc_csu_init (/home/max/test-lto/test-2/test/a.out+0x58a40c) #4 0x7fb4c6568ed4 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21ed4) #5 0x405f38 (/home/max/test-lto/test-2/test/a.out+0x405f38) 0x0142cf68 is located 8 bytes inside of global variable 'xptimer_sweep' defined in 'xptiming.cc:6:9' (0x142cf60) of size 16 registered at: #0 0x41d62c in __asan_register_globals /home/max/workspace/downloads/gcc/libsanitizer
[Bug lto/79061] [7 Regression][LTO][ASAN] LTO plus ASAN fails with "AddressSanitizer: initialization-order-fiasco"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79061 --- Comment #21 from Maxim Ostapenko --- (In reply to Tobias Burnus from comment #20) > Created attachment 40574 [details] > New still failing test case (tar.gz), slightly modifying the previous one > > (In reply to chefmax from comment #19) > > New Revision: 244890 > > I can confirm that the attached test case [attachment 40504 [details]] is > fixed with that commit. > > Unfortunately, for the big test case, it still fails with > > AddressSanitizer: initialization-order-fiasco > > New test case attached; the crucial difference (cf. xptimer.cc) seems to be > that the code calls strdup() and, hence, allocates memory in the constructor. Strange, new testcase (with strdup) doesn't fail for me: /home/max/install/master/bin/g++ -g -O0 -flto -fsanitize=address xptimer.cc xptiming.cc test.cc -static-libasan ASAN_OPTIONS=check_initialization_order=true ./a.out max@max:~/test-lto/test-2/test$ ASAN_OPTIONS=check_initialization_order=true ./a.out max@max:~/test-lto/test-2/test$ echo $? 0
[Bug fortran/79165] 100% compile-time increase for polyhedron aermod by r244581
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79165 Maxim Ostapenko changed: What|Removed |Added CC||m.ostapenko at samsung dot com --- Comment #15 from Maxim Ostapenko --- (In reply to David Malcolm from comment #13) > What's the purpose of the linemap_add call at line 4761? I used this to add a source location for TRANSLATION_UNIT_DECL as was discussed in pr79061. Dunno, maybe, I've reverted my patch for pr79061 so this change isn't present anymore. As Richard pointed out in related mail it would be better to do something like this: +tree tu = build_decl (UNKNOWN_LOCATION, TRANSLATION_UNIT_DECL, - name, NULL_TREE); + get_identifier (main_input_filename), + NULL_TREE); and use DECL_NAME (translation_unit_decl) later instead of creating new source location.
[Bug lto/79061] [7 Regression][LTO][ASAN] LTO plus ASAN fails with "AddressSanitizer: initialization-order-fiasco"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79061 --- Comment #14 from Maxim Ostapenko --- (In reply to Richard Biener from comment #13) > (In reply to Maxim Ostapenko from comment #12) > > Created attachment 40525 [details] > > Untested fix 2. > > > > The patch I'm testing now. > > DECL_SOURCE_LOCATION is streamed for all decls already: > > if (CODE_CONTAINS_STRUCT (code, TS_DECL_MINIMAL)) > stream_output_location (ob, &bp, DECL_SOURCE_LOCATION (expr)); Aha, right, thank you. But it seems that stream_output_location fails to find it in the location cache that's probably caused by this line in lto.c: /* We have the special case of size-1 SCCs that are pre-merged by means of identifier and string sharing for example. ??? Maybe we should avoid streaming those as SCCs. */ tree first = streamer_tree_cache_get_tree (data_in->reader_cache, from); if (len == 1 && (TREE_CODE (first) == IDENTIFIER_NODE || TREE_CODE (first) == INTEGER_CST || TREE_CODE (first) == TRANSLATION_UNIT_DECL)) continue; that prohibits /* Tree merging failed, mark entries in location cache as permanent. */ data_in->location_cache.accept_location_cache (); several lines below. Perhaps we can just remove TREE_CODE (first) == TRANSLATION_UNIT_DECL from the condition?
[Bug lto/79061] [7 Regression][LTO][ASAN] LTO plus ASAN fails with "AddressSanitizer: initialization-order-fiasco"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79061 Maxim Ostapenko changed: What|Removed |Added Attachment #40514|0 |1 is obsolete|| --- Comment #12 from Maxim Ostapenko --- Created attachment 40525 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40525&action=edit Untested fix 2. The patch I'm testing now.
[Bug lto/79061] [7 Regression][LTO][ASAN] LTO plus ASAN fails with "AddressSanitizer: initialization-order-fiasco"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79061
--- Comment #11 from Maxim Ostapenko ---
(In reply to Maxim Ostapenko from comment #10)
> Yeah, but it seems that lto doesn't propagate source location either:
>
> /* Output info about new location into bitpack BP.
>After outputting bitpack, lto_output_location_data has
>to be done to output actual data. */
>
> void
> lto_output_location (struct output_block *ob, struct bitpack_d *bp,
> location_t loc)
> {
> expanded_location xloc;
>
> loc = LOCATION_LOCUS (loc);
> bp_pack_int_in_range (bp, 0, RESERVED_LOCATION_COUNT,
> loc < RESERVED_LOCATION_COUNT
> ? loc : RESERVED_LOCATION_COUNT);
> if (loc < RESERVED_LOCATION_COUNT)
> return;
>
> [...]
> }
>
> where RESERVED_LOCATION_COUNT == 2. Or maybe I missed something?
> We can probably teach it to propagate source location but is it OK for
> current stage?
Hm, attached patch seems to propagate source location normally:
diff --git a/gcc/tree-streamer-in.c b/gcc/tree-streamer-in.c
index 3496df5..714a5b1 100644
--- a/gcc/tree-streamer-in.c
+++ b/gcc/tree-streamer-in.c
@@ -405,6 +405,7 @@ unpack_ts_translation_unit_decl_value_fields (struct
data_in *data_in,
struct bitpack_d *bp, tree expr)
{
TRANSLATION_UNIT_LANGUAGE (expr) = xstrdup (bp_unpack_string (data_in, bp));
+ DECL_SOURCE_LOCATION (expr) = stream_input_location_now (bp, data_in);
vec_safe_push (all_translation_units, expr);
}
diff --git a/gcc/tree-streamer-out.c b/gcc/tree-streamer-out.c
index 0ee2abe..3c11d61 100644
--- a/gcc/tree-streamer-out.c
+++ b/gcc/tree-streamer-out.c
@@ -359,6 +359,7 @@ pack_ts_translation_unit_decl_value_fields (struct
output_block *ob,
struct bitpack_d *bp, tree expr)
{
bp_pack_string (ob, bp, TRANSLATION_UNIT_LANGUAGE (expr), true);
+ stream_output_location (ob, bp, DECL_SOURCE_LOCATION (expr));
}
diff --git a/gcc/tree.c b/gcc/tree.c
index cffa36d..ee611e2 100644
--- a/gcc/tree.c
+++ b/gcc/tree.c
@@ -4758,7 +4758,9 @@ vec *all_translation_units;
tree
build_translation_unit_decl (tree name)
{
- tree tu = build_decl (UNKNOWN_LOCATION, TRANSLATION_UNIT_DECL,
+ linemap_add (line_table, LC_ENTER, false, main_input_filename, 1);
+ location_t loc = linemap_line_start (line_table, 1, 0);
+ tree tu = build_decl (loc, TRANSLATION_UNIT_DECL,
name, NULL_TREE);
TRANSLATION_UNIT_LANGUAGE (tu) = lang_hooks.name;
vec_safe_push (all_translation_units, tu);
The only issue is failing diagnostic test now:
/home/max/workspace/downloads/gcc/gcc/diagnostic.c:1557:
test_print_parseable_fixits_insert: FAIL: ASSERT_STREQ
("fix-it:\"test.c\":{5:10-5:10}:\"added content\"\n", pp_formatted_text (&pp))
expected="fix-it:"test.c":{5:10-5:10}:"added content"
" actual="fix-it:"/dev/null":{33:10-33:10}:"added content"
"
[Bug lto/79061] [7 Regression][LTO][ASAN] LTO plus ASAN fails with "AddressSanitizer: initialization-order-fiasco"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79061
--- Comment #10 from Maxim Ostapenko ---
Yeah, but it seems that lto doesn't propagate source location either:
/* Output info about new location into bitpack BP.
After outputting bitpack, lto_output_location_data has
to be done to output actual data. */
void
lto_output_location (struct output_block *ob, struct bitpack_d *bp,
location_t loc)
{
expanded_location xloc;
loc = LOCATION_LOCUS (loc);
bp_pack_int_in_range (bp, 0, RESERVED_LOCATION_COUNT,
loc < RESERVED_LOCATION_COUNT
? loc : RESERVED_LOCATION_COUNT);
if (loc < RESERVED_LOCATION_COUNT)
return;
[...]
}
where RESERVED_LOCATION_COUNT == 2. Or maybe I missed something?
We can probably teach it to propagate source location but is it OK for current
stage?
[Bug lto/79061] [7 Regression][LTO][ASAN] LTO plus ASAN fails with "AddressSanitizer: initialization-order-fiasco"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79061
--- Comment #8 from Maxim Ostapenko ---
(In reply to Jakub Jelinek from comment #7)
> Comment on attachment 40514 [details]
> Untested fix 1.
>
> But DECL_SOURCE_FILE is not the main input file of the TU that contains it,
> if e.g. a variable is defined in a header.
> Can't you find the corresponding TRANSLATION_UNIT_DECL (see e.g. how
> dwarf2out.c is_cxx now looks for that) and get the name from that?
> And, the multiple ?s look just weird, (in_lto_p && something ? something :
> main_input_filename); would be nicer.
Yes, but with following helper (extracted from is_cxx) I get DECL_NAME
(translation_unit_decl) == NULL:
static const_tree
get_translation_unit_decl (tree decl)
{
const_tree context = decl;
while (context && TREE_CODE (context) != TRANSLATION_UNIT_DECL)
{
if (TREE_CODE (context) == BLOCK)
context = BLOCK_SUPERCONTEXT (context);
else
context = get_containing_scope (context);
}
return context;
}
and from gdb:
Breakpoint 1, asan_add_global (decl=0x77ff7f30, type=0x7658df18,
v=0x7659d2d0) at /home/max/workspace/downloads/gcc/gcc/asan.c:2410
2410 const_tree translation_unit_decl = get_translation_unit_decl (decl);
(gdb) n
2411 if (translation_unit_decl)
(gdb) call debug_tree(translation_unit_decl)
(gdb)
[Bug lto/79061] [7 Regression][LTO][ASAN] LTO plus ASAN fails with "AddressSanitizer: initialization-order-fiasco"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79061 --- Comment #6 from Maxim Ostapenko --- Created attachment 40514 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40514&action=edit Untested fix 1. The fix I'm testing now. With this patch trivial example works and attached testcase doesn't raise false alarm. Does this approach look sane?
[Bug lto/79061] [7 Regression][LTO][ASAN] LTO plus ASAN fails with "AddressSanitizer: initialization-order-fiasco"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79061 Maxim Ostapenko changed: What|Removed |Added CC||m.ostapenko at samsung dot com --- Comment #4 from Maxim Ostapenko --- (In reply to Tobias Burnus from comment #3) > (In reply to Richard Biener from comment #2) > > Is this after the fix for PR79042? > > I am nearly certain that it was after that fix. > > Before, I got an UBSAN overflow but only when combining OpenMP, LTO, > -fipa-cp-clone and UBSAN, which I had hoped PR78365 and PR78599 would fix. > (It didn't.) > > Shortly after, I saw the commit for PR79042, tried whether it made a > difference - and ended up with this bug. > > [Sorry for not narrowing the regression range in the initial report. (I > somehow failed to realize that this ASAN message comes way before the UBSAN > error can be triggered.)] You have ASAN_OPTIONS=check_initialization_order=true exported on your system, right? (because w/o this option initialization-order-fiasco checker is disabled) Here a more detailed ASan log: $ ASAN_OPTIONS=check_initialization_order=true:report_globals=3 ./a.out #0 0x41a29b in __asan_register_globals /home/max/workspace/downloads/gcc/libsanitizer/asan/asan_globals.cc:326 #1 0x4f608f in _GLOBAL__sub_I_00099_1_main.4474 (/tmp/test/a.out+0x4f608f) #2 0x4f60ec in __libc_csu_init (/tmp/test/a.out+0x4f60ec) #3 0x7f9f12efaed4 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21ed4) #4 0x405feb (/tmp/test/a.out+0x405feb) === ID 1140850689; 0x0072ce40 0x0072d000 ==29614==Added Global[0x0072ce40]: beg=0x0050bee0 size=1/64 name=piecewise_construct module=/tmp/ccdXK8GX.ltrans0.o dyn_init=0 ==29614== location (0x0072ce00): name=/home/max/install/master/include/c++/7.0.0/bits/stl_pair.h[0x0050c020], 79 35 ==29614==Added Global[0x0072ce80]: beg=0x01391e20 size=1/64 name=__ioinit module=/tmp/ccdXK8GX.ltrans0.o dyn_init=1 ==29614== location (0x0072ce10): name=/home/max/install/master/include/c++/7.0.0/iostream[0x0050c060], 74 25 ==29614==Added Global[0x0072cec0]: beg=0x01391ea0 size=2/64 name=xptimer_coordinit module=/tmp/ccdXK8GX.ltrans0.o dyn_init=1 ==29614== location (0x0072ce20): name=xptiming.cc[0x0050bf60], 5 9 ==29614==Added Global[0x0072cf00]: beg=0x01391e60 size=2/64 name=xptimer_tiling module=/tmp/ccdXK8GX.ltrans0.o dyn_init=1 ==29614== location (0x0072ce30): name=xptiming.cc[0x0050bf60], 4 9 ==29614==Added Global[0x0072cf40]: beg=0x0050bfe0 size=18/64 name=*.LC3 module=/tmp/ccdXK8GX.ltrans0.o dyn_init=0 ==29614==Added Global[0x0072cf80]: beg=0x0050bf60 size=12/64 name=*.LC1 module=/tmp/ccdXK8GX.ltrans0.o dyn_init=0 ==29614==Added Global[0x0072cfc0]: beg=0x0050bfa0 size=15/64 name=*.LC2 module=/tmp/ccdXK8GX.ltrans0.o dyn_init=0 ==29614==Added Global[0x0072d000]: beg=0x0050bf20 size=11/64 name=*.LC0 module=/tmp/ccdXK8GX.ltrans0.o dyn_init=0 DynInitPoison module: xptimer.cc DynInitPoison module: xptiming.cc = ==29614==Search Global[0x0072d000]: beg=0x0050bf20 size=11/64 name=*.LC0 module=/tmp/ccdXK8GX.ltrans0.o dyn_init=0 ==29614==Search Global[0x0072cfc0]: beg=0x0050bfa0 size=15/64 name=*.LC2 module=/tmp/ccdXK8GX.ltrans0.o dyn_init=0 ==29614==Search Global[0x0072cf80]: beg=0x0050bf60 size=12/64 name=*.LC1 module=/tmp/ccdXK8GX.ltrans0.o dyn_init=0 ==29614==Search Global[0x0072cf40]: beg=0x0050bfe0 size=18/64 name=*.LC3 module=/tmp/ccdXK8GX.ltrans0.o dyn_init=0 ==29614==Search Global[0x0072cf00]: beg=0x01391e60 size=2/64 name=xptimer_tiling module=/tmp/ccdXK8GX.ltrans0.o dyn_init=1 ==29614== location (0x0072ce30): name=xptiming.cc[0x0050bf60], 4 9 ==29614==Search Global[0x0072cec0]: beg=0x01391ea0 size=2/64 name=xptimer_coordinit module=/tmp/ccdXK8GX.ltrans0.o dyn_init=1 ==29614== location (0x0072ce20): name=xptiming.cc[0x0050bf60], 5 9 ==29614==Search Global[0x0072ce80]: beg=0x01391e20 size=1/64 name=__ioinit module=/tmp/ccdXK8GX.ltrans0.o dyn_init=1 ==29614== location (0x0072ce10): name=/home/max/install/master/include/c++/7.0.0/iostream[0x0050c060], 74 25 ==29614==Search Global[0x0072ce40]: beg=0x0050bee0 size=1/64 name=piecewise_construct module=/tmp/ccdXK8GX.ltrans0.o dyn_init=0 ==29614== location (0x0072ce00): name=/home/max/install/master/include/c++/7.0.0/bits/stl_pair.h[0x0050c020], 79 35 ==29614==ERROR: AddressSanitizer: initialization-order-fiasco on address 0x01391e60 at pc 0x004f5ea9 bp 0x7ffcf3920920 sp 0x7ffcf3920918 WRITE of size 1 at 0x01391e60 thread T0 #0 0x4f5ea8 in __base_ctor /tmp/test/xptimer.cc:9 #1 0x4f602d in __static_initialization_and_des
[Bug lto/79042] LTO doesn't propagate node->dynamically_initialized bit for varpool nodes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79042 Maxim Ostapenko changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Maxim Ostapenko --- Fixed.
[Bug lto/79042] New: LTO doesn't propagate node->dynamically_initialized bit for varpool nodes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79042
Bug ID: 79042
Summary: LTO doesn't propagate node->dynamically_initialized
bit for varpool nodes.
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: m.ostapenko at samsung dot com
Target Milestone: ---
Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu
Build: x86_64-pc-linux-gnu
Created attachment 40490
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40490&action=edit
Trivial fix
Consider following testcase:
$ cat test.cc
class A {
public:
A () : x_(0) {};
private:
int x_;
};
static A a;
int main () {
return 0;
}
Running this with ASan and LTO gives us:
$ ~/install/master/bin/g++ -fsanitize=address test.cc -static-libasan -flto
$ ASAN_OPTIONS=report_globals=3 ./a.out
#0 0x41d7b6 in __asan_register_globals
/home/max/workspace/downloads/gcc/libsanitizer/asan/asan_globals.cc:326
#1 0x58a186 in _GLOBAL__sub_I_00099_1_main.4327
(/tmp/usr/apps/ise-default/mobile/bin/a.out+0x58a186)
#2 0x58a1dc in __libc_csu_init
(/tmp/usr/apps/ise-default/mobile/bin/a.out+0x58a1dc)
#3 0x7f16b2316ed4 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x21ed4)
#4 0x405e68 (/tmp/usr/apps/ise-default/mobile/bin/a.out+0x405e68)
=== ID 1098907649; 0x007c6f40 0x007c6f80
==16281==Added Global[0x007c6f40]: beg=0x0142bd60 size=4/64 name=a
module=/tmp/ccQdsNjQ.ltrans0.o dyn_init=0
The dyn_init field should be equal to 1 (we have a global constructor), as we
can confirm running the testcase without LTO:
$ ~/install/master/bin/g++ -fsanitize=address test.cc -static-libasan
$ ASAN_OPTIONS=report_globals=3 ./a.out
#0 0x41d7b6 in __asan_register_globals
/home/max/workspace/downloads/gcc/libsanitizer/asan/asan_globals.cc:326
#1 0x58a138 in _GLOBAL__sub_I_00099_1_main
(/tmp/usr/apps/ise-default/mobile/bin/a.out+0x58a138)
#2 0x58a1dc in __libc_csu_init
(/tmp/usr/apps/ise-default/mobile/bin/a.out+0x58a1dc)
#3 0x7f9cdad24ed4 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x21ed4)
#4 0x405e68 (/tmp/usr/apps/ise-default/mobile/bin/a.out+0x405e68)
=== ID 385875969; 0x007c6f40 0x007c6f40
==16302==Added Global[0x007c6f40]: beg=0x0142bd20 size=4/64 name=a
module=test.cc dyn_init=1
This happens because LTO doesn't propagate node->dynamically_initialized to
LTRANS stage.
The trivial fix (untested) is attached.
[Bug sanitizer/78532] [7 Regression] libsanitizer fails to build on sparc64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78532 --- Comment #7 from Maxim Ostapenko --- Created attachment 40197 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40197&action=edit Fix Right. Attached patch fixes build error (perhaps all sparc stuff should go upstream, because I think we already have too many local fixes?).
[Bug sanitizer/78532] [7 Regression] libsanitizer fails to build on sparc64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78532 --- Comment #6 from Maxim Ostapenko --- (In reply to jos...@codesourcery.com from comment #5) > On Tue, 29 Nov 2016, m.ostapenko at samsung dot com wrote: > > > /home/max/src/glibc/resolv/ns_print.c:99: undefined reference to > > `__stack_chk_guard' > > You get this if glibc and GCC have mismatched stack checking > configuration. To avoid that, use the --with-glibc-version= > option when configuring a bootstrap GCC to be used to build glibc. > > Mainline glibc's build-many-glibcs.py knows how to configure GCC and glibc > for building many different configurations. It uses > --disable-libsanitizer, but if libsanitizer is meant to work for all glibc > configurations you could try removing it (adding it back for the initial > bootstrap GCC only) and seeing what libsanitizer problems it shows up. Joseph, thank you for clarification. Anyway, the failure is confirmed. I suspect it was caused by this commit in Glibc: ommit a059d359d86130b5fa74e04a978c8523a0293f77 Author: David S. Miller Date: Tue Apr 22 17:47:12 2014 -0700 Fix sigaction conform test failures on sparc. * sysdeps/unix/sysv/linux/sparc/bits/sigaction.h (struct sigaction): New struct member __glibc_reserved0, change type of sa_flags to int. diff --git a/ChangeLog b/ChangeLog index c3fa6e5..9319a31 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,9 @@ +2014-04-22 David S. Miller + + * sysdeps/unix/sysv/linux/sparc/bits/sigaction.h + (struct sigaction): New struct member __glibc_reserved0, change + type of sa_flags to int. + 2014-04-22 Yufeng Zhang * stdlib/longlong.h (count_leading_zeros, count_trailing_zeros) diff --git a/sysdeps/unix/sysv/linux/sparc/bits/sigaction.h b/sysdeps/unix/sysv/linux/sparc/bits/sigaction.h index eaccf97..7a0ca7e 100644 --- a/sysdeps/unix/sysv/linux/sparc/bits/sigaction.h +++ b/sysdeps/unix/sysv/linux/sparc/bits/sigaction.h @@ -43,7 +43,8 @@ struct sigaction __sigset_t sa_mask; /* Special flags. */ -unsigned long sa_flags; +int __glibc_reserved0; +int sa_flags; /* Not used by Linux/Sparc yet. */ void (*sa_restorer) (void); First Glibc release I see the patch in is 2.20.
[Bug sanitizer/78532] [7 Regression] libsanitizer fails to build on sparc64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78532 --- Comment #3 from Maxim Ostapenko --- (In reply to Matthias Klose from comment #2) > glibc 2.24 and linux 4.8.7. Could you also share how you configure Glibc? Do you use native or cross build? I'm asking because Glibc 2.24 fails to build for me with: sparc64-linux-gcc -shared -static-libgcc -Wl,-O1 -Wl,-z,defs -Wl,-dynamic-linker=/opt/cross/sparc//sparc64-linux/lib/ld-linux.so.2 -B/home/max/build/sparc/glibc/csu/ -Wl,--version-script=/home/max/build/sparc/glibc/libresolv.map -Wl,-soname=libresolv.so.2 -Wl,-z,combreloc -Wl,-z,relro -Wl,--hash-style=both -L/home/max/build/sparc/glibc -L/home/max/build/sparc/glibc/math -L/home/max/build/sparc/glibc/elf -L/home/max/build/sparc/glibc/dlfcn -L/home/max/build/sparc/glibc/nss -L/home/max/build/sparc/glibc/nis -L/home/max/build/sparc/glibc/rt -L/home/max/build/sparc/glibc/resolv -L/home/max/build/sparc/glibc/crypt -L/home/max/build/sparc/glibc/mathvec -L/home/max/build/sparc/glibc/nptl -Wl,-rpath-link=/home/max/build/sparc/glibc:/home/max/build/sparc/glibc/math:/home/max/build/sparc/glibc/elf:/home/max/build/sparc/glibc/dlfcn:/home/max/build/sparc/glibc/nss:/home/max/build/sparc/glibc/nis:/home/max/build/sparc/glibc/rt:/home/max/build/sparc/glibc/resolv:/home/max/build/sparc/glibc/crypt:/home/max/build/sparc/glibc/mathvec:/home/max/build/sparc/glibc/nptl -o /home/max/build/sparc/glibc/resolv/libresolv.so -T /home/max/build/sparc/glibc/shlib.lds /home/max/build/sparc/glibc/csu/abi-note.o -Wl,--whole-archive /home/max/build/sparc/glibc/resolv/libresolv_pic.a -Wl,--no-whole-archive -Wl,--start-group /home/max/build/sparc/glibc/libc.so /home/max/build/sparc/glibc/libc_nonshared.a -Wl,--as-needed /home/max/build/sparc/glibc/elf/ld.so -Wl,--no-as-needed -Wl,--end-group /home/max/build/sparc/glibc/resolv/libresolv_pic.a(ns_print.os): In function `__GI_ns_sprintrrf': /home/max/src/glibc/resolv/ns_print.c:99: undefined reference to `__stack_chk_guard' /home/max/src/glibc/resolv/ns_print.c:99: undefined reference to `__stack_chk_guard' /home/max/src/glibc/resolv/ns_print.c:99: undefined reference to `__stack_chk_guard' /home/max/src/glibc/resolv/ns_print.c:728: undefined reference to `__stack_chk_guard' /home/max/src/glibc/resolv/ns_print.c:728: undefined reference to `__stack_chk_guard'
[Bug sanitizer/78532] [7 Regression] libsanitizer fails to build on sparc64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78532 Maxim Ostapenko changed: What|Removed |Added CC||m.ostapenko at samsung dot com --- Comment #1 from Maxim Ostapenko --- Could you provide more details: Glibc and kernel headers version?
[Bug sanitizer/78307] [7 Regression] missing symbols in libubsan without changing the soname
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78307 --- Comment #9 from Maxim Ostapenko --- Can we close this?
[Bug sanitizer/78267] [7 Regression] libsanitizer breaks bootstrap on x86_64-apple-darwin16 at r241977
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78267 --- Comment #47 from Maxim Ostapenko --- (In reply to r...@cebitec.uni-bielefeld.de from comment #45) > > --- Comment #44 from Maxim Ostapenko --- > [...] > >> Otherwise the definition of SANITIZER_OS_TRACE results in > >> libsanitizer/sanitizer_common/sanitizer_mac.cc making calls to os_trace(). > > > > This is probably insufficient, we would have errors with /usr/include/asl.h > > (see comment #10 for error messages) on darwin16. Shouldn't we ifdef out asl > > stuff too in this case? > > That's one option. Another would be to keep the > darwin_availabilityinternal part of my fixincludes patch, which would do > away with the unconditional use of __attribute__((availability)). > > Rainer Rainer, sorry for a dumb question: are you going to commit your fix for darwin_availabilityinternal part? Or should I just apply a patch from comment #15? I've completely messed in this discussion thus I don't understand clearly what should I do now.
[Bug sanitizer/78267] [7 Regression] libsanitizer breaks bootstrap on x86_64-apple-darwin16 at r241977
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78267 --- Comment #44 from Maxim Ostapenko --- (In reply to Jack Howarth from comment #41) > (In reply to r...@cebitec.uni-bielefeld.de from comment #39) > > > --- Comment #36 from Jack Howarth --- > > > Created attachment 40044 [details] > > > --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40044&action=edit > > > fixincludes trace.h generated in stage 1 > > > > > > fixincludes trace.h generated in stage 1 on darwin15 using > > > https://gcc.gnu.org/ml/gcc-patches/2016-11/msg01045.html > > > > So the fix has worked as expected/designed. Good to have the confirmation. > > > > Rainer > > I see the problem now. Your proposed fix from > https://gcc.gnu.org/ml/gcc-patches/2016-11/msg01045.html simply is simply > insufficient in the absence of the change proposed in Comment 33... > > 2016-11-14 Jack Howarth > > libsanitizer/ > > PR sanitizer/78267 > * sanitizer_common/sanitizer_mac.cc: Include only if > compiler supports blocks extension. > > > Index: libsanitizer/sanitizer_common/sanitizer_mac.cc > === > --- libsanitizer/sanitizer_common/sanitizer_mac.cc(revision 242387) > +++ libsanitizer/sanitizer_common/sanitizer_mac.cc(working copy) > @@ -34,7 +34,7 @@ > extern char **environ; > #endif > > -#if defined(__has_include) && __has_include() > +#if defined(__has_include) && __has_include() && > defined(__BLOCKS__) > #define SANITIZER_OS_TRACE 1 > #include > #else > > Otherwise the definition of SANITIZER_OS_TRACE results in > libsanitizer/sanitizer_common/sanitizer_mac.cc making calls to os_trace(). This is probably insufficient, we would have errors with /usr/include/asl.h (see comment #10 for error messages) on darwin16. Shouldn't we ifdef out asl stuff too in this case?
[Bug sanitizer/78267] [7 Regression] libsanitizer breaks bootstrap on x86_64-apple-darwin16 at r241977
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78267 --- Comment #28 from Maxim Ostapenko --- So, perhaps I can commit it (from #15) as Jakub suggested to restore GCC bootstrap for now?
[Bug sanitizer/77827] tsan lacks support for 48 bit VMA on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77827 Maxim Ostapenko changed: What|Removed |Added CC||m.ostapenko at samsung dot com --- Comment #2 from Maxim Ostapenko --- The libsanitizer merge was happened at r241977. Please check whether TSan works on AArch64 48 bit VMA.
[Bug sanitizer/78307] [7 Regression] missing symbols in libubsan without changing the soname
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78307 --- Comment #6 from Maxim Ostapenko --- (In reply to Jakub Jelinek from comment #5) > (In reply to Maxim Ostapenko from comment #4) > > But LLVM doesn't support shared UBSan runtime (the only one supported is > > ASan) and AFAIK there aren't any plans to support it there. > > Yeah, it is a very weird policy. > > > > In any case, we shouldn't be making ABI incompatible changes in the > > > libraries. So, either we should bump soname, or preferably, if it is not > > > that hard to readd those symbols, just do that, so that people don't have > > > to > > > fight yet another changed library. > > > > Do you mean we can apply a local patch? > > We can, sure. Ok, I think I can just add (perhaps empty?) stubs into libubsan to readd those symbols, this should be quite trivial.
[Bug sanitizer/78307] [7 Regression] missing symbols in libubsan without changing the soname
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78307 --- Comment #4 from Maxim Ostapenko --- (In reply to Jakub Jelinek from comment #3) > Sure, it doesn't affect gcc emitted code unless somebody calls those > directly, but perhaps say llvm compiled code using the shared libubsan.so. But LLVM doesn't support shared UBSan runtime (the only one supported is ASan) and AFAIK there aren't any plans to support it there. > In any case, we shouldn't be making ABI incompatible changes in the > libraries. So, either we should bump soname, or preferably, if it is not > that hard to readd those symbols, just do that, so that people don't have to > fight yet another changed library. Do you mean we can apply a local patch?
[Bug sanitizer/78307] [7 Regression] missing symbols in libubsan without changing the soname
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78307 Maxim Ostapenko changed: What|Removed |Added CC||m.ostapenko at samsung dot com --- Comment #1 from Maxim Ostapenko --- Did this cause the link error? AFAIK GCC doesn't support CFI thus doesn't emit these symbols at compiler side.
[Bug sanitizer/78294] -fsanitize=thread broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78294
Maxim Ostapenko changed:
What|Removed |Added
CC||m.ostapenko at samsung dot com
--- Comment #2 from Maxim Ostapenko ---
The testcase also works for me with Glibc 2.24 and dynamic libtsan:
max@max:/tmp$ echo "int main(){}" | ~/install/master/bin/g++ -fsanitize=thread
-L/home/max/install/glibc/usr/lib -L/home/max/install/glibc/lib
-I/home/max/install/glibc/include -Wl,-rpath=/home/max/install/glibc/lib
-Wl,--dynamic-linker=/home/max/install/glibc/lib/ld-2.24.90.so
-Wl,-rpath=/home/max//install/master/lib64 -x c++ - && ./a.out
max@max:/tmp$ echo $?
0
max@max:/tmp$ ldd a.out
linux-vdso.so.1 => (0x7ffe0edb)
libtsan.so.0 => /home/max//install/master/lib64/libtsan.so.0
(0x7f6d97505000)
libstdc++.so.6 => /home/max//install/master/lib64/libstdc++.so.6
(0x7f6d97183000)
libm.so.6 => /home/max/install/glibc/lib/libm.so.6 (0x7f6d96e7f000)
libgcc_s.so.1 => /home/max/install/glibc/lib/libgcc_s.so.1
(0x7f6d96c69000)
libc.so.6 => /home/max/install/glibc/lib/libc.so.6 (0x7f6d968d)
libdl.so.2 => /home/max/install/glibc/lib/libdl.so.2
(0x7f6d966cc000)
librt.so.1 => /home/max/install/glibc/lib/librt.so.1
(0x7f6d964c4000)
libpthread.so.0 => /home/max/install/glibc/lib/libpthread.so.0
(0x7f6d962a7000)
/home/max/install/glibc/lib/ld-2.24.90.so =>
/lib64/ld-linux-x86-64.so.2 (0x7f6d985bc000)
[Bug sanitizer/78267] [7 Regression] libsanitizer breaks bootstrap on x86_64-apple-darwin16 at r241977
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78267 --- Comment #15 from Maxim Ostapenko --- Created attachment 40012 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40012&action=edit Untested fix 2. Ok, thanks. I'm attaching a second short-term fix for now.
[Bug sanitizer/78267] [7 Regression] libsanitizer breaks bootstrap on x86_64-apple-darwin16 at r241977
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78267 --- Comment #13 from Maxim Ostapenko --- (In reply to Rainer Orth from comment #11) > (In reply to Jakub Jelinek from comment #5) > > extern char **environ; > > #endif > > > > -#if defined(__has_include) && __has_include() > > +#if defined(__has_include) && __has_include() && > > defined(__clang__) > > #define SANITIZER_OS_TRACE 1 > > #include > > #else > > > > is preapproved if it works. > > I'd use fixincludes instead to wrap the two offending declarations in > > with #ifdef __BLOCKS__. > > This is a macOS bug, actually: many other places using the Blocks extension > already wrap them correctly. > > I've filed Bug 29184470 uses Blocks extension unconditionally > for > this. > > Rainer The fixincludes fix looks cleaner, but it's harder to me to cook a patch because: 1) I have no experience with fixincludes. 2) I have no Darwin machine to test the fix. I can try fixincludes anyway, but this may take some time. But if the issue is urgent, can we try to ifdef out and ? There isn't much lost in functionality, corresponding code reflects to printing sanitizer logs into syslog on Darwin.
[Bug sanitizer/78267] [7 Regression] libsanitizer breaks bootstrap on x86_64-apple-darwin16 at r241977
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78267 --- Comment #8 from Maxim Ostapenko --- (In reply to Dominique d'Humieres from comment #7) > > Attaching untested fix. > > Dominique, could you try it? > > Allow for ~2 hours. Or better Jakub's fix, it looks cleaner.
[Bug sanitizer/78267] [7 Regression] libsanitizer breaks bootstrap on x86_64-apple-darwin16 at r241977
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78267 --- Comment #6 from Maxim Ostapenko --- Created attachment 40007 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40007&action=edit Untested fix. Attaching untested fix. Dominique, could you try it?
[Bug sanitizer/78267] [7 Regression] libsanitizer breaks bootstrap on x86_64-apple-darwin16 at r241977
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78267 --- Comment #4 from Maxim Ostapenko --- (In reply to Iain Sandoe from comment #3) > (In reply to Maxim Ostapenko from comment #1) > > Eh, mine. > > > > typedef void (^os_trace_payload_t)(xpc_object_t xdict) looks very strange, > > it seems that it's an Objective-C declaration, right? > > It's declaring os_trace_payload_t to of type "Apple block" (like a lambda > that can be used over the whole of c-family); Apple blocks are currently > not supported by GCC. There is no realistic work-around, any interface > using blocks will fail, and thus either those interfaces need to be excluded > from tests, or the tests skipped/xfailed. > > > > > Could you check: > > > > 1) Libc version on your system. > > 2) Contents of /usr/include/os/trace.h. Is that a valid C header? Thank you for clarification. We'll probably need GCC local patch here (say, define SANITIZER_OS_TRACE to 0).
[Bug sanitizer/78267] [7 Regression] libsanitizer breaks bootstrap on x86_64-apple-darwin16 at r241977
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78267 Maxim Ostapenko changed: What|Removed |Added CC||m.ostapenko at samsung dot com --- Comment #1 from Maxim Ostapenko --- Eh, mine. typedef void (^os_trace_payload_t)(xpc_object_t xdict) looks very strange, it seems that it's an Objective-C declaration, right? Could you check: 1) Libc version on your system. 2) Contents of /usr/include/os/trace.h. Is that a valid C header?
[Bug sanitizer/77982] deadlock in asan thread initialization/interception.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77982
--- Comment #11 from Maxim Ostapenko ---
Created attachment 39882
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39882&action=edit
Untested fix
Untested fix (works for me with attached testcase).
To sum up:
1) dlopen grabs a __GI___pthread_mutex_lock in main thread.
2) main thread calls pthread_create, ASan intercepts it, calls real
pthread_create and waits for the second thread to be "fully initialized".
3) Newly created thread tries to access a thread local "disable_counter" in
LSan (to complete its "full initialization") and hangs in tls_get_addr_tail,
because it also tries to acquire __GI___pthread_mutex_lock.
The issue doesn't reproduce on older Glibc (e.g. 2.19 on my Ubuntu box) because
tls_get_addr_tail doesn't try to acquire __GI___pthread_mutex_lock there (yes,
2.19 and 2.23 have many differences in TLS implementation).
The deadlock doesn't occur with ASan static linkage because in this case
"disable_counter" resides in static tls, thus tls_get_addr_tail isn't called.
The simple fix would be just using __attribute__((tls_model("initial-exec")))
for "disable_counter" in LSan. This should be fine since nobody would dlopen
{A, L}San runtime in any case.
[Bug sanitizer/77982] deadlock in asan thread initialization/interception.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77982 --- Comment #10 from Maxim Ostapenko --- (In reply to Pawel Sikora from comment #9) > (In reply to Maxim Ostapenko from comment #8) > > > Hm, perhaps environment issue. What version of Glibc do you use? > > glibc-2.23.1-10.fc24.x86_64 Reproduced with current trunk Glibc: max@max:/tmp/bug$ make rm -f m *.so ~/install/master/bin/g++ -g2 -Og -flto -fsanitize=address -L/home/max/install/glibc/usr/lib -L/home/max/install/glibc/lib -I/home/max/install/glibc/include -Wl,-rpath=/home/max/install/glibc/lib -Wl,--dynamic-linker=/home/max/install/glibc/lib/ld-2.24.90.so s.cpp -shared -o s.so -fPIC ~/install/master/bin/g++ -g2 -Og -flto -fsanitize=address -L/home/max/install/glibc/usr/lib -L/home/max/install/glibc/lib -I/home/max/install/glibc/include -Wl,-rpath=/home/max/install/glibc/lib -Wl,--dynamic-linker=/home/max/install/glibc/lib/ld-2.24.90.so m.cpp -o m max@max:/tmp/bug$ LD_LIBRARY_PATH=/home/max/install/master/lib64/ ./m initializing library... ^C Seems to be ASan + recent Glibc (probably 2.23+) issue.
[Bug sanitizer/77982] deadlock in asan thread initialization/interception.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77982 --- Comment #8 from Maxim Ostapenko --- (In reply to Pawel Sikora from comment #7) > (In reply to Maxim Ostapenko from comment #6) > > The attached testcase works for me with current trunk GCC: > > > > max@max:/tmp/bug$ make > > rm -f m *.so > > ~/install/master/bin/g++ -fuse-ld=gold -g2 -Og -flto -fsanitize=address > > s.cpp -shared -o s.so -fPIC > > ~/install/master/bin/g++ -fuse-ld=gold -g2 -Og -flto -fsanitize=address > > m.cpp -o m > > max@max:/tmp/bug$ LD_LIBRARY_PATH=/home/max/install/master/lib64 ./m > > initializing library... > > done. > > thread started. > > max@max:/tmp/bug$ echo $? > > 0 > > > strange, i've tested gcc-trunk and it locks in the same way as 6.2.1. > > > ~/src/gcc-install/usr/local/bin/g++ -v > Using built-in specs. > COLLECT_GCC=/home/pawels/src/gcc-install/usr/local/bin/g++ > COLLECT_LTO_WRAPPER=/home/pawels/src/gcc-install/usr/local/bin/../libexec/ > gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper > Target: x86_64-pc-linux-gnu > Configured with: /home/pawels/src/gcc/configure --with-arch=x86-64 > --with-linker-hash-style=gnu --disable-multilib --disable-nls > --disable-libssp --disable-libgomp --disable-libquadmath --disable-libitm > --disable-libcilkrts --disable-libvtv --disable-liboffloadmic > --disable-libmpx --enable-tls --enable-libstdcxx-allocator=new > --enable-extern-template --enable-libstdcxx-time=rt > --enable-libstdcxx-threads --disable-libstdcxx-dual-abi > --enable-libstdcxx-filesystem-ts=no --enable-symvers=gnu-versioned-namespace > --disable-libstdcxx-pch --enable-lto --enable-plugin --enable-c99 > --enable-long-long --enable-linux-futex --enable-threads=posix > --enable-shared --with-pic --enable-gold --enable-__cxa_atexit > --enable-gnu-unique-object --enable-initfini-array --enable-languages=c,c++ > --enable-checking=release --with-long-double-128 --disable-cld > --disable-bootstrap > Thread model: posix > gcc version 7.0.0 20161025 (experimental) (GCC) > > ~/src/gcc-install/usr/local/bin/g++ -fuse-ld=gold -g2 -Og -fsanitize=address > -Wl,-rpath,/home/pawels/src/gcc-install/usr/local/lib64 -flto s.cpp -shared > -o s.so -fPIC -pthread > ~/src/gcc-install/usr/local/bin/g++ -fuse-ld=gold -g2 -Og -fsanitize=address > -Wl,-rpath,/home/pawels/src/gcc-install/usr/local/lib64 -flto m.cpp -o m -ldl > > [pawels@pawels]~/src/bug% ./m > initializing library... > ^C Hm, perhaps environment issue. What version of Glibc do you use?
[Bug sanitizer/77982] deadlock in asan thread initialization/interception.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77982 Maxim Ostapenko changed: What|Removed |Added CC||m.ostapenko at samsung dot com --- Comment #6 from Maxim Ostapenko --- The attached testcase works for me with current trunk GCC: max@max:/tmp/bug$ make rm -f m *.so ~/install/master/bin/g++ -fuse-ld=gold -g2 -Og -flto -fsanitize=address s.cpp -shared -o s.so -fPIC ~/install/master/bin/g++ -fuse-ld=gold -g2 -Og -flto -fsanitize=address m.cpp -o m max@max:/tmp/bug$ LD_LIBRARY_PATH=/home/max/install/master/lib64 ./m initializing library... done. thread started. max@max:/tmp/bug$ echo $? 0
[Bug testsuite/63299] ASan reported alloc-dealloc-mismatch in g++.old-deja/g++.jason/init3.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63299 Maxim Ostapenko changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #2 from Maxim Ostapenko --- No, the issue isn't reproducible on current trunk. Closing.
[Bug driver/72765] New: Dynamic stack buffer overflow in GCC driver with -save-temps switch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72765 Bug ID: 72765 Summary: Dynamic stack buffer overflow in GCC driver with -save-temps switch. Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver Assignee: unassigned at gcc dot gnu.org Reporter: m.ostapenko at samsung dot com Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Build: x86_64-pc-linux-gnu When testing experimental allocas and VLAs handling in AddressSanitizer, I've got such an error during GCC's "make check": max@max:~/build/master$ /home/max/build/master/gcc/testsuite/g++/../../xg++ -B/home/max/build/master/gcc/testsuite/g++/../../ /home/max/workspace/downloads/gcc/gcc/testsuite/c-c++-common/cilk-plus/CK/pr69826-2.c -fno-diagnostics-show-caret -fdiagnostics-color=never -nostdinc++ -I/home/max/build/master/x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu -I/home/max/build/master/x86_64-unknown-linux-gnu/libstdc++-v3/include -I/home/max/workspace/downloads/gcc/libstdc++-v3/libsupc++ -I/home/max/workspace/downloads/gcc/libstdc++-v3/include/backward -I/home/max/workspace/downloads/gcc/libstdc++-v3/testsuite/util -fmessage-length=0 -g -O2 -fcilkplus -save-temps -B/home/max/build/master/x86_64-unknown-linux-gnu/./libcilkrts/ -L/home/max/build/master/x86_64-unknown-linux-gnu/./libcilkrts/.libs -L/home/max/build/master/x86_64-unknown-linux-gnu/./libstdc++-v3/src/.libs -B/home/max/build/master/x86_64-unknown-linux-gnu/./libstdc++-v3/src/.libs -L/home/max/build/master/x86_64-unknown-linux-gnu/./libstdc++-v3/src/.libs -B/home/max/build/master/x86_64-unknown-linux-gnu/./libitm/ -L/home/max/build/master/x86_64-unknown-linux-gnu/./libitm/.libs -lm -o ./pr69826-2.exe = ==32062==ERROR: AddressSanitizer: dynamic-stack-buffer-overflow on address 0x7ffc9059d2cc at pc 0x0044fc2c bp 0x7ffc9059d250 sp 0x7ffc9059ca00 READ of size 13 at 0x7ffc9059d2cc thread T0 #0 0x44fc2b in __interceptor_memcpy /home/max/workspace/downloads/gcc/libsanitizer/asan/asan_interceptors.cc:436 #1 0x4e1397 in save_string /home/max/workspace/downloads/gcc/gcc/gcc.c:8368 #2 0x4f3027 in do_spec_1 /home/max/workspace/downloads/gcc/gcc/gcc.c:5423 #3 0x4f60f4 in process_brace_body /home/max/workspace/downloads/gcc/gcc/gcc.c:6431 #4 0x4f60f4 in handle_braces /home/max/workspace/downloads/gcc/gcc/gcc.c:6345 #5 0x4f2eb7 in do_spec_1 /home/max/workspace/downloads/gcc/gcc/gcc.c:5802 #6 0x4f60f4 in process_brace_body /home/max/workspace/downloads/gcc/gcc/gcc.c:6431 #7 0x4f60f4 in handle_braces /home/max/workspace/downloads/gcc/gcc/gcc.c:6345 #8 0x4f2eb7 in do_spec_1 /home/max/workspace/downloads/gcc/gcc/gcc.c:5802 #9 0x4f1a91 in do_spec_1 /home/max/workspace/downloads/gcc/gcc/gcc.c:5917 #10 0x4f60f4 in process_brace_body /home/max/workspace/downloads/gcc/gcc/gcc.c:6431 #11 0x4f60f4 in handle_braces /home/max/workspace/downloads/gcc/gcc/gcc.c:6345 #12 0x4f2eb7 in do_spec_1 /home/max/workspace/downloads/gcc/gcc/gcc.c:5802 #13 0x4f60f4 in process_brace_body /home/max/workspace/downloads/gcc/gcc/gcc.c:6431 #14 0x4f60f4 in handle_braces /home/max/workspace/downloads/gcc/gcc/gcc.c:6345 #15 0x4f2eb7 in do_spec_1 /home/max/workspace/downloads/gcc/gcc/gcc.c:5802 #16 0x4f60f4 in process_brace_body /home/max/workspace/downloads/gcc/gcc/gcc.c:6431 #17 0x4f60f4 in handle_braces /home/max/workspace/downloads/gcc/gcc/gcc.c:6345 #18 0x4f2eb7 in do_spec_1 /home/max/workspace/downloads/gcc/gcc/gcc.c:5802 #19 0x4f60f4 in process_brace_body /home/max/workspace/downloads/gcc/gcc/gcc.c:6431 #20 0x4f60f4 in handle_braces /home/max/workspace/downloads/gcc/gcc/gcc.c:6345 #21 0x4f2eb7 in do_spec_1 /home/max/workspace/downloads/gcc/gcc/gcc.c:5802 #22 0x4f474b in do_spec_2 /home/max/workspace/downloads/gcc/gcc/gcc.c:4841 #23 0x4f719e in do_spec(char const*) /home/max/workspace/downloads/gcc/gcc/gcc.c:4808 #24 0x4f74fe in driver::do_spec_on_infiles() const /home/max/workspace/downloads/gcc/gcc/gcc.c:8076 #25 0x406e59 in driver::main(int, char**) /home/max/workspace/downloads/gcc/gcc/gcc.c:7216 #26 0x407747 in main /home/max/workspace/downloads/gcc/gcc/gcc-main.c:46 #27 0x7f1513415ec4 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21ec4) #28 0x408509 (/home/max/build/master/gcc/xg+++0x408509) Address 0x7ffc9059d2cc is located in stack of thread T0 SUMMARY: AddressSanitizer: dynamic-stack-buffer-overflow /home/max/workspace/downloads/gcc/libsanitizer/asan/asan_interceptors.cc:436 in __interceptor_memcpy Shadow bytes around the buggy address: 0x1000120aba00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x1000120aba10: 00 00 00 00 00 00 00 00 00
[Bug sanitizer/71480] ASan should align string constants to shadow granularity.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71480 Maxim Ostapenko changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #5 from Maxim Ostapenko --- Fixed.
[Bug sanitizer/71480] ASan should align string constants to shadow granularity.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71480 --- Comment #3 from Maxim Ostapenko --- Thanks, will post the fix in ML soon.
[Bug sanitizer/71480] ASan should align string constants to shadow granularity.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71480
--- Comment #1 from Maxim Ostapenko ---
The problem appears for arm target only, x86 is fine.
$ armv7l-tizen-linux-gnueabi-gcc -v
Using built-in specs.
COLLECT_GCC=armv7l-tizen-linux-gnueabi-gcc
COLLECT_LTO_WRAPPER=/home/max/install/armv7l-tizen/libexec/gcc/armv7l-tizen-linux-gnueabi/7.0.0/lto-wrapper
Target: armv7l-tizen-linux-gnueabi
Configured with: /home/max/workspace/downloads/gcc/configure
--prefix=/home/max/install/armv7l-tizen --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=armv7l-tizen-linux-gnueabi --disable-nls
--enable-poison-system-directories
--with-pkgversion=Tizen.armv7l.GA2.2015-08-26
--with-sysroot=/home/max/install/armv7l-tizen/armv7l-tizen-linux-gnueabi/sys-root
--with-gmp=/home/max/build/v6/fake-root
--with-libelf=/home/max/build/v6/fake-root
--with-mpc=/home/max/build/v6/fake-root
--with-mpfr=/home/max/build/v6/fake-root --without-cloog --without-ppl
--with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm'
--enable-languages=c,c++,fortran --disable-libstdcxx-pch --enable-__cxa_atexit
--enable-libssp --enable-lto --enable-checking=release
--with-build-time-tools=/home/max/install/armv7l-tizen/bin --with-gnu-as
--with-gnu-ld
--with-specs='%{funwind-tables|fno-unwind-tables|mabi=*|ffreestanding|nostdlib:;:-funwind-tables}
%{!Werror=unused-local-typedefs:%{!Wno-error=unused-local-typedefs:-Wno-error=unused-local-typedefs}}
%{fuse-linker-plugin|fno-use-linker-plugin|flto|flto=*:;:-fno-use-linker-plugin}'
--disable-multilib --disable-gnu-unique-object --enable-linker-build-id
--with-mode=arm --with-fpu=neon-vfpv4 --with-tune=cortex-a8 --with-float=softfp
--enable-libgomp --enable-linux-futex
Thread model: posix
gcc version 7.0.0 20160607 (experimental) (Tizen.armv7l.GA2.2015-08-26)
[Bug sanitizer/71480] New: ASan should align string constants to shadow granularity.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71480
Bug ID: 71480
Summary: ASan should align string constants to shadow
granularity.
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: m.ostapenko at samsung dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
Target Milestone: ---
Host: x86_64-pc-linux-gnu
Target: arm-linux-gnueabi
Consider following testcase:
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
int main (void)
{
struct stat st;
char tpl[20] = "/tmp/test.XX";
char tpl2[20] = "/tmp/test.XX";
int fd = mkstemp (tpl);
int fd2 = mkstemp (tpl2);
if (fd == -1)
{
if (fd2 != -1)
unlink (tpl2);
exit (1);
}
if (fd2 == -1)
exit (1);
unlink (tpl);
unlink (tpl2);
if (fstat (fd, &st) != 0)
exit(1);
if ((st.st_mode & 0777) != 0600)
exit (1);
if (strcmp (tpl, "/tmp/test.XX") == 0)
exit(1);
if (strcmp (tpl, tpl2) == 0)
exit(1);
return 0;
}
When compiling this code to arm-linux-gnueabi with Thumb mode,
"/tmp/test.XX" may actually stay unaligned to shadow granularity:
$ armv7l-tizen-linux-gnueabi-gcc -O2 -mthumb test.c -S -fno-omit-frame-pointer
$ cat test.s
.section.rodata
.align 2
.set.LANCHOR0,. + 0
.LC4:
.ascii "/tmp/test.XX\000"
.space 3
.space 44
.data
.align 2
.set.LANCHOR1,. + 0
.type .LASAN0, %object
.size .LASAN0, 28
.LASAN0:
.word .LC4
.word 20
.word 64
.word .LC6
.word .LC7
.word 0
.word 0
.space 36
.section.rodata.str1.4,"aMS",%progbits,1
.align 2
Here, we have align == 2 for .LC4, that may cause runtime failure in ASan with
something like this:
bash-3.2# ASAN_OPTIONS=report_globals=2
/home/abuild/rpmbuild/BUILD/tdb-1.3.1/testprog
#0 0x40859645 in __asan_register_globals (/usr/lib/libasan.so+0x25645)
#1 0x10b67 in __libc_csu_init
(/home/abuild/rpmbuild/BUILD/tdb-1.3.1/testprog+0x10b67)
#2 0x40dd848b in __libc_start_main (/lib/libc.so.6+0x1648b)
=== ID 92274689; 0x00020dd0 0x00020dd0
==8205==Added Global[0x00020dd0]: beg=0x00010b8c size=20/64 name=*.LC4
module=test.c dyn_init=0
==8205==AddressSanitizer CHECK failed:
../../../../libsanitizer/asan/asan_globals.cc:145
"((AddrIsAlignedByGranularity(g->beg))) != (0)" (0x0, 0x0)
#0 0x408cd749 (/usr/lib/libasan.so+0x99749)
#1 0x408d1e5d in __sanitizer::CheckFailed(char const*, int, char const*,
unsigned long long, unsigned long long) (/usr/lib/libasan.so+0x9de5d)
#2 0x40859a1f in __asan_register_globals (/usr/lib/libasan.so+0x25a1f)
#3 0x10b67 in __libc_csu_init
(/home/abuild/rpmbuild/BUILD/tdb-1.3.1/testprog+0x10b67)
#4 0x40dd848b in __libc_start_main (/lib/libc.so.6+0x1648b)
The problem here is that for ".LC4" TREE_CONSTANT_POOL_ADDRESS_P (symbol) is
true and we don't enforce additional alignment requirements in
place_block_symbol. Perhaps something like this can fix the issue:
diff --git a/gcc/varasm.c b/gcc/varasm.c
index 4a7124e..de8bcd6 100644
--- a/gcc/varasm.c
+++ b/gcc/varasm.c
@@ -7201,7 +7201,11 @@ place_block_symbol (rtx symbol)
if ((flag_sanitize & SANITIZE_ADDRESS)
&& TREE_CODE (DECL_INITIAL (decl)) == STRING_CST
&& asan_protect_global (DECL_INITIAL (decl)))
- size += asan_red_zone_size (size);
+ {
+ size += asan_red_zone_size (size);
+ alignment = MAX (alignment,
+ ASAN_RED_ZONE_SIZE * BITS_PER_UNIT);
+ }
}
else
{
[Bug sanitizer/71445] libsanitizer build failure on aarch64-linux-gnu with recent glibc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71445 --- Comment #5 from Maxim Ostapenko --- Can we use dlvsym for versioned symbols (recvmsg, sendmsg, etc) in the wrappers?
[Bug sanitizer/71445] libsanitizer build failure on aarch64-linux-gnu with recent glibc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71445 Maxim Ostapenko changed: What|Removed |Added CC||m.ostapenko at samsung dot com --- Comment #1 from Maxim Ostapenko --- Hm, one I can see, Glibc still has __GLIBC_MINOR__ = 23: /* Major and minor version number of the GNU C library package. Use these macros to test for features in specific releases. */ #define __GLIBC__ 2 #define __GLIBC_MINOR__ 23 Perhaps we can cherry-pick http://llvm.org/viewvc/llvm-project?view=revision&revision=272008 after Glibc release happens?
[Bug sanitizer/71291] Firefox with GCC reports stack-buffer-overflow but clang does not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71291 --- Comment #13 from Maxim Ostapenko --- Created attachment 38620 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38620&action=edit mozconfig This .mozconfig with current trunk clang 3.9.0. The source code I've downloaded from here: $ hg clone https://hg.mozilla.org/mozilla-central/ firefox
[Bug sanitizer/71291] Firefox with GCC reports stack-buffer-overflow but clang does not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71291 --- Comment #10 from Maxim Ostapenko --- I've build Firefox locally with clang with optimizations disabled (CFLAGS="-fsanitize=address -fsanitize-recover=address -O0") and got pretty the same backtrace: ==12707==ERROR: AddressSanitizer: stack-buffer-underflow on address 0x7fe22dbc417c at pc 0x7fe25e3b9ee5 bp 0x7fe22dbc40b0 sp 0x7fe22dbc40a8 READ of size 4 at 0x7fe22dbc417c thread T39 (Compositor) #0 0x7fe25e3b9ee4 in mozilla::gfx::BasePoint4D >::DotProduct(mozilla::gfx::Point4DTyped const&) const /home/max/src/firefox/gfx/2d/BasePoint4D.h:101:68 #1 0x7fe25e3b7e6e in unsigned long mozilla::gfx::Matrix4x4Typed::TransformAndClipRect(mozilla::gfx::RectTyped const&, mozilla::gfx::RectTyped const&, mozilla::gfx::PointTyped*) const /home/max/src/firefox/gfx/2d/Matrix.h:738:19 #2 0x7fe25e3a2329 in mozilla::gfx::RectTyped mozilla::gfx::Matrix4x4Typed::TransformAndClipBounds(mozilla::gfx::RectTyped const&, mozilla::gfx::RectTyped const&) const /home/max/src/firefox/gfx/2d/Matrix.h:675:24 #3 0x7fe25ea08163 in mozilla::layers::BasicCompositor::DrawQuad(mozilla::gfx::RectTyped const&, mozilla::gfx::RectTyped const&, mozilla::layers::EffectChain const&, float, mozilla::gfx::Matrix4x4Typed const&, mozilla::gfx::RectTyped const&) /home/max/src/firefox/gfx/layers/basic/BasicCompositor.cpp:311:23 #4 0x7fe25e888778 in mozilla::layers::Compositor::DrawQuad(mozilla::gfx::RectTyped const&, mozilla::gfx::RectTyped const&, mozilla::layers::EffectChain const&, float, mozilla::gfx::Matrix4x4Typed const&) /home/max/src/firefox/objdir-ff-asan-O0/dist/include/mozilla/layers/Compositor.h:331:7 #5 0x7fe25eb0b14f in mozilla::layers::ColorLayerComposite::RenderLayer(mozilla::gfx::IntRectTyped const&)::$_1::operator()(mozilla::layers::EffectChain&, mozilla::gfx::RectTyped const&) const /home/max/src/firefox/gfx/layers/composite/ColorLayerComposite.cpp:31:5 #6 0x7fe25ead8bdd in void mozilla::layers::RenderWithAllMasks const&)::$_1>(mozilla::layers::Layer*, mozilla::layers::Compositor*, mozilla::gfx::IntRectTyped const&, mozilla::layers::ColorLayerComposite::RenderLayer(mozilla::gfx::IntRectTyped const&)::$_1) /home/max/src/firefox/gfx/layers/composite/LayerManagerComposite.h:616:5 #7 0x7fe25ead8437 in mozilla::layers::ColorLayerComposite::RenderLayer(mozilla::gfx::IntRectTyped const&) /home/max/src/firefox/gfx/layers/composite/ColorLayerComposite.cpp:28:3 #8 0x7fe25eb749e6 in void mozilla::layers::RenderLayers(mozilla::layers::ContainerLayerComposite*, mozilla::layers::LayerManagerComposite*, mozilla::gfx::IntRectTyped const&) /home/max/src/firefox/gfx/layers/composite/ContainerLayerComposite.cpp:662:7 ... Address 0x7fe22dbc417c is located in stack of thread T39 (Compositor) at offset 28 in frame #0 0x7fe25e3b6b8f in unsigned long mozilla::gfx::Matrix4x4Typed::TransformAndClipRect(mozilla::gfx::RectTyped const&, mozilla::gfx::RectTyped const&, mozilla::gfx::PointTyped*) const /home/max/src/firefox/gfx/2d/Matrix.h:709 This frame has 20 object(s): [32, 1056) 'points' <== Memory access at offset 28 underflows this variable [1184, 1200) 'ref.tmp' [1216, 1232) 'ref.tmp2' [1248, 1264) 'ref.tmp4' [1280, 1296) 'ref.tmp5' [1312, 1328) 'ref.tmp11' [1344, 1360) 'ref.tmp12' [1376, 1392) 'ref.tmp18' [1408, 1424) 'ref.tmp19' [1440, 1504) 'planeNormals' [1536, 1552) 'ref.tmp32' [1568, 1584) 'ref.tmp35' [1600, 1616) 'ref.tmp38' [1632, 1648) 'ref.tmp42' [1664, 1680) 'ref.tmp68' [1696, 1712) 'coerce' [1728, 1744) 'ref.tmp71' [1760, 1768) 'p' [1792, 1800) 'ref.tmp99' [1824, 1832) 'ref.tmp100' HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext (longjmp and C++ exceptions *are* supported) SUMMARY: AddressSanitizer: stack-buffer-underflow /home/max/src/firefox/gfx/2d/BasePoint4D.h:101:68 in mozilla::gfx::BasePoint4D >::DotProduct(mozilla::gfx::Point4DTyped const&) const Shadow bytes around the buggy address: 0x0ffcc5b707d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0ffcc5b707e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0ffcc5b707f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0ffcc5b70800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0ffcc5b70810: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 =>0x0ffcc5b70820: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1[f1] 0x0ffcc5b70830: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0ffcc5b70840: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0ffcc5b70850: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0ffcc5b70860: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0ffcc5b70870: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Heap right redzone:
[Bug sanitizer/71291] Firefox with GCC reports stack-buffer-overflow but clang does not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71291
Maxim Ostapenko changed:
What|Removed |Added
CC||m.ostapenko at samsung dot com
--- Comment #9 from Maxim Ostapenko ---
Hm, looking to corresponding source code (dist/include/mozilla/gfx/Matrix.h):
705 template
706 size_t TransformAndClipRect(const RectTyped& aRect,
707 const RectTyped& aClip,
708 PointTyped* aVerts) const
709 {
710 // Initialize a double-buffered array of points in homogenous space
711 // with the input rectangle, aRect.
712 Point4DTyped points[2]kTransformAndClipRectMaxVerts];
713 Point4DTyped* dstPoint = points[0];
727 // Iterate through each clipping plane and clip the polygon.
728 // In each pass, we double buffer, alternating between points[0] and
729 // points[1].
730 for (int plane=0; plane < 4; plane++) {
731 planeNormals[plane].Normalize();
732
733 Point4DTyped* srcPoint = points[plane & 1];
734 Point4DTyped* srcPointEnd = dstPoint;
735 dstPoint = points[~plane & 1];
736
737 Point4DTyped* prevPoint = srcPointEnd - 1;
738 F prevDot = planeNormals[plane].DotProduct(*prevPoint);
I suspect this scenario to happen:
1) On iteration 2 (i == 1) dstPoint becomes points[0] at line 735.
2) Later on iteration 1 dstPoint doesn't change for some reason.
3) On iteration 3 (i == 2) srcPointEnd becomes srcPointEnd = dstPoint (==
point[0]) at line 734.
4) Later on iteration 3 prevPoint = srcPointEnd - 1 (point[-1]) at line 737.
5) At line 738 we use *prevPoint (points[-1]) that leads to ASan report (valid,
because points[-1] overflows).
Could you check this? If this is what happens, than ASan is innocent and
something else went wrong here.
[Bug sanitizer/70712] False positive from AddressSanitizer with use of 'alignas'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70712 Maxim Ostapenko changed: What|Removed |Added CC||m.ostapenko at samsung dot com --- Comment #3 from Maxim Ostapenko --- Another option would be relaxing align value to ASAN_RED_ZONE_SIZE, because prev_offset should be aligned only by ASAN_RED_ZONE_SIZE due to previous left redzone.
[Bug sanitizer/70624] [6/7 Regression] Several hundred asan failures with 6.0 on x86_64-apple-darwin10.8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70624 --- Comment #12 from Maxim Ostapenko --- Should be fixed on trunk and gcc-6-branch. Older branches don't need the patch, because they don't contain 'dyldVersionNumber' in libsanitizer.
[Bug sanitizer/70624] [6 Regression] Several hundred asan failures with 6.0 on x86_64-apple-darwin10.8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70624 Maxim Ostapenko changed: What|Removed |Added CC||m.ostapenko at samsung dot com --- Comment #2 from Maxim Ostapenko --- Darwin 10.8 seems to be quite an old system (June 23, 2011), perhaps it's dynamic linker (dyld) just haven't dyldVersionNumber symbol? Anyway, this is a library issue and perhaps it should go to sanitizer bugzilla (https://github.com/google/sanitizers/issues).
[Bug sanitizer/70474] [4.9 Regression] Several hundred asan failures with 4.9.4 on x86_64-apple-darwin15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70474 --- Comment #5 from Maxim Ostapenko --- Eh, just forgot about this one, sorry. Will post the patch shortly.
[Bug sanitizer/70541] unnoticed invalid dereference when using address sanitizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70541
--- Comment #4 from Maxim Ostapenko ---
(In reply to Jakub Jelinek from comment #3)
> (In reply to Maxim Ostapenko from comment #1)
> > @@ -2060,7 +2067,20 @@ maybe_instrument_call (gimple_stmt_iterator *iter)
> >return true;
> > }
>
> If the function call returns a struct, then your patch wouldn't instrument
> it.
> You need the bool instrumented = false; already above
> if (gimple_store_p (stmt))
> and set instrumented = true; there instead of gsi_next (iter); return true;
>
> > - return false;
> > + bool instrumented = false;
> > + HOST_WIDE_INT args_num = gimple_call_num_args (stmt);
> > + for (int i = 0; i < args_num; ++i)
> > +{
> > + if (is_arg_deref_p (TREE_CODE (gimple_call_arg (stmt, i
>
> I'm not aware of any is_arg_deref_p predicate.
> IMHO you should test:
> if (!is_gimple_reg (gimple_call_arg (stmt, i)))
>
> > + {
> > + instrument_derefs (iter, gimple_call_arg (stmt, i),
> > +gimple_location (stmt), false);
> > + instrumented = true;
> > + }
> > +}
> > + if (instrumented)
> > +gsi_next (iter);
> > + return instrumented;
>
Thanks, looks better now?
diff --git a/gcc/asan.c b/gcc/asan.c
index 47bfdcd..c51e629 100644
--- a/gcc/asan.c
+++ b/gcc/asan.c
@@ -1766,6 +1766,8 @@ instrument_derefs (gimple_stmt_iterator *iter, tree t,
tree type, base;
HOST_WIDE_INT size_in_bytes;
+ if (location == UNKNOWN_LOCATION)
+location = EXPR_LOCATION (t);
type = TREE_TYPE (t);
switch (TREE_CODE (t))
@@ -2049,6 +2051,7 @@ maybe_instrument_call (gimple_stmt_iterator *iter)
gsi_insert_before (iter, g, GSI_SAME_STMT);
}
+ bool instrumented = false;
if (gimple_store_p (stmt))
{
tree ref_expr = gimple_call_lhs (stmt);
@@ -2056,11 +2059,22 @@ maybe_instrument_call (gimple_stmt_iterator *iter)
gimple_location (stmt),
/*is_store=*/true);
- gsi_next (iter);
- return true;
+ instrumented = true;
}
- return false;
+ HOST_WIDE_INT args_num = gimple_call_num_args (stmt);
+ for (int i = 0; i < args_num; ++i)
+{
+ if (!is_gimple_reg (gimple_call_arg (stmt, i)))
+ {
+ instrument_derefs (iter, gimple_call_arg (stmt, i),
+gimple_location (stmt), false);
+ instrumented = true;
+ }
+}
+ if (instrumented)
+gsi_next (iter);
+ return instrumented;
}
> As for the location_t thing, the fix would be to do in instrument_derefs
> something like:
> if (location == UNKNOWN_LOCATION)
> location = EXPR_LOCATION (t);
> after the early bail outs.
Hm, even with if (location == UNKNOWN_LOCATION) location = EXPR_LOCATION (t); I
don't see reasonable line in -O2 case:
1 #include
2 #include
3
4 struct Simple {
5 int value;
6 };
7
8 int f(struct Simple simple) {
9 return simple.value;
10 }
11
12 int g(int value) {
13 return value;
14 }
15
16 int main() {
17 struct Simple *psimple = (struct Simple *) malloc(sizeof(struct Simple));
18 psimple->value = 42;
19 free(psimple);
20 printf("%d\n", f(*psimple));
21 return 0;
22 }
$ ./a.out
==29898==ERROR: AddressSanitizer: heap-use-after-free on address 0x6020eff0
at pc 0x004055a6 bp 0x7ffc6b5632c0 sp 0x7ffc6b5632a0
READ of size 4 at 0x6020eff0 thread T0
#0 0x4055a5 in main /tmp/test2.c:22
#1 0x7f8e6df32ec4 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x21ec4)
#2 0x4055f9 (/tmp/a.out+0x4055f9)
$ cat test2.c.126t.asan1
main ()
{
int simple$value;
struct Simple * psimple;
:
[test2.c:17:18] psimple_3 = malloc (4);
[test2.c:17:18] # DEBUG psimple => psimple_3
[test2.c:19:3] free (psimple_3);
ASAN_CHECK (6, psimple_3, 4, 8);
simple$value_6 = MEM[(struct Simple *)psimple_3];
# DEBUG simple$value => simple$value_6
[test2.c:20:3] printf ([test2.c:20:10] "%d\n", simple$value_6);
return 0;
}
Perhaps we indeed should look at the inliner.
[Bug sanitizer/70541] unnoticed invalid dereference when using address sanitizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70541
Maxim Ostapenko changed:
What|Removed |Added
CC||m.ostapenko at samsung dot com
--- Comment #1 from Maxim Ostapenko ---
This bug also happens on current trunk. Consider slightly reduced testcase
(just part of Christof's one):
#include
#include
struct Simple {
int value;
};
int f(struct Simple simple) {
return simple.value;
}
int main() {
int *pint = (int *) malloc(sizeof(int));
*pint = 24;
free(pint);
printf("%d\n", g(*pint));
return 0;
}
Corresponding gimple dump:
main ()
{
int D.3060;
int D.3061;
{
struct Simple * psimple;
psimple = malloc (4);
psimple->value = 42;
free (psimple);
D.3060 = f (*psimple); <===
printf ("%d\n", D.3060);
D.3061 = 0;
return D.3061;
}
D.3061 = 0;
return D.3061;
}
Here, GCC propagates *psimple directly to f() without creating temporary
variable and ASan is unable to check it because it doesn't sanitize gimple
calls arguments.
I think the easiest way to fix this would be adding arguments checks in
maybe_instrument_call, something like this:
@@ -2060,7 +2067,20 @@ maybe_instrument_call (gimple_stmt_iterator *iter)
return true;
}
- return false;
+ bool instrumented = false;
+ HOST_WIDE_INT args_num = gimple_call_num_args (stmt);
+ for (int i = 0; i < args_num; ++i)
+{
+ if (is_arg_deref_p (TREE_CODE (gimple_call_arg (stmt, i
+ {
+ instrument_derefs (iter, gimple_call_arg (stmt, i),
+gimple_location (stmt), false);
+ instrumented = true;
+ }
+}
+ if (instrumented)
+gsi_next (iter);
+ return instrumented;
[Bug sanitizer/70474] [4.9 Regression] Several hundred asan failures with 4.9.4 on x86_64-apple-darwin15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70474 --- Comment #1 from Maxim Ostapenko --- Created attachment 38143 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38143&action=edit Proposed patch. Does this patch fix the problem?
