[Bug sanitizer/85230] asan: false positives in kernel on allocas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85230 chefmax at gcc dot gnu.org changed: What|Removed |Added CC||chefmax at gcc dot gnu.org --- Comment #5 from chefmax at gcc dot gnu.org --- Hi Dmitry, > I thought that maybe code first deallocates the alloca memory on stack, and > only then unpoisons it. But no, it first unpoisons and then restores rsp. Actually when handling __builtin_stack_restore for alloca, GCC indeed first deallocates the alloca memory on stack, and only then unpoisons it. Take a look on disasm around shash_update_unaligned crypto/shash.c:104: 8301cc1d: 48 8b 65 b8 mov-0x48(%rbp),%rsp 8301cc21: 48 8b 7d b0 mov-0x50(%rbp),%rdi 8301cc25: 48 89 e6mov%rsp,%rsi 8301cc28: e8 f3 b0 b0 fe callq 81b27d20 <__asan_allocas_unpoison> This is also reflected in GCC source code: /* Insert __asan_allocas_unpoison (top, bottom) call after __builtin_stack_restore (new_sp) call. The pseudocode of this routine should look like this: __builtin_stack_restore (new_sp); top = last_alloca_addr; bot = new_sp; __asan_allocas_unpoison (top, bot); last_alloca_addr = new_sp; That's why the issue happens only when interrupt happens inside __asan_allocas_unpoison call. So, this looks like an implementation flaw inside GCC, sorry about that :(. Perhaps we just need to insert all unpoisoning stuff before __builtin_stack_restore call to resolve the issue.
[Bug sanitizer/85230] asan: false positives in kernel on allocas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85230 --- Comment #7 from chefmax at gcc dot gnu.org --- (In reply to Dmitry Vyukov from comment #6) > Right! > > Unpoisoning before restoring SP looks like a reasonable and simple solution > to me. I don't see any potential downsides. > > Do you mind submitting a fix for this? > > Thanks Sure, but it seems that it's not so simple as I thought... it can make some time to cook a proper fix (although I can attach a dirty workaround for x86_64 here to unblock your progress on a kernel side).
[Bug sanitizer/85230] asan: false positives in kernel on allocas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85230 --- Comment #11 from chefmax at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #10) > Unfortunately that doesn't work, because the second argument to > __asan_allocas_unpoison is incorrect then. Unfortunately we can't use new_sp as a second parameter for __asan_allocas_unpoison, because e.g. for PowerPC it doesn't point to a new (restored) dynamic stack area (http://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi.html#DYNAM-STACK). That's why current implementation inserts __asan_allocas_unpoison after __builtin_stack_restore and uses virtual_dynamic_stack_rtx as a second argument. We can probably use a 'new_sp + STACK_DYNAMIC_OFFSET' for a second argument for __asan_allocas_unpoison inside expand_asan_emit_allocas_unpoison, but AFAIU STACK_DYNAMIC_OFFSET becomes valid only in pass_instantiate_virtual_regs (so we can't rely on it during pass_expand).
[Bug sanitizer/85230] asan: false positives in kernel on allocas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85230 --- Comment #14 from chefmax at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #13) > or introduce a new virtual pseudo register that vregs pass would map directly > to dynamic_offset. Yeah, that's what I though about (LLVM does pretty the same thing). But (new_sp + virtual_stack_dynamic_rtx - stack_pointer_rtx) seems like an appropriate solution too. I'll cover the testing for both approaches.
[Bug sanitizer/85230] asan: false positives in kernel on allocas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85230
--- Comment #17 from chefmax at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #15)
> (In reply to chefmax from comment #14)
> > (In reply to Jakub Jelinek from comment #13)
> > > or introduce a new virtual pseudo register that vregs pass would map
> > > directly to dynamic_offset.
> >
> > Yeah, that's what I though about (LLVM does pretty the same thing). But
> > (new_sp + virtual_stack_dynamic_rtx - stack_pointer_rtx) seems like an
> > appropriate solution too. I'll cover the testing for both approaches.
>
> The above patch passed
> make -j16 -k check-gcc check-g++
> RUNTESTFLAGS='--target_board=unix\{-m32,-m64\} asan.exp=alloca*'
> on x86_64-linux and powerpc64-linux and without the -m32, part also on
> powerpc64le-linux.
Nice! Jakub, would you post the patch in ML?
[Bug sanitizer/86090] [ASAN] ASAN does not properly configure libbacktrace.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86090 --- Comment #3 from chefmax at gcc dot gnu.org --- Author: chefmax Date: Wed Jun 13 19:51:42 2018 New Revision: 261564 URL: https://gcc.gnu.org/viewcvs?rev=261564&root=gcc&view=rev Log: 2018-06-13 Denis Khalikov libsanitizer/ PR sanitizer/86090 * configure.ac: Check for lstat and readlink. * configure, config.h.in: Rebuild. Modified: trunk/libsanitizer/ChangeLog trunk/libsanitizer/config.h.in trunk/libsanitizer/configure trunk/libsanitizer/configure.ac
[Bug other/86198] Libbacktrace does not properly work with ".note.gnu.build-id" section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86198 --- Comment #4 from chefmax at gcc dot gnu.org --- Author: chefmax Date: Thu Jun 21 05:42:53 2018 New Revision: 261832 URL: https://gcc.gnu.org/viewcvs?rev=261832&root=gcc&view=rev Log: libbacktrace/ 2018-06-21 Denis Khalikov PR other/86198 * elf.c (elf_add): Increase ".note.gnu.build-id" section size checking up to 36 bytes. Modified: trunk/libbacktrace/ChangeLog trunk/libbacktrace/elf.c
[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 #5 from chefmax at gcc dot gnu.org --- Author: chefmax Date: Wed Jul 4 19:49:06 2018 New Revision: 262421 URL: https://gcc.gnu.org/viewcvs?rev=262421&root=gcc&view=rev Log: gcc/ 2018-07-04 Maxim Ostapenko PR sanitizer/84250 * config/gnu-user.h (LIBASAN_EARLY_SPEC): Pass -lstdc++ for static libasan. * gcc.c: Do not pass LIBUBSAN_SPEC if ASan is enabled with UBSan. libsanitizer/ 2018-07-04 Maxim Ostapenko PR sanitizer/84250 * Makefile.am: Reorder libs. * Makefile.in: Regenerate. * asan/Makefile.am: Define DCAN_SANITIZE_UB=1, add dependancy from libsanitizer_ubsan.la. * asan/Makefile.in: Regenerate. * ubsan/Makefile.am: Define new libsanitizer_ubsan.la library. * ubsan/Makefile.in: Regenerate. Modified: trunk/gcc/ChangeLog trunk/gcc/config/gnu-user.h trunk/gcc/gcc.c trunk/libsanitizer/ChangeLog trunk/libsanitizer/Makefile.am trunk/libsanitizer/Makefile.in trunk/libsanitizer/asan/Makefile.am trunk/libsanitizer/asan/Makefile.in trunk/libsanitizer/ubsan/Makefile.am trunk/libsanitizer/ubsan/Makefile.in
[Bug objc/80798] Dynamic stack buffer (alloca) overflow in ObjC compiler.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80798 chefmax at gcc dot gnu.org changed: What|Removed |Added CC||chefmax at gcc dot gnu.org --- Comment #3 from chefmax at gcc dot gnu.org --- It seems that you have already fixed this bug by https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=259521 . Perhaps close then as a dup?
[Bug other/86656] Issues found with -fsanitize=address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86656 Bug 86656 depends on bug 80798, which changed state. Bug 80798 Summary: Dynamic stack buffer (alloca) overflow in ObjC compiler. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80798 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE
[Bug objc/80798] Dynamic stack buffer (alloca) overflow in ObjC compiler.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80798 chefmax at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from chefmax at gcc dot gnu.org --- Dup of pr85476. *** This bug has been marked as a duplicate of bug 85476 ***
[Bug objc/85476] ASAN error in finish_class ../../gcc/objc/objc-act.c:8006
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85476 chefmax at gcc dot gnu.org changed: What|Removed |Added CC||m.ostapenko at samsung dot com --- Comment #3 from chefmax at gcc dot gnu.org --- *** Bug 80798 has been marked as a duplicate of this bug. ***
[Bug sanitizer/86755] [ASAN] Libasan failed to be build for arm with -mthumb and -fno-omit-frame-pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86755 chefmax at gcc dot gnu.org changed: What|Removed |Added CC||chefmax at gcc dot gnu.org --- Comment #1 from chefmax at gcc dot gnu.org --- Upstream review: https://reviews.llvm.org/D50180
[Bug sanitizer/78651] Incorrect exception handling when catch clause uses local class and PIC and sanitizer are active
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78651 --- Comment #10 from chefmax at gcc dot gnu.org --- Seems to be closed on GCC 8 and 7, OK to close?
[Bug sanitizer/78651] Incorrect exception handling when catch clause uses local class and PIC and sanitizer are active
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78651 --- Comment #11 from chefmax at gcc dot gnu.org --- (In reply to chefmax from comment #10) > Seems to be closed on GCC 8 and 7, OK to close? s/closed/fixed/
[Bug c++/78651] Incorrect exception handling when catch clause uses local class and PIC and sanitizer are active
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78651 chefmax at gcc dot gnu.org changed: What|Removed |Added CC||chefmax at gcc dot gnu.org --- Comment #4 from chefmax at gcc dot gnu.org --- Hm, it seems that ASan is breaking internal ABI between GCC and libstdc++ by adding redzones to global .LDFCM* symbols: $ ~/install/master/bin/g++ /tmp/throws.cc -fsanitize=address -fPIC -S -o bad.s ... .LLSDACSE1: .byte 0x2 .byte 0 .byte 0x1 .byte 0x7d .align 4 .long DW.ref._ZTI1A-. .long .LDFCM0-. .LLSDATT1: ... ... ... .LDFCM0: .zero 56 <== inserted by ASan .quad _ZTIN12_GLOBAL__N_114SomeRandomTypeE .hidden DW.ref.__gxx_personality_v0 .weak DW.ref.__gxx_personality_v0 .section .data.DW.ref.__gxx_personality_v0,"awG",@progbits,DW.ref.__gxx_personality_v0,comdat .align 8 .type DW.ref.__gxx_personality_v0, @object .size DW.ref.__gxx_personality_v0, 8 AFAU, during exception handling, libstdc++ tries to obtain a pointer to `typeinfo for (anonymous namespace)::SomeRandomType' from a constant offset from `.LDFCM0' label and gets zero, because ASan added a right redzone. I suspect that not sanitizing `.LDFCM*' variables (and probably all other debug vars) should resolve the issue.
[Bug c++/78651] Incorrect exception handling when catch clause uses local class and PIC and sanitizer are active
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78651 --- Comment #5 from chefmax at gcc dot gnu.org --- Created attachment 43652 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43652&action=edit Untested fix Simple untested fix that seems to cure the issue.
[Bug sanitizer/78651] Incorrect exception handling when catch clause uses local class and PIC and sanitizer are active
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78651 --- Comment #6 from chefmax at gcc dot gnu.org --- Author: chefmax Date: Mon Mar 19 19:59:56 2018 New Revision: 258658 URL: https://gcc.gnu.org/viewcvs?rev=258658&root=gcc&view=rev Log: 2018-03-19 Maxim Ostapenko gcc/ PR sanitizer/78651 * dwarf2asm.c (dw2_output_indirect_constant_1): Disable ASan before calling assemble_variable. gcc/testsuite/ PR sanitizer/78651 * g++.dg/asan/pr78651.C: New test. Added: trunk/gcc/testsuite/g++.dg/asan/pr78651.C Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2asm.c trunk/gcc/testsuite/ChangeLog
[Bug sanitizer/87840] LSAN not always printing the leaks when -fsanitize=address is absent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87840
chefmax at gcc dot gnu.org changed:
What|Removed |Added
CC||chefmax at gcc dot gnu.org
--- Comment #10 from chefmax at gcc dot gnu.org ---
(In reply to Jan Engelhardt from comment #0)
> $ cat x.cpp
> #include
> struct S {
> std::shared_ptr other;
> };
> int main()
> {
> auto e = std::make_shared();
> e->other = e;
> }
>
> $ g++-9 x.cpp -ggdb3 -llsan -fsanitize=leak
> $ ./a.out
> $
>
> LSAN fails to report the cycle while valgrind does.
>
> Using built-in specs.
> COLLECT_GCC=g++-9
> COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/9/lto-wrapper
> OFFLOAD_TARGET_NAMES=hsa:nvptx-none
> Target: x86_64-suse-linux
> Configured with: ../configure --prefix=/usr --infodir=/usr/share/info
> --mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64
> --enable-languages=c,c++,objc,fortran,obj-c++,ada,go
> --enable-offload-targets=hsa,nvptx-none=/usr/nvptx-none,
> --without-cuda-driver --enable-checking=release --disable-werror
> --with-gxx-include-dir=/usr/include/c++/9 --enable-ssp --disable-libssp
> --disable-libvtv --disable-cet --disable-libcc1 --enable-plugin
> --with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux'
> --with-slibdir=/lib64 --with-system-zlib --enable-libstdcxx-allocator=new
> --disable-libstdcxx-pch --enable-version-specific-runtime-libs
> --with-gcc-major-version-only --enable-linker-build-id --enable-linux-futex
> --enable-gnu-indirect-function --program-suffix=-9
> --without-system-libunwind --enable-multilib --with-arch-32=x86-64
> --with-tune=generic --build=x86_64-suse-linux --host=x86_64-suse-linux
> Thread model: posix
> gcc version 9.0.0 20181026 (experimental) [trunk revision 265522] (SUSE
> Linux)
> Applies to
> gcc version 8.2.1 20180831 [gcc-8-branch revision 264010] (SUSE Linux)
> gcc version 7.3.1 20180817 [gcc-7-branch revision 263612] (SUSE Linux)
> as well.
I can confirm this with master GCC:
$ ~/install/master/bin/g++ x.cpp -ggdb3 -fsanitize=leak -static-liblsan ;
LSAN_OPTIONS=log_pointers=1:log_threads=1 ./a.out
==9273==Scanning GLOBAL range 0x00651000-0x00654fe0.
==9273==Scanning GLOBAL range 0x006552a8-0x00ee86e8.
==9273==Scanning GLOBAL range 0x7fa92c405308-0x7fa92c4140a0.
==9273==0x7fa92c410ca8: found 0x6310 pointing into chunk
0x6310-0x63111c00 of size 72704.
==9273==Scanning GLOBAL range 0x7fa92c090d70-0x7fa92c0910f8.
==9273==Scanning GLOBAL range 0x7fa92bd87d60-0x7fa92bd880f0.
==9273==Scanning GLOBAL range 0x7fa92bb83d58-0x7fa92bb84bc0.
==9273==Scanning GLOBAL range 0x7fa92b977b78-0x7fa92b97c428.
==9273==Scanning GLOBAL range 0x7fa92b75edc8-0x7fa92b75f450.
==9273==Scanning GLOBAL range 0x7fa92b53f7c0-0x7fa92b5489a0.
==9273==Scanning GLOBAL range 0x7fa92c63abc0-0x7fa92c63c168.
==9273==Processing thread 9272.
==9273==Scanning REGISTERS range 0x7fa92c5ff000-0x7fa92c5ff0d8.
==9273==Stack at 0x7ffe51e77000-0x7ffe52677000 (SP = 0x7ffe52674a28).
==9273==Scanning STACK range 0x7ffe52674a28-0x7ffe52677000.
==9273==0x7ffe52674bf8: found 0x6028 pointing into chunk
0x6020-0x60200020 of size 32.
==9273==TLS at 0x7fa92c5e2000-0x7fa92c5f0c00.
==9273==Scanning TLS range 0x7fa92c5e2000-0x7fa92c5e2758.
==9273==Scanning TLS range 0x7fa92c5f02d8-0x7fa92c5f0c00.
==9273==Scanning HEAP range 0x6020-0x60200020.
==9273==Scanning HEAP range 0x6310-0x63111c00.
==9273==Processing platform-specific allocations.
==9273==Scanning leaked chunks
>From the log I can see that pointer to allocated chunk still reachable from
main thread stack.
I'm not sure why this doesn't happen with ASan enabled, perhaps it performs
some stack cleanup before exit and rewrites this pointer.
Anyways, I don't see any opportunity to fix this in LSan in its current usage
model.
FWIW upstream has several similar reports, see e.g.
https://github.com/google/sanitizers/issues/937
[Bug sanitizer/88022] New: Support dynamic shadow offset in ASan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88022 Bug ID: 88022 Summary: Support dynamic shadow offset in ASan Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: chefmax at gcc dot gnu.org 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, marxin at gcc dot gnu.org Target Milestone: --- This is a possible feature for GCC 10. The possibility of setting ASan shadow offset dynamically is discussed many times and recent libsanitizer already supports it for Android and Windows. Although Linux is not supported yet, it seems that code for Android can be reused quite easily. Mainly, we'll need to tweak ifdefs in libsanitizer and add support on compiler side (which won't be hard). Preliminary performance numbers can be obtained from here: https://github.com/google/sanitizers/issues/837
[Bug sanitizer/88022] Support dynamic shadow offset in ASan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88022 --- Comment #2 from chefmax at gcc dot gnu.org --- I think nothing prevents us from trying several ranges, the question is whether upstream guys will accept this... I've just noticed that the code for dynamic shadow offset is already present in libsanitizer sources and it seems that it's not hard to enable it for Linux.
[Bug testsuite/63292] ASan reports global-buffer-overflow in gcc.dg/vect/pr59594.c.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63292 chefmax at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||chefmax at gcc dot gnu.org Resolution|--- |FIXED --- Comment #4 from chefmax at gcc dot gnu.org --- sure
[Bug sanitizer/88022] Support dynamic shadow offset in ASan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88022 --- Comment #5 from chefmax at gcc dot gnu.org --- (In reply to Martin Liška from comment #4) > Agree with Jakub that if really not necessary, I wouldn't complicate > libsanitizer. My point was that we won't need to complicate libsanitizer -- almost all necessary code is already there, just need to enable it for Linux. > Slowness is nicely seen in your table Maxim: > https://github.com/google/sanitizers/issues/837#issuecomment-322519336 > > Can you Maximum more describe which difficulties do you see using > libsanitizer on 32-bit ARM target? AFAIR we had problems with PIE binaries on ARM (and we still have them). Anyways, if you don't interested, I'm not insist on implementing this feature in GCC. Just be informed that sanitizer runtime is almost ready for this to be implemented.
[Bug sanitizer/81697] Incorrect ASan global variables alignment on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81697 chefmax at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||chefmax at gcc dot gnu.org Resolution|--- |FIXED --- Comment #7 from chefmax at gcc dot gnu.org --- sure
[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 #8 from chefmax at gcc dot gnu.org --- (In reply to Martin Liška from comment #7) > Maxim, Jakub: Can the bug be marked as resolved? Or at least update Known to > work? Hm, I think the bug is still present -- the first fix was reverted and I haven't cooked a proper fix since then.
[Bug sanitizer/78878] stacktrace engine can't use compressed/separated debug info for extracting symbols.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78878 --- Comment #2 from chefmax at gcc dot gnu.org --- Should be fixed, I guess, by: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67165 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77631
[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 #6 from chefmax at gcc dot gnu.org --- Author: chefmax Date: Tue Apr 5 11:52:34 2016 New Revision: 234744 URL: https://gcc.gnu.org/viewcvs?rev=234744&root=gcc&view=rev Log: Cherry-pick r224315,221379 and r241487 from upstream. libsanitizer/ PR sanitizer/70474 * asan/asan_mac.cc (GetMacosVersionInternal): Cherry pick upstream r241487, 221379 and r224315. (void MaybeReexec): Cherry pick upstream r241487. * asan/asan_mac.h (enum MacosVersion): Cherry pick upstream r224315. Modified: branches/gcc-4_9-branch/libsanitizer/ChangeLog branches/gcc-4_9-branch/libsanitizer/asan/asan_mac.cc branches/gcc-4_9-branch/libsanitizer/asan/asan_mac.h
[Bug sanitizer/70541] unnoticed invalid dereference when using address sanitizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70541 --- Comment #5 from chefmax at gcc dot gnu.org --- Author: chefmax Date: Fri Apr 8 10:46:13 2016 New Revision: 234827 URL: https://gcc.gnu.org/viewcvs?rev=234827&root=gcc&view=rev Log: 2016-04-08 Maxim Ostapenko PR sanitizer/70541 * asan.c (instrument_derefs): If we get unknown location, extract it with EXPR_LOCATION. (maybe_instrument_call): Instrument gimple_call's arguments if needed. * c-c++-common/asan/pr70541.c: New test. Added: trunk/gcc/testsuite/c-c++-common/asan/pr70541.c Modified: trunk/gcc/ChangeLog trunk/gcc/asan.c trunk/gcc/testsuite/ChangeLog
[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 #10 from chefmax at gcc dot gnu.org --- Author: chefmax Date: Thu Apr 21 12:12:53 2016 New Revision: 235337 URL: https://gcc.gnu.org/viewcvs?rev=235337&root=gcc&view=rev Log: Cherry-pick r266868 from upstream. PR sanitizer/70624 * asan/asan_mac.cc: Cherry pick upstream r266868. Modified: branches/gcc-6-branch/libsanitizer/ChangeLog branches/gcc-6-branch/libsanitizer/asan/asan_mac.cc
[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 #11 from chefmax at gcc dot gnu.org --- Author: chefmax Date: Thu Apr 21 12:19:54 2016 New Revision: 235338 URL: https://gcc.gnu.org/viewcvs?rev=235338&root=gcc&view=rev Log: Cherry-pick r266868 from upstream. PR sanitizer/70624 * asan/asan_mac.cc: Cherry pick upstream r266868. Modified: trunk/libsanitizer/ChangeLog trunk/libsanitizer/asan/asan_mac.cc
[Bug sanitizer/64354] no preprocessor symbol __SANITIZE_THREAD__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64354 --- Comment #2 from chefmax at gcc dot gnu.org --- Author: chefmax Date: Thu May 19 12:05:59 2016 New Revision: 236457 URL: https://gcc.gnu.org/viewcvs?rev=236457&root=gcc&view=rev Log: 2016-05-19 Maxim Ostapenko PR sanitizer/64354 * cppbuiltin.c (define_builtin_macros_for_compilation_flags): Add new builtin __SANITIZE_THREAD__ macros for fsanitize=thread switch. * doc/cpp.texi: Document new macros. * c-c++-common/tsan/sanitize-thread-macro.c: New test. Added: trunk/gcc/testsuite/c-c++-common/tsan/sanitize-thread-macro.c Modified: trunk/gcc/ChangeLog trunk/gcc/cppbuiltin.c trunk/gcc/doc/cpp.texi trunk/gcc/testsuite/ChangeLog
[Bug sanitizer/71480] ASan should align string constants to shadow granularity.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71480 --- Comment #4 from chefmax at gcc dot gnu.org --- Author: chefmax Date: Fri Jun 10 12:57:14 2016 New Revision: 237306 URL: https://gcc.gnu.org/viewcvs?rev=237306&root=gcc&view=rev Log: 2016-06-10 Maxim Ostapenko PR sanitizer/71480 * varasm.c (place_block_symbol): Adjust alignment for asan protected STRING_CSTs even if TREE_CONSTANT_POOL_ADDRESS_P. * c-c++-common/asan/pr71480.c: New test. Added: trunk/gcc/testsuite/c-c++-common/asan/pr71480.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/varasm.c
[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 --- Comment #8 from chefmax at gcc dot gnu.org --- Author: chefmax Date: Thu Aug 17 11:58:13 2017 New Revision: 251145 URL: https://gcc.gnu.org/viewcvs?rev=251145&root=gcc&view=rev Log: 2017-08-17 Maxim Ostapenko PR target/81861 * config/i386/i386.c (ix86_option_override_internal): Save target specific options after ix86_stack_protector_guard_reg was changed. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c
[Bug tree-optimization/67328] range test rather than single bit test for code testing enum values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67328 --- Comment #7 from chefmax at gcc dot gnu.org --- Author: chefmax Date: Tue Jun 13 11:13:52 2017 New Revision: 249149 URL: https://gcc.gnu.org/viewcvs?rev=249149&root=gcc&view=rev Log: 2017-06-13 Yury Gribov gcc/ PR tree-optimization/67328 * fold-const.c (maskable_range_p): New function. (build_range_check): Generate bittests if possible. gcc/testsuite/ PR tree-optimization/67328 * c-c++-common/fold-masked-cmp-1.c: New test. * c-c++-common/fold-masked-cmp-2.c: Likewise. * gcc.dg/pr46309.c: Fix pattern. * gcc.dg/pr46309-2.c: Likewise. Added: trunk/gcc/testsuite/c-c++-common/fold-masked-cmp-1.c trunk/gcc/testsuite/c-c++-common/fold-masked-cmp-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/pr46309-2.c trunk/gcc/testsuite/gcc.dg/pr46309.c
[Bug bootstrap/80565] [8 Regression] ICE at -O2 and -O3 in 32-bit mode (not 64-bit) on x86_64-linux-gnu (in edge_badness, at ipa-inline.c:1028)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80565 --- Comment #3 from chefmax at gcc dot gnu.org --- Author: chefmax Date: Thu Jun 29 08:50:21 2017 New Revision: 249771 URL: https://gcc.gnu.org/viewcvs?rev=249771&root=gcc&view=rev Log: 2017-06-29 Yury Gribov PR bootstrap/80565 * ipa-cp.c (allocate_and_init_ipcp_value): Add initialization code. * ipa-inline.h (edge_growth_cache_entry::edge_growth_cache_entry): New function. (reset_edge_growth_cache): Update to use constructor. Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-cp.c trunk/gcc/ipa-inline.h
[Bug sanitizer/78532] [7 Regression] libsanitizer fails to build on sparc64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78532 --- Comment #8 from chefmax at gcc dot gnu.org --- Author: chefmax Date: Wed Nov 30 12:31:07 2016 New Revision: 243014 URL: https://gcc.gnu.org/viewcvs?rev=243014&root=gcc&view=rev Log: PR sanitizer/78532 * sanitizer_common/sanitizer_platform_limits_posix.h (__sanitizer_sigaction): Adjust for sparc targets and various Glibc versions. Modified: trunk/libsanitizer/ChangeLog trunk/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h
[Bug sanitizer/78532] [7 Regression] libsanitizer fails to build on sparc64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78532 --- Comment #9 from chefmax at gcc dot gnu.org --- Author: chefmax Date: Wed Nov 30 12:32:55 2016 New Revision: 243016 URL: https://gcc.gnu.org/viewcvs?rev=243016&root=gcc&view=rev Log: Add PR sanitizer/78532 patch to libsanitizer/LOCAL_PATCHES. Modified: trunk/libsanitizer/ChangeLog trunk/libsanitizer/LOCAL_PATCHES
[Bug lto/79042] LTO doesn't propagate node->dynamically_initialized bit for varpool nodes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79042 --- Comment #2 from chefmax at gcc dot gnu.org --- Author: chefmax Date: Wed Jan 11 12:57:42 2017 New Revision: 244314 URL: https://gcc.gnu.org/viewcvs?rev=244314&root=gcc&view=rev Log: PR lto/79042 * lto-cgraph.c (lto_output_varpool_node): Pack dynamically_initialized bit. (input_varpool_node): Unpack dynamically_initialized bit. Modified: trunk/gcc/ChangeLog trunk/gcc/lto-cgraph.c
[Bug lto/79042] LTO doesn't propagate node->dynamically_initialized bit for varpool nodes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79042 --- Comment #3 from chefmax at gcc dot gnu.org --- Author: chefmax Date: Wed Jan 11 16:53:52 2017 New Revision: 244324 URL: https://gcc.gnu.org/viewcvs?rev=244324&root=gcc&view=rev Log: PR lto/79042 * lto-cgraph.c (lto_output_varpool_node): Pack dynamically_initialized bit. (input_varpool_node): Unpack dynamically_initialized bit. * lto-streamer.h (LTO_minor_version): Bump version. Modified: branches/gcc-6-branch/gcc/ChangeLog branches/gcc-6-branch/gcc/lto-cgraph.c branches/gcc-6-branch/gcc/lto-streamer.h
[Bug lto/79042] LTO doesn't propagate node->dynamically_initialized bit for varpool nodes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79042 --- Comment #4 from chefmax at gcc dot gnu.org --- Author: chefmax Date: Thu Jan 12 07:44:17 2017 New Revision: 244347 URL: https://gcc.gnu.org/viewcvs?rev=244347&root=gcc&view=rev Log: PR lto/79042 * lto-cgraph.c (lto_output_varpool_node): Pack dynamically_initialized bit. (input_varpool_node): Unpack dynamically_initialized bit. * lto-streamer.h (LTO_minor_version): Bump version. Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/lto-cgraph.c branches/gcc-5-branch/gcc/lto-streamer.h
[Bug sanitizer/78887] [7 Regression] Failure to build aarch64 allmodconfig Linux kernel 4.9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78887 --- Comment #8 from chefmax at gcc dot gnu.org --- Author: chefmax Date: Fri Jan 13 10:08:50 2017 New Revision: 244402 URL: https://gcc.gnu.org/viewcvs?rev=244402&root=gcc&view=rev Log: PR sanitizer/78887 * asan.c (asan_needs_odr_indicator_p): Don't emit ODR indicators if -fsanitize=kernel-address is present. Modified: trunk/gcc/ChangeLog trunk/gcc/asan.c
[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 #15 from chefmax at gcc dot gnu.org --- Author: chefmax Date: Wed Jan 18 16:06:31 2017 New Revision: 244581 URL: https://gcc.gnu.org/viewcvs?rev=244581&root=gcc&view=rev Log: PR lto/79061 gcc/ * asan.c (get_translation_unit_decl): New function. (asan_add_global): Extract modules file name from globals TRANSLATION_UNIT_DECL in lto mode. * tree.c (build_translation_unit_decl): Add source location for newly built TRANSLATION_UNIT_DECL. gcc/lto/ * lto.c (lto_read_decls): accept location cache for TRANSLATION_UNIT_DECL. gcc/testsuite/ * gcc.dg/cpp/mi1.c: Adjust testcase. * gcc.dg/pch/cpp-3.c: Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/asan.c trunk/gcc/lto/ChangeLog trunk/gcc/lto/lto.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/cpp/mi1.c trunk/gcc/testsuite/gcc.dg/pch/cpp-3.c trunk/gcc/tree.c
[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 #17 from chefmax at gcc dot gnu.org --- Author: chefmax Date: Mon Jan 23 09:12:29 2017 New Revision: 244773 URL: https://gcc.gnu.org/viewcvs?rev=244773&root=gcc&view=rev Log: Revert fix for PR lto/79061 due to this regresses compile-time by 100% on some fortran cases. Modified: trunk/gcc/ChangeLog trunk/gcc/asan.c trunk/gcc/lto/ChangeLog trunk/gcc/lto/lto.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/cpp/mi1.c trunk/gcc/testsuite/gcc.dg/pch/cpp-3.c trunk/gcc/tree.c
[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 #19 from chefmax at gcc dot gnu.org --- Author: chefmax Date: Wed Jan 25 07:45:40 2017 New Revision: 244890 URL: https://gcc.gnu.org/viewcvs?rev=244890&root=gcc&view=rev Log: PR lto/79061 gcc/ * asan.c (get_translation_unit_decl): New function. (asan_add_global): Extract modules file name from globals TRANSLATION_UNIT_DECL name. gcc/fortran/ * f95-lang.c (gfc_create_decls): Include stringpool.h. Pass main_input_filename to build_translation_unit_decl. gcc/ada/ * gcc-interface/utils.c (get_global_context): Pass main_input_filename to build_translation_unit_decl. gcc/c/ * c-decl.c (pop_scope): Pass main_input_filename to build_translation_unit_decl. gcc/cp/ * decl.c (cxx_init_decl_processing): Pass main_input_filename to build_translation_unit_decl. Modified: trunk/gcc/ChangeLog trunk/gcc/ada/ChangeLog trunk/gcc/ada/gcc-interface/utils.c trunk/gcc/asan.c trunk/gcc/c/ChangeLog trunk/gcc/c/c-decl.c trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/f95-lang.c
[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 #30 from chefmax at gcc dot gnu.org --- Author: chefmax Date: Mon Jan 30 16:06:15 2017 New Revision: 245033 URL: https://gcc.gnu.org/viewcvs?rev=245033&root=gcc&view=rev Log: PR lto/79061 * asan.c (get_translation_unit_decl): Remove function. (asan_add_global): Force has_dynamic_init to zero in LTO mode. Modified: trunk/gcc/ChangeLog trunk/gcc/asan.c
[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 #32 from chefmax at gcc dot gnu.org --- Author: chefmax Date: Fri Feb 3 07:17:38 2017 New Revision: 245144 URL: https://gcc.gnu.org/viewcvs?rev=245144&root=gcc&view=rev Log: PR lto/79061 * asan.c (asan_add_global): Force has_dynamic_init to zero in LTO mode. Modified: branches/gcc-6-branch/gcc/ChangeLog branches/gcc-6-branch/gcc/asan.c
[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 #33 from chefmax at gcc dot gnu.org --- Author: chefmax Date: Fri Feb 3 09:13:06 2017 New Revision: 245148 URL: https://gcc.gnu.org/viewcvs?rev=245148&root=gcc&view=rev Log: PR lto/79061 * asan.c (asan_add_global): Force has_dynamic_init to zero in LTO mode. Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/asan.c
[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 #9 from chefmax at gcc dot gnu.org --- Author: chefmax Date: Fri Feb 3 12:17:59 2017 New Revision: 245149 URL: https://gcc.gnu.org/viewcvs?rev=245149&root=gcc&view=rev Log: PR sanitizer/78663 * sanitizer_common/sanitizer_mac.cc: Cherry-pick upstream r293992. * sanitizer_common/sanitizer_platform_interceptors.h: Likewise. Modified: trunk/libsanitizer/ChangeLog trunk/libsanitizer/sanitizer_common/sanitizer_mac.cc trunk/libsanitizer/sanitizer_common/sanitizer_platform_interceptors.h
[Bug sanitizer/80414] [UBSAN] segfault with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80414 --- Comment #1 from chefmax at gcc dot gnu.org --- Author: chefmax Date: Thu Apr 13 14:52:23 2017 New Revision: 246909 URL: https://gcc.gnu.org/viewcvs?rev=246909&root=gcc&view=rev Log: PR sanitizer/80414 * ubsan.c (ubsan_expand_bounds_ifn): Pass original index to ubsan_encode_value. * c-c++-common/ubsan/bounds-15.c: New test. Added: trunk/gcc/testsuite/c-c++-common/ubsan/bounds-15.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/ubsan.c
[Bug sanitizer/81697] Incorrect ASan global variables alignment on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81697 --- Comment #4 from chefmax at gcc dot gnu.org --- Author: chefmax Date: Thu Nov 30 21:38:16 2017 New Revision: 255283 URL: https://gcc.gnu.org/viewcvs?rev=255283&root=gcc&view=rev Log: gcc/ 2017-11-30 Maxim Ostapenko PR sanitizer/81697 * asan.c (asan_protect_global): Add new ignore_decl_rtl_set_p parameter. Return true if ignore_decl_rtl_set_p is true and other conditions are satisfied. * asan.h (asan_protect_global): Add new parameter. * varasm.c (categorize_decl_for_section): Pass true as second parameter to asan_protect_global calls. gcc/testsuite/ 2017-11-30 Maxim Ostapenko PR sanitizer/81697 * c-c++-common/asan/pr81697.c: New test. Added: trunk/gcc/testsuite/c-c++-common/asan/pr81697.c Modified: trunk/gcc/ChangeLog trunk/gcc/asan.c trunk/gcc/asan.h trunk/gcc/testsuite/ChangeLog trunk/gcc/varasm.c
[Bug sanitizer/63958] [5 Regression] bootstrap failure in the sanitizer libs on sparc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63958 --- Comment #15 from chefmax at gcc dot gnu.org --- Author: chefmax Date: Tue Nov 8 22:06:02 2016 New Revision: 241978 URL: https://gcc.gnu.org/viewcvs?rev=241978&root=gcc&view=rev Log: PR sanitizer/63958 Reapply: 2014-10-14 David S. Miller * sanitizer_common/sanitizer_platform_limits_linux.cc (time_t): Define at __kernel_time_t, as needed for sparc. (struct __old_kernel_stat): Don't check if __sparc__ is defined. * libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h (__sanitizer): Define struct___old_kernel_stat_sz, struct_kernel_stat_sz, and struct_kernel_stat64_sz for sparc. (__sanitizer_ipc_perm): Adjust for sparc targets. (__sanitizer_shmid_ds): Likewsie. (__sanitizer_sigaction): Likewise. (IOC_SIZE): Likewsie. Modified: trunk/libsanitizer/ChangeLog trunk/libsanitizer/sanitizer_common/sanitizer_platform_limits_linux.cc trunk/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h
[Bug sanitizer/78307] [7 Regression] missing symbols in libubsan without changing the soname
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78307 --- Comment #8 from chefmax at gcc dot gnu.org --- Author: chefmax Date: Wed Nov 16 11:13:19 2016 New Revision: 242478 URL: https://gcc.gnu.org/viewcvs?rev=242478&root=gcc&view=rev Log: PR sanitizer/78307 * ubsan/ubsan_handlers.cc (__ubsan_handle_cfi_bad_icall): New function. ( __ubsan_handle_cfi_bad_icall_abort): Likewise. * ubsan/ubsan_handlers.h (struct CFIBadIcallData): New type. * ubsan/ubsan_handlers_cxx.cc (__ubsan_handle_cfi_bad_type): New function. (__ubsan_handle_cfi_bad_type_abort): Likewise. * ubsan/ubsan_handlers_cxx.h (struct CFIBadTypeData): New type. (__ubsan_handle_cfi_bad_type): Export function. (__ubsan_handle_cfi_bad_type_abort): Likewise. * HOWTO_MERGE: Update documentation. Modified: trunk/libsanitizer/ChangeLog trunk/libsanitizer/HOWTO_MERGE trunk/libsanitizer/ubsan/ubsan_handlers.cc trunk/libsanitizer/ubsan/ubsan_handlers.h trunk/libsanitizer/ubsan/ubsan_handlers_cxx.cc trunk/libsanitizer/ubsan/ubsan_handlers_cxx.h
[Bug other/60681] New: Libbacktrace library doesn't work with QEMU in application mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60681 Bug ID: 60681 Summary: Libbacktrace library doesn't work with QEMU in application mode Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: chefmax at gcc dot gnu.org CC: v.garbuzov at samsung dot com, y.gribov at samsung dot com The libbacktrace library doesn't work well with QEMU in application mode. $ arm-linux-gnueabi-gcc -fsanitize=address -g gcc/testsuite/c-c++-common/asan/null-deref-1.c $ qemu-arm -cpu cortex-a15 -L /home/max/install/gcc-upstream-arm/arm-linux-gnueabi/sys-root/ -R 0 -E LD_LIBRARY_PATH=/home/max/install/gcc-upstream-arm/arm-linux-gnueabi/lib/ ./a.out ... #0 0x873f (/home/max/build/gcc-upstream-arm/a.out+0x873f) #1 0x876f (/home/max/build/gcc-upstream-arm/a.out+0x876f) #2 0x40ddb507 (/lib/libc.so.6+0x18507) When running the same binary on the target board, libbacktrace works well: -sh-4.1$ ./a.out ... #0 0x873f in NullDeref /home/m.ostapenko/null-deref-1.c:10 #1 0x876f in main /home/m.ostapenko/null-deref-1.c:15 #2 0xb6855507 in __libc_start_main /home/max/build.arm.cortex-a15/sources/glibc/libc/csu/libc-start.c:269 After investigation I discovered that libbacktrace scans /proc/self/exe to init symbolizer and in QEMU case it finds information about qemu-arm binary itself, not a.out. Is it a real bug or we should leave this as it is now? Perhaps I should report this to QEMU developers?
[Bug sanitizer/61530] [4.10 Regression] segfault with asan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61530 --- Comment #7 from Maxim Ostapenko --- Author: chefmax Date: Fri Jun 20 10:26:55 2014 New Revision: 211846 URL: https://gcc.gnu.org/viewcvs?rev=211846&root=gcc&view=rev Log: 2014-06-18 Yury Gribov gcc/ PR sanitizer/61530 * asan.c (build_check_stmt): Add condition. gcc/testsuite/ * c-c++-common/asan/pr61530.c: New test. Added: trunk/gcc/testsuite/c-c++-common/asan/pr61530.c Modified: trunk/gcc/ChangeLog trunk/gcc/asan.c trunk/gcc/testsuite/ChangeLog
[Bug sanitizer/64820] Libsanitizer fails with ((AddrIsAlignedByGranularity(addr + size))) != (0)" (0x0, 0x0) if ssp is enabled.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64820 --- Comment #2 from Maxim Ostapenko --- Author: chefmax Date: Mon Mar 16 11:17:32 2015 New Revision: 221457 URL: https://gcc.gnu.org/viewcvs?rev=221457&root=gcc&view=rev Log: 2015-03-16 Max Ostapenko PR sanitizer/64820 gcc/ * cfgexpand.c (align_base): New function. (alloc_stack_frame_space): Call it. (expand_stack_vars): Align prev_frame to be sure data->asan_vec elements aligned properly. gcc/testsuite/ * c-c++-common/asan/pr64820.c: New test. Added: trunk/gcc/testsuite/c-c++-common/asan/pr64820.c Modified: trunk/gcc/ChangeLog trunk/gcc/cfgexpand.c trunk/gcc/testsuite/ChangeLog
[Bug sanitizer/64820] Libsanitizer fails with ((AddrIsAlignedByGranularity(addr + size))) != (0)" (0x0, 0x0) if ssp is enabled.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64820 --- Comment #4 from Maxim Ostapenko --- Fixed by r22145.
[Bug sanitizer/64820] Libsanitizer fails with ((AddrIsAlignedByGranularity(addr + size))) != (0)" (0x0, 0x0) if ssp is enabled.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64820 Maxim Ostapenko changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #5 from Maxim Ostapenko --- Fixed.
[Bug target/65624] New: ICE in aarch64-builtins.c when expanding 4-argument aarch64 intrinsic.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65624 Bug ID: 65624 Summary: ICE in aarch64-builtins.c when expanding 4-argument aarch64 intrinsic. Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: chefmax at gcc dot gnu.org Host: i686-linux-gnu Target: aarch64-linux-gnu Build: i686-pc-linux-gnu Created attachment 35178 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35178&action=edit Reprocase. When testing cross toolchain for AArch64 on 32 bit host (i686), I ran to the such issue: $ /home/m.ostapenko/jazz64/vd49_a5x/toolchain/aarch64-tizen/libexec/gcc/aarch64-tizen-linux-gnueabi/5.0.0/cc1 -quiet ref_vqdmlsl_lane.c -quiet -dumpbase ref_vqdmlsl_lane.c -march=armv8-a+simd -mlittle-endian -mabi=lp64 -auxbase-strip ref_vqdmlsl_lane.gccarm.o -g -Wall -Wno-unused-variable -Wno-unused-function -Wno-error=unused-local-typedefs -fshort-wchar -freport-bug // In file included from ref_vqdmlal_lane.c:27:0, // from ref_vqdmlsl_lane.c:29: // /home/m.ostapenko/jazz64/vd49_a5x/toolchain/aarch64-tizen/lib/gcc/aarch64-tizen-linux-gnueabi/5.0.0/include/arm_neon.h: In function 'exec_vqdmlsl_lane': // /home/m.ostapenko/jazz64/vd49_a5x/toolchain/aarch64-tizen/lib/gcc/aarch64-tizen-linux-gnueabi/5.0.0/include/arm_neon.h:19165:10: internal compiler error: tree check: accessed operand 8 of call_expr with 7 operands in aarch64_simd_expand_args, at config/aarch64/aarch64-builtins.c:915 //return __builtin_aarch64_sqdmlsl_lanev4hi (__a, __b, __c, __d); // ^ // 0x89b4948 tree_operand_check_failed(int, tree_node const*, char const*, int, char const*) // >/home/m.ostapenko/jazz64/vd49_a5x/toolchain/build/sources/gcc_1/gcc/tree.c:9507 // 0x8a3c9f9 tree_operand_check // >/home/m.ostapenko/jazz64/vd49_a5x/toolchain/build/sources/gcc_1/gcc/tree.h:3346 // 0x8a3c9f9 aarch64_simd_expand_args // >/home/m.ostapenko/jazz64/vd49_a5x/toolchain/build/sources/gcc_1/gcc/config/aarch64/aarch64-builtins.c:915 // 0x8a3c9f9 aarch64_simd_expand_builtin(int, tree_node*, rtx_def*) // >/home/m.ostapenko/jazz64/vd49_a5x/toolchain/build/sources/gcc_1/gcc/config/aarch64/aarch64-builtins.c:1075 // 0x828256b expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int) // >/home/m.ostapenko/jazz64/vd49_a5x/toolchain/build/sources/gcc_1/gcc/builtins.c:5967 // 0x83a3bb0 expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) // >/home/m.ostapenko/jazz64/vd49_a5x/toolchain/build/sources/gcc_1/gcc/expr.c:10489 // 0x83b0ce6 store_expr_with_bounds(tree_node*, rtx_def*, int, bool, tree_node*) // >/home/m.ostapenko/jazz64/vd49_a5x/toolchain/build/sources/gcc_1/gcc/expr.c:5385 // 0x83b37c9 expand_assignment(tree_node*, tree_node*, bool) // >/home/m.ostapenko/jazz64/vd49_a5x/toolchain/build/sources/gcc_1/gcc/expr.c:5154 // 0x82a9a6e expand_call_stmt // >/home/m.ostapenko/jazz64/vd49_a5x/toolchain/build/sources/gcc_1/gcc/cfgexpand.c:2397 // 0x82a9a6e expand_gimple_stmt_1 // >/home/m.ostapenko/jazz64/vd49_a5x/toolchain/build/sources/gcc_1/gcc/cfgexpand.c:3343 // 0x82a9a6e expand_gimple_stmt // >/home/m.ostapenko/jazz64/vd49_a5x/toolchain/build/sources/gcc_1/gcc/cfgexpand.c:3497 // 0x82aaf80 expand_gimple_basic_block // >/home/m.ostapenko/jazz64/vd49_a5x/toolchain/build/sources/gcc_1/gcc/cfgexpand.c:5509 // 0x82ad761 execute // >/home/m.ostapenko/jazz64/vd49_a5x/toolchain/build/sources/gcc_1/gcc/cfgexpand.c:6127 // Please submit a full bug report, // with preprocessed source if appropriate. // Please include the complete backtrace with any bug report. // See <http://gcc.gnu.org/bugs.html> for instructions. Looking to the GCC source code (aarch64_simd_expand_builtin function), I've noticed that all arguments and return value types are stored to args[SIMD_MAX_BUILTIN_ARGS] array. In aarch64_simd_expand_builtin, we also write special SIMD_ARG_STOP indicator to this array after all arguments. But if we have 4-argument intrinsic with return value, we will overflow args[SIMD_MAX_BUILTIN_ARGS] with SIMD_ARG_STOP since SIMD_MAX_BUILTIN_ARGS is defined as 5. I'm attaching preprocessed reprocase and trivial fix. max@max:~/build$ aarch64-tizen-linux-gnueabi-gcc -v // Configured with: /home/m.ostapenko/jazz64/vd49_a5x/toolchain/build/sources/gcc_1/configure --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --target=aarch64-tizen-linux-gnueabi --prefix=/home/m.ostapenko/jazz64/vd49_a5x/toolchain/aarch64-tizen --with-sysroot=/home/m.ostapenko/jazz64/vd49_a5x/toolchain/aarch64-tizen/aarch64-tizen-linux-gnueabi/sys-root --disable-libmudflap --enable-libssp --disable-nls --disable-libstdcxx-pch --disable-multilib --disable-gnu-unique-objec
[Bug target/65624] ICE in aarch64-builtins.c when expanding 4-argument aarch64 intrinsic.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65624 --- Comment #1 from Maxim Ostapenko --- Created attachment 35179 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35179&action=edit Trivial fix Trivial fix.
[Bug target/65624] ICE in aarch64-builtins.c when expanding 4-argument aarch64 intrinsic.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65624
--- Comment #4 from Maxim Ostapenko ---
(In reply to ktkachov from comment #3)
> Actually, r218021 touches the argument expansion rather than builtin
> expansion functions, so I'm not sure that would fix it. But still, I can't
> reproduce this on current trunk with aarch64-none-linux-gnu
I'm sorry, but did you try to reproduce on i686 host? This is the only host I
can reproduce this on, for x86_64 everything is fine.
When aarch64_simd_expand_builtin fills args array for 4-argument intrinsic with
return value, it feels it with values like this:
1070 args[k] = SIMD_ARG_STOP;
(gdb) p args
$4 = {SIMD_ARG_COPY_TO_REG, SIMD_ARG_COPY_TO_REG, SIMD_ARG_COPY_TO_REG,
SIMD_ARG_COPY_TO_REG, SIMD_ARG_LANE_INDEX}
(gdb) p args[5]
$6 = SIMD_ARG_STOP
Note, that SIMD_ARG_STOP was written right after args array, since it's size is
5. Isn't it a UB here?
[Bug target/65624] ICE in aarch64-builtins.c when expanding 4-argument aarch64 intrinsic.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65624 --- Comment #6 from Maxim Ostapenko --- Author: chefmax Date: Wed Apr 1 11:18:03 2015 New Revision: 221807 URL: https://gcc.gnu.org/viewcvs?rev=221807&root=gcc&view=rev Log: 2015-04-01 Max Ostapenko PR target/65624 gcc/ * config/aarch64/aarch64-builtins.c (aarch64_simd_expand_builtin): Increase args array size by one to avoid buffer overflow. gcc/testsuite/ * gcc.target/aarch64/pr65624.c: New test. Added: trunk/gcc/testsuite/gcc.target/aarch64/pr65624.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/aarch64/aarch64-builtins.c trunk/gcc/testsuite/ChangeLog
[Bug target/65624] ICE in aarch64-builtins.c when expanding 4-argument aarch64 intrinsic.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65624 Maxim Ostapenko changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Maxim Ostapenko --- Fixed.
[Bug c++/57271] ARM: gcc generates insufficient alignment for memory passed as extra argument for function return large composite type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57271
Maxim Ostapenko changed:
What|Removed |Added
Target|arm |arm-linux-gnueabi
CC||chefmax at gcc dot gnu.org,
||ygribov at gcc dot gnu.org
Host||x86_64-pc-linux-gnu
Known to fail||6.0
--- Comment #7 from Maxim Ostapenko ---
I've ran to the exactly the same issue on armv7-a (cortex-A8) target with trunk
compiler and pr55073.C testcase:
$ ~/install/gcc-trunk-arm/armv7l-tizen/bin/armv7l-tizen-linux-gnueabi-gcc
~/workspace/downloads/gcc/gcc/testsuite/gcc.target/arm/pr55073.C -O2
-mcpu=cortex-a8 -lm -o ./pr55073.exe
$ ~/install/gcc-5.0-arm/armv7l-tizen/bin/armv7l-tizen-linux-gnueabi-gcc -v
Using built-in specs.
COLLECT_GCC=/home/max/install/gcc-trunk-arm/armv7l-tizen/bin/armv7l-tizen-linux-gnueabi-gcc
COLLECT_LTO_WRAPPER=/home/max/install/gcc-trunk-arm/armv7l-tizen/libexec/gcc/armv7l-tizen-linux-gnueabi/6.0.0/lto-wrapper
Target: armv7l-tizen-linux-gnueabi
Configured with: /home/max/build/v6/sources/gcc_1/configure
--build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu
--target=armv7l-tizen-linux-gnueabi
--prefix=/home/max/install/gcc-trunk-arm/armv7l-tizen
--with-sysroot=/home/max/install/gcc-trunk-arm/armv7l-tizen/armv7l-tizen-linux-gnueabi/sys-root
--disable-libmudflap
--enable-libssp
--disable-nls
--disable-libstdcxx-pch
--disable-multilib
--disable-gnu-unique-object
--enable-linker-build-id
--with-mode=arm
--with-fpu=neon-vfpv4
--with-arch=armv7-a
--with-tune=cortex-a15.cortex-a7
--with-float=softfp
--enable-libgomp
--enable-poison-system-directories
--enable-long-long
--enable-threads
--enable-languages=c,c++,fortran
--enable-shared
--enable-lto
--enable-symvers=gnu
--enable-__cxa_atexit
--with-gnu-as
--with-gnu-ld
--with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm' --
Thread model: posix
gcc version 6.0.0 20150505 (experimental)
Looking to gdb output:
Breakpoint 1, 0x8608 in test_func() ()
(gdb) disas
Dump of assembler code for function _Z9test_funcv:
0x85b4 <+0>: movwr3, #34480 ; 0x86b0
0x85b8 <+4>: movtr3, #0
0x85bc <+8>: add r2, r3, #16
0x85c0 <+12>:vld1.8 {d20-d21}, [r3 :128]
0x85c4 <+16>:vld1.8 {d16-d17}, [r2 :128]
0x85c8 <+20>:vorrd17, d20, d20
0x85cc <+24>:vorrd18, d16, d16
0x85d0 <+28>:vzip.8 d16, d20
0x85d4 <+32>:vzip.8 d17, d18
0x85d8 <+36>:vorrd20, d16, d16
0x85dc <+40>:vorrd18, d17, d17
0x85e0 <+44>:vorrd22, d16, d16
0x85e4 <+48>:vzip.8 d20, d18
0x85e8 <+52>:vzip.8 d17, d22
0x85ec <+56>:vorrd18, d20, d20
0x85f0 <+60>:vmov.i16q12, #2 ; 0x0002
0x85f4 <+64>:vmovl.s8q10, d17
0x85f8 <+68>:vmovl.s8q9, d18
0x85fc <+72>:vsub.i16q10, q10, q12
0x8600 <+76>:vsub.i16q8, q9, q12
0x8604 <+80>:vadd.i16q8, q10, q8
=> 0x8608 <+84>:vst1.64 {d16-d17}, [r0 :128]
0x860c <+88>:bx lr
End of assembler dump.
r0 0xbe3ffc58 3191864408
(gdb)
vst1.64 wants r0 to be 128-bit aligned, but it's only 64-bit aligned here.
Documentation from ARM info center (http://infocenter.arm.com/help/index.jsp?
topic=/com.arm.doc.ddi0344c/Cihejdic.html) points here for cortex-a8:
"If an alignment qualifier is specified, a check is made for strict alignment
based on the qualifier, independent of the A-bit setting." So, bus error seems
to be expected here.
On cortex-a15.cortex-a7 the same code executed without errors. So, I wonder, if
it's a testcase problem and it should be disabled for CA8? Or maybe it is a
compiler bug?
[Bug testsuite/66046] New: UBSan output pattern tests fail on target ARM board.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66046
Bug ID: 66046
Summary: UBSan output pattern tests fail on target ARM board.
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: chefmax at gcc dot gnu.org
CC: tetra2005 at gmail dot com
Target Milestone: ---
Host: x86_64-pc-linux-gnu
Target: arm-linux-gnueabi
I see lots of output pattern test failures in UBSan testsuite running it on
target ARM board:
FAIL: c-c++-common/ubsan/object-size-1.c -O2 output pattern test
FAIL: c-c++-common/ubsan/object-size-10.c -O2 output pattern test
FAIL: c-c++-common/ubsan/object-size-4.c -O2 output pattern test
FAIL: c-c++-common/ubsan/object-size-5.c -O2 output pattern test
FAIL: c-c++-common/ubsan/overflow-negate-3.c -O2 output pattern test
FAIL: c-c++-common/ubsan/overflow-sub-4.c -O0 output pattern test
.
Looking to the failing tests, I've noticed, that they all try to match the last
(\n|\r\n|\r), for example overflow-negate-3.c:
/* { dg-do run } */
/* { dg-options "-fsanitize=signed-integer-overflow" } */
#define INT_MIN (-__INT_MAX__ - 1)
int
main ()
{
int x = INT_MIN;
int y;
asm ("" : "+g" (x));
y = -(-x);
asm ("" : "+g" (y));
y = -(-INT_MIN);
asm ("" : "+g" (y));
}
/* { dg-output "negation of -2147483648 cannot be represented in type
'int'\[^\n\r]*; cast to an unsigned type to negate this value to
itself\[^\n\r]*(\n|\r\n|\r)" } */
/* { dg-output "\[^\n\r]*negation of -2147483648 cannot be represented in type
'int'\[^\n\r]*; cast to an unsigned type to negate this value to
itself\[^\n\r]*(\n|\r\n|\r)" } */
/* { dg-output "\[^\n\r]*negation of -2147483648 cannot be represented in type
'int'\[^\n\r]*; cast to an unsigned type to negate this value to
itself\[^\n\r]*(\n|\r\n|\r)" } */
/* { dg-output "\[^\n\r]*negation of -2147483648 cannot be represented in type
'int'\[^\n\r]*; cast to an unsigned type to negate this value to
itself\[^\n\r]*(\n|\r\n|\r)" } */ <-- matches (\n|\r\n|\r)
But for some reasons, Dejagnu eats the last \n when running tests through ssh,
consider:
$ cat /usr/share/dejagnu/rsh.exp
proc rsh_exec { boardname program pargs inp outp } {
global timeout
...
# Delete one trailing \n because that is what `exec' will do and we want
# to behave identical to it.
regsub "\n$" $output "" output <-- delete last \n here
return [list [expr {$status != 0}] $output]
}
Although the easiest way to fix this is just deleting 'regsub "\n$" $output ""
output' line from rsh_exec, I'm not sure that modifying Dejagnu is a good idea.
Another option is to postprocess tests output in
gcc/testsuite/lib/ubsan-dg.exp, just like we do it in
gcc/testsuite/lib/asan-dg.exp:
+# Replace ${tool}_load with a wrapper so that we can symbolize the output.
+if { [info procs ${tool}_load] != [list] \
+ && [info procs saved_ubsan_${tool}_load] == [list] } {
+rename ${tool}_load saved_ubsan_${tool}_load
+
+proc ${tool}_load { program args } {
+ global tool
+ set result [eval [list saved_ubsan_${tool}_load $program] $args]
+ set output [lindex $result 1]
+ set result [list [lindex $result 0] "${output}\n"]
+ return $result
+}
+}
+
#
# ubsan_finish -- called at the end of each subdir of tests
#
[Bug testsuite/66046] UBSan output pattern tests fail on target ARM board.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66046 --- Comment #5 from Maxim Ostapenko --- (In reply to Marek Polacek from comment #3) > Oops. Let me prepare a patch. But I won't be able to test -- are you > willing to test it once I have something?. If it passes both x86_64, I'll > just commit it. > > This way maybe I'll remember to not add trailing (\n|\r\n|\r). Sure, thank you!
[Bug target/57271] ARM: gcc generates insufficient alignment for memory passed as extra argument for function return large composite type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57271 Maxim Ostapenko changed: What|Removed |Added CC||ktkachov at gcc dot gnu.org, ||rearnsha at gcc dot gnu.org Version|4.8.1 |6.0 --- Comment #9 from Maxim Ostapenko --- Add ARM maintainers.
[Bug testsuite/59897] FAIL: c-c++-common/asan/use-after-return-1.c -O* output pattern test, is 1: 0x2285020
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59897 --- Comment #5 from chefmax at gcc dot gnu.org --- Author: chefmax Date: Thu Jan 23 12:48:25 2014 New Revision: 206961 URL: http://gcc.gnu.org/viewcvs?rev=206961&root=gcc&view=rev Log: 2014-01-23 Dominique Dhumieres PR sanitizer/59897 * c-c++-common/asan/use-after-return-1.c: Fixed to pass on darwin. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/c-c++-common/asan/use-after-return-1.c
[Bug sanitizer/60055] New: Invalid binding of __tsan_default_options
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60055
Bug ID: 60055
Summary: Invalid binding of __tsan_default_options
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: chefmax at gcc dot gnu.org
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
It is impossible to override default value of report_bugs option from external
program with
extern "C" const char *__tsan_default_options() {
return "report_bugs=0";
}
After investigation it was discovered that this bug was caused by LOCAL value
of Bind attribute of tsan_default_options symbol:
$ readelf -s ~/gcc-master-install/lib64/libtsan.so | grep tsan_default_options
1773: 0002c255 8 FUNCLOCAL DEFAULT 10 __tsan_default_options
[Bug sanitizer/60055] Invalid binding of __tsan_default_options
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60055 --- Comment #1 from chefmax at gcc dot gnu.org --- Created attachment 32034 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32034&action=edit Proposed patch Attached patch seems to fix the bug. $ readelf -s ~/gcc-master-install/lib64/libtsan.so | grep tsan_default 3305: 0002c2b5 8 FUNCWEAK DEFAULT 10 __tsan_default_options
[Bug sanitizer/60055] Invalid binding of __tsan_default_options
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60055 --- Comment #4 from Maxim Ostapenko --- (In reply to Dmitry Vyukov from comment #3) > Hi, > > Does this work for you > http://llvm.org/viewvc/llvm-project?view=revision&revision=200747 > ? > > These callbacks are intended for very specific usages. I am curious how do > you want to use them? We use these callbacks in tsan test g++.dg/tsan/default_options.C. I guess we'll wait for next merge with LLVM libsanitizer to get this fix.
[Bug sanitizer/60055] Invalid binding of __tsan_default_options
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60055 Maxim Ostapenko changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #6 from Maxim Ostapenko --- Fixed by Jakub.
[Bug sanitizer/67867] New: UBSan bootstrap fails with error: ‘otype’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67867
Bug ID: 67867
Summary: UBSan bootstrap fails with error: ‘otype’ may be used
uninitialized in this function
[-Werror=maybe-uninitialized]
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: chefmax at gcc dot gnu.org
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,
mpolacek at gcc dot gnu.org, y.gribov at samsung dot com
Target Milestone: ---
Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu
Build: x86_64-pc-linux-gnu
$ /home/max/build/master-ref/./prev-gcc/xg++
-B/home/max/build/master-ref/./prev-gcc/
-B/home/max/install/master-ref/x86_64-unknown-linux-gnu/bin/ -nostdinc++
-B/home/max/build/master-ref/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
-B/home/max/build/master-ref/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
-I/home/max/build/master-ref/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu
-I/home/max/build/master-ref/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include
-I/home/max/workspace/downloads/gcc/libstdc++-v3/libsupc++
-L/home/max/build/master-ref/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
-L/home/max/build/master-ref/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
-fno-PIE -c -DIN_GCC_FRONTEND -g -O2 -fsanitize=undefined -DIN_GCC
-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing
-Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror
-fno-common -DHAVE_CONFIG_H -I. -Icp -I/home/max/workspace/downloads/gcc/gcc
-I/home/max/workspace/downloads/gcc/gcc/cp
-I/home/max/workspace/downloads/gcc/gcc/../include
-I/home/max/workspace/downloads/gcc/gcc/../libcpp/include
-I/home/max/workspace/downloads/gcc/gcc/../libdecnumber
-I/home/max/workspace/downloads/gcc/gcc/../libdecnumber/bid -I../libdecnumber
-I/home/max/workspace/downloads/gcc/gcc/../libbacktrace -o cp/search.o -MT
cp/search.o -MMD -MP -MF cp/.deps/search.TPo
/home/max/workspace/downloads/gcc/gcc/cp/search.c
/home/max/workspace/downloads/gcc/gcc/cp/search.c: In function ‘int
accessible_p(tree, tree, bool)’:
/home/max/workspace/downloads/gcc/gcc/cp/search.c:1011:41: error: ‘otype’ may
be used uninitialized in this function [-Werror=maybe-uninitialized]
dfs_accessible_data d = { decl, otype };
^
$ /home/max/build/master-ref/./prev-gcc/xg++ -v
Using built-in specs.
COLLECT_GCC=/home/max/build/master-ref/./prev-gcc/xg++
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-ref --enable-languages=c,c++,lto
--enable-bootstrap --with-build-config=bootstrap-ubsan
Thread model: posix
gcc version 6.0.0 20151006 (experimental) (GCC)
I'm also attaching preprocessed source as bug.i.
[Bug sanitizer/67867] UBSan bootstrap fails with error: ‘otype’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67867 --- Comment #2 from Maxim Ostapenko --- Created attachment 36451 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36451&action=edit Reprocase.
[Bug sanitizer/68016] New: ASan doesn't catch overflow in globals when COPY relocation is involved.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68016
Bug ID: 68016
Summary: ASan doesn't catch overflow in globals when COPY
relocation is involved.
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: chefmax at gcc dot gnu.org
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,
y.gribov at samsung dot com
Target Milestone: ---
Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu
Build: x86_64-pc-linux-gnu
Consider:
max@max:~/workspace/downloads/gcc$ cat libfoo.c
int f[5] = {1};
max@max:~/workspace/downloads/gcc$ cat main.c
extern int f[5];
int main ()
{
return f[5];
}
max@max:~/workspace/downloads/gcc$ ~/install/master-ref/bin/gcc
-fsanitize=address libfoo.c -shared -fpic -fsanitize=address -o libfoo.so
max@max:~/workspace/downloads/gcc$ ~/install/master-ref/bin/gcc
-fsanitize=address main.c -c -o main.o
max@max:~/workspace/downloads/gcc$ ~/install/master-ref/bin/gcc
-fsanitize=address main.o ./libfoo.so -o main
max@max:~/workspace/downloads/gcc$ LD_LIBRARY_PATH=~/install/master-ref/lib64
ASAN_OPTIONS=report_globals=3 ./main
#0 0x7f73cc9bfdde in __asan_register_globals
/home/max/workspace/downloads/gcc/libsanitizer/asan/asan_globals.cc:228
#1 0x7f73cc796800 in _GLOBAL__sub_I_00099_1_libfoo.c (libfoo.so+0x800)
#2 0x7f73cd910139 (/lib64/ld-linux-x86-64.so.2+0x10139)
#3 0x7f73cd910222 (/lib64/ld-linux-x86-64.so.2+0x10222)
#4 0x7f73cd901309 (/lib64/ld-linux-x86-64.so.2+0x1309)
=== ID 738197505; 0x7f73cc996bc0 0x7f73cc996bc0
==16063==Added Global[0x7f73cc996bc0]: beg=0x7f73cc996b60 size=20/64 name=f
module=libfoo.c dyn_init=0
==16063== location (0x7f73cc996ba0): name=libfoo.c[0x7f73cc79680d], 1 5
max@max:~/workspace/downloads/gcc$ readelf -r main | grep COPY
0070eac0 02540005 R_X86_64_COPY 0070eac0 f + 0
This happens due to private aliases, used by GCC to register globals. LLVM
catches this overflow, but it has another drawback - mixing sanitized and
non-sanitized code may lead to application crash.
Don't know if there is a good fix for both issues. Any thoughts? IMHO, false
negatives are more preferable than application crash.
[Bug bootstrap/63888] [5 Regression] bootstrap failed when configured with -with-build-config=bootstrap-asan --disable-werror
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63888 Maxim Ostapenko changed: What|Removed |Added CC||chefmax at gcc dot gnu.org --- Comment #40 from Maxim Ostapenko --- Just a little bit more fuel to the flames: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68016
[Bug sanitizer/63958] [5 Regression] bootstrap failure in the sanitizer libs on sparc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63958 --- Comment #14 from Maxim Ostapenko --- Author: chefmax Date: Wed Oct 21 07:44:35 2015 New Revision: 229113 URL: https://gcc.gnu.org/viewcvs?rev=229113&root=gcc&view=rev Log: libsanitizer/ PR sanitizer/63958 Reapply: 2014-10-14 David S. Miller * sanitizer_common/sanitizer_platform_limits_linux.cc (time_t): Define at __kernel_time_t, as needed for sparc. (struct __old_kernel_stat): Don't check if __sparc__ is defined. * libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h (__sanitizer): Define struct___old_kernel_stat_sz, struct_kernel_stat_sz, and struct_kernel_stat64_sz for sparc. (__sanitizer_ipc_perm): Adjust for sparc targets. (__sanitizer_shmid_ds): Likewsie. (__sanitizer_sigaction): Likewise. (IOC_SIZE): Likewsie. Modified: trunk/libsanitizer/ChangeLog trunk/libsanitizer/sanitizer_common/sanitizer_platform_limits_linux.cc trunk/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h
[Bug bootstrap/63888] [5 Regression] bootstrap failed when configured with -with-build-config=bootstrap-asan --disable-werror
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63888 --- Comment #41 from Maxim Ostapenko --- Author: chefmax Date: Wed Oct 21 07:47:54 2015 New Revision: 229114 URL: https://gcc.gnu.org/viewcvs?rev=229114&root=gcc&view=rev Log: libsanitizer/ PR bootstrap/63888 Reapply: 2015-02-20 Jakub Jelinek * asan/asan_globals.cc (RegisterGlobal): Disable detect_odr_violation support until it is rewritten upstream. * c-c++-common/asan/pr63888.c: New test. Modified: trunk/libsanitizer/ChangeLog trunk/libsanitizer/asan/asan_globals.cc
[Bug bootstrap/68041] [6 Regression] Bootstrap broken on x86_64-apple-darwin14 at revision r229119
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68041 --- Comment #1 from Maxim Ostapenko --- Yes, this is mine.
[Bug bootstrap/68041] [6 Regression] Bootstrap broken on x86_64-apple-darwin14 at revision r229119
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68041 --- Comment #2 from Maxim Ostapenko --- Created attachment 36555 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36555&action=edit First version of the fix. Dominique, I'm sorry about that. Could you please try attached patch? There may be other errors for Darwin in libsanitizer build (I didn't make proper testing because of lack of target) and it would be great to fix them here too.
[Bug sanitizer/68016] ASan doesn't catch overflow in globals when COPY relocation is involved.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68016 --- Comment #2 from Maxim Ostapenko --- Ok, I guess won't fix here.
[Bug bootstrap/68041] [6 Regression] Bootstrap broken on x86_64-apple-darwin14 at revision r229119
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68041 --- Comment #5 from Maxim Ostapenko --- (In reply to Dominique d'Humieres from comment #4) > With the patch in comment 2, bootstrap completed without any problem. > > Preliminary tests for g++ and asan > > === g++ Summary for unix/-m64 === > > # of expected passes 1007 > # of unexpected failures 14 > # of unsupported tests179 > > === g++ Summary === > > # of expected passes 2021 > # of unexpected failures 21 > # of unsupported tests358 > > the failures are > > FAIL: c-c++-common/asan/sanity-check-pure-c-1.c -O0 output pattern test > FAIL: c-c++-common/asan/sanity-check-pure-c-1.c -O1 output pattern test > FAIL: c-c++-common/asan/sanity-check-pure-c-1.c -O2 output pattern test > FAIL: c-c++-common/asan/sanity-check-pure-c-1.c -O3 -g output pattern test > FAIL: c-c++-common/asan/sanity-check-pure-c-1.c -Os output pattern test > FAIL: c-c++-common/asan/sanity-check-pure-c-1.c -O2 -flto > -flto-partition=none output pattern test > FAIL: c-c++-common/asan/sanity-check-pure-c-1.c -O2 -flto output pattern > test > > for both -m32 and -m64, and > > FAIL: c-c++-common/asan/memcmp-1.c -O0 output pattern test > FAIL: c-c++-common/asan/memcmp-1.c -O1 output pattern test > FAIL: c-c++-common/asan/memcmp-1.c -O2 output pattern test > FAIL: c-c++-common/asan/memcmp-1.c -O3 -g output pattern test > FAIL: c-c++-common/asan/memcmp-1.c -Os output pattern test > FAIL: c-c++-common/asan/memcmp-1.c -O2 -flto -flto-partition=none output > pattern test > FAIL: c-c++-common/asan/memcmp-1.c -O2 -flto output pattern test > > for -m64 only. > > How many lines of the output do you need to adjust the regexps? Thanks! These tests passed before, right? So, could you share more details about these tests output (perhaps open a new bug with sanitizer label)? > > Further tests for ubsan and gcc in progress.
[Bug sanitizer/68042] [6 Regression] c-c++-common/asan/(memcmp-1.c|sanity-check-pure-c-1.c) failures on x86_64-apple-darwin14 after r229111
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68042 --- Comment #1 from Maxim Ostapenko --- I wonder if the fix would be just output patterns adjustment (just like here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63939)?
[Bug bootstrap/68041] [6 Regression] Bootstrap broken on x86_64-apple-darwin14 at revision r229119
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68041 --- Comment #8 from Maxim Ostapenko --- Created attachment 36556 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36556&action=edit The patch I've posted to gcc-patches ML for review.
[Bug bootstrap/68041] [6 Regression] Bootstrap broken on x86_64-apple-darwin14 at revision r229119
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68041 --- Comment #10 from Maxim Ostapenko --- (In reply to Dominique d'Humieres from comment #9) > > Created attachment 36556 [details] > > The patch I've posted to gcc-patches ML for review. > > I have not tested the part "removes -lc++abi flag for UBSan on Darwin" > (later tonight). > Comment from Iain Sandoe on IRC: > > we don't use libc++ anyway on GCC, so academic > i.e. "it seems the right thing to do" The patch was approved by Mike in ML (https://gcc.gnu.org/ml/gcc-patches/2015-10/msg02127.html).
[Bug bootstrap/68041] [6 Regression] Bootstrap broken on x86_64-apple-darwin14 at revision r229119
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68041 --- Comment #11 from Maxim Ostapenko --- Author: chefmax Date: Thu Oct 22 09:47:17 2015 New Revision: 229168 URL: https://gcc.gnu.org/viewcvs?rev=229168&root=gcc&view=rev Log: Fix bootstrap on x86_64-apple-darwin14 after r229119. libsanitizer/ PR bootstrap/68041 * configure.ac (link_sanitizer_common): Link against librt only if it contains shm_open, required by sanitizers. (CXX_ABI_NEEDED): Remove variable. * configure: Regenerate. * ubsan/Makefile.am (libubsan_la_LIBADD): Do not add -lc++abi anymore. * ubsan/Makefile.in: Regenerate. Modified: trunk/libsanitizer/ChangeLog trunk/libsanitizer/configure trunk/libsanitizer/configure.ac trunk/libsanitizer/ubsan/Makefile.am trunk/libsanitizer/ubsan/Makefile.in
[Bug bootstrap/68041] [6 Regression] Bootstrap broken on x86_64-apple-darwin14 at revision r229119
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68041 --- Comment #12 from Maxim Ostapenko --- Should be fixed on trunk. Dominique, let me know if the issue still occurs.
[Bug sanitizer/68042] [6 Regression] c-c++-common/asan/(memcmp-1.c|sanity-check-pure-c-1.c) failures on x86_64-apple-darwin14 after r229111
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68042 --- Comment #3 from Maxim Ostapenko --- Created attachment 36562 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36562&action=edit Draft patch. Here an expected patch for memcmp-1.c and sanity-check-pure-c-1.c output patterns. Does it fix the problem?
[Bug sanitizer/68016] ASan doesn't catch overflow in globals when COPY relocation is involved.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68016 Maxim Ostapenko changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #3 from Maxim Ostapenko --- Won't fix, this is intentional design decision.
[Bug sanitizer/68042] [6 Regression] c-c++-common/asan/(memcmp-1.c|sanity-check-pure-c-1.c) failures on x86_64-apple-darwin14 after r229111
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68042 --- Comment #5 from Maxim Ostapenko --- Author: chefmax Date: Fri Oct 23 07:22:37 2015 New Revision: 229212 URL: https://gcc.gnu.org/viewcvs?rev=229212&root=gcc&view=rev Log: Fix ASan output pattern tests on Darwin. gcc/testsuite/ PR sanitizer/68042 * c-c++-common/asan/memcmp-1.c: Adjust test to pass on Darwin. * c-c++-common/asan/sanity-check-pure-c-1.c: Likewise. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/c-c++-common/asan/memcmp-1.c trunk/gcc/testsuite/c-c++-common/asan/sanity-check-pure-c-1.c
[Bug sanitizer/68042] [6 Regression] c-c++-common/asan/(memcmp-1.c|sanity-check-pure-c-1.c) failures on x86_64-apple-darwin14 after r229111
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68042 --- Comment #6 from Maxim Ostapenko --- Should be fix on trunk.
[Bug sanitizer/68016] ASan doesn't catch overflow in globals when COPY relocation is involved.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68016
--- Comment #4 from Maxim Ostapenko ---
Actualy, LLVM is not better here (perhaps even worse). Consider the following
testcase (it's the same Jakub provided in PR63888):
max@max:/tmp$ cat libfoo.c
long f = 4;
long foo (long *p) {
return *p;
}
max@max:/tmp$ cat libbar.c
long h = 12;
long i = 13;
max@max:/tmp$ cat main.c
extern void abort (void);
extern long f;
extern long h;
extern long i;
long foo (long *);
int main () {
if (foo (&f) != 4 || foo (&h) != 12 || foo (&i) != 13)
abort ();
return 0;
}
max@max:/tmp$ clang libfoo.c -shared -fpic -o libfoo.so -g
max@max:/tmp$ clang libbar.c -shared -fpic -o libbar.so -g
max@max:/tmp$ clang main.c -c -o main.o -g
max@max:/tmp$ clang main.o ./libfoo.so ./libbar.so -o main -fsanitize=address
max@max:/tmp$ ./main
max@max:/tmp$ echo $?
0
max@max:/tmp$ clang libfoo.c -shared -fpic -o libfoo.so -g -fsanitize=address
max@max:/tmp$ ./main
./main: Symbol `f' has different size in shared object, consider re-linking
=
==19089==ERROR: AddressSanitizer: global-buffer-overflow on address
0x0070fb10 at pc 0x7f0e0b65c931 bp 0x7ffc67828000 sp 0x7ffc67827ff8
READ of size 8 at 0x0070fb10 thread T0
#0 0x7f0e0b65c930 in foo /tmp/libfoo.c:2:29
#1 0x4e166f in main /tmp/main.c:9:42
#2 0x7f0e0a570ec4 in __libc_start_main
/build/buildd/eglibc-2.19/csu/libc-start.c:287
#3 0x418fd5 in _start (/tmp/main+0x418fd5)
0x0070fb10 is located 0 bytes to the right of global variable 'f' defined
in 'libfoo.c:1:6' (0x70fb08) of size 8
SUMMARY: AddressSanitizer: global-buffer-overflow /tmp/libfoo.c:2:29 in foo
Shadow bytes around the buggy address:
0x800d9f10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x800d9f20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x800d9f30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x800d9f40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x800d9f50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x800d9f60: 00 00[f9]f9 f9 f9 f9 f9 f9 00 00 00 00 00 00 00
0x800d9f70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x800d9f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x800d9f90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x800d9fa0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x800d9fb0: 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: fb
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack partial redzone: f4
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
==19089==ABORTING
This happens because in LLVM case ASan changes symbols size ('f' in our case)
and just breaks ABI for the library. Relinking binary each time we replace
non-sanitized library with sanitized one is undesirable for large package
oriented systems (e.g. distributives), so we need a general solution for the
problem.
[Bug sanitizer/68099] arm-*-linux-gnueabihf -fsanitize=undefined warning: '' is used uninitialized in this function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68099 Maxim Ostapenko changed: What|Removed |Added CC||chefmax at gcc dot gnu.org --- Comment #2 from Maxim Ostapenko --- I actually believe this is a dup of PR66977, that was fixed by Marek quite time ago. Could you try trunk compiler?
[Bug sanitizer/68099] arm-*-linux-gnueabihf -fsanitize=undefined warning: '' is used uninitialized in this function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68099 --- Comment #5 from Maxim Ostapenko --- (In reply to Jonathan Ben-Avraham from comment #3) > (In reply to Maxim Ostapenko from comment #2) > > I actually believe this is a dup of PR66977, that was fixed by Marek quite > > time ago. Could you try trunk compiler? > > "trunk compiler"? As in SVN trunk? If so please send URL of branch to test. I suspect something like this should work: svn checkout svn://gcc.gnu.org/svn/gcc/trunk/ trunk
[Bug sanitizer/68016] ASan doesn't catch overflow in globals when COPY relocation is involved.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68016
--- Comment #8 from Maxim Ostapenko ---
(In reply to Reid Kleckner from comment #7)
> (In reply to Jakub Jelinek from comment #6)
> > Because symbol size is part of the ABI, and LLVM emits different symbol size
> > between -fsanitize=address and -fno-sanitize=address.
> > E.g. COPY relocations use the st_size field, so you can have:
> > 1) shared library originally not ASAN instrumented, binary (e.g. non-ASAN)
> > linked against it, then the shared library recompiled with ASAN - the size
> > of the symbol in the binary will be the one without padding, but LLVM
> > incorrectly registers the variable using global symbol rather than local
> > alias and thus assumes there is padding which is not available (plus you can
> > get a runtime warning on the st_size mismatch from the dynamic linker)
>
> I thought COPY relocations only occurred with fPIE, but I must have been
> mistaken.
>
> > 2) even without COPY relocations, you could have the same variable defined
> > in multiple shared libraries, if some of them are -fsanitize=address and the
> > others are not, there is mismatch between the variable sizes, and depending
> > on which library comes earlier in the symbol search scope, you could have
> > either the version without or with padding used at runtime, but the
> > sanitized libraries could very well register the non-padded one, making it
> > fatal error to access e.g. variables after it
>
> LLVM ASan tries to instrument only global definitions with external linkage.
> The goal of this check is to ensure that we have found the one true
> definition of the global, and it isn't COMDAT, weak, a C string, or going to
> get replaced with something else at link time through some other means.
>
> It seems like you are describing interposition, which isn't something LLVM
> supports very well. LLVM has no equivalent of -fsemantic-interposition, for
> example. We always operate under something like -fno-semantic-interposition.
> (I know, it's ironic, because ASan interposes libc.)
>
> Anyway, I agree the COPY relocation issue is a real problem, but other than
> that I think our approach is at least internally consistent.
Jakub is right, here an example, where I believe COPY relocations are not
involved:
max@max:/tmp$ cat libfoo.c
long h = 15;
long f = 4;
long foo (long *p) {
return *p;
}
max@max:/tmp$ cat libbar.c
extern void abort (void);
long foo (long *);
long h = 12;
long i = 13;
long f = 5;
int bar () {
if (foo (&f) != 5 || foo (&h) != 12 || foo (&i) != 13)
abort ();
return 0;
}
max@max:/tmp$ cat main.c
int bar ();
int main () {
return bar ();
}
max@max:/tmp$ clang libfoo.c -shared -fpic -o libfoo.so -g
max@max:/tmp$ clang libbar.c -shared -fpic -o libbar.so -g
max@max:/tmp$ clang main.c -c -o main.o
max@max:/tmp$ clang main.o ./libbar.so ./libfoo.so -o main -fsanitize=address
max@max:/tmp$ ./main
max@max:/tmp$ clang libfoo.c -shared -fpic -o libfoo.so -g -fsanitize=address
max@max:/tmp$ ./main
=
==27105==ERROR: AddressSanitizer: global-buffer-overflow on address
0x7f28c26a0050 at pc 0x7f28c229d9c1 bp 0x7ffd1716a950 sp 0x7ffd1716a948
READ of size 8 at 0x7f28c26a0050 thread T0
#0 0x7f28c229d9c0 in foo /tmp/libfoo.c:4:10
#1 0x7f28c249f7bf in bar /tmp/libbar.c:8:7
#2 0x4e1585 in main (/tmp/main+0x4e1585)
#3 0x7f28c13b3ec4 in __libc_start_main
/build/buildd/eglibc-2.19/csu/libc-start.c:287
#4 0x418f25 in _start (/tmp/main+0x418f25)
0x7f28c26a0050 is located 0 bytes inside of global variable 'f' defined in
'libfoo.c:2:6' (0x7f28c26a0050) of size 8
0x7f28c26a0050 is located 8 bytes to the right of global variable 'h' defined
in 'libfoo.c:1:6' (0x7f28c26a0040) of size 8
SUMMARY: AddressSanitizer: global-buffer-overflow /tmp/libfoo.c:4:10 in foo
Shadow bytes around the buggy address:
0x0fe5984cbfb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe5984cbfc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe5984cbfd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe5984cbfe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe5984cbff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0fe5984cc000: 00 00 00 00 00 00 00 00 00 f9[f9]f9 f9 f9 f9 f9
0x0fe5984cc010: f9 f9 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe5984cc020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe5984cc030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe5984cc040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0fe5984cc050: 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: fb
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack partial redzone: f4
Stack
[Bug sanitizer/68122] ICE in gcc/toplev.c:353 with -fsanitize=undefined and -fgnu-tm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68122
Maxim Ostapenko changed:
What|Removed |Added
CC||chefmax at gcc dot gnu.org
--- Comment #2 from Maxim Ostapenko ---
$ cat tm-thread.c.019t.ubsan
;; Function main (main, funcdef_no=0, decl_uid=2229, cgraph_uid=0,
symbol_order=1)
main ()
{
int D.2233;
int cnt.0;
int D.2234;
int cnt.0_2;
int _3;
int _6;
:
__transaction_atomic // SUBCODE=[ GTMA_HAVE_LOAD GTMA_HAVE_STORE ]
:
cnt.0_2 = cnt;
_3 = UBSAN_CHECK_ADD (cnt.0_2, 1);
cnt = _3;
__builtin__ITM_commitTransaction ();
:
_6 = 0;
:
return _6;
}
It seems that pass_ipa_tm tries to handle UBSAN_CHECK_ADD call and fails.
Should we teach it to handle ubsan intrinsics? Or maybe just not instrument
transaction clauses at all?
[Bug sanitizer/64820] Libsanitizer fails with ((AddrIsAlignedByGranularity(addr + size))) != (0)" (0x0, 0x0) if ssp is enabled.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64820 --- Comment #7 from Maxim Ostapenko --- (In reply to joakim.tjernl...@transmode.se from comment #6) > Is this fix in gcc 4.9.3? No, this didn't go to GCC 4.9, only to GCC 5. > If not, will go into 4.9.4? Well, actually we didn't plan backport this on gcc-4.9 branch, the case is quite specific. But I think it would be pretty easy to backport the fix now. I can do it if there aren't objections from GCC hackers.
[Bug driver/64690] -freport-bug issue with comments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64690 --- Comment #1 from Maxim Ostapenko --- Thanks, I'll send the fix shortly.
[Bug driver/64690] -freport-bug issue with comments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64690 --- Comment #2 from Maxim Ostapenko --- Author: chefmax Date: Thu Jan 22 10:55:32 2015 New Revision: 219990 URL: https://gcc.gnu.org/viewcvs?rev=219990&root=gcc&view=rev Log: 2015-01-22 Max Ostapenko PR driver/64690 * gcc.c (insert_comments): New function. (try_generate_repro): Call it. (append_text): Removed. Modified: trunk/gcc/ChangeLog trunk/gcc/gcc.c
[Bug sanitizer/64820] New: Libsanitizer fails with ((AddrIsAlignedByGranularity(addr + size))) != (0)" (0x0, 0x0) if ssp is enabled.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64820 Bug ID: 64820 Summary: Libsanitizer fails with ((AddrIsAlignedByGranularity(addr + size))) != (0)" (0x0, 0x0) if ssp is enabled. Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: chefmax at gcc dot gnu.org 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, ygribov at gcc dot gnu.org Host: x86_64-pc-linux-gnu Target: i386-linux-gnu, arm-linux-gnueabi Created attachment 34589 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34589&action=edit Simple reprocase If compile with both -fsanitize=address and -fstack-protector for 32-bit architectures and run with ASAN_OPTIONS=detect_stack_use_after_return=1, libsanitizer fails with: $ ~/install/master/bin/gcc -m32 -fsanitize=address -fstack-protector test.c $ ASAN_OPTIONS=detect_stack_use_after_return=1 ./a.out ==7299==AddressSanitizer CHECK failed: /home/max/workspace/downloads/gcc/libsanitizer/asan/asan_poisoning.cc:25 "((AddrIsAlignedByGranularity(addr + size))) != (0)" (0x0, 0x0) #0 0xf72d8afc in AsanCheckFailed /home/max/workspace/downloads/gcc/libsanitizer/asan/asan_rtl.cc:68 #1 0xf72dda89 in __sanitizer::CheckFailed(char const*, int, char const*, unsigned long long, unsigned long long) /home/max/workspace/downloads/gcc/libsanitizer/sanitizer_common/sanitizer_common.cc:72 #2 0xf72d39b1 in __asan::PoisonShadow(unsigned long, unsigned long, unsigned char) /home/max/workspace/downloads/gcc/libsanitizer/asan/asan_poisoning.cc:25 #3 0xf7261e29 in __asan::SetShadow(unsigned long, unsigned long, unsigned long, unsigned long long) /home/max/workspace/downloads/gcc/libsanitizer/asan/asan_fake_stack.cc:32 #4 0xf7261e29 in __asan::OnMalloc(unsigned long, unsigned long, unsigned long) /home/max/workspace/downloads/gcc/libsanitizer/asan/asan_fake_stack.cc:198 #5 0xf7261e29 in __asan_stack_malloc_7 /home/max/workspace/downloads/gcc/libsanitizer/asan/asan_fake_stack.cc:230 #6 0x8048655 in foo (/tmp/a.out+0x8048655) #7 0x8048707 in main (/tmp/a.out+0x8048707) Simple reprocase is attached. This happens because size parameter is not aligned by 8 bytes (Granularity) here: $~/install/master/bin/gcc -m32 -fsanitize=address-fstack-protector test.c -o- -S ... cmpl$0, __asan_option_detect_stack_use_after_return je .L1 subl$8, %esp pushl %eax pushl $4188 // Aligned by 4 bytes. call__asan_stack_malloc_7 addl$16, %esp Perhaps we should emit some warning (error) in compile time to prevent the issue? $ ~/install/master/bin/gcc -v Using built-in specs. COLLECT_GCC=/home/max/install/master/bin/gcc COLLECT_LTO_WRAPPER=/home/max/install/master/libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/lto-wrapper 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++ Thread model: posix gcc version 5.0.0 20150127 (experimental) (GCC)
[Bug sanitizer/63507] New: boostrap-asan failure: /usr/bin/ld: /home/max/build/bootstrap-asan/./gcc/liblto_plugin.so: error loading plugin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63507 Bug ID: 63507 Summary: boostrap-asan failure: /usr/bin/ld: /home/max/build/bootstrap-asan/./gcc/liblto_plugin.so: error loading plugin Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: chefmax at gcc dot gnu.org 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, ygribov at gcc dot gnu.org Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Build: x86_64-pc-linux-gnu Asan-bootstrap on x86_64-pc-linux-gnu fails with: # @multilib_flags@ is still needed because this may use # /home/max/build/bootstrap-asan/./gcc/xgcc -B/home/max/build/bootstrap-asan/./gcc/ -B/home/max/install/bootstrap-asan/x86_64-unknown-linux-gnu/bin/ -B/home/max/install/bootstrap-asan/x86_64-unknown-linux-gnu/lib/ -isystem /home/max/install/bootstrap-asan/x86_64-unknown-linux-gnu/include -isystem /home/max/install/bootstrap-asan/x86_64-unknown-linux-gnu/sys-includeand -O2 -g -O2 -DIN_GCC-W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fpic -mlong-double-80 -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector directly. # @multilib_dir@ is not really necessary, but sometimes it has # more uses than just a directory name. /bin/bash /home/max/workspace/downloads/gcc/libgcc/../mkinstalldirs 32 mkdir -p -- 32 /home/max/build/bootstrap-asan/./gcc/xgcc -B/home/max/build/bootstrap-asan/./gcc/ -B/home/max/install/bootstrap-asan/x86_64-unknown-linux-gnu/bin/ -B/home/max/install/bootstrap-asan/x86_64-unknown-linux-gnu/lib/ -isystem /home/max/install/bootstrap-asan/x86_64-unknown-linux-gnu/include -isystem /home/max/install/bootstrap-asan/x86_64-unknown-linux-gnu/sys-include-O2 -g -O2 -DIN_GCC-W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fpic -mlong-double-80 -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -shared -nodefaultlibs -Wl,--soname=libgcc_s.so.1 -Wl,--version-script=libgcc.map -o 32/libgcc_s.so.1.tmp -g -O2 -m32 -B./ _muldi3_s.o _negdi2_s.o _lshrdi3_s.o _ashldi3_s.o _ashrdi3_s.o _cmpdi2_s.o _ucmpdi2_s.o _clear_cache_s.o _trampoline_s.o __main_s.o _absvsi2_s.o _absvdi2_s.o _addvsi3_s.o _addvdi3_s.o _subvsi3_s.o _subvdi3_s.o _mulvsi3_s.o _mulvdi3_s.o _negvsi2_s.o _negvdi2_s.o _ctors_s.o _ffssi2_s.o _ffsdi2_s.o _clz_s.o _clzsi2_s.o _clzdi2_s.o _ctzsi2_s.o _ctzdi2_s.o _popcount_tab_s.o _popcountsi2_s.o _popcountdi2_s.o _paritysi2_s.o _paritydi2_s.o _powisf2_s.o _powidf2_s.o _powixf2_s.o _powitf2_s.o _mulsc3_s.o _muldc3_s.o _mulxc3_s.o _multc3_s.o _divsc3_s.o _divdc3_s.o _divxc3_s.o _divtc3_s.o _bswapsi2_s.o _bswapdi2_s.o _clrsbsi2_s.o _clrsbdi2_s.o _fixunssfsi_s.o _fixunsdfsi_s.o _fixunsxfsi_s.o _fixsfdi_s.o _fixdfdi_s.o _fixxfdi_s.o _fixunssfdi_s.o _fixunsdfdi_s.o _fixunsxfdi_s.o _floatdisf_s.o _floatdidf_s.o _floatdixf_s.o _floatundisf_s.o _floatundidf_s.o _floatundixf_s.o _divdi3_s.o _moddi3_s.o _udivdi3_s.o _umoddi3_s.o _udiv_w_sdiv_s.o _udivmoddi4_s.o cpuinfo_s.o tf-signs_s.o sfp-exceptions_s.o addtf3_s.o divtf3_s.o eqtf2_s.o getf2_s.o letf2_s.o multf3_s.o negtf2_s.o subtf3_s.o unordtf2_s.o fixtfsi_s.o fixunstfsi_s.o floatsitf_s.o floatunsitf_s.o fixtfdi_s.o fixunstfdi_s.o floatditf_s.o floatunditf_s.o extendsftf2_s.o extenddftf2_s.o extendxftf2_s.o trunctfsf2_s.o trunctfdf2_s.o trunctfxf2_s.o enable-execute-stack_s.o unwind-dw2_s.o unwind-dw2-fde-dip_s.o unwind-sjlj_s.o unwind-c_s.o emutls_s.o libgcc.a -lc && rm -f 32/libgcc_s.so && if [ -f 32/libgcc_s.so.1 ]; then mv -f 32/libgcc_s.so.1 32/libgcc_s.so.1.backup; else true; fi && mv 32/libgcc_s.so.1.tmp 32/libgcc_s.so.1 && ln -s libgcc_s.so.1 32/libgcc_s.so /usr/bin/ld: /home/max/build/bootstrap-asan/./gcc/liblto_plugin.so: error in plugin cleanup (ignored) /usr/bin/ld: /home/max/build/bootstrap-asan/./gcc/liblto_plugin.so: error loading plugin collect2: error: ld returned 1 exit status make[5]: *** [libgcc_s.so] Error 1 make[5]: Leaving directory `/home/max/build/bootstrap-asan/x86_64-unknown-linux-gnu/32/libgcc' make[4]: *** [multi-do] Error 1 make[4]: Leaving directory `/home/max/build/bootstrap-asan/x86_64-unknown-linux-gnu/libgcc' make[3]: *** [all-multi] Error 2 make[3]: Leaving directory `/home/max/build/bootstrap-asan/x86_64-unknown-linux-gnu/libgcc' make[2]: *** [all-stage2-target-libgcc] Error 2 make[2]: Leaving directory `/home/max/build/bootstrap-asan' make[1]: *** [stage2-bubble] Error 2 make[1]: Leaving directory `/home/max/build/bootstrap-asan' make: *** [all] Error 2
