[Bug 1000801] New: Synthetic target crash with -fstack-protector

[Bug 1000801] New: Synthetic target crash with -fstack-protector

[bugzilla-daemon]

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1000801

           Summary: Synthetic target crash with -fstack-protector
           Product: eCos
           Version: CVS
          Platform: linux (Linux synthetic target)
        OS/Version: Other
            Status: NEW
          Severity: normal
          Priority: normal
         Component: HAL
        AssignedTo: bartv@ecoscentric.com
        ReportedBy: john@dallaway.org.uk
         QAContact: ecos-bugs@ecos.sourceware.org
             Class: ---


eCos applications built for the linux synthetic target are liable to crash when
compiled using "-fstack-protector". Unfortunately this is the default behaviour
for versions of GCC in recent Ubuntu Linux distributions.


-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

[Bug 1000801] Synthetic target crash with -fstack-protector

[bugzilla-daemon]

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1000801





--- Comment #1 from John Dallaway <john@dallaway.org.uk>  2009-06-30 09:48:08 ---
-------- Original Message --------
Subject: Re: GCC stack protector with linux synthetic target
Date: Mon, 29 Jun 2009 10:49:47 +0100
From: Bart Veer <bartv@ecoscentric.com>

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.


-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

[Bug 1000801] Synthetic target crash with -fstack-protector

[bugzilla-daemon]

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1000801





--- Comment #2 from John Dallaway <john@dallaway.org.uk>  2009-06-30 10:37:38 ---
The GCC "-fstack-protector" feature became mainstream with GCC 4.1 so will be
present in the following Linux distributions and later versions:

  Fedora 5 (March 2006)
  openSUSE 10.1 (May 2006)
  Ubuntu 6.10 (October 2006)

I doubt there will be many developers using distros dating back to 2006 on
their desktop, but release machines may be using even older distros.

Thinking some more about this, adding the "-fno-stack-protector" switch to the
default CFLAGS for the linux synthetic target makes good sense from a usability
perspective. It really isn't obvious what the problem is when eCos linux
synthetic target applications crash due to "-fstack-protector". But an old
compiler complaining that it doesn't understand the "-fno-stack-protector"
switch provides a big clue and most users will soon determine that they can
safely remove the switch with older GCC. We could also mention this issue in
the description string for CYGBLD_GLOBAL_CFLAGS in the platform HAL.

While I agree that adding the "-fno-stack-protector" switch does not address
the underlying issue, on balance I think it makes sense to do this as a
temporary measure. It may be quite some time before the the underlying issue is
addressed.


-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.