public inbox for ecos-bugs@sourceware.org help / color / mirror / Atom feed
From: bugzilla-daemon@ecoscentric.com To: ecos-bugs@ecos.sourceware.org Subject: [Bug 1000801] Synthetic target crash with -fstack-protector Date: Tue, 30 Jun 2009 08:48:00 -0000 [thread overview] Message-ID: <20090630084810.3E9471519284@mail.ecoscentric.com> (raw) In-Reply-To: <bug-1000801-13@http.bugs.ecos.sourceware.org/> 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.
next prev parent reply other threads:[~2009-06-30 8:48 UTC|newest] Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top 2009-06-30 8:44 [Bug 1000801] New: " bugzilla-daemon 2009-06-30 8:48 ` bugzilla-daemon [this message] 2009-06-30 9:37 ` [Bug 1000801] " bugzilla-daemon
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20090630084810.3E9471519284@mail.ecoscentric.com \ --to=bugzilla-daemon@ecoscentric.com \ --cc=ecos-bugs@ecos.sourceware.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).