Hello,
We have found what seems a bug in the C compiler GCC 4.9.4 included in S32DS for PowerPC. This bug is reproducible with an unmodified SDK project example after setting optimization to "-Og". As a summary, the compiler appears to emit instructions that write to a reserved address (different behavior from the C source code), resulting in an exception of the CPU.
The steps to reproduce are very simple:
- Create a new Hello World project "hello_world_mpc5748g".
- In Project Settings -> C/C++ Build -> Settings, change "optimization level" to None, set "Other optimizations flags" to "-Og".
- Compile and flash.
To save you time, the resulting project is included in a 7z file here.
The resulting binary generates an IVOR1 exception. The instruction that cause the exception is at 0x01003374, but the previous one is also related, screenshot below:
Exception is raised when trying to execute 0x01003374 (store half-word). Let me put also a screenshot of the CPU registers right after the exception occurs:
What we have analysed:
-> "e_li r4, -2" --> R4 <= 0xFFFFFFFE, nothing harmful
-> "e_sth r4, 0x2C3E(r4)" ---> This is generating a 16 bit write of 0xFFFE to address (R4 + 0x2C3E) = 0x2C3C (?!?!)
This 16bit write to 0x2C3C seems the cause of the exception (in memory map of MPC5748G reference manual this area is marked as Reserved). Bits MCSR.BUS_WRERR=1, and address (MCSR.MAV=1) is MCAR=0x2C3C are coherent with the analysis.
Anyhow with the given C source code (which is part of the SDK), this 16-bit write doesn't make any sense. The C code is just applying bit masks to a variable in the stack.
Please let me know what you think, if this is indeed a bug in GCC or maybe we missed something.
Thanks!
Any news?
Thanks!
Hi Andreu,
it is compiler issue and compiler team is working on it. Basically - compiler generates rlwnm instruction which is unsupported in VLE mode. Disassembly in VLE mode shows this instruction as e_sth with incorrect parameters.
Unfortunately - there is no workaround yet.
Jiri
Hi Jiri,
Ok. Now that the issue is understood, do you know whether this issue is reproducible with -Og only? In other words, would it be enough to avoid -Og to be sure the compiler is working correctly?
Thanks again for your support,
Hi Andreu,
based on tests - this issue is related to -Og only. You should be okay if you remove -Og option.
Jiri
Hi Andreu,
thanks for report and perfect issue description. I can reproduce it and - it is really strange. If I'm correct R4 in EABI is used for function call arguments. I'll create JIRA ticket for that. Thanks!
Jiri