From mint-bounce@lists.fishpool.fi Sun May 3 19:47:44 2009 Date: Sun, 3 May 2009 19:44:59 -0400 (EDT) From: Keith Scroggins To: =?ISO-8859-1?Q?Vincent_Rivi=E8re?= cc: mint@fishpool.com Subject: Re: [MiNT] Should Setting Stack be added to Binutils? In-Reply-To: Message-ID: References: <49B585D2.7080209@freesbee.fr> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-851401618-1241394299=:4914" X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-to: mint-bounce@lists.fishpool.fi X-original-sender: kws@radix.net Precedence: bulk List-help: List-unsubscribe: List-Id: X-List-ID: List-subscribe: List-owner: List-post: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-851401618-1241394299=:4914 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Hi Vincent, List, Any reason this should feature should not be added into Binutils? It is=20 basically necessary to build newer GCC natively, and I am guessing even=20 with a Coldfire CPU (which will definitely need the newer dev tools) this= =20 will be needed. So, any possible problems seen with this? The only other possible addition I see is maybe making it so strip does=20 not remove the stack setting, or saves/restores it. Keith On Sun, 15 Mar 2009, Keith Scroggins wrote: > Hello Vincent, List, > > I tried the patch this weekend with a bootstrap build of GCC4 (Just the C= =20 > Compiler) and this fixed the problems caused by reusing th non stack=20 > adjusteds files from the previous stage. > > More to come in a few minutes (hopefully). > > Keith > > On Mon, 9 Mar 2009, Vincent Rivi=E8re wrote: > >> Keith Scroggins wrote: >>> What I was wondering was if we could/should add stack functionality to >>> Binutils so you could pass a linking flag of something like --stack=3D5= 12k >>> to have it set? Any input? >>=20 >> Here is a quick and dirty patch for enabling the --stack option in the= =20 >> linker. It must be applied to binutils 2.19 already patched for MiNT. >>=20 >> This is just a test for verifying if the concept is good. When we agree = to=20 >> what is good or not, I will take the time to clean it ant to merge it to= my=20 >> "official" binutils patch. >>=20 >> Current limitations are : >> - The "ld" produced with this patch seems to be good, but I'm pretty sur= e=20 >> that the "strip" would reset the stack settings. So use only the "ld"=20 >> produced by this patch and keep your old "strip". >> - The stack value is a number of bytes, the suffixes "K", etc. are not y= et=20 >> supported. >> - When the --stack option is not used, the value "0" is put into the=20 >> executable, which means "mysterious default stack size" (actually 64K if= I=20 >> remember well). The MiNTLib has been recently patched for setting an=20 >> explicit stack value, this linker breaks that behavior. >>=20 >> Usage : >> See ld --target-help for the new option :-) >>=20 >> Typical usage is by using the "gcc" command. >> Beware, if you want to replace only the "ld" executable for test purpose= s.=20 >> On my cross-environment, gcc uses the linker located at this location : >> /usr/local/cross-mint/m68k-atari-mint/bin/ld >> The "normal" linker command /usr/local/m68k-atari-mint-ld is not used. >> Is is probably the same for a native compiler. >>=20 >> So the typical usage is : >> gcc hello.c -o hello -Wl,--stack,512000 >> It just works. >>=20 >> When compiling a GNU package, you can use : >> configure ... LDFLAGS=3D-Wl,--stack,512000 >> So the stack size will be written in all the makefiles :-) >>=20 >> Another option is so specify the LDFLAGS on the make command line. >> make LDFLAGS=3D-Wl,--stack,512000 >>=20 >> If this behavior seems good for you, and it it works as expected, I will= =20 >> clean the patch and get rid of the current limitations. >>=20 >> --=20 >> Vincent Rivi=E8re > ---559023410-851401618-1241394299=:4914--