EEPW论坛

好像由于内存扩大造成，现2片，各32M

相关branch instruction产生错误

在gcc编译中增加mlongcall，编译不通过，不识别longcall

“cc1.exe: Invalid option `longcalls'”，并且无源码，无法重新编译库！

将参数改为longcall或－mlong－calls后，可编译通过，但问题没有解决，可能和库有关。

找到几种解决办法供大家参考：

The easiest way around it is to limit the board memory to 64m, load your
program and do a memAddToPool for the rest of the memory.

Or use mlongcalls

Or link your app in with the kernel

or (I think) get the current release

是不是每个版本的vxworks识别命令不同

我用的是“-mlongcall”，确实有问题，如上所述

版本：vxworks5.5 为做过任何升级

感觉很奇怪，

用“-mlongcall”时报出“cc1.exe: Invalid option `longcall'”

用“-mlongcalls”时报出“cc1.exe: Invalid option `longcalls'”

很无奈，实在没办法，只好牺牲32M内存了，实在不想：（

不需要牺牲的。。。可以把高32M作为堆栈和动态块（用malloc等分配）来使用。在BSP中通过内存映射函数把这块内存添加到系统内存堆中。

也就是说，文本段的大小被限制为低32M内，使用26位寻址，但数据段则没有限制。

如果使用longcall，代价太大，不合适。。。。

网上看了一下，longcall有不少缺点，不太想用。

你说的内存映射函数在哪里？如何实现能说的具体点吗？

我在bsp中将bank模块定义为64M的，但size为32M，剩余的32M除了用memAddToPool（）函数，还能增么添加进去？

谢谢yaopg，有空请你吃肯德基

应该是：LOCAL_MEM_SIZE 64M

USER_RESERVED_MEM 32M

RAM_HIGH_ADRS不要超过32M范围，在29M处比较合适吧。

在sysLib.c里面用memAddToPool函数添加，，，，很多参考bsp里面有例子。

启动后，用大型内存块分配来测试是否成功。

内存起始地址定义：0x30000000

LOCAL_MEM_SIZE 64M

USER_RESERVED_MEM 32M

RAM_LOW_ADRS 0x30001000

RAM_HIGH_ADRS 0x30200000

正常启动后，内存大小为32M，此时加载应用程序loadmodule（）正常

但，如果添加到内存池后，通过memAddToPool(0x32000000,0x2000000);

加载应用程序会像以前一样报出：“Relocation value does not fit in 26 bits.”

而且感觉两部分内存没有连接上，memAddToPool之后，用malloc来测试，

发现动态加载32M不成功，加载两个20M成功，20M的内存指针分别位于低32M和高32M中

所有两块内存没有连接统一管理。

分支和带链接分支寻址＋—32M，添加内存池后，寻址范围还是超过32M。

恩，loadmodule是把代码段和数据段放在了高处

这样改只是避开了loadmodule，是否会影响以后程序稳定性就不好说了

show组件这些都已经添加，正在询问风和那边，看看有什么更好办法

有结果会跟帖回复

只有采用－mlongcall（或类似指令），来解决此问题才能确保安全、稳定。

目前库文件中的26bit编码无法重新编译，无源码，考虑新板件只保留32M，足够用了:)