On Mon, Nov 19, 2012 at 07:28:18PM +0400, Konstantin Serebryany wrote:
> On Mon, Nov 19, 2012 at 6:49 PM, Peter Bergner <berg...@vnet.ibm.com> wrote:
> > On Mon, 2012-11-19 at 15:29 +0100, Jakub Jelinek wrote:
> >> On Fri, Nov 16, 2012 at 05:08:06PM -0600, Peter Bergner wrote:
> >> > One question that I have is that the toplev.c test for port support
> >> > tests for !FRAME_GROWS_DOWNWARD. The rs6000 port has
> >> > FRAME_GROWS_DOWNWARD
> >> > defined as (flag_stack_protect != 0), so ASAN only works when we use
> >> > -fstack-protector. Is there a technical reason why FRAME_GROWS_DOWNWARD
> >> > must be false?
> >>
> >> It would be way too much work to support FRAME_GROWS_DOWNWARD.
> >
> > Do you you have a pointer or a reference that describes why ASAN
> > relies on that?
>
> The only part where I know for sure that asan relies on stack growing
> down is the custom unwinder, which is not applicable to PowerPC
> anyway.
FRAME_GROWS_DOWNWARD is still a different thing from STACK_GROWS_DOWNWARD,
all GCC supported targets but hppa are AFAIK STACK_GROWS_DOWNWARD,
FRAME_GROWS_DOWNWARD is about in which order stack slots are assigned to
automatic variables, with FRAME_GROWS_DOWNWARD it is top to bottom,
otherwise it is bottom to top. This is generally just a GCC internal thing,
obviously user visible if you look at the order of variables, but there are
other aspects that influence it (stack slot sharing, stack protector, etc.).
Jakub
