Memscope connection problem (memory) - VxWorks

This is a discussion on Memscope connection problem (memory) - VxWorks ; 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 ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: Memscope connection problem (memory)

  1. 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!

    /Mikael


  2. Re: Memscope connection problem (memory)

    Hello Mikael,

    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
    site...

    RESEARCH:

    * PowerPC Embedded Application Binary Interface, Version 1.0
    * System V Application Binary Interface, PowerPC Processor Supplement
    (Sept. 1995)
    * Reproduced failure on mv1604 board w/64MB of RAM while loading an
    object module with external function references.

    RESOLUTION:

    The error message above is known to appear while loading modules with
    external function references on PowerPC targets having more than 32MB
    of RAM.

    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
    Solution Center.

    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
    for assistance.

    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
    been performed.

    Jamie
    truewise@hotmail.com wrote:
    > 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!
    >
    > /Mikael



+ Reply to Thread