Responding in new thread since other thread is dead. http://www.keil.com/forum/21199
So, anyone else with this problem? It seems to be a general Keil issue...
Anyone else with what problem? Forgetting to use the correct keyword to tag an ISR as an ISR?
What general Keil issue? That the compiler needs to adapt to the hardware?
Lots of compilers for lots of processors have needed a special keyword to let the compiler know when it should generate prologue/epilogue for an ISR instead of for a normal function.
A number of processors have a normal "RET" instruction and a special "RETI" instruction. Or need to name specific registers to reload PC with the correct return address depending on if the processor did use the normal stack or an interrupt stack.
And an ISR often need to save extra registers compared to a normal function, since the interrupt can happen asynchronously - breaking in in the middle of other code execution.
So if you Google and finds lots of mentions of Keil, it is just because Keil works with compilers for embedded use. So the majority of users of Keil tools will create interrupt handlers.
Only OS or drive routine coders need to care about any interrupt handlers if you write code for a modern PC. So you don't see lots of threads about interrupt handlers for Visual C++.
Of course - a processor can be implemented in a way where an ISR do not need any special prologue or epilogue. In that case, there will be no need for any extra keyword to tag the ISR as different from a normal function. ARM did add extra logic in the Cortex chips to allow 100% of the code to be written in C, and without any special keyword for ISR. But that is an exception to the rule that interrupt service routines are different from normal functions.
The compiler only complains about compile-time errors (or warnings). It does not know what is "correct" code.
Naturally. But the problem started when I didn't count on a possibility that there is an "incorrect" or rather to say different code on some path included by default. I'll never stop finding this issue quite odd. I was expecting that the compiler would complain missing if some part of the source is not properly included in the project instead of finiding one of a same name on some other location.
Ok, so you read my cross-posting (actually there are more, I tried to find the solution for my problem any way I can) - I'm an old TI-based device programmer and I didn't bother to imagine what issues come up when one vendors IDE for 3rd party chip manufacturers.
The stone-hard version control part is what I could absolutely agree with after all.
Well, the linker is happy with any implementation it finds that happens to have the correct name. But that doesn't mean that the linker gets a function that is written to be compatible with other code that happens to make references to this function name.
The most common issues is that the linker do get good code, but that the user have included header files for another version of the code. And these header files may have more or less number of fields in a struct. So the struct you thought you allocated had wrong size compared to the size that other code assumed. And the offset of individual fields were different between the code you compiled, and the code you linked.
Extremely strange things can happen when the header files aren't for same version of code that is already compiled and is just brought in during linking.
So lots of people makes copies of header files and libraries and duplicate in their project tree, to really make sure that the library with related files are locked down to the project. This also makes sure that someone copying the project directory tree will not be standing there without a library and without being able to guess what library (and version) that is required.