Hello. Is there any way to simplify the call tree manipulation in linker..? (Scripting kind of) My code has number of function calls through pointers. The functions are divided in few main groups. I want to achieve overlay among the functions of an individual group.(Intragroup) At the same time I want to avoid overlaying among the functions from different groups.(Intergroup) Adding and removing the references for every function from every other function is big task. I somehow managed it at the moment. However it is not good practice from the long term perspective.
So, can I define a list of functions which can be used at multiple places in linker script. Or can I share a macro from compiler to the linker..?
Best regards, Vivek.
"My system requirements will always (sic?) result in multiple function calls through pointers"
Really?
When I looked at this, I concluded that the chances of getting manual calltree manipulation all correct - and maintaining it that way - were slim. So I redesigned the code to not use function pointers. It wasn't hard.
But, if you really must use function pointers, have you studied the app note - it shows you how it can be done without having to manipulate the calltree.
You do realise, don't you, that this is all due to a fundamental limitation of the 8051 hardware architecture - so, if function pointers really are so essential to you, you have really chosen the wrong target architcture!
"Expecting from tool set an easy way to manipulate the call tree, sounds more obvious and practical"
Well, there's only so far you can bend an inappropriate architecture...
You can sometimes get away with using a hammer to drive screws - but expecting hammer makers to adjust their designs to better drive screws is solving the wrong problem...
Hello, I am not expecting linker to automatically manipulate the call tree for me. I know it has to be done manually. Now, if you may have overlooked my question, is there any way to group the function names in linker file..?
Calling functions through pointers. My system has several modules which are plug able kind of. Just to reuse flash area. So pointers can not be avoided. Besides, this is an evolved product running in the market. So changing everything for tool set and testing it again calls for too much efforts and risk.
Now I would really appreciate if someone answers my basic question is there any way to group the function names in linker file..? instead of wasting time in suggesting changing the design.
Best regards, Vivek.!
Now, if you may have overlooked my question, We didn't. We just concluded you were asking the wrong question.
My system has several modules which are plug able kind of. Just to reuse flash area.
So not only did you pick (and stick with) the wrong CPU architecture for the job, causing a need to jump through hoops to cram all the code into the available address space; you even picked the wrong set of hoops to jump through, rolling your own "plug-in, kind of" system instead of using the existing code-banking mechanism.
So pointers can not be avoided. Repeating that claim doesn't make it any less incorrect.
So changing everything for tool set and testing it again calls for too much efforts and risk. Nobody asked you to change everything. But you apparently believe so strictly that nothing you did so far could possibly have been a mistake, that you won't even consider changing anything. Good luck with that attitude in the future. You (and your customers) will need it.
Yet another poor attempt of blaming anything possible. Why is this so difficult to accept the fact that there is no way one can combine function names in linker file..? Anyways. I already concluded and even started developing perl script for that.
About attitude. The answer expected to my question was very simple. Either yes or no. Which by the way is yet not said by the professional experts here. Instead the hardware architecture, the software design and even function pointers (lol) are blamed. So just rethink. Who should improve on attitude front..? The person seeking for help for using your tool Or the person who is so uncomfortable in accepting the fact.
By the way, the plugin system I mentioned was not to overcome the addressing limit. I m already using banking technique for that. The plugin system is to literally download a new piece of code and registering its entry in a look up table. Now please don't suggest me that I should have fixed calling locations for new functions instead of using function pointers.
Not directly but I got the answer from this forum. Thanks a lot.
Best regards, Vivek
Consider again the "The person seeking for help for using your tool"
Who is the "you" in that sentence? We are not Keil. We have no need to defend Keil's products.
Yet another poor attempt of blaming anything possible. Nice of you to volunteer such a perfect summary of both your problem and your failed efforts at solving it.
Why is this so difficult to accept the fact that there is no way one can combine function names in linker file..? The only person here failing to accept facts is yourself. Those facts being when you fight your tools, sooner or later you'll lose. You've now reached that point, and your reaction is try to blame anything and anybody else.
The plugin system is to literally download a new piece of code and registering its entry in a look up table.
That makes no sense whatsoever. For call tree additions to have any reliable or even useful effect at all, the functions you add information about have to be linked with the rest of the program. There is just no way that a function that didn't even exist yet at link time (i.e. one that's actually "new code") can usefully be presented to call tree analysis.
Vivek,
A little advice for you.
There are certain posters to this forum who are never wrong. Even when they are, they will argue and twist and manipulate minor points to make those stand out and leave a big glaring hole where an answer to a simple question should be.
Don't get me wrong. They are not all like that. The majority are very good, very helpful and give good advice. With some of those, you might not like what they say, but you'd do well to consider their responses.
I'm sure you can judge which respondent falls into which category.
Thanks Mertek, At the end of the day, I got an answer. That is more important. How that does not matter. I will see if any of these suggestions can be applied in design. Thanks everyone for spending time. :-)
Hello Hans, You r right. The piece of code which is plug able, has to be linked first. But that is not the real problem. The real problem is putting another piece of code at the same location. It is impossible in normal ways. But compile and link the code multiple times for every piece and separate its binary image from there. At the moment this process is manual and will try to automate using some scripts. Now one can put the piece of code which is needed at a time and replace it with the other as and when needed. So is the flash saving.
Do you see any possible improvement in this approach..?
The piece of code which is plug able, has to be linked first. But that is not the real problem. Actually, it is, because it means your entire plan is based on an incorrect assumption: that repeatedly linking the primary code with different "plug-in" functions will leave the rest of the code unmodified. Well, with this linker (or more generally: on this CPU architecture), it won't.
Which brings up the next question: given you're already suffering the pain of code banking, what on earth is keeping you from linking all those plug-ins into a single fat binary, so you can do away with that silly, doomed-to-fail plug-in mechanism? Ah... let me guess: not only has your program outgrown the code address space of an 8051, it's outgrown even the limits of 8051-with-maxed-out-code-banking, has it?
And, just to go back to your earlier protestations: no, you do not need function pointers for that setup.
Exactly Hans, The code has outgrown even the limits of banking. Or I would say the limits of flash to be precise. The hardware here is a single chip with limited xram and xflash. So upgrading it further is not in my control unless there is any such an option from the vendor. Hence single fat binary is not possible.
About the rest of the code being changed. No. Its not happening. I guess until my plugins are at assembly level. So, there are no common code findings for the linker to do any further optimization and reshuffle.
The code banking is not a pain. Why would it be anyway. Without it, probably I wouldn't have reached this far. What do you think..?
Vivek.
Another point. It could be question, why do I need to worry about overlay for an assembly routine. No. I am not. But there are some other ways it is ensured that the core of the binary does not change. Couple of them are to place a function at a fixed location while linking, Or a function too simple but lengthy enough... Meanwhile the script seems to be working for me at the moment.
I will still consider avoiding fp where ever possible. At least it will reduce number of manipulations needed.