Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759427AbYFSNC2 (ORCPT ); Thu, 19 Jun 2008 09:02:28 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754628AbYFSNCU (ORCPT ); Thu, 19 Jun 2008 09:02:20 -0400 Received: from mx1.redhat.com ([66.187.233.31]:41970 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754185AbYFSNCT (ORCPT ); Thu, 19 Jun 2008 09:02:19 -0400 Date: Thu, 19 Jun 2008 09:01:58 -0400 (EDT) From: Mikulas Patocka To: David Miller cc: sparclinux@vger.kernel.org, linux-kernel@vger.kernel.org, agk@redhat.com Subject: Re: stack overflow on Sparc64 In-Reply-To: <20080618.233713.87158879.davem@davemloft.net> Message-ID: References: <20080618.205948.107681537.davem@davemloft.net> <20080618.233713.87158879.davem@davemloft.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1497 Lines: 35 On Wed, 18 Jun 2008, David Miller wrote: > From: Mikulas Patocka > Date: Thu, 19 Jun 2008 01:17:39 -0400 (EDT) > >> I see ... the callee writes arguments into caller's stack frame, if it has >> variable number of arguments. That it misdesign, the callee should write >> registers arguments into it's own frame like on AMD64 (then this space >> would be allocated only if needed). > > The callee can do this even for non-variable argument lists. > > It's like a set of pre-allocated stack slots for those incoming > argument registers when reloading under register pressure. > > In my opinion it is better to put this onus on the callee because only > the callee knows if it needs to pop these values onto the stack to > alleviate register pressure. > > I think it might be possible for the compiler to only use 176 bytes. > I'll take a look at the gcc sparc backend and the ABI specification > to see if this is the case. Yes, it could be shrunk to 176 bytes. Maybe there could be some performance problems if the spills are cacheline-unaligned. Or better --- make special -mkernel-abi function to gcc that will drop this area at all and make 128-byte frames. In kernel it wouldn't matter that ABI is incompatible. Mikulas -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/