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
