https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85230
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85230
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85230
--- Comment #22 from Jakub Jelinek ---
Author: jakub
Date: Tue Apr 17 20:22:50 2018
New Revision: 259446
URL: https://gcc.gnu.org/viewcvs?rev=259446&root=gcc&view=rev
Log:
PR sanitizer/85230
* asan.c (handle_builtin_stack_restore
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85230
--- Comment #21 from Dmitry Vyukov ---
I guess it just used my system binutils. Used to work before.
I now used an older distribution to build it. Seems to work.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85230
--- Comment #20 from Jakub Jelinek ---
Are you configuring gcc against binutils 2.30+ and then assembling stuff with
older binutils?
You can always use -gno-as-locview-support even in that case, but the general
assumption is if you configure agai
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85230
--- Comment #19 from Dmitry Vyukov ---
When I am trying to build anything with -g on a machine with binutils 2.26.1 I
am getting:
/tmp/ccTFsPnM.s: Assembler messages:
/tmp/ccTFsPnM.s:11: Error: unknown .loc sub-directive `view'
/tmp/ccTFsPnM.s:1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85230
--- Comment #18 from Jakub Jelinek ---
I will, once I bootstrap/regtest it fully on a couple of targets.
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85230
--- Comment #16 from Dmitry Vyukov ---
Here is disasm of the function with the patch:
https://gist.githubusercontent.com/dvyukov/e9dca961ceb436049cf5881b3307b104/raw/05ed3daff60d00eb71ca7a85be707d6d5eca3c47/gistfile1.txt
And the epilogue:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85230
--- Comment #15 from Jakub Jelinek ---
(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
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 pre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85230
--- Comment #13 from Jakub Jelinek ---
Created attachment 43919
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43919&action=edit
gcc8-pr85230.patch
So, if you want to add STACK_DYNAMIC_OFFSET to new_sp for the second argument,
then we coul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85230
--- Comment #12 from Dmitry Vyukov ---
When/if you have a patch I can test it on kernel.
But seems this is a problem for user-space too. We just need a large alloca +
signal handlers, or dirty manual SP manipulations (like we have in tsan to
imp
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85230
--- Comment #10 from Jakub Jelinek ---
Unfortunately that doesn't work, because the second argument to
__asan_allocas_unpoison is incorrect then.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85230
--- Comment #9 from Jakub Jelinek ---
So (completely untested):
--- gcc/asan.c.jj 2018-01-09 21:53:38.821577722 +0100
+++ gcc/asan.c 2018-04-12 12:30:43.360840432 +0200
@@ -554,14 +554,14 @@ get_last_alloca_addr ()
return last_alloca_ad
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85230
--- Comment #8 from Dmitry Vyukov ---
Depending on how long the proper fix will take. If we are talking about, say, a
week then I will just wait. We have to deal with hundreds of assorted kernel
crashes all over the place anyway.
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85230
--- Comment #6 from Dmitry Vyukov ---
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
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
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85230
--- Comment #4 from Dmitry Vyukov ---
Removing these lines from runtime does not help unfortunately:
- kasan_poison_shadow(left_redzone, KASAN_ALLOCA_REDZONE_SIZE,
- KASAN_ALLOCA_LEFT);
The right redzone is also someho
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85230
--- Comment #3 from Dmitry Vyukov ---
Hummm, perhaps gcc expects that the left ASAN redzone will be within the
128-byte ABI redzone, but this becomes false with -mno-red-zone?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85230
--- Comment #2 from Dmitry Vyukov ---
The runtime callbacks look correct to me, and the shadow they produce also
looks reasonable: 32-byte rezone before, 32 + (32 - object size) redzone after:
8800247b7180: 00 00 00 00 00 00 00 00 00 00 00
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85230
--- Comment #1 from Dmitry Vyukov ---
I am also looking at kernel callback implementation, maybe they disagree with
compiler as to what's actually passed as arguments:
/* Emitted by compiler to poison alloca()ed objects. */
void __asan_alloca_p
24 matches
Mail list logo
