From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2827 invoked by alias); 30 Jun 2009 08:55:03 -0000 Received: (qmail 2806 invoked by uid 22791); 30 Jun 2009 08:55:01 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from mtaout03-winn.ispmail.ntl.com (HELO mtaout03-winn.ispmail.ntl.com) (81.103.221.49) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 30 Jun 2009 08:54:53 +0000 Received: from aamtaout02-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout03-winn.ispmail.ntl.com (InterMail vM.7.08.04.00 201-2186-134-20080326) with ESMTP id <20090630085449.TWCJ5579.mtaout03-winn.ispmail.ntl.com@aamtaout02-winn.ispmail.ntl.com>; Tue, 30 Jun 2009 09:54:49 +0100 Received: from cog.dallaway.org.uk ([86.9.207.237]) by aamtaout02-winn.ispmail.ntl.com (InterMail vG.2.02.00.01 201-2161-120-102-20060912) with ESMTP id <20090630085449.OOXF21638.aamtaout02-winn.ispmail.ntl.com@cog.dallaway.org.uk>; Tue, 30 Jun 2009 09:54:49 +0100 Received: from cog.dallaway.org.uk (cog.dallaway.org.uk [127.0.0.1]) by cog.dallaway.org.uk (8.13.8/8.13.8) with ESMTP id n5U8shMS013202; Tue, 30 Jun 2009 09:54:43 +0100 Message-ID: <4A49D2D3.9010106@dallaway.org.uk> Date: Tue, 30 Jun 2009 08:55:00 -0000 From: John Dallaway User-Agent: Thunderbird 2.0.0.22 (X11/20090625) MIME-Version: 1.0 To: Bart Veer CC: ecos-devel@ecos.sourceware.org Subject: Re: GCC stack protector with linux synthetic target References: <4A475994.7010203@cs.vu.nl> <4A486BEE.9070803@dallaway.org.uk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Mailing-List: contact ecos-devel-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: ecos-devel-owner@ecos.sourceware.org X-SW-Source: 2009-06/txt/msg00049.txt.bz2 Hi Bart Bart Veer wrote: > Basically -fstack-protector depends on some extra work done by the > glibc startup code. Of course the synthetic target does not use glibc > so that extra bit of initialization does not happen. The extra init is > not straightforward. It involves manipulating the x86 segment > registers via a Linux system call. I could find no documentation for > exactly what has to be done, and I could not immediately figure it out > from the glibc sources. Straightforward copying from glibc is not > acceptable either because of licensing issues. > > Stack protection support was added to the compiler a few years back, > offhand I don't know exactly when. However the default setting varies > between distributions. Fedora and its ilk default to > -fno-stack-protector, so everything just works. Debian and its ilk > default to -fstack-protector, so things go wrong. > > Possible solutions are: > > 1) add -fno-stack-protector to the default flags for synth. This > should work fine with all current distros. However it will break the > world for anybody using an older distro where the gcc being used did > not yet know about this compiler flag, or for anybody deliberately > using an older gcc e.g. to use the same compiler version for synth and > for real embedded targets. This was not really acceptable when we last > looked at this. It may be more acceptable now, but is still not ideal. > > 2) try to do some run-time detection to figure out whether or not > -fno-stack-protector should be added. There are various complications, > e.g. if people change the COMMAND_PREFIX setting. > > 3) fix the problem properly by doing the segment register > initialization. This should solve the problem irrespective of the > distro or the version of gcc being used. It would also mean that the > synthetic targets gains whatever benefits -fstack-protector offers. > > Since I run Fedora on most of my systems I am not affected by any of > this, so sorting it out is a low priority for me. If you want to look > at option (3), that would be great. I would much prefer that to option > (1), since if you go for that then there will never be any incentive > to do the job properly. Agreed. Thanks for the analysis. I have raised a bug report so this doesn't get forgotten about: http://bugs.ecos.sourceware.org/show_bug.cgi?id=1000801 There is also an issue with very old GCC: http://bugs.ecos.sourceware.org/show_bug.cgi?id=1000723 John Dallaway