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.
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.