https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715
Martin Liška changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715
--- Comment #35 from Martin Liška ---
Author: marxin
Date: Fri Nov 30 14:25:15 2018
New Revision: 24
URL: https://gcc.gnu.org/viewcvs?rev=24=gcc=rev
Log:
Make red zone size more flexible for stack variables (PR sanitizer/81715).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715
--- Comment #34 from Martin Liška ---
For the next version of the patch:
https://gcc.gnu.org/ml/gcc-patches/2018-09/msg01529.html
I seen even better results:
TOTAL warnings: 23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715
--- Comment #33 from Martin Liška ---
(In reply to Arnd Bergmann from comment #32)
> (In reply to Martin Liška from comment #31)
> > (In reply to Arnd Bergmann from comment #30)
> > > (In reply to Martin Liška from comment #29)
> > > > Which is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715
--- Comment #32 from Arnd Bergmann ---
(In reply to Martin Liška from comment #31)
> (In reply to Arnd Bergmann from comment #30)
> > (In reply to Martin Liška from comment #29)
> > > Which is very promising improvement I would say.
> >
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715
--- Comment #31 from Martin Liška ---
(In reply to Arnd Bergmann from comment #30)
> (In reply to Martin Liška from comment #29)
> > I'm got a patch candidate for which I did testing of allmodconfig
> > configuration.
> > Sorting all violations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715
--- Comment #30 from Arnd Bergmann ---
(In reply to Martin Liška from comment #29)
> I'm got a patch candidate for which I did testing of allmodconfig
> configuration.
> Sorting all violations against 2KB of stack memory:
>
> Before:
> TOTAL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715
--- Comment #29 from Martin Liška ---
I'm got a patch candidate for which I did testing of allmodconfig
configuration.
Sorting all violations against 2KB of stack memory:
Before:
TOTAL warnings: 185
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715
--- Comment #28 from Martin Liška ---
(In reply to Martin Liška from comment #27)
> Let me decrypt how clang generates the red zones. I can probably quickly
> come up with a patch that will do the dynamic red zone size allocation.
> Having that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715
Martin Liška changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715
--- Comment #26 from Arnd Bergmann ---
(In reply to Martin Liška from comment #25)
> (In reply to Arnd Bergmann from comment #24)
>
> Ok, I don't have problem to implement the similar behavior in GCC 9. Looks
> most
> of warnings are in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715
--- Comment #25 from Martin Liška ---
(In reply to Arnd Bergmann from comment #24)
> (In reply to Martin Liška from comment #23)
>
> > That's definitely possible for GCC 9. Question is whether such change will
> > be sufficient for you. Do you
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715
--- Comment #24 from Arnd Bergmann ---
(In reply to Martin Liška from comment #23)
> That's definitely possible for GCC 9. Question is whether such change will
> be sufficient for you. Do you expect it will reduce stack usage in the
> desired
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715
--- Comment #23 from Martin Liška ---
> One side issue that is not solved at all by the patch is
> -fsanitize-address-use-after-scope, since that still leads to extreme stack
> usage in the kernel. The problem here is that it forces many local
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715
--- Comment #22 from Arnd Bergmann ---
(In reply to Jakub Jelinek from comment #20)
> I haven't heard any answer to #c16 whether it actually helped the kernel or
> not.
Sorry about that. Yes, it definitely helped the kernel a lot. At this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715
Martin Liška changed:
What|Removed |Added
Assignee|marxin at gcc dot gnu.org |unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715
--- Comment #20 from Jakub Jelinek ---
I haven't heard any answer to #c16 whether it actually helped the kernel or
not.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715
--- Comment #19 from Martin Liška ---
As it's fixed on GCC-7 and currect trunk, can we Jakub close that?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715
--- Comment #18 from Jakub Jelinek ---
Author: jakub
Date: Thu Jan 18 20:30:33 2018
New Revision: 256861
URL: https://gcc.gnu.org/viewcvs?rev=256861=gcc=rev
Log:
PR sanitizer/81715
PR testsuite/83882
* function.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715
--- Comment #17 from Jakub Jelinek ---
Author: jakub
Date: Fri Oct 27 20:33:35 2017
New Revision: 254179
URL: https://gcc.gnu.org/viewcvs?rev=254179=gcc=rev
Log:
Backported from mainline
2017-09-21 Jakub Jelinek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715
--- Comment #16 from Jakub Jelinek ---
Did this change help? Would it be beneficial to backport to 7.x or even 6.x?
As is it is certainly too dangerous, but wonder about additionally guarding the
3 hunks either with (flag_sanitize &
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715
--- Comment #15 from Jakub Jelinek ---
Author: jakub
Date: Thu Sep 21 12:26:34 2017
New Revision: 253065
URL: https://gcc.gnu.org/viewcvs?rev=253065=gcc=rev
Log:
PR sanitizer/81715
* tree-inline.c (expand_call_inline): Emit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715
--- Comment #14 from Jakub Jelinek ---
Note the patch failed bootstrap, but just the first hunk from it passed
bootstrap and is being regtested right now. I'll need to debug what's wrong
with the retval clobbers tomorrow.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715
--- Comment #13 from Arnd Bergmann ---
Tested the fix with an x86 allmodconfig kernel (linux-next, with
-fsanitize-address-use-after-scope disabled manually). With an arbitrary limit
of 1500 bytes (the default is no limit when
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715
--- Comment #12 from Jakub Jelinek ---
Created attachment 42212
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42212=edit
gcc8-pr81715.patch
Untested fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715
--- Comment #11 from Jakub Jelinek ---
(In reply to Arnd Bergmann from comment #10)
> As far as I can tell, gcc doesn't merge stack slots that came from inline
> functions, as in comment 1, or this example:
>
> void baz (int *, int *, int *,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715
--- Comment #10 from Arnd Bergmann ---
As far as I can tell, gcc doesn't merge stack slots that came from inline
functions, as in comment 1, or this example:
void baz (int *, int *, int *, int *, int *, int *);
static inline void foo (int a,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715
--- Comment #9 from Jakub Jelinek ---
Unless -fsanitize-user-after-scope (default for -fsanitize=address, but not for
-fsanitize=kernel-address), GCC does reuse stack slots. Just try say:
void foo (int *, int *, int *, int *, int *, int *);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715
--- Comment #8 from Arnd Bergmann ---
(In reply to Martin Liška from comment #7)
> Ok, I'm quite opened for changes that will make smaller red zones for
> smaller variables. However, in case of sanitization-aware inlining, it's
> probably too
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715
--- Comment #7 from Martin Liška ---
Ok, I'm quite opened for changes that will make smaller red zones for smaller
variables. However, in case of sanitization-aware inlining, it's probably too
complicated and I would rather use no_inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715
--- Comment #6 from Arnd Bergmann ---
(In reply to Martin Liška from comment #5)
> I can confirm that for the biggest function 'nl80211_send_wiphy', it really
> contains majority of stack variables which are 4B large. Having an adaptive
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715
Martin Liška changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #5 from Martin Liška
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715
--- Comment #4 from Arnd Bergmann ---
Created attachment 42195
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42195=edit
preprocessed net/wireless/nl80211.c, compressed
This is another file that shows the problem, in fact we hit this with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715
--- Comment #3 from Arnd Bergmann ---
(In reply to Arnd Bergmann from comment #2)
> Created attachment 42178 [details]
> preprocessed linux/drivers/media/dvb-frontends/stv090x.c, compressed
>
> This is one of the typical files showing the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715
--- Comment #2 from Arnd Bergmann ---
Created attachment 42178
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42178=edit
preprocessed linux/drivers/media/dvb-frontends/stv090x.c, compressed
This is one of the typical files showing the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
36 matches
Mail list logo
