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.

Symbol Table as input to Linker

Hello,

I was wondering if there is a way for TMS570 linker to provide the symbol table of a linked binary (*.out) file as input when linking a second binary. I want to link two binaries into the internal flash memory, where the second one makes use of functions included in the first one.

--- FIRST binary ---

void bar ( int foo )
{
   printf ("'bar' called by foo%d\n", foo);
}

void foo1 ( void )
{
   bar (1);
}

--- / FIRST binary ---

--- SECOND binary ---

extern void bar ( int foo );

void foo2 ( void )
{
    bar (2);
}

--- / SECOND binary ---

My idea would be linking the first binary and feed its symbol table to the linker when creating the second binary so it knows the address of function 'bar' when resolving the external symbol 'bar'. Is there some way to do this?

Thanks in advance!
Stefan

  • Good question. I am moving to the c-compiler forum to have an expert on the linker answer your question.
  • I recommend you consider another approach to this problem.  Put bar (and other functions called by both executables) in an object library.  Then make that library an input to the link command used to build each executable. One example of a library is the RTS library that comes with the compiler.  LIbraries are created with the archiver utility.  It is described in the ARM assembly language tools manual.

    Thanks and regards,

    -George

  • Unfortunately using object libraries is not an option. This is because we need to certify the first binary, but still be able to extend it with features (via function hooks in the second binary) which make use of functionality which is already implemented in the first binary (e.g. printf). Certification is not possible for libraries.

    Stefan
  • The ARM TI compiler toolchain does not directly provide this sort of feature, but you can fake most of the functionality. Use the armnm tool on the first executable to get a list of globally defined symbols. From this, you can make a series of definitions in the linker command file like so:

    func1=0x80001234;
    func2=0x80005689;

    This tells the linker that these symbols are already defined at those addresses, and doesn't need to pull them in again for the second executable.

    Next, make sure that the second executable does not try to re-use memory used by the first executable. The easiest way would be to alter the linker command file to remove the used portions of memory from the MEMORY directive.
  • Thanks a lot! This will do the trick.

    Stefan