On 2/18/2015 2:05 PM, Gedare Bloom wrote: > > > On Wed, Feb 18, 2015 at 2:38 PM, Joel Sherrill > <joel.sherr...@oarcorp.com <mailto:joel.sherr...@oarcorp.com>> wrote: > > Hi > > I am trying to wrap my head around this discussion and its > impact on RTEMS. Should we compile parts of RTEMS with > this option? All of it? > > A bit more context would have helped! S
Sorry. This was the first I had seen of this option and I really didn't have much context besides "this looks like it could break code". > o basically, gcc can now optimize out NULL pointer accesses and turn > them into traps directly? And this is a problem for targets that have > a valid address at 0x0. One solution is to turn on the flag > "-fno-delete-null-pointer-checks"? > Yep. But if all we have is writeable vector tables at 0x0, then it MIGHT be ok. GCC may not be able to detect. But on the m68k's without a VBR register the table is always at 0x0. > I guess we should identify which BSPs this would affect, that is, > which ones are allowed to make valid memory accesses at 0x0, and then > turn off the optimization for those BSPs? > It might not just be BSPs, but architectures. Running code at 0x0 should be OK since that would likely be the start code. You would never indirectly jump through it. Reading/writing data at 0 is the issue. I really have no idea if/how this impacts anything but wanted us all to think on it. > Gedare > > > > > --joel > > > -------- Forwarded Message -------- > Subject: Re: Obscure crashes due to gcc 4.9 -O2 => > -fisolate-erroneous-paths-dereference > Date: Wed, 18 Feb 2015 13:30:24 -0600 > From: Andrew Pinski <pins...@gmail.com> <mailto:pins...@gmail.com> > To: Jeff Prothero <jprot...@altera.com> <mailto:jprot...@altera.com> > CC: GCC Mailing List <g...@gcc.gnu.org> <mailto:g...@gcc.gnu.org> > > > > On Wed, Feb 18, 2015 at 11:21 AM, Jeff Prothero <jprot...@altera.com> > <mailto:jprot...@altera.com> wrote: > > > > Starting with gcc 4.9, -O2 implicitly invokes > > > > -fisolate-erroneous-paths-dereference: > > > > which > > > > https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html > > > > documents as > > > > Detect paths that trigger erroneous or undefined behavior due to > > dereferencing a null pointer. Isolate those paths from the main > control > > flow and turn the statement with erroneous or undefined behavior > into a > > trap. This flag is enabled by default at -O2 and higher. > > > > This results in a sizable number of previously working embedded > programs mysteriously > > crashing when recompiled under gcc 4.9. The problem is that embedded > > programs will often have ram starting at address zero (think > hardware-defined > > interrupt vectors, say) which gets initialized by code which the > > -fisolate-erroneous-paths-deference logic can recognize as reading > and/or > > writing address zero. > > You should have used -fno-delete-null-pointer-checks which has been > doing this optimization for a long time now, just it got better with > -fisolate-erroneous-paths-dereference pass. > > Thanks, > Andrew Pinski > > > > > > > What happens then is that the previously running program compiles > without > > any warnings, but then typically locks up mysteriously (often disabling > the > > remote debug link) due to the trap not being gracefully handled by the > > embedded runtime. > > > > Granted, such code is out-of-spec wrt to C standards. > > > > None the less, the problem is quite painful to track down and > > unexpected. > > > > Is there any good reason the > > > > -fisolate-erroneous-paths-dereference > > > > logic could not issue a compiletime warning or error, instead of just > > silently generating code virtually certain to crash at runtime? > > > > Such a warning/error would save a lot of engineers significant amounts > > of time, energy and frustration tracking down this problem. > > > > I would like to think that the spirit of gcc is about helping engineers > > efficiently correct nonstandard pain, rather than inflicting maximal > > pain upon engineers violating C standards. :-) > > > > -Jeff > > > > BTW, I'd also be curious to know what is regarded as engineering best > > practice for writing a value to address zero when this is > architecturally > > required by the hardware platform at hand. Obviously one can do various > > things to obscure the process sufficiently that the current gcc > implementation > > won't detect it and complain, but as gcc gets smarter about optimization > > those are at risk of failing in a future release. It would be nice to > have > > a guaranteed-to-work future-proof idiom for doing this. Do we have one, > short > > of retreating to assembly code? > > > > > _______________________________________________ > devel mailing list > devel@rtems.org <mailto:devel@rtems.org> > http://lists.rtems.org/mailman/listinfo/devel > > -- Joel Sherrill, Ph.D. Director of Research & Development joel.sherr...@oarcorp.com On-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
