Today I observed a nice behavior today using AdvIecChk (the same uploaded to this topic, I already compared).
The application is running on an ARM target system X20CP0484-1 with AR H4.90 GCC6.3.
I found a lot of logger entries 55555 TC#3 "Divide by Zero - Word in task “” Section: without exception page fault !!!
It seems the exception is not triggered because of the use of memcpy(1,1,1) instead of brsmemcpy(1,1,1)
As soon as I use brsmemcpy the exception is correctly generated.
Does anyone have an explanation? This project is evolving since 5 years, and I’m pretty sure the exception was triggered before for other programming issues (checkbounds…)
I’m not a hardware crack, but in my understanding it could be possible that ARM and Intel processors behave different bei division by zero (even maybe different if it’s a integer or a float division by zero).
what I think to know is, that on the processor level an Intel processor provides a different trap for division by 0 than an ARM processor - I’m not completely sure but as I remember an Intel processor has an own processor exception for DIV0, while ARM hasn’t but delivers a different processor exception (if enabled by the compiler / operating system).
But, and that’s the even more tricky one:
I don’t understand why memcpy() doesn’t triggers the “invalid memory access” processor exception on ARM, while brsmemcpy() does?
No idea about that. Maybe there’s some context with the cross-compiling of IEC languages that has to be done on ARM, but really sorry, I don’t know.
Since the whole AdvIecChk “pagefault enforcement” is done by memcpy() in every possible case, for me that means, that the for debugging reasons wanted pagefault is never generated, independent of the IEC check type?
Or?
Thank you, Alexander and Marcos, for your answers.
So maybe this library has never worked in the real target and all IEC error we faced in the past were debugged in ARsim environment so with intel processor.
This is my current version of AdvIecChk where I changed all occurrence of functions from AsString : memcpy(), itoa() … to AsBrStr since AsString will be deprecated in ASW6.
I also updated the dependencies.
So this library SHOULD BE compatible with AS6 (not tested) AdvIecChk_ASW6Ready.zip (5.6 KB)