Hi, first of all, we are generating code with IBM Rhapsody in C++. In this case I am packing a library of a HAL to provide collegues with this. When testing the library in a test project I must notice that one generated file, where only interrupt service routines are handled is removed from the linker of my test project. No I am searching for a setting or option of the linker to prevent this.
I did have a similar problem a few weeks ago but I could handle it with calling an object in the file which was removed first.
But in this time I have no influences in changing the Rhapsody settings to let the linker know that I need the file.
I hope you understand my problem, otherwise please ask for details.
Thanks for your help.
Heiko
Make sure you use extern "C" in front of the IRQ Handlers you have in .CPP files to ensure the linker binds entries in the vector table coming from a startup.s assembler file.
I still use the extern "C" phrase before the IRQHandler. By now I found a similar workaround with an additional object with a statechart, so that Rhapsody generates a call to the objects initial state. But that can´t be a real solution. Maybe someone knows details about the linker to tell him not to remove anything...
So have you asked Rhapsody about this?
No, because the generated code looks as it shoud be. It is also proved that the parts got their place in the lib. but when the lib is linked together with the test code, these parts are thrown away.
I now have two cases, in one an object without a call in this module is killed and in the other the ISR is removed.
in both cases an automatically generated call to set the initial state in the statechart leads to a no_removal
but when the lib is linked together with the test code, these parts are thrown away.
And that, in turn, is most probably happening because the interrupt handlers are not coded "as it shoud be" for this purpose.
Code from a library will only be pulled into the executable if something else in the linker's input requires it by referring to its name. Interrupt handlers generally do not fit that bill, because nothing else calls them or otherwise refers to them by name. So they won't be included.
That leaves two possibilities: don't try and put actual interrupt handlers into a library, but rather deliver them as separate object files. Or teach the user(s) of the library how to coerce the linker into including them.