From mint-bounce@lists.fishpool.fi Wed Feb 18 18:17:58 2009 Message-ID: <499C966D.4020204@atari-source.org> Date: Wed, 18 Feb 2009 18:14:53 -0500 From: Mark Duckworth User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Vincent_Rivi=E8re?= CC: mint Subject: Re: [MiNT] Default Stack Size References: <499C82B4.6060005@atari-source.org> <499C944D.7090404@freesbee.fr> In-Reply-To: <499C944D.7090404@freesbee.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-SA-Score: -1.4 X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-to: mint-bounce@lists.fishpool.fi X-original-sender: mduckworth@atari-source.org Precedence: bulk List-help: List-unsubscribe: List-Id: X-List-ID: List-subscribe: List-owner: List-post: Vincent Rivière wrote: > Mark Duckworth wrote: >> For the time being we are stuck with a one size stack. I was >> wondering if anyone has contemplated the idea of setting a default >> stack size other than 0 bytes? > > I think a clean way to fix this problem would be to include a > parameter in MINT.CNF called DefaultStackSize. So when the kernel > loads an executable with extended MiNT header and the stacksize is set > to 0, it will dynamically patch it with the default size. > > I think it would be easy to get such behavior by making a little patch > to Pexec(). Such patch would not break any compatibility. > > Kernel experts, what do you thing about that ? > Well this would cause differences in behavior from users which wouldn't be immediately obvious if they are set at 0 in the mint.cnf. Would make supporting problems more difficult. That's why I suggested the binutils make a sane default but really I don't know what a sane default is. I never really thought a program would need more than 64KB of stack space but G++ easily proves me wrong ;) I guess I think small ;) Thanks, Mark