<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<div class="moz-cite-prefix">On 2/18/2015 2:05 PM, Gedare Bloom
wrote:<br>
</div>
<blockquote
cite="mid:CAC82fA0JDB4zuaym1B6RNwuJM-3cB3_5YRVO-J2Op0Lsyn2Y6g@mail.gmail.com"
type="cite">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Wed, Feb 18, 2015 at 2:38 PM, Joel
Sherrill <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:joel.sherrill@oarcorp.com" target="_blank">joel.sherrill@oarcorp.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"> Hi<br>
<br>
I am trying to wrap my head around this discussion and
its <br>
impact on RTEMS. Should we compile parts of RTEMS with<br>
this option? All of it?<br>
<br>
</div>
</blockquote>
<div>A bit more context would have helped! S</div>
</div>
</div>
</div>
</blockquote>
<br>
Sorry. This was the first I had seen of this option and I really
didn't have <br>
much context besides "this looks like it could break code". <br>
<blockquote
cite="mid:CAC82fA0JDB4zuaym1B6RNwuJM-3cB3_5YRVO-J2Op0Lsyn2Y6g@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div>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"?<br>
<br>
</div>
</div>
</div>
</div>
</blockquote>
Yep. But if all we have is writeable vector tables at 0x0, then it
MIGHT be<br>
ok. GCC may not be able to detect. But on the m68k's without a VBR
<br>
register the table is always at 0x0.<br>
<blockquote
cite="mid:CAC82fA0JDB4zuaym1B6RNwuJM-3cB3_5YRVO-J2Op0Lsyn2Y6g@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div>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?<br>
<br>
</div>
</div>
</div>
</div>
</blockquote>
It might not just be BSPs, but architectures. Running code at 0x0
should be<br>
OK since that would likely be the start code. You would never
indirectly <br>
jump through it.<br>
<br>
Reading/writing data at 0 is the issue.<br>
<br>
I really have no idea if/how this impacts anything but wanted us all
to<br>
think on it. <br>
<blockquote
cite="mid:CAC82fA0JDB4zuaym1B6RNwuJM-3cB3_5YRVO-J2Op0Lsyn2Y6g@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div>Gedare<br>
</div>
<div><br>
<br>
</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"> --joel<br>
<div><br>
<br>
-------- Forwarded Message --------
<table border="0" cellpadding="0" cellspacing="0">
<tbody>
<tr>
<th align="RIGHT" nowrap="nowrap"
valign="BASELINE">Subject: </th>
<td>Re: Obscure crashes due to gcc 4.9 -O2 =>
-fisolate-erroneous-paths-dereference</td>
</tr>
<tr>
<th align="RIGHT" nowrap="nowrap"
valign="BASELINE">Date: </th>
<td>Wed, 18 Feb 2015 13:30:24 -0600</td>
</tr>
<tr>
<th align="RIGHT" nowrap="nowrap"
valign="BASELINE">From: </th>
<td>Andrew Pinski <a moz-do-not-send="true"
href="mailto:pinskia@gmail.com"
target="_blank"><pinskia@gmail.com></a></td>
</tr>
<tr>
<th align="RIGHT" nowrap="nowrap"
valign="BASELINE">To: </th>
<td>Jeff Prothero <a moz-do-not-send="true"
href="mailto:jprother@altera.com"
target="_blank"><jprother@altera.com></a></td>
</tr>
<tr>
<th align="RIGHT" nowrap="nowrap"
valign="BASELINE">CC: </th>
<td>GCC Mailing List <a moz-do-not-send="true"
href="mailto:gcc@gcc.gnu.org"
target="_blank"><gcc@gcc.gnu.org></a></td>
</tr>
</tbody>
</table>
<br>
<br>
<pre>On Wed, Feb 18, 2015 at 11:21 AM, Jeff Prothero <a moz-do-not-send="true" href="mailto:jprother@altera.com" target="_blank"><jprother@altera.com></a> wrote:
>
> Starting with gcc 4.9, -O2 implicitly invokes
>
> -fisolate-erroneous-paths-dereference:
>
> which
>
> <a moz-do-not-send="true" href="https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html" target="_blank">https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html</a>
>
> 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?
</pre>
<br>
</div>
<br>
</div>
<br>
_______________________________________________<br>
devel mailing list<br>
<a moz-do-not-send="true" href="mailto:devel@rtems.org">devel@rtems.org</a><br>
<a moz-do-not-send="true"
href="http://lists.rtems.org/mailman/listinfo/devel"
target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Joel Sherrill, Ph.D. Director of Research & Development
<a class="moz-txt-link-abbreviated" href="mailto:joel.sherrill@OARcorp.com">joel.sherrill@OARcorp.com</a> On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985</pre>
</body>
</html>