I am using keil uVision4 for compiling the code. I found in the compiled code that for the nested functions all the working registers and LR is pushed on stack and popped back just before the return is executed. For non-nested functions the registers are not stored on stack. But I want that at every function entry, whether it be nested or not, these registers and LR to be saved on stack. How do I do it? What settings I have to do?
Thanks, Bharat
By choosing to use a High-Level Language (HLL), you have delegated responsibility for this stuff to the compiler - so don't try to interfere by "micro-managing" it!
If this level of detail is really important to you, then you need to be writing in assembler.
en.wikipedia.org/.../Micromanagement
But I want that at every function entry, whether it be nested or not, these registers and LR to be saved on stack.
That sounds like a very odd wish. Why would you want to do that? By the way, I don't think there is a compiler knob for that.
www.catb.org/.../smart-questions.html
Although I cannot think of a sensible reason for wanting this control here, the existance of such controls on other products has existed and it did have purpose. For example, the Watcom C compiler permitted a lot of configurability of calling convention and argument storage detail without having to resort to assembler.
That said, I don't think the Keil compiler has this type of option.
And the reason for the huge amount of calling conventions supported by the Watcom compiler was to use it to call code written in foreign languages.
It isn't as likely, in an embedded environment, that you need to call code compiled with a different compiler. Projects are smaller than on a PC. And most people have so much invested in their proprietary hardware that they don't dare to use libraries they don't have the full source code for. Which is also a reason why people have been avoiding some of the Keil libraries like the plague.
But the main reason for a compiler switch to always force a standard stack frame isn't so much compatibility with foreign code. A standard stack frame means larger/slower code. But have the advantage that an exception handler can perform a walk of the stack all the way back to main() - so it can be a huge advantage when trying to figure out exactly where a program went nuts.
It isn't as likely, in an embedded environment, that you need to call code compiled with a different compiler.
The ABI basically dictates the preferred calling convention anyway.
But have the advantage that an exception handler can perform a walk of the stack all the way back to main()
If you're requiring that facility, then you'd normally be better off using the facilities provided by the compiler for such a purpose; and not try to just force a stack frame.
Except that there are environments when the official ARM ABI isn't used. But true - Keil don't have any reason to cater for them.
Not sure what "compiler facility" you are talking about. The comppiler either have - or do not have - a switch to enforce a stack frame. If it doesn't, then it's way harder to have an exception handler dump the stack. And it's likely you wnat that stack dump on a production unit out in field - not a unit with a special debug bouild. And not a unit in laboratory with debugger connected.
Except that there are environments when the official ARM ABI isn't used.
Maybe I'm too new to the ARM, but I've not heard of any (apart from pure assembler or hobbyist work).
Not sure what "compiler facility" you are talking about.
I was thinking about exception handling. With that the facility is enabled/disabled in it's entirety, stack frame and all.
I didn't talk about exceptions as in C++ exceptions, but the hw traps for invalid instructions etc.
About the ARM ABI: infocenter.arm.com/.../index.jsp
For that I'd concur with what you say. It's not going help the OP in getting his desired answer though. I can't find any facility to force the stack frame.