Quote:
Originally Posted by Mike Copioli
This happens to us once in a while. I am not exactly sure what causes it but this is what fixes it for us.
|
The root cause of the problem is that DKMs are dynamically linked at runtime.
Whether the debugger does the load, or the DKM is loaded automatically at boot (I guess that's what's meant by deployed), the .out file is loaded into some area of memory.
After loading, all the unresolved references (to functions and data) in the .out file are linked to the appropriate addresses.
For example, if your DKM makes function calls to printf, and printf wasn't statically linked into your DKM, then all the calls to printf must be relocated.
The dynamic link process knows how to find the unresolved references and how to fix them (relocate them) so they really call printf, which was linked into the vxWorks kernel (most likely).
If the area of memory into which the .out is loaded happens to be sufficiently "far away from" (more than 32 Meg away from) the actual location of the printf function, then you will get the relocation too large error.
My suggestion to all teams using C++ is to always build your DKMs with -mlongcall and avoid all this try this and try that.
As your DKMs get larger and more numerous, the likelihood that you'll cross the 32M distance barrier increases.
And yes, building with -mlongcall will indeed make your DKMs a tad larger and maybe even a tad slower -- but not by enough to warrant concern IMHO.