https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #78 from Eric Gallager ---
(In reply to Ilya Leoshkevich from comment #77)
> Apparently fixing the message in GCC will produce maintenance overhead [1].
> If that's not very important to you, I'd rather leave this message as is.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #77 from Ilya Leoshkevich ---
Apparently fixing the message in GCC will produce maintenance overhead [1]. If
that's not very important to you, I'd rather leave this message as is.
[1]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #76 from Ilya Leoshkevich ---
It's because the sanitizer runtime was copied from LLVM to GCC. I will post a
patch removing the unsupported MSan and DFSan from the error message.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #74 from Dominik Vogt ---
With the pending patches/fixes, the *san testsuites are clean on s390x biarch
and s390. :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #73 from Jakub Jelinek ---
I've filed https://reviews.llvm.org/D29992 upstream for this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #72 from Dominik Vogt ---
I wanted to refer to the funny pc value. The line information is actually
correct.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #71 from Ulrich Weigand ---
(In reply to Dominik Vogt from comment #70)
> If funny line information is the only consequence, no. Is it safe to assume
> that libsanitizer won't crash or produce garbege because of this?
Why should
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #70 from Dominik Vogt ---
If funny line information is the only consequence, no. Is it safe to assume
that libsanitizer won't crash or produce garbege because of this?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #69 from Jakub Jelinek ---
Is it really that bad? Does it really matter if the addresses printed in the
backtrace are somewhere in the call instructions, end of those call
instructions or their start?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #68 from Dominik Vogt ---
Okay, that fixes the test failure, but the addresses further up in the
backtrace are still bad, e.g.
#0 0x10008d2 in NullDeref
#1 0x1000759 in main
#2 0x3fffce23069 in
#3 0x10007d5
Maybe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #67 from Jakub Jelinek ---
This seems to fix the testcase with -march=zEC12 for me.
The problem is that while we carefully compute it, other code than "cleverly"
overwrites it back to the pc it got from the siginfo.
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #66 from Dominik Vogt ---
Compiled from scratch to make sure it's not a build dependency problem, but the
tests still fail because of the odd backtrace addresses. Can I provide some
information from single stepping in Gdb?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #65 from Dominik Vogt ---
That patch does not compile, and fixing the compiler error (context -> ctx)
doesn't help either.
> but I also can't reproduce the nullptr-1.c failure myself
An example command line is
$
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #64 from Jakub Jelinek ---
Perhaps the easiest hack would be for
sanitizer_common/sanitizer_unwind_linux_libcdep.cc (Unwind_GetIP) call
_Unwind_GetIPInfo instead of _Unwind_GetIP (perhaps just on SANITIZER_LINUX or
wherever it is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #63 from Jakub Jelinek ---
(In reply to Jakub Jelinek from comment #61)
> It is true that libasan calls just _Unwind_GetIP rather than
> _Unwind_GetIPInfo,
> but I don't see where there is that subtraction of 1, so it shouldn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #62 from Dominik Vogt ---
(In reply to Jakub Jelinek from comment #61)
> It is true that libasan calls just _Unwind_GetIP rather than
> _Unwind_GetIPInfo,
> but I don't see where there is that subtraction of 1, so it shouldn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #61 from Jakub Jelinek ---
(In reply to Florian Weimer from comment #58)
> (In reply to Dominik Vogt from comment #57)
> > libsanitizer miscalculates the Pcs in the backtrace:
> >
> > #0 0x1000839 in NullDeref
> > #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #60 from Ulrich Weigand ---
... well, as Florian said as well :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #59 from Ulrich Weigand ---
(In reply to Dominik Vogt from comment #57)
> libsanitizer miscalculates the Pcs in the backtrace:
>
> #0 0x1000839 in NullDeref
> #1 0x10006c1 in main
> #2 0x3fff6e23069 in __libc_start_main
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #58 from Florian Weimer ---
(In reply to Dominik Vogt from comment #57)
> libsanitizer miscalculates the Pcs in the backtrace:
>
> #0 0x1000839 in NullDeref
> #1 0x10006c1 in main
> #2 0x3fff6e23069 in __libc_start_main
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #57 from Dominik Vogt ---
libsanitizer miscalculates the Pcs in the backtrace:
#0 0x1000839 in NullDeref
#1 0x10006c1 in main
#2 0x3fff6e23069 in __libc_start_main
#3 0x100073d
These are all odd addresses, pointing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #56 from Dominik Vogt ---
null-deref-1.c fails because the test expects this message in source line 10
but gets it for line 11:
#0 0x1000853 in NullDeref .../c-c++-common/asan/null-deref-1.c:11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #55 from Dominik Vogt ---
(In reply to Dominik Vogt from comment #53)
> no fails with -m31; with -m64 null-deref-1.c fails with c and
> c++, and memcmp-1.c with c++ only.
memcmp-1.c is not reproducible.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #54 from Jakub Jelinek ---
Author: jakub
Date: Mon Feb 13 23:09:09 2017
New Revision: 245411
URL: https://gcc.gnu.org/viewcvs?rev=245411=gcc=rev
Log:
PR sanitizer/79341
* c-c++-common/ubsan/float-cast-overflow-8.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #53 from Dominik Vogt ---
(In reply to Dominik Vogt from comment #51)
> With r245382 plus the patch from comment 43, only the failure in
> null-deref-1.c is left.
Ah, not quite; no fails with -m31; with -m64 null-deref-1.c fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
Dominik Vogt changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #51 from Dominik Vogt ---
With r245382 plus the patch from comment 43, only the failure in null-deref-1.c
is left.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #50 from Jakub Jelinek ---
Author: jakub
Date: Sat Feb 11 18:38:11 2017
New Revision: 245361
URL: https://gcc.gnu.org/viewcvs?rev=245361=gcc=rev
Log:
PR sanitizer/79341
* g++.dg/asan/deep-stack-uaf-1.C: New test.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #49 from Jakub Jelinek ---
On the other side, we don't turn -fno-omit-frame-pointer or
-mno-omit-leaf-frame-pointer for -fsanitize=address on other targets either,
perhaps this is just a documentation issue. I'll add -mbackchain to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #48 from Ulrich Weigand ---
s390(x) has -fasynchronous-unwind-tables on by default anyway, and .eh_frame
based DWARF unwinding is the only way to create stack backtraces that always
works.
However, I understood that asan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #47 from Jakub Jelinek ---
Seems clang doesn't default to -mbackchain for -fsanitize=address, they just
force it on when testing:
if config.target_arch == 's390x':
clang_asan_static_cflags.append("-mbackchain")
So, if we just want
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #46 from Jakub Jelinek ---
Or shall we use -mbackchain for -fsanitize=address by default and tweak the
unwinding code sanitizer_common/sanitizer_stacktrace.{cc,h} to use the
backchain?
AFAIK libsanitizer uses the .eh_frame unwinding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #45 from Jakub Jelinek ---
deep-stack-uaf*.C failure is presumably because the fast unwind (one that
doesn't use .eh_frame unwind info) isn't working properly.
But I'm afraid I don't know enough about s390{,x} to debug that.
E.g. on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #44 from Jakub Jelinek ---
Author: jakub
Date: Fri Feb 10 23:34:49 2017
New Revision: 245350
URL: https://gcc.gnu.org/viewcvs?rev=245350=gcc=rev
Log:
PR sanitizer/79341
* configure.tgt (s390*-*-linux*): Don't disable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #43 from Jakub Jelinek ---
Ah, so, if I build with -O0, I always get the expected errors.
If I build with -O2 -mcpu=z9-109, I also get them, but with -O2 -mcpu=z10 or
-O2 -mcpu=zEC12 I don't.
Does _Decimal32 on s390{,x} behave
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #42 from Dominik Vogt ---
With glibc-2.18 and the various patches, the following tets fail:
-m31:
* deep-stack-uaf-1.C
-m64:
* null-deref-1.c
* deep-stack-uaf-1.C
* overflow-vec-1.c
* overflow-vec-2.c
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #41 from Dominik Vogt ---
> The first loop loops until add is -1.00E+12, at which point for the
> first time tem is -9.223373E+18 and thus different from -9.223372E+18, and
> -9.223373E+18 should not be representable in signed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #40 from Jakub Jelinek ---
(In reply to Dominik Vogt from comment #38)
> (And if it does generate messages, does it take the if or the else bodies?
> For me it's the if-bodies.)
/home/jakub/gcc/obj/gcc/xgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #39 from Jakub Jelinek ---
For overflow-vec-*.c moved this to PR79454.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #38 from Dominik Vogt ---
(And if it does generate messages, does it take the if or the else bodies? For
me it's the if-bodies.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #37 from Jakub Jelinek ---
The overflow-vec-1.c and vec-2.c on -m64 fail also on ppc64{,le}.
Minimum failing testcase is:
#define SCHAR_MAX __SCHAR_MAX__
#define SCHAR_MIN (-__SCHAR_MAX__ - 1)
typedef signed char VC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #36 from Dominik Vogt ---
Created attachment 40711
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40711=edit
Reduced test for float-cast-overflow-10.c
Test for the float-cast-overflow-10.c failure.
This snippet should detect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #35 from Jakub Jelinek ---
I've filed https://reviews.llvm.org/D29824 and https://reviews.llvm.org/D29825
upstream.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #34 from Dominik Vogt ---
(In reply to Jakub Jelinek from comment #33)
> (In reply to Dominik Vogt from comment #32)
> > On a machine with
> > * glibc-2.23
>
> :(; I was hoping you could test #c24 patch against glibc 2.18
I'll
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #33 from Jakub Jelinek ---
(In reply to Dominik Vogt from comment #32)
> On a machine with
> * glibc-2.23
:(; I was hoping you could test #c24 patch against glibc 2.18
> * kernel 4.4.0 + patch for the CVE
> * CVE environment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #32 from Dominik Vogt ---
On a machine with
* glibc-2.23
* kernel 4.4.0 + patch for the CVE
* CVE environment variable set to allow running the Asan tests
* patch from comment 24 applied
=>
In addition to the FAILs you've
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #30 from Jakub Jelinek ---
Following patch adds the RHEL{6,7} errata kernels to the whitelist.
SUSE and/or Debian would need to add theirs if they want.
--- libsanitizer/sanitizer_common/sanitizer_linux_s390.cc 2016-11-09
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #29 from Dominik Vogt ---
$ uname -s -r
Linux 4.2.0-20151029.0.65fcf15.5a12af1.fc20.s390xperformance
I'm quite sure we had a working kernel on that machine at some time because I
believe to remember that I'd been the first one who
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #28 from Jakub Jelinek ---
The bug has been introduced in
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/arch/s390/include/asm/mmu_context.h?id=6252d702c5311ce916caf75ed82e5c8245171c92
so I assume kernels
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #27 from Jakub Jelinek ---
The function says:
// 3.2.79+ is OK.
// 3.12.58+ is OK.
// Otherwise, bad.
// 4.1.21+ is OK.
// 4.4.6+ is OK.
// Otherwise, OK if 4.5+.
// Linux 5 and up are fine.
Perhaps it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #26 from Dominik Vogt ---
(We cannot upgrade the kernel before end of this or beginning of next week.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #25 from Dominik Vogt ---
Looks better, but now we get this quite often:
--
==23722==ERROR: Your kernel seems to be vulnerable to CVE-2016-2143. Using
ASa\
n,
MSan, TSan, DFSan or LSan with such kernel can and will crash your
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #24 from Jakub Jelinek ---
Created attachment 40693
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40693=edit
gcc7-pr79341.patch
Does the attached patch work for you? Only tested on s390x-linux (64-bit).
The intent is that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #23 from Jakub Jelinek ---
(In reply to Ulrich Weigand from comment #22)
> (In reply to Jakub Jelinek from comment #21)
> > Could libsanitizer call __tls_get_offset instead, after setting %r12 or
> > whatever else is needed for it to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #22 from Ulrich Weigand ---
(In reply to Jakub Jelinek from comment #21)
> Could libsanitizer call __tls_get_offset instead, after setting %r12 or
> whatever else is needed for it to make work and then perhaps adjust the
> result if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #21 from Jakub Jelinek ---
Could libsanitizer call __tls_get_offset instead, after setting %r12 or
whatever else is needed for it to make work and then perhaps adjust the result
if needed?
E.g. on s390x __tls_get_offset is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #20 from Florian Weimer ---
(In reply to Andreas Krebbel from comment #19)
> As a debugging tool I think asan is a special case also regarding ABI
> compatibility. We probably do not want to export the internal symbol and
> make it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #19 from Andreas Krebbel ---
koriakin stands for Marcin Kościelnicki who implemented LLVM sanitizer support
for z as part of a bounty. Ulrich Weigand led the discussions with him. CC'ing
Uli.
My personal opinion is that support of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #18 from Jakub Jelinek ---
Plus one thing is interception (which still requires that the private symbol
has stable ABI), and another thing is calling that symbol even when it isn't
called in the original program (which is what must
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
Jakub Jelinek changed:
What|Removed |Added
CC||dodji at gcc dot gnu.org,
62 matches
Mail list logo
