Memscope connection problem (memory)
I try to use memscope, but is restricted by the size of the binary. I
use WxWorks 5.4.2 and Tornado 2.1, have tried to rebuild the bsp with
extended exception vectors without success.
The workaround so far is to shrink the binary and build with debug info
included, by this I can connect. I have not been able to reproduce
that build that was working for me(3-4 hours build time). Do you have
experience of this? What should be changed to get this working.
I have changed this extended exception vectors but not sure if it
supported by my OS version, is there some otherway that could solve
this. (At least figure out how to make the minimal build of the app
working) Please contact me if you have any advice!
Re: Memscope connection problem (memory)
You didn't specify your image size or architecture...assuming it's PPC
and the image size is less than 32MB you can simply limit the size of
your loadable vxWorks image size by setting the size of viewable memory
MEM_SIZE to be less than 32MB and the size of USER_RESERVED_MEM to be
the remaining portion of physical memory. Then at run time you add
this reserved portion of memory back to the system partition vi
memPartAddToPool(). Here's a tech tip from wind rivers online support
* PowerPC Embedded Application Binary Interface, Version 1.0
* System V Application Binary Interface, PowerPC Processor Supplement
* Reproduced failure on mv1604 board w/64MB of RAM while loading an
object module with external function references.
The error message above is known to appear while loading modules with
external function references on PowerPC targets having more than 32MB
The limitation is due to how direct function calls are implemented for
the EABI (Embedded Application Binary Interface). The EABI is a
standard we follow for the PowerPC architecture and it may be
downloaded from the IBM web page. The EABI is based upon the SVR4 ABI
which suggests that all direct function calls be made with the 'bl'
instruction. Because the addressing range of the 'bl' instruction is
+/- 32MB, all direct function calls referencing functions defined more
than 32MB away will fail with the above relocation error.
Calling functions indirectly (i.e. through a function pointer) removes
the 32MB limitation as 32-bit absolute addressing is used in place of
26-bit PC relative addressing, thus giving you access to all routines
in the 4GB address space. Asking people to rewrite their code to make
all external function calls through pointers is not very practical and
may not be necessary in all cases. We suggest the following solutions
for the problem:
1) Use the "-mlongcall" option flag when compiling your code or
use the "#pragma longcall" directive to suggest certain
function calls be made through a function pointer.
"#pragma longcall" gives a suggestion to the compiler to call
a set of functions through a function pointer (using 32-bit
absolute addresses). This should be used primarily for
external functions as local functions are less likely to
reside far from your module.
NOTE: For those users employing Tornado 1.0.1, the patch for
SPR22767 will be required. For all other Tornado
users, the GNU toolkit has the ability to use
"-mlongcall" and "#pragma longcall" without problem.
The patch may be obtained from the WRS Customer
NOTE: In some cases, VxWorks library modules may need to be
re-compiled with the "-mlongcall" option. If problems
exist with the VxWorks libraries (as built and
installed) contact the WRS Customer Solution Center
2)If your code does not require constant loading and unloading
of object modules at runtime, you can also set LOCAL_MEM_SIZE
to 32MB and set aside the rest of memory as USER_RESERVED_MEM
(i.e. user reserved memory) and use memAddToPool to add the
rest after your object modules have been loaded. No further
object modules should be loaded after the memAddToPool has
> I try to use memscope, but is restricted by the size of the binary. I
> use WxWorks 5.4.2 and Tornado 2.1, have tried to rebuild the bsp with
> extended exception vectors without success.
> The workaround so far is to shrink the binary and build with debug info
> included, by this I can connect. I have not been able to reproduce
> that build that was working for me(3-4 hours build time). Do you have
> experience of this? What should be changed to get this working.
> I have changed this extended exception vectors but not sure if it
> supported by my OS version, is there some otherway that could solve
> this. (At least figure out how to make the minimal build of the app
> working) Please contact me if you have any advice!