开发者

Relocation value does not fit in 24 bits

开发者 https://www.devze.com 2023-04-04 06:14 出处:网络
I tried to load a code file to memory using the vxWorks functi开发者_Python百科on loadModule and it gave me the error:

I tried to load a code file to memory using the vxWorks functi开发者_Python百科on loadModule and it gave me the error:

Relocation value does not fit in 24 bits

I tried to add the -mlongcall flag in my compiler but it doesn't work.


I have seen this error before working in a PowerPC architecture. Assuming that you are working in a similar environment, the issue has to do specifically with the amount of memory in the system and the range of the relative branch instruction.

The Argonne National Labs has a webpage detailing their experiences with the same issue. The following excerpt explains the issue with the relative branch addressing:

The PowerPC relative branch instruction is limited to jumps between +/- 32MB of the current instruction (24 bits = +/- 4M instructions, 4 bytes per instruction = +/- 32MB). Unfortunately the vxWorks kernel gets put into the bottom end of RAM, but it loads all application code at the top end. If the two are separated by more than 32MB (should you have 64MB or more on board) then when it tries to load the application code those calls that use these relative branch instructions to vxWorks routines can't be resolved within 24 bits, and the loader prints the message you're seeing.

The suggested fix for this problem, both at the Argonne National Labs is to recompile your loaded modules with the -mlongcall flag enabled.

Your initial question indicated that this flag was not a fix for your problem. The gnu flag is set, but no further information is listed for your compiler. Given that I can only suggest that you check your compiler documentation and verify that the -mlongcall flag is valid.

Assuming that the flag is supported, this may be caused by a linked library which was not itself compiled with the -mlongcall flag. An article at ComplexIT details a similar issue, also in a PowerPC architecture, using QT. In order to resolve that issue a rebuild of all libraries, including QT, was required.


Be sure that your compiler is set to GNU for your Active Build Spec if you want to use -mlongcall. Remember that WindRiver also provides the Diab compiler, which happens to be their proprietary compiler. If you want to use the Diab compiler the equivalent flag for that compiler is:

-Xcode-absolute-far

If you are using Workbench, you can see what compiler you are using (and possibly change it if you so desire) by right clicking on your project in the Project Explorer sub-window then select

Properties->Build Properties->Build Support and Specs.

In that dialog you will see (usually at the bottom) a drop-down menu button named Active Build Spec. Select the architecture-compiler combination that you desire.

If you don't find the architecture-compiler combination that you require, you most likely did not select it when you were creating the project OR it did not come with your purchased pkg of VxWorks.


-mlongcall flag is for GNU C compiler. Windriver Diab do not support this, enabling _Xcode-absolute-far didn't solve the problem in my case, instead linking the libs to VxWorks image seems to be solving the problem.

0

精彩评论

暂无评论...
验证码 换一张
取 消

关注公众号