Debugger memory offset error

[dpeterson3]

I can deploy code to the CRIO, but I can not debug code to it. When I try to debug, I get tossed an error message saying "WTX Loader Error:Relocation offset too large" It does that even with the default code. I just started today. The only thing I did differently was to modify my project's build properties to match those of all the defualt code properties. Does anyone know what this means?

[grantf]

I just had this error as well. It turns out that I was trying to debug the wrong project. Bring up the "Debug" dialog by right-clicking on your project in the project explorer and click "Debug Kernel Task." In the "Downloads" tab, make sure that the file that is being transferred is the .out file associated with your project. Make sure that the other settings you specify conform to the instructions in the WPI C/C++ Getting Started Guide in the section titled "Debugging your robot program" (page 11).

Good luck, and please reply if this fixed your problem or not so others can benefit too!

[sdlynx]

We've tried everything here but we still have this problem.

[gvarndell]

Please see this thread.
I think you have the same problem.

http://www.chiefdelphi.com/forums/sh...threadid=80931

[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. First try undeploying the code then reloading it for debug. If this does not fix the problem make sure that the kernal tasks are running and not pending, if they are not running, reset the cRIO and reconnect. Do not try to debug until the Kernel tasks are running and can be seen in the tree view at the lower left. If this still does not fix it try restarting windriver and folowing the same steps.

I hope this helps.

[gvarndell]

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.