Article ID: 000085705 Content Type: Troubleshooting Last Reviewed: 05/19/2015

Why do I see crashes when I use Null pointer dereferencing in the nios2-elf-gcc 4.9 ToolChain?

Environment

    Quartus® II Subscription Edition
    Nios® II Processor
BUILT IN - ARTICLE INTRO SECOND COMPONENT
Description

In the Quartus® II software version 15.0, Nios® II code compiles using the nios2-elf-gcc 4.9 toolchain. When compiling code at -O2 (or higher) with nios2-elf-gcc 4.9 toolchain, the optimization -fisolate-erroneous-paths-dereference will be switched ON by default.

 

As described in

https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#Optimize-Options,

 

-fisolate-erroneous-paths-dereference

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 optimization means when the toolchain detects the code is trying to load or store through a possible null pointer, it will change the load or store statement into a trap instruction. This may cause embedded program to crash without a compile-time warning.

Resolution

If your design contains valid data at address zero, compile your code using the following switch to avoid issues related to null pointer dereferences:

 

-fno-delete-null-pointer-checks

Related Products

This article applies to 1 products

Intel® Programmable Devices

1