[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20080812.175948.214598056.davem@davemloft.net>
Date: Tue, 12 Aug 2008 17:59:48 -0700 (PDT)
From: David Miller <davem@...emloft.net>
To: mpatocka@...hat.com
Cc: sparclinux@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: stack overflow on Sparc64
From: Mikulas Patocka <mpatocka@...hat.com>
Date: Tue, 12 Aug 2008 20:53:04 -0400 (EDT)
> On Tue, 12 Aug 2008, David Miller wrote:
>
> > From: David Miller <davem@...emloft.net>
> > Date: Mon, 11 Aug 2008 23:30:13 -0700 (PDT)
> >
> > > The problem is that CONFIG_STACK_DEBUG doesn't understand
> > > the IRQ stacks at all.
> > >
> > > I'll see if I can tweak it to handle this.
> >
> > This patch, on top of my original IRQSTACKS patch for
> > sparc64, seems to get things working for me.
>
> Thanks, the patch works.
Thanks for testing. I'm engaged in a few activities right
now related to this:
1) I'm making a final version of this irqstacks patch which
I'll get into Linus's tree and then submit to -stable.
2) I have a patch which I'm regression testing for gcc which
gets rid of the 16-byte secondary-reload stack slot. This
gcc is emitting 176 byte default stack frames on sparc64.
3) I'm talking with some folks familiar with the V9 ABI about
the mandatory incoming argument stack slots. I think they
can be eliminated in all cases except functions taking
varargs. If it cannot be done universally for some
reason, I'll add a -mkernel option that will eliminate
them. This will emit 128 byte default stack frames when
possible.
So in the end we should hopefully have 128 byte stack frames
coming out of gcc and IRQ stacks in the kernel.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists