Possible bug in GCC 4.9.4 EABI VLE PowerPC (S32DS)

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Possible bug in GCC 4.9.4 EABI VLE PowerPC (S32DS)

1,227 Views
andreu_montiel
Contributor II

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:

pastedImage_1.png

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:

pastedImage_3.png

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!

Labels (1)
5 Replies

1,052 Views
andreu_montiel
Contributor II

Any news?

Thanks!

0 Kudos

1,052 Views
jiri_kral
NXP Employee
NXP Employee

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 

0 Kudos

1,052 Views
andreu_montiel
Contributor II

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,

0 Kudos

1,052 Views
jiri_kral
NXP Employee
NXP Employee

Hi Andreu, 

based on tests - this issue is related to -Og only. You should be okay if you remove -Og option. 

Jiri 

0 Kudos

1,052 Views
jiri_kral
NXP Employee
NXP Employee

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