I warn anybody before using ARM Keil 4.13a. It generates defective code. I have spent several hours with debugging a code that has been already worked. The problem affects local variables of functions and passing arguments. Code has been wrongly compiled without any optimization. I have no courage and time to test optimizations.
I also encourage Keil not to publish Keil 4.13a any more.
Keil 4.12 seems to be OK.
You're not being asked to de-bug it - you're just being asked to produce conclusive evidence that a bug actually exists!
Taking your car analogy, you would need to prove that the car really was susbstantially underperforming, and that this was not due to your mis-handling of the vehicle; eg, carrying excessive loads or driving with the handbrake on...
Well, guys, just a comment: I would say that precise locating a bug in the disassembled machine code is pretty close to debugging - keeping in mind that the the Keil development suite is not open source... You are also lucky that your employer is paying hours and/or days (each of you know how much...) of your extra work to locate the bug in development tool and provide the evidence. No doubt it is a challenging task - and rather satisfactory if successful - but most of the programmers are hired to write a software and not to be testing the commercial dev tools ;-)
"You are also lucky that your employer is paying hours and/or days (each of you know how much...) of your extra work to locate the bug in development tool and provide the evidence."
But, if you don't know that the problem is with the compiler, you are potentially just giving Keil support the task of finding a bug in your code. They are not paid to do that.
That is entirely irrelevant!
You are alleging that there is a fault in the output from the compiler. So all (sic) you need to do is to provide a concrete example of where that output is manifestly wrong - there is no need whatsoever to delve into the inner workings of the tools!
Is your employer, perhaps, being naive in thinking that switching fron one compiler version to another is a trivial task?
We keep older compiler versions for older products, and only switch compiler version when making larger code changes requiring huge amounts of new qualifying tests.
In some cases, the compiler version used is also reported in certification documents where a tool change may result in a very costly external recertification.
It's only during the development phase that it is reasonably simple to switch between different compiler versions.
Closed-source or not really desn't matter. We have quite a lot of C/C++ code that is being built with gcc toolchains from 2005.
When a program fails, debugging is needed. That debugging should be thorough enough that it can be deduced if the error was in the source code or in the compiler. But that obviously requires that the person debugging the code doesn't fall for invalid assumptions about what is correct or not. And that includes the understanding that the debugger will not always be able to display the correct values because optimization has changed instruction order or life span of variables.
Here is a small test case that I am now going to send to Keil failing the debugger:
int main( void ) { int x1 = 1, x2 = 2, x3 = 3, x4 = 4, x5 = 5, x6 = 6, x7 = 7, x8 = 8, x9 = 9, x10 = 10, x11 = 11, x12 = 12, x13 = 13, x14 = 14, x15 = 15, x16 = 16; for (;;) { ++x1 ; ++x2 ; ++x3 ; ++x4 ; ++x5 ; ++x6 ; ++x7 ; ++x8 ; ++x9 ; ++x10 ; ++x11 ; ++x12 ; ++x13 ; ++x14 ; ++x15 ; ++x16 ; } }
Compiled using ARM code (LPC2478), no microlib, compiler optimization 0, no cross module optimization. On my system, the values of x14, x15, x16 are all set to 0x10 (according to the debugger), then incremented in the loop. Why does this happen? Well, the storage of x14 happens like this:
0x00000178 E3A0E00E MOV R14,#0x0000000E 0x0000017C E58DE008 STR R14,[R13,#0x0008] 17: x15 = 15,
and the debugger displays the contents of the stack without taking the offset into consideration! Please copy-paste this program and try it will MDK 4.13a in a simulator.
This seems to be an entirely unrelated problem?
I really think it would be better to put it in separate thread - you can always give a link to this one...
Before making any conclusions - how about adding a function that takes your variables x1 .. x16 as parameters, so the compiler may at least believe that you are using them?
Right now, you only have a rather large empty loop that doesn't produce any real work.
Next thing is that you must separate problems with debugger from problems with compiler.
You show a piece of assembler output - but isn't the x15 = 15 handled by assembler instructions after the source line? You show the assembler above the source line.
Per,
This is NOT a compiler issue at all - above, I referred to a debugger failure and that's what is happening here. The same problem applies to x14, x15 and x16.
I probably should not have pasted "x15" alongside the assembly for "x14". Sorry, my bad.
Andy,
The damage is already done - will correct next time...
Yes, but remember that the original post had the subject line "Avoid using Keil 4.13a - it generates defective code" which is claiming a bug with the compiler. It really is important to perform a careful analysis before making an error report. A large percentage of developers will probably never see a true compiler bug, that isn't in reality a misunderstanding of what the compiler is expected to do.
All,
Keil support have provided me with DLLs that address the debugger issue above (wrong value displayed). I believe they will make them available to others as well.
So we know that there are debugger issues.
Therefore, to prove a compiler code generation bug, the OP needs to demonstrate both that it's not his own code that's faulty and that it's not a result of the known debugger issues...
To continue the car analogy, a false (low) reading on the speedometer would give the impression that the car's performance was poor...
I had a problem today, whereby a previously working bit of code "stopped working" when compiled with 4.13. I started the debugger and stepped through the code, and found that a local variable was being stored in r9, we then had a switch statement switching on this "local variable". Once it got to the correct case, the code then passed this local variable into another function. On single stepping we found that the compiler was using r9 during the switch statement to determine which case was a match. This then meant that when the "local" was passed into the function, r9 had become corrupted, and therefore it had incorrect functionality. Recompiled the code with aditional debug code, but it always failed in the same way. Loaded 4.11 back onto the PC, and recompiled the code, and the exact same code now functions as expected! I understand what people say about not being able to trust the debugger to report values correctly, but the code did not work with 4.13, but worked fine with 4.11. This seems to be similar to the original post on this thread reporting an issue with using local variables and passing them into functions. Think i am going to stick with 4.11 until I hear more from Keil.
Steve F,
This is very worrying indeed. You did provide Keil with sample code, right...?