• Locked Locked
  • Replies 5 replies
  • Subscribers 53 subscribers
  • Views 903 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Relocation Capabilities (-ar) option availability in CCS 5.3

Sandeep Manjunatha
Prodigy 170 points

Hi All,

 I am using CCS 5.3 with compiler v7.4.1 on Windows 7 professional.

 Please let me know how to use/enable -ar option explained in Compiler version 7.4 user guide in CCS 5.3

 I tried enabling both -a and -r options in advanced linking options, but i got error saying it is not supported while producing elf output files.

Copying the snippet from compiler user guide

7.4.2. Relocation Capabilities (--absolute_exe and --relocatable Options)

The linker performs relocation, which is the process of adjusting all references to a symbol when the symbol's address changes. The linker supports two options (--absolute_exe and --relocatable) that allow you to produce an absolute or a relocatable output module. The linker also supports a third option (-ar) that allows you to produce an executable, relocatable output module.

When the linker encounters a file that contains no relocation or symbol table information, it issues a warning message (but continues executing). Relinking an absolute file can be successful only if each input file contains no information that needs to be relocated (that is, each file has no unresolved references and is bound to the same virtual address that it was bound to when the linker created it).

Thanks in advance,

Sandeep M

  • TI__Guru**** 253270 points

    The linker documentation needs to be updated.  The option -ar (which is the same as using --relocatable and --absolute_exe together) is not supported for ELF object file format.

    Thanks and regards,

    -George

  • in reply to George Mock
    Prodigy 170 points

    Dear George,

     Thanks for your reply.

     The intention of using -ar option in my project was to link shared code present in library to multiple executable outputs.

     In this regard, I tried to link library first with the 1st executable project. This created .out with proper placement of the code in shared memory as expected.

     Next, when I linked the library with 2nd executable project, which was including another shared library, there was difference in placement of shared code.

     Because of this behavior, I thought it would be right to make first project as executable with relocatable option, so that I can link both the library and 1st .out with 2nd executable project to get linear placement of code in shared memory, without overwriting the shared code memory.

     Please suggest any other possible way of generating different executable outputs(for different cores) with proper placement of shared code present in various libraries, and different projects linking only few of the shared libraries/code.

    Regards,

    Sandeep M

  • in reply to Sandeep Manjunatha
    TI__Guru**** 253270 points

    Why have two separate executable programs?  Why not combine them into one program?

    Thanks and regards,

    -George

  • in reply to George Mock
    Prodigy 170 points

    Hi George/All,

    For example,

    Module A is supposed to be running in Core0

    Module B is supposed to be running in Core1

    Module C is supposed to be running in Core2

    Now, Core0 and Core1 have one function (say func1 from lib1)in common, which has to be placed in shared memory, but Core1 and Core2 have another function in common(say func2 from lib2).

    In this case, when I build Core0 by including lib1, func1 will occupy starting of MSMC(0x0c000000). When I build Core1 including both lib1 and lib2, may be the functions func1 and func2 gets placed in similar way as func1 might get address as starting of MSMC(Not sure how linker links the libraries included though). But when I build Core2 by including only lib2, func2 will occupy starting of MSMC which overrides Core0 and Core1's memory pattern of MSMC.

    Similar is the requirement because of which I am trying to have different executable per core.

     I need to know if there is some way to guide the linker to use previous executable's map file information and avoid overwriting/re-placing the shared code/functions while generating executable for next core.

    Please suggest if this is possible. For this, I tried -ar option, which I got to know, is not available for ELF.

    Attaching the code with readme.txt explaining the requirement.

    7851.PerCoreExecutableTest.zip

    Regards,

    Sandeep M

  • in reply to Sandeep Manjunatha
    TI__Guru**** 253270 points

    You are trying to do something fairly advanced.  To give you an idea of what I mean, consider this ... Suppose you want to use the library function printf across multiple modules running on different cores. The printf function creates and manages a non-trivial data structure of its own.  It has file handles, buffers, and the like.  While it is OK to share the printf code across multiple modules, it is not OK to share the data.  The bottom line is this: Your area of technical concern now includes much more than just the compiler and linker.

    TI has a solution named Multicore Application Deployment (MAD).  I am not certain, but I think it does what you want.  I suggest you start with this wiki article.  The summary on MAD is here.  And downloads are described here.  If you have questions, please take those to the multicore forum.

    Hope this helps ...

    -George