From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21292 invoked by alias); 29 Jun 2009 09:50:00 -0000 Received: (qmail 21281 invoked by uid 22791); 29 Jun 2009 09:49:59 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from hagrid.ecoscentric.com (HELO mail.ecoscentric.com) (212.13.207.197) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 29 Jun 2009 09:49:52 +0000 Received: from localhost (hagrid.ecoscentric.com [127.0.0.1]) by mail.ecoscentric.com (Postfix) with ESMTP id 038BA151AD6E; Mon, 29 Jun 2009 10:49:50 +0100 (BST) Received: from mail.ecoscentric.com ([127.0.0.1]) by localhost (hagrid.ecoscentric.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iUYk5oG9rKUN; Mon, 29 Jun 2009 10:49:48 +0100 (BST) Date: Mon, 29 Jun 2009 09:50:00 -0000 Message-Id: From: Bart Veer To: John Dallaway CC: ecos-devel@ecos.sourceware.org In-reply-to: <4A486BEE.9070803@dallaway.org.uk> (message from John Dallaway on Mon, 29 Jun 2009 08:23:26 +0100) Subject: Re: GCC stack protector with linux synthetic target References: <4A475994.7010203@cs.vu.nl> <4A486BEE.9070803@dallaway.org.uk> 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/msg00045.txt.bz2 >>>>> "John" == John Dallaway writes: John> Hi Rutger John> Rutger Hofman wrote: >> An aside: I run Ubuntu. At first, I couldn't run synth at all. >> Applications would crash, and gdb would crash on the >> application too! After some list searching, I found out that >> this probably is Ubuntu-specific. We need to include >> -fno-stack-protector in the GLOBAL_CFLAGS configure flag. >> Request: cannot this be automated for synth building? My guess >> is that it will not harm on systems other than Ubuntu, and it >> will save Ubuntu users effort. John> Do you understand _why_ eCos is crashing with the GCC stack John> protector enabled? Is it due to an assumption made in eCos John> regarding the stack frame which could be corrected? We John> should ensure we understand the nature of the failure before John> disabling this feature. This was investigated some time ago - look at the archives. 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. Bart -- Bart Veer eCos Configuration Architect eCosCentric Limited The eCos experts http://www.ecoscentric.com/ Barnwell House, Barnwell Drive, Cambridge, UK. Tel: +44 1223 245571 Registered in England and Wales: Reg No 4422071.