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