https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975
--- Comment #39 from Bill Schmidt ---
I believe this work has been completed. Peter, do you concur?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975
Peter Bergner changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975
--- Comment #37 from William J. Schmidt wschmidt at gcc dot gnu.org
2013-01-24 13:30:53 UTC ---
(In reply to comment #36)
Bill, tests in Instrumentation/AddressSanitizer are compiler-only tests
and thus are mostly platform independent.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975
--- Comment #38 from Kostya Serebryany kcc at gcc dot gnu.org 2013-01-24
13:46:17 UTC ---
OK. Please let me know if we can assist setting up a PPC bot in the future,
to
help maintain compatibility.
Oh, that'll be great even now.
If
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975
--- Comment #25 from Kostya Serebryany kcc at gcc dot gnu.org 2013-01-23
12:21:51 UTC ---
So, what is our decision?
Are we just doing
- static const uptr kHighMemEnd = 0x0fffUL;
+ static const uptr kHighMemEnd =
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975
--- Comment #26 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-23
12:26:30 UTC ---
(In reply to comment #25)
So, what is our decision?
Are we just doing
- static const uptr kHighMemEnd = 0x0fffUL;
+ static
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975
--- Comment #27 from Kostya Serebryany kcc at gcc dot gnu.org 2013-01-23
12:51:40 UTC ---
BTW, I wonder why clang generates larger and slower code with ADD instead of
OR
I did not investigate. I noticed that the code size with OR is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975
--- Comment #28 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-23
13:05:57 UTC ---
Why doesn't it error for unlimited stack say on x86_64? If the stack mapping
size is unlimited, it also potentially overlaps with the shadow memory.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975
--- Comment #29 from Kostya Serebryany kcc at gcc dot gnu.org 2013-01-23
13:19:30 UTC ---
Why doesn't it error for unlimited stack say on x86_64?
Because on x86_64 the stack is still high enough (we are lucky).
Note: I would not
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975
--- Comment #30 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-23
13:30:19 UTC ---
What I mean, is a stack PROT_GROWSDOWN RLIM_INFINITY RLIMIT_STACK mapping is
defined to be a mapping from the top of that mapping down to the first
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975
--- Comment #31 from Kostya Serebryany kcc at gcc dot gnu.org 2013-01-23
13:32:11 UTC ---
I've committed an upstream change
http://llvm.org/viewvc/llvm-project?view=revrevision=173260 that makes
kHighMemEnd dynamic.
Hopefully, it will
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975
--- Comment #32 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-23
13:33:45 UTC ---
I take it back, seems it is because the kernel mmaps the shared libraries in
that range in this case. So indeed, you probably need a dynamic mapping,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975
--- Comment #33 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-23
13:40:57 UTC ---
(In reply to comment #31)
I've committed an upstream change
http://llvm.org/viewvc/llvm-project?view=revrevision=173260 that makes
kHighMemEnd
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975
--- Comment #34 from Kostya Serebryany kcc at gcc dot gnu.org 2013-01-23
13:50:31 UTC ---
Do you really want to make kHighMemEnd dynamic always? Shouldn't it be
dynamic
only when needed (i.e. for configurations like ppc64 which now
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975
William J. Schmidt wschmidt at gcc dot gnu.org changed:
What|Removed |Added
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975
--- Comment #36 from Kostya Serebryany kcc at gcc dot gnu.org 2013-01-24
07:19:00 UTC ---
Well, although the ppc64 LNT bot is not quite functional yet, there are many
of
us who run the LLVM unit test suite several times a day. So as
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975
--- Comment #24 from Kostya Serebryany kcc at gcc dot gnu.org 2013-01-21
09:11:22 UTC ---
I've tried adding the offset instead of OR-ing it and got 2%-5% slowdown and
same code size increase on SPEC on x86_64 (using fresh clang -02).
So,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975
--- Comment #14 from Kostya Serebryany kcc at gcc dot gnu.org 2013-01-18
08:26:00 UTC ---
Because of this:
#define kLowShadowBeg SHADOW_OFFSET
#define kLowShadowEnd MEM_TO_SHADOW(kLowMemEnd)
If we leave kLowShadowEnd as before, we
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975
--- Comment #15 from Kostya Serebryany kcc at gcc dot gnu.org 2013-01-18
11:40:57 UTC ---
There are two off-by-one:
In LLVM trunk: http://llvm.org/viewvc/llvm-project?rev=172807view=rev
Initially I wanted to do a merge to gcc this
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975
--- Comment #16 from Kostya Serebryany kcc at gcc dot gnu.org 2013-01-18
12:30:11 UTC ---
-#define SHADOW_OFFSET (1ULL 41)
+#define SHADOW_OFFSET (1ULL 43)
On my ppc box which uses 44 bit address space this does not work:
%
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975
--- Comment #17 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-18
13:02:41 UTC ---
But why doesn't the 1 41 version work with both 44 and 46-bit VA?
It should be:
|| `[0x0a00, 0x3fff]` || HighMem||
||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975
--- Comment #18 from Andreas Schwab sch...@linux-m68k.org 2013-01-18 13:21:02
UTC ---
(In reply to comment #15)
In LLVM trunk: http://llvm.org/viewvc/llvm-project?rev=172807view=rev
That only happens when running under gdb which appears
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975
--- Comment #19 from Andreas Schwab sch...@linux-m68k.org 2013-01-18 13:25:42
UTC ---
MEM_TO_SHODOW does not work when (SHADOW_OFFSET SHADOW_SHIFT) is less than
kHighMemEnd.
$ ASAN_OPTIONS=verbosity=1 ./clone-test-1.exe
==16778==
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975
--- Comment #20 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-18
13:52:02 UTC ---
Ah yes, it can't be | SHADOW_OFFSET then, but has to be + SHADOW_OFFSET. + is
what gcc emits (the reason for that was primarily that it resulted in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975
--- Comment #21 from Kostya Serebryany kcc at gcc dot gnu.org 2013-01-18
15:33:33 UTC ---
While we are at it...
It is possible to use zero shadow offset of powerpc somehow?
on x86_64 linux, when I build the code with -fPIC -pie
the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975
--- Comment #22 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-18
15:41:09 UTC ---
Forcing everything to be built as -pie is a non-starter. The 5% just aren't
worth the trouble. Especially, how are you going to deal with say a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975
--- Comment #23 from Kostya Serebryany kcc at gcc dot gnu.org 2013-01-18
15:46:00 UTC ---
in our use-case 5% of run-time (and code size too) is a lot.
We are currently in the process of migrating the chrome builds to zero based
offset
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975
--- Comment #10 from Kostya Serebryany kcc at gcc dot gnu.org 2013-01-17
08:30:05 UTC ---
Since I can't reproduce the failure,
please help me debug this (basically, print all local variables around the
assertion and the proc maps) or
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975
--- Comment #11 from Andreas Schwab sch...@linux-m68k.org 2013-01-17 23:23:47
UTC ---
There are two off-by-one:
diff --git a/libsanitizer/asan/asan_poisoning.cc
b/libsanitizer/asan/asan_poisoning.cc
index a00baff..bbbaf0a 100644
---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975
--- Comment #12 from Andreas Schwab sch...@linux-m68k.org 2013-01-17 23:52:39
UTC ---
Created attachment 29199
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29199
make check-gcc RUNTESTFLAGS='--target_board=unix/-m64 asan.exp'
diff
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975
Kostya Serebryany kcc at gcc dot gnu.org changed:
What|Removed |Added
Summary|FAIL: |asan
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975
--- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-16
11:50:47 UTC ---
I think for 44-46 bits we can still make it constant. But generally, the
constructors of libasan are usually run from the stack of the initial thread,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975
--- Comment #8 from Kostya Serebryany kcc at gcc dot gnu.org 2013-01-16
11:54:36 UTC ---
Sounds good for both.
Andreas, could you please try replacing
kHighMemEnd = 0x0fffUL
with
kHighMemEnd = 0x3fffUL
and
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975
--- Comment #9 from Andreas Schwab sch...@linux-m68k.org 2013-01-16 19:12:01
UTC ---
-FAIL: c-c++-common/asan/global-overflow-1.c -O0 output pattern test, is
==9876== AddressSanitizer CHECK failed:
34 matches
Mail list logo
