This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Invalid unpoisoning of stack redzones on ARM
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Yury Gribov <y dot gribov at samsung dot com>, gcc-patches at gcc dot gnu dot org, dodji at gcc dot gnu dot org, dvyukov at gcc dot gnu dot org, kcc at gcc dot gnu dot org, GarbuzovViacheslav <v dot garbuzov at samsung dot com>, Evgeny Gavrin <e dot gavrin at samsung dot com>, rsandifo at linux dot vnet dot ibm dot com
- Date: Tue, 29 Oct 2013 14:50:26 +0100
- Subject: Re: [PATCH] Invalid unpoisoning of stack redzones on ARM
- Authentication-results: sourceware.org; auth=none
- References: <524591E1 dot 9060302 at samsung dot com> <20130927142529 dot GN30970 at tucnak dot zalov dot cz> <5248FBF4 dot 2050807 at samsung dot com> <525240F7 dot 1010409 at samsung dot com> <525E2599 dot 4020803 at samsung dot com> <20131029093730 dot GV30970 at tucnak dot zalov dot cz> <87bo28z2ki dot fsf at sandifor-thinkpad dot stglab dot manchester dot uk dot ibm dot com> <20131029124116 dot GZ30970 at tucnak dot zalov dot cz> <8738nkz0oi dot fsf at sandifor-thinkpad dot stglab dot manchester dot uk dot ibm dot com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Tue, Oct 29, 2013 at 01:06:21PM +0000, Richard Sandiford wrote:
> > If it is a pseudo, it is certainly a pseudo that isn't used for
> > anything else, as it is the result of (base >> 3) + constant, if it isn't a
> > pseudo, then supposedly it is better not to just keep adding the offsets to
> > a base and thus not to use the end address from asan_clear_shadow.
> > Your patch would force using the end address even if shadow_base
> > is initially say some_reg + 32, I think it is better to use shadow_mem
> > some_reg + 72 next time instead of some_other_reg + 40.
>
> But I thought the register pressure thing was to avoid having the
> original base live across the loop. Doesn't that apply for reg + offset
> as well as plain reg? If we have to force some_reg + 32 into a
> temporary and then loop on it, using the new base should avoid keeping
> both it and some_reg live at the same time. Plus smaller offsets are
> often better on some targets.
On the other side, if we force the address to be just register based when it
previously wasn't, it makes life harder for alias analysis etc., at least in
the past say on ia64 I remember the fact that it didn't allow anything but
registers as valid addresses often resulted in tons of missed
optimizations), so in the end I guess I have nothing against the original
patch (with whatever form of the copy to reg call is desirable).
Jakub