[Bug sanitizer/80953] Support libsanitizer on Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80953 --- Comment #39 from Eric Botcazou --- Author: ebotcazou Date: Wed Mar 13 09:19:25 2019 New Revision: 269641 URL: https://gcc.gnu.org/viewcvs?rev=269641&root=gcc&view=rev Log: PR sanitizer/80953 Merge from LLVM revision 355980 * asan/asan_allocator.h (kAllocatorSpace): Define for SPARC. (kAllocatorSize): Likewise. (DefaultSizeClassMap): Likewise. * asan/asan_mapping.h (kSPARC64_ShadowOffset64): Define. (SHADOW_OFFSET): Define for SPARC. Include asan_mapping_sparc64.h for SPARC 64-bit. * asan/asan_mapping_sparc64.h: New file. Added: trunk/libsanitizer/asan/asan_mapping_sparc64.h Modified: trunk/libsanitizer/ChangeLog trunk/libsanitizer/asan/asan_allocator.h trunk/libsanitizer/asan/asan_mapping.h
[Bug sanitizer/80953] Support libsanitizer on Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80953 --- Comment #38 from Eric Botcazou --- Author: ebotcazou Date: Wed Mar 13 09:15:02 2019 New Revision: 269640 URL: https://gcc.gnu.org/viewcvs?rev=269640&root=gcc&view=rev Log: PR sanitizer/80953 Merge from LLVM revision 355979 * asan/asan_globals.c (GetGlobalsForAddress): Use internal_memcpy to copy Global objects for SPARC with GCC. Modified: trunk/libsanitizer/ChangeLog trunk/libsanitizer/asan/asan_globals.cc
[Bug sanitizer/80953] Support libsanitizer on Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80953 --- Comment #37 from Eric Botcazou --- Author: ebotcazou Date: Wed Mar 13 09:11:46 2019 New Revision: 269639 URL: https://gcc.gnu.org/viewcvs?rev=269639&root=gcc&view=rev Log: PR sanitizer/80953 Merge from LLVM revision 355978 * sanitizer_common/sanitizer_allocator_primary32.h (class SizeClassAllocator32): Assert that kSpaceSize is power of 2 if SANITIZER_SIGN_EXTENDED_ADDRESSES is set. (PointerIsMine): Deal with SANITIZER_SIGN_EXTENDED_ADDRESSES. (ComputeRegionId): Likewise. * sanitizer_common/sanitizer_linux.cc (GetMaxVirtualAddress): Return appropriate value for SPARC 64-bit. * sanitizer_common/sanitizer_platform.h (SANITIZER_MMAP_RANGE_SIZE): Define for SPARC. (SANITIZER_SIGN_EXTENDED_ADDRESSES): Define to 1 for SPARC 64-bit. Modified: trunk/libsanitizer/ChangeLog trunk/libsanitizer/sanitizer_common/sanitizer_allocator_primary32.h trunk/libsanitizer/sanitizer_common/sanitizer_linux.cc trunk/libsanitizer/sanitizer_common/sanitizer_platform.h
[Bug sanitizer/80953] Support libsanitizer on Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80953 --- Comment #36 from Eric Botcazou --- Author: ebotcazou Date: Wed Mar 13 09:05:43 2019 New Revision: 269638 URL: https://gcc.gnu.org/viewcvs?rev=269638&root=gcc&view=rev Log: PR sanitizer/80953 Merge from LLVM revision 355965 * sanitizer_common/sanitizer_linux.cc (GetWriteFlag): Implement for SPARC/Linux. (GetPcSpBp): Likewise. * sanitizer_common/sanitizer_stacktrace.cc (GetNextInstructionPc): Adjust for SPARC. * sanitizer_common/sanitizer_stacktrace.h (SANITIZER_CAN_FAST_UNWIND): Define to 1 for SPARC. * sanitizer_common/sanitizer_stacktrace_sparc.cc: Rewrite. * sanitizer_common/sanitizer_unwind_linux_libcdep.cc (SlowUnwindStack): Adjust the PC address for SPARC with GCC. Modified: trunk/libsanitizer/ChangeLog trunk/libsanitizer/sanitizer_common/sanitizer_linux.cc trunk/libsanitizer/sanitizer_common/sanitizer_stacktrace.cc trunk/libsanitizer/sanitizer_common/sanitizer_stacktrace.h trunk/libsanitizer/sanitizer_common/sanitizer_stacktrace_sparc.cc trunk/libsanitizer/sanitizer_common/sanitizer_unwind_linux_libcdep.cc
[Bug sanitizer/80953] Support libsanitizer on Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80953 --- Comment #35 from Eric Botcazou --- > Right: 64-bit Solaris/SPARC uses the full 64-bit address space: > > https://docs.oracle.com/cd/E37838_01/html/E66175/advanced-2. > html#SSFDGadvanced-5 > > The gap between the low and high parts cannot be determined > programmatically right now and varies between different sparc machines. Linux uses an equivalent VM layout (although the primary stack is in the low part instead of the high part). I think that on Linux the hole is fully determined by the number of bits available for virtual addresses. > Even if that could be fixed (there's been talk about adding an interface > to determine that information at runtime), the current shadow address > calculation cannot cope with such a discontinuous address space. Right, but you can tweak it once the position of the hole is determined. I have done so for a 52-bit VM layout (T4 and later apparently) and, modulo fixes all over the place (libsanitizer, libbacktrace, compiler, testsuite), I now have a 100% clean ASAN testsuite on both 32-bit and 64-bit SPARC/Linux. Trying on Solaris now...
[Bug sanitizer/80953] Support libsanitizer on Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80953 --- Comment #34 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #33 from Eric Botcazou --- >> I found that enabling it causes quite a number of regressions. Here's >> the list that I've just recreated: [...] >> Maybe this goes away with your unwinding fix, though. > > OK, that was a second unwinding issue, now fixed too. Great. > Can you remind me of the issue in 64-bit mode? Inconvenient memory layout, > right? It seems to be present on Linux as well. Right: 64-bit Solaris/SPARC uses the full 64-bit address space: https://docs.oracle.com/cd/E37838_01/html/E66175/advanced-2.html#SSFDGadvanced-5 The gap between the low and high parts cannot be determined programmatically right now and varies between different sparc machines. Even if that could be fixed (there's been talk about adding an interface to determine that information at runtime), the current shadow address calculation cannot cope with such a discontinuous address space. 64-bit Solaris/x86 had the same problem, but the layout was changed for Solaris 11.4 at least, so here things are easier: https://docs.oracle.com/cd/E37838_01/html/E66175/fcowb.html#SSFDGfcpaf
[Bug sanitizer/80953] Support libsanitizer on Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80953 --- Comment #33 from Eric Botcazou --- > I found that enabling it causes quite a number of regressions. Here's > the list that I've just recreated: > > +FAIL: c-c++-common/asan/heap-overflow-1.c -O0 output pattern test > +FAIL: c-c++-common/asan/heap-overflow-1.c -O1 output pattern test > +FAIL: c-c++-common/asan/heap-overflow-1.c -O2 output pattern test > +FAIL: c-c++-common/asan/heap-overflow-1.c -O2 -flto output pattern test > +FAIL: c-c++-common/asan/heap-overflow-1.c -O2 -flto -flto-partition=none > output pattern test > +FAIL: c-c++-common/asan/heap-overflow-1.c -O3 -g output pattern test > +FAIL: c-c++-common/asan/heap-overflow-1.c -Os output pattern test > > +FAIL: c-c++-common/asan/pr70541.c -O0 output pattern test > > +FAIL: c-c++-common/asan/strncpy-overflow-1.c -O0 output pattern test > +FAIL: c-c++-common/asan/strncpy-overflow-1.c -O1 output pattern test > +FAIL: c-c++-common/asan/strncpy-overflow-1.c -O2 output pattern test > +FAIL: c-c++-common/asan/strncpy-overflow-1.c -O2 -flto output pattern > test > +FAIL: c-c++-common/asan/strncpy-overflow-1.c -O2 -flto > -flto-partition=none output pattern test > +FAIL: c-c++-common/asan/strncpy-overflow-1.c -O3 -g output pattern test > +FAIL: c-c++-common/asan/strncpy-overflow-1.c -Os output pattern test > +FAIL: c-c++-common/asan/use-after-free-1.c -O0 output pattern test > +FAIL: c-c++-common/asan/use-after-free-1.c -O1 output pattern test > +FAIL: c-c++-common/asan/use-after-free-1.c -O2 output pattern test > +FAIL: c-c++-common/asan/use-after-free-1.c -O2 -flto output pattern test > +FAIL: c-c++-common/asan/use-after-free-1.c -O2 -flto -flto-partition=none > output pattern test > +FAIL: c-c++-common/asan/use-after-free-1.c -O3 -g output pattern test > +FAIL: c-c++-common/asan/use-after-free-1.c -Os output pattern test > +FAIL: g++.dg/asan/deep-stack-uaf-1.C -O0 output pattern test > > Maybe this goes away with your unwinding fix, though. OK, that was a second unwinding issue, now fixed too. Can you remind me of the issue in 64-bit mode? Inconvenient memory layout, right? It seems to be present on Linux as well.
[Bug sanitizer/80953] Support libsanitizer on Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80953 --- Comment #32 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #31 from Eric Botcazou --- >> I think it is important to find out why there are those differences in line >> numbers. Is libbacktrace broken on Solaris, or not used at all, something >> different? > > The libsanitizer does its private unwinding by means of _Unwind_Backtrace, > which works fine. But, at the end, it overwrites the first address with the > result of __builtin_return_address, which returns the address of the call > instruction and not the return address on the SPARC (maybe you know why, > Jakub?) so the first frame is off by 8 bytes. I have a tentative fixlet for > the libsanitizer. Excellent, thanks for the detective work. > Btw, Rainer, why did you disable fast unwinding on the SPARC? This puts the > SPARC port in its own basket (admittedly with MIPS) so that's not very > convenient. For one, this is how it had been on Linux/sparc (although I wonder how this can ever have been tested given that asan with clang is useless on sparc). When I looked into this https://reviews.llvm.org/D54099 I found that enabling it causes quite a number of regressions. Here's the list that I've just recreated: +FAIL: c-c++-common/asan/heap-overflow-1.c -O0 output pattern test +FAIL: c-c++-common/asan/heap-overflow-1.c -O1 output pattern test +FAIL: c-c++-common/asan/heap-overflow-1.c -O2 output pattern test +FAIL: c-c++-common/asan/heap-overflow-1.c -O2 -flto output pattern test +FAIL: c-c++-common/asan/heap-overflow-1.c -O2 -flto -flto-partition=none output pattern test +FAIL: c-c++-common/asan/heap-overflow-1.c -O3 -g output pattern test +FAIL: c-c++-common/asan/heap-overflow-1.c -Os output pattern test +FAIL: c-c++-common/asan/pr70541.c -O0 output pattern test +FAIL: c-c++-common/asan/strncpy-overflow-1.c -O0 output pattern test +FAIL: c-c++-common/asan/strncpy-overflow-1.c -O1 output pattern test +FAIL: c-c++-common/asan/strncpy-overflow-1.c -O2 output pattern test +FAIL: c-c++-common/asan/strncpy-overflow-1.c -O2 -flto output pattern test +FAIL: c-c++-common/asan/strncpy-overflow-1.c -O2 -flto -flto-partition=none output pattern test +FAIL: c-c++-common/asan/strncpy-overflow-1.c -O3 -g output pattern test +FAIL: c-c++-common/asan/strncpy-overflow-1.c -Os output pattern test +FAIL: c-c++-common/asan/use-after-free-1.c -O0 output pattern test +FAIL: c-c++-common/asan/use-after-free-1.c -O1 output pattern test +FAIL: c-c++-common/asan/use-after-free-1.c -O2 output pattern test +FAIL: c-c++-common/asan/use-after-free-1.c -O2 -flto output pattern test +FAIL: c-c++-common/asan/use-after-free-1.c -O2 -flto -flto-partition=none output pattern test +FAIL: c-c++-common/asan/use-after-free-1.c -O3 -g output pattern test +FAIL: c-c++-common/asan/use-after-free-1.c -Os output pattern test +FAIL: g++.dg/asan/deep-stack-uaf-1.C -O0 output pattern test Maybe this goes away with your unwinding fix, though. While trying this, I stumbled over the fact that a 64-bit-default gcc with -m32 doesn't define __sparcv8, unlike its 32-bit-default equivalent, which leaves an empty sanitizer_stacktrace_sparc.o. Need to look into this.
[Bug sanitizer/80953] Support libsanitizer on Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80953 --- Comment #31 from Eric Botcazou --- > I think it is important to find out why there are those differences in line > numbers. Is libbacktrace broken on Solaris, or not used at all, something > different? The libsanitizer does its private unwinding by means of _Unwind_Backtrace, which works fine. But, at the end, it overwrites the first address with the result of __builtin_return_address, which returns the address of the call instruction and not the return address on the SPARC (maybe you know why, Jakub?) so the first frame is off by 8 bytes. I have a tentative fixlet for the libsanitizer. Btw, Rainer, why did you disable fast unwinding on the SPARC? This puts the SPARC port in its own basket (admittedly with MIPS) so that's not very convenient.
[Bug sanitizer/80953] Support libsanitizer on Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80953 --- Comment #30 from Eric Botcazou --- > Is already included in sol2.h (ASAN_CC1_SPEC). OK. Then unwind info is needed in the epilogue?
[Bug sanitizer/80953] Support libsanitizer on Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80953 --- Comment #29 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #28 from Eric Botcazou --- [...] >> -fno-delayed-branch made no difference. > > What about -fasynchronous-unwind-tables? Is already included in sol2.h (ASAN_CC1_SPEC).
[Bug sanitizer/80953] Support libsanitizer on Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80953 --- Comment #28 from Eric Botcazou --- > For a quick check, I just tried it on > c-c++-common/asan/heap-overflow-1.c at -O0 > > #0 0x11258 in main > /vol/gcc/src/hg/trunk/local/gcc/testsuite/c-c++-common/asan/heap-overflow-1. > c:21 > > vs. -O1: > > #0 0x1121c in main > /vol/gcc/src/hg/trunk/local/gcc/testsuite/c-c++-common/asan/heap-overflow-1. > c:24 > > -fno-delayed-branch made no difference. What about -fasynchronous-unwind-tables?
[Bug sanitizer/80953] Support libsanitizer on Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80953 --- Comment #27 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #26 from Jakub Jelinek --- > Try -fno-delayed-branch then? The debug info and unwind info for delayed > slots > isn't really well defined... For a quick check, I just tried it on c-c++-common/asan/heap-overflow-1.c at -O0 #0 0x11258 in main /vol/gcc/src/hg/trunk/local/gcc/testsuite/c-c++-common/asan/heap-overflow-1.c:21 vs. -O1: #0 0x1121c in main /vol/gcc/src/hg/trunk/local/gcc/testsuite/c-c++-common/asan/heap-overflow-1.c:24 -fno-delayed-branch made no difference.
[Bug sanitizer/80953] Support libsanitizer on Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80953 --- Comment #26 from Jakub Jelinek --- Try -fno-delayed-branch then? The debug info and unwind info for delayed slots isn't really well defined...
[Bug sanitizer/80953] Support libsanitizer on Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80953 --- Comment #25 from Eric Botcazou --- > It is definitely used, same as on Solaris/x86 where this issue doesn't > occur. Maybe related to delay slots then.
[Bug sanitizer/80953] Support libsanitizer on Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80953 --- Comment #24 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #22 from Eric Botcazou --- >> I think it is important to find out why there are those differences in line >> numbers. Is libbacktrace broken on Solaris, or not used at all, something >> different? > > AFAICS they only occur with optimization enabled. Indeed: in the cases where the output pattern test failures also occur at -O0, there are different issues, not just slight line number differences.
[Bug sanitizer/80953] Support libsanitizer on Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80953 --- Comment #23 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #21 from Jakub Jelinek --- > I think it is important to find out why there are those differences in line > numbers. Is libbacktrace broken on Solaris, or not used at all, something > different? It is definitely used, same as on Solaris/x86 where this issue doesn't occur. Sometime last year I'd already started looking at this issue and found that for some PCs the DWARF line numbers seem to be off. I'll verify this again and report the details once I'm done. It would be interesting to test this on Linux/SPARC, too.
[Bug sanitizer/80953] Support libsanitizer on Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80953 --- Comment #22 from Eric Botcazou --- > I think it is important to find out why there are those differences in line > numbers. Is libbacktrace broken on Solaris, or not used at all, something > different? AFAICS they only occur with optimization enabled.
[Bug sanitizer/80953] Support libsanitizer on Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80953 --- Comment #21 from Jakub Jelinek --- I think it is important to find out why there are those differences in line numbers. Is libbacktrace broken on Solaris, or not used at all, something different?
[Bug sanitizer/80953] Support libsanitizer on Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80953 --- Comment #20 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #18 from Eric Botcazou --- > (> These are often just off-by-one errors in the line numbers; I believe I >> have a patch around somewhere to fix at least some of those... > > OK, I see, a bit annoying in the test results though. Very true. The attached patch allows for the line number variations I'm seeing in the failing sparc output pattern tests. I've no idea yet if something like this is acceptable, though. This leaves me with the following output patter failures (on Solaris 11.5 Beta): c-c++-common/asan/global-overflow-1.c AddressSanitizer: nested bug in the same thread, aborting. c-c++-common/asan/pr62089.c AddressSanitizer: nested bug in the same thread, aborting. c-c++-common/asan/strlen-overflow-1.c AddressSanitizer: nested bug in the same thread, aborting. g++.dg/asan/deep-tail-call-1.C AddressSanitizer: nested bug in the same thread, aborting. g++.dg/asan/function-argument-3.C empty output at -O0 gcc.dg/asan/use-after-scope-5.c AddressSanitizer:DEADLYSIGNAL (SIGBUS), a recent regression to be dealt with separately and of course the execution failures.
[Bug sanitizer/80953] Support libsanitizer on Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80953 --- Comment #19 from Rainer Orth --- Created attachment 45163 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45163&action=edit Preliminary patch for regular sparc output patter test failures
[Bug sanitizer/80953] Support libsanitizer on Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80953 --- Comment #18 from Eric Botcazou --- (> These are often just off-by-one errors in the line numbers; I believe I > have a patch around somewhere to fix at least some of those... OK, I see, a bit annoying in the test results though.
[Bug sanitizer/80953] Support libsanitizer on Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80953 --- Comment #17 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #15 from Eric Botcazou --- >> I only have: [...] >> as execution test failures, but I have a bunch of output pattern test >> failures. > > Rainer, do you also have a slew of output pattern test failures on SPARC? I do indeed: on S11.5 the full list is 6 c-c++-common/asan/alloca_big_alignment.c 6 c-c++-common/asan/alloca_detect_custom_size.c 6 c-c++-common/asan/alloca_overflow_partial.c 6 c-c++-common/asan/alloca_overflow_right.c 6 c-c++-common/asan/alloca_underflow_left.c 14 c-c++-common/asan/global-overflow-1.c 6 c-c++-common/asan/heap-overflow-1.c 2 c-c++-common/asan/misalign-1.c 2 c-c++-common/asan/misalign-2.c 7 c-c++-common/asan/pr62089.c 6 c-c++-common/asan/stack-overflow-1.c 10 c-c++-common/asan/strlen-overflow-1.c 6 c-c++-common/asan/use-after-free-1.c 7 g++.dg/asan/deep-tail-call-1.C 3 g++.dg/asan/large-func-test-1.C These are often just off-by-one errors in the line numbers; I believe I have a patch around somewhere to fix at least some of those...
[Bug sanitizer/80953] Support libsanitizer on Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80953 --- Comment #16 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #14 from Eric Botcazou --- >> The only asan execution failures I see on Solaris 11/SPARC are [...] > I only have: > > c-c++-common/asan/pointer-compare-1.c > c-c++-common/asan/pointer-compare-2.c > c-c++-common/asan/pointer-subtract-1.c > c-c++-common/asan/pointer-subtract-2.c > g++.dg/asan/function-argument-3.C > > as execution test failures, but I have a bunch of output pattern test > failures. I've checked current results and find the same on S11.3, while on S11.[45] there's the added g++.dg/asan/default-options-1.C.
[Bug sanitizer/80953] Support libsanitizer on Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80953 --- Comment #15 from Eric Botcazou --- > I only have: > > c-c++-common/asan/pointer-compare-1.c > c-c++-common/asan/pointer-compare-2.c > c-c++-common/asan/pointer-subtract-1.c > c-c++-common/asan/pointer-subtract-2.c > g++.dg/asan/function-argument-3.C > > as execution test failures, but I have a bunch of output pattern test > failures. Rainer, do you also have a slew of output pattern test failures on SPARC?
[Bug sanitizer/80953] Support libsanitizer on Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80953 --- Comment #14 from Eric Botcazou --- > The only asan execution failures I see on Solaris 11/SPARC are > > c-c++-common/asan/pointer-compare-1.c > c-c++-common/asan/pointer-compare-2.c > c-c++-common/asan/pointer-subtract-1.c > c-c++-common/asan/pointer-subtract-2.c > c-c++-common/asan/pointer-subtract-3.c > g++.dg/asan/default-options-1.C > g++.dg/asan/function-argument-3.C > g++.dg/asan/pr78651.C > g++.dg/asan/pr81021.C I only have: c-c++-common/asan/pointer-compare-1.c c-c++-common/asan/pointer-compare-2.c c-c++-common/asan/pointer-subtract-1.c c-c++-common/asan/pointer-subtract-2.c g++.dg/asan/function-argument-3.C as execution test failures, but I have a bunch of output pattern test failures.
[Bug sanitizer/80953] Support libsanitizer on Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80953 --- Comment #13 from Eric Botcazou --- > This is weird: this test PASSes for me on Solaris 11.3, 11.4 and 11.5, > both 32 and 64-bit, as and gas. A more useful backtrace just before the crash: (gdb) bt #0 0xfe8d9080 in free () from /home/botcazou/gcc-head/install_sparc/lib/libasan.so.5 #1 0xff14de1c in __deregister_frame_info_bases (begin=) at /homes/botcazou/gcc-head/src/libgcc/unwind-dw2-fde.c:228 #2 __deregister_frame_info_bases (begin=0xff15f044) at /homes/botcazou/gcc-head/src/libgcc/unwind-dw2-fde.c:201 #3 0xff1435fc in __do_global_dtors_aux () from /home/botcazou/gcc-head/install_sparc/lib/libgcc_s.so.1 #4 0xff14ed80 in _fini () from /home/botcazou/gcc-head/install_sparc/lib/libgcc_s.so.1 #5 0xff1b236c in call_fini () from /usr/lib/ld.so.1 #6 0xff1b24a4 in atexit_fini () from /usr/lib/ld.so.1 #7 0xff05c128 in _exithandle () from /lib/libc.so.1 #8 0xff049f94 in exit () from /lib/libc.so.1 #9 0x00010dfc in _start () so libgcc is dereferencing its EH frames by invoking libasan's free... The bottom line is that you need to HAVE_LD_EH_FRAME_HDR enabled in the compiler otherwise the sanitizer is unusable (it wasn't because the configure script requires GNU sed and only found the system sed on the machine).
[Bug sanitizer/80953] Support libsanitizer on Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80953 --- Comment #12 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #11 from Eric Botcazou --- > I have a bunch of sanitizer failures on SPARC/Solaris 11.3: [...] This is weird: this test PASSes for me on Solaris 11.3, 11.4 and 11.5, both 32 and 64-bit, as and gas. Cannot check on Solaris 10 since libsanitizer doesn't currently compile there and I won't probably get around to fixing that. The only asan execution failures I see on Solaris 11/SPARC are c-c++-common/asan/pointer-compare-1.c c-c++-common/asan/pointer-compare-2.c c-c++-common/asan/pointer-subtract-1.c c-c++-common/asan/pointer-subtract-2.c c-c++-common/asan/pointer-subtract-3.c g++.dg/asan/default-options-1.C g++.dg/asan/function-argument-3.C g++.dg/asan/pr78651.C g++.dg/asan/pr81021.C Solaris 11/x86 is way better, though: c-c++-common/asan/pointer-subtract-3.c c-c++-common/asan/swapcontext-test-1.c g++.dg/asan/default-options-1.C
[Bug sanitizer/80953] Support libsanitizer on Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80953 Eric Botcazou changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org --- Comment #11 from Eric Botcazou --- I have a bunch of sanitizer failures on SPARC/Solaris 11.3: FAIL: c-c++-common/asan/alloca_safe_access.c -O0 execution test FAIL: c-c++-common/asan/alloca_safe_access.c -O1 execution test FAIL: c-c++-common/asan/alloca_safe_access.c -O2 execution test FAIL: c-c++-common/asan/alloca_safe_access.c -O2 -flto execution test FAIL: c-c++-common/asan/alloca_safe_access.c -O2 -flto -flto-partition=none execution test FAIL: c-c++-common/asan/alloca_safe_access.c -O3 -g execution test FAIL: c-c++-common/asan/alloca_safe_access.c -Os execution test Program received signal SIGABRT, Aborted. [Switching to Thread 1 (LWP 1)] 0xff0de934 in __lwp_sigqueue () from /lib/libc.so.1 (gdb) bt #0 0xff0de934 in __lwp_sigqueue () from /lib/libc.so.1 #1 0xff082178 in raise () from /lib/libc.so.1 #2 0xff05a534 in abort () from /lib/libc.so.1 #3 0xff14bc74 in uw_init_context_1 (context=0xffbfead4, outer_cfa=0xffbff070, outer_ra=0xfe90abd0) at /homes/botcazou/gcc-head/src/libgcc/unwind-dw2.c:1602 #4 0xff14c580 in _Unwind_Backtrace (trace=0xfe90aaa0, trace_argument=0xffbff0e0) at /homes/botcazou/gcc-head/src/libgcc/unwind.inc:295 #5 0xfe90abd8 in ?? () from /homes/botcazou/gcc-head/install_sparc/lib/libasan.so.5 Backtrace stopped: previous frame identical to this frame (corrupt stack?)
[Bug sanitizer/80953] Support libsanitizer on Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80953 Rainer Orth changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED URL||https://gcc.gnu.org/ml/gcc- ||patches/2018-11/msg00337.ht ||ml Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |ro at gcc dot gnu.org Target Milestone|--- |9.0 --- Comment #10 from Rainer Orth --- Fixed for 9.0.
[Bug sanitizer/80953] Support libsanitizer on Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80953 --- Comment #9 from Rainer Orth --- Author: ro Date: Tue Nov 6 10:49:34 2018 New Revision: 265837 URL: https://gcc.gnu.org/viewcvs?rev=265837&root=gcc&view=rev Log: Enable libsanitizer on Solaris (PR sanitizer/80953) gcc: PR sanitizer/80953 * config/sol2.h (ASAN_CC1_SPEC): Define. (LD_WHOLE_ARCHIVE_OPTION): Define. (LD_NO_WHOLE_ARCHIVE_OPTION): Define. (ASAN_REJECT_SPEC): Provide default. (LIBASAN_EARLY_SPEC): Define. (LIBTSAN_EARLY_SPEC): Define. (LIBLSAN_EARLY_SPEC): Define. * config/i386/sol2.h (CC1_SPEC): Redefine. (ASAN_REJECT_SPEC): Define. * config/sparc/sparc.c (sparc_asan_shadow_offset): Declare. (TARGET_ASAN_SHADOW_OFFSET): Define. (sparc_asan_shadow_offset): New function. * config/sparc/sol2.h (CC1_SPEC): Append ASAN_CC1_SPEC. (ASAN_REJECT_SPEC): Define. gcc/testsuite: PR sanitizer/80953 * c-c++-common/asan/alloca_loop_unpoisoning.c: Require alloca support. (foo): Use __builtin_alloca. libsanitizer: PR sanitizer/80953 * configure.tgt (sparc*-*-solaris2.11*): Enable. (x86_64-*-solaris2.11* | i?86-*-solaris2.11*): Enable. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/sol2.h trunk/gcc/config/sol2.h trunk/gcc/config/sparc/sol2.h trunk/gcc/config/sparc/sparc.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/c-c++-common/asan/alloca_loop_unpoisoning.c trunk/libsanitizer/ChangeLog trunk/libsanitizer/configure.tgt
[Bug sanitizer/80953] Support libsanitizer on Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80953 --- Comment #8 from Rainer Orth --- Author: ro Date: Tue Nov 6 10:42:05 2018 New Revision: 265836 URL: https://gcc.gnu.org/viewcvs?rev=265836&root=gcc&view=rev Log: Cherry-pick Solaris sanitizer fixes (PR sanitizer/80953) PR sanitizer/80953 * sanitizer_common/sanitizer_internal_defs.h, sanitizer_common/sanitizer_platform_limits_solaris.h, sanitizer_common/sanitizer_procmaps_solaris.cc, sanitizer_common/sanitizer_solaris.cc: Cherry-pick compiler-rt revision 346153. * sanitizer_common/sanitizer_stacktrace.h, sanitizer_common/sanitizer_stacktrace_sparc.cc: Cherry-pick compiler-rt revision 346155. Modified: trunk/libsanitizer/ChangeLog trunk/libsanitizer/sanitizer_common/sanitizer_internal_defs.h trunk/libsanitizer/sanitizer_common/sanitizer_platform_limits_solaris.h trunk/libsanitizer/sanitizer_common/sanitizer_procmaps_solaris.cc trunk/libsanitizer/sanitizer_common/sanitizer_solaris.cc trunk/libsanitizer/sanitizer_common/sanitizer_stacktrace.h trunk/libsanitizer/sanitizer_common/sanitizer_stacktrace_sparc.cc
[Bug sanitizer/80953] Support libsanitizer on Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80953 --- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #6 from Maxim Ostapenko --- [...] > For ODR violation bug we have a local patch in libsanitizer. Could you check > whether you applied all local patches listed in libsanitizer/LOCAL_PATCHES > file? excellent, I totally missed that. As the saying goes: a day of debugging can save you an hour in the library ;-) With those patches applied (two of them have already been integrated upstream, r241978 and r243014), the ODR violation failures are gone. Thanks a lot. Rainer
[Bug sanitizer/80953] Support libsanitizer on Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80953 Maxim Ostapenko changed: What|Removed |Added CC||m.ostapenko at samsung dot com --- Comment #6 from Maxim Ostapenko --- (In reply to Rainer Orth from comment #5) > Created attachment 41484 [details] > Merge libsanitizer from compiler-rt r304722 > > I've now completed a merge of llvm r304722 into gcc trunk libsanitizer. > Most of > it was straightforward, but a couple of issues may save others work: > > * Two bugs in sanitizer_common/sanitizer_symbolizer_libbacktrace.cc have > already > been reported upstream: https://reviews.llvm.org/D33933 > > * In libubsan, __ubsan_handle_type_mismatch has been renamed to > __ubsan_handle_type_mismatch_v1, and likewise for > __ubsan_handle_type_mismatch_abort__ubsan_handle_type_mismatch_v1_abort > > The sanitizer.def and ubsan.c changes reflect this. Worse, however, > the former uptr Alignment member of ubsan/ubsan_handlers.h was changed to > unsigned char LogAlignment. This needs a corresponding gcc change to pass > log2(align) instead of just align. > > * Many (all) */float-cast-overflow-*.c tests FAILed initially because of a > message change: > > runtime error: value -133 is outside the range of representable values of > type 'signed char' > > lost the leading "value" > > With these gcc side changes, testresults on x86_64-pc-linux-gnu are identical > to those with current gcc trunk, with the exception of > > +FAIL: c-c++-common/asan/pr63888.c -O2 execution test > +FAIL: c-c++-common/asan/pr63888.c -O2 -flto execution test > +FAIL: c-c++-common/asan/pr63888.c -O2 -flto -flto-partition=none > execution t > est > +FAIL: c-c++-common/asan/pr63888.c -O3 -g execution test > +FAIL: c-c++-common/asan/pr63888.c -Os execution test > > I get here > > = > ==4734==ERROR: AddressSanitizer: odr-violation (0x004009e0): > [1] size=12 'CSWTCH.1' > /vol/gcc/src/hg/trunk/solaris-asan/gcc/testsuite/c-c++-common/asan/pr63888.c: > 8:3 > [2] size=12 'CSWTCH.3' > /vol/gcc/src/hg/trunk/solaris-asan/gcc/testsuite/c-c++-common/asan/pr63888.c: > 21:3 > These globals were registered at these points: > [1]: > #0 0x7f2c9c48fb88 in __asan_register_globals > /vol/gcc/src/hg/trunk/solaris-asan/libsanitizer/asan/asan_globals.cc:356 > #1 0x40097c in __libc_csu_init > (/var/scratch/gcc/gcc-8.0.0-20170531/4.10.10-gcc-gas-gld-asan/gcc/testsuite/ > gcc17/pr63888.exe+0x40097c) > > [2]: > #0 0x7f2c9c48fb88 in __asan_register_globals > /vol/gcc/src/hg/trunk/solaris-asan/libsanitizer/asan/asan_globals.cc:356 > #1 0x40097c in __libc_csu_init > (/var/scratch/gcc/gcc-8.0.0-20170531/4.10.10-gcc-gas-gld-asan/gcc/testsuite/ > gcc17/pr63888.exe+0x40097c) > > ==4734==HINT: if you don't care about these errors you may set > ASAN_OPTIONS=detect_odr_violation=0 > SUMMARY: AddressSanitizer: odr-violation: global 'CSWTCH.1' at > /vol/gcc/src/hg/trunk/solaris-asan/gcc/testsuite/c-c++-common/asan/pr63888.c: > 8:3 > ==4734==ABORTING > > Someone who knows that code way better needs to look into this. > > Rainer For ODR violation bug we have a local patch in libsanitizer. Could you check whether you applied all local patches listed in libsanitizer/LOCAL_PATCHES file?
[Bug sanitizer/80953] Support libsanitizer on Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80953 --- Comment #5 from Rainer Orth --- Created attachment 41484 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41484&action=edit Merge libsanitizer from compiler-rt r304722 I've now completed a merge of llvm r304722 into gcc trunk libsanitizer. Most of it was straightforward, but a couple of issues may save others work: * Two bugs in sanitizer_common/sanitizer_symbolizer_libbacktrace.cc have already been reported upstream: https://reviews.llvm.org/D33933 * In libubsan, __ubsan_handle_type_mismatch has been renamed to __ubsan_handle_type_mismatch_v1, and likewise for __ubsan_handle_type_mismatch_abort__ubsan_handle_type_mismatch_v1_abort The sanitizer.def and ubsan.c changes reflect this. Worse, however, the former uptr Alignment member of ubsan/ubsan_handlers.h was changed to unsigned char LogAlignment. This needs a corresponding gcc change to pass log2(align) instead of just align. * Many (all) */float-cast-overflow-*.c tests FAILed initially because of a message change: runtime error: value -133 is outside the range of representable values of type 'signed char' lost the leading "value" With these gcc side changes, testresults on x86_64-pc-linux-gnu are identical to those with current gcc trunk, with the exception of +FAIL: c-c++-common/asan/pr63888.c -O2 execution test +FAIL: c-c++-common/asan/pr63888.c -O2 -flto execution test +FAIL: c-c++-common/asan/pr63888.c -O2 -flto -flto-partition=none execution t est +FAIL: c-c++-common/asan/pr63888.c -O3 -g execution test +FAIL: c-c++-common/asan/pr63888.c -Os execution test I get here = ==4734==ERROR: AddressSanitizer: odr-violation (0x004009e0): [1] size=12 'CSWTCH.1' /vol/gcc/src/hg/trunk/solaris-asan/gcc/testsuite/c-c++-common/asan/pr63888.c:8:3 [2] size=12 'CSWTCH.3' /vol/gcc/src/hg/trunk/solaris-asan/gcc/testsuite/c-c++-common/asan/pr63888.c:21:3 These globals were registered at these points: [1]: #0 0x7f2c9c48fb88 in __asan_register_globals /vol/gcc/src/hg/trunk/solaris-asan/libsanitizer/asan/asan_globals.cc:356 #1 0x40097c in __libc_csu_init (/var/scratch/gcc/gcc-8.0.0-20170531/4.10.10-gcc-gas-gld-asan/gcc/testsuite/gcc17/pr63888.exe+0x40097c) [2]: #0 0x7f2c9c48fb88 in __asan_register_globals /vol/gcc/src/hg/trunk/solaris-asan/libsanitizer/asan/asan_globals.cc:356 #1 0x40097c in __libc_csu_init (/var/scratch/gcc/gcc-8.0.0-20170531/4.10.10-gcc-gas-gld-asan/gcc/testsuite/gcc17/pr63888.exe+0x40097c) ==4734==HINT: if you don't care about these errors you may set ASAN_OPTIONS=detect_odr_violation=0 SUMMARY: AddressSanitizer: odr-violation: global 'CSWTCH.1' at /vol/gcc/src/hg/trunk/solaris-asan/gcc/testsuite/c-c++-common/asan/pr63888.c:8:3 ==4734==ABORTING Someone who knows that code way better needs to look into this. Rainer
[Bug sanitizer/80953] Support libsanitizer on Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80953 --- Comment #4 from Rainer Orth --- Created attachment 41453 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41453&action=edit Add SPARC ASan support in GCC
[Bug sanitizer/80953] Support libsanitizer on Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80953 --- Comment #3 from Rainer Orth --- Created attachment 41452 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41452&action=edit Adapt c-c++-common/ubsan/float-cast-overflow-1.c for Solaris
[Bug sanitizer/80953] Support libsanitizer on Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80953 --- Comment #2 from Rainer Orth --- Created attachment 41451 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41451&action=edit Basic libsanitizer Solaris support: x86 GCC side
[Bug sanitizer/80953] Support libsanitizer on Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80953 --- Comment #1 from Rainer Orth --- Created attachment 41450 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41450&action=edit Basic libsanitizer Solaris support
