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.

Compiler/TMS320F28377S: Linker command file: group library sections

Part Number: TMS320F28377S

Tool/software: TI C/C++ Compiler

I need to group some sections together, including sections from a library. I've tried to follow the grouping / naming suggestions as described in

http://processors.wiki.ti.com/index.php/Linker_Command_File_Primer

Extract of my linker command file:

SECTIONS
{

MyLibrary

{

-l..\path\to\my\library.lib(.text)

}

GROUP : >> RAMLS0 | RAMLS1 | RAMLS2 | RAMLS3 | RAMLS4, PAGE = 0

{

.text

MyLibrary

.cinit

.econst

}

}

The problem is MyLibrary is put after the .cinit / .econst sections.

Questions:

1) How can I group the sections so the order is as following:

.text

MyLibrary.text

.cinit / .econst

2) I've read I can define -l..\path\to\my\library.lib at the top of the file and then just use the name library.lib. Where / how do I need to define it?

  • Consider these lines, which appear outside the GROUP ...

    DSPGER said:

    MyLibrary

    {

    -l..\path\to\my\library.lib(.text)

    }

    This says to create an output section named MyLibrary.  It's input sections are the .text sections from mylibrary.lib.  No allocation is specified, so linker allocates it by default.  While this is legal syntax, it is never wise to do it this way.

    When you write MyLibrary inside the GROUP ... This says to create an output section name MyLibrary.  Multiple output sections of the same name are allowed, but generally a bad idea.  It is made up of all the input sections also named MyLibrary.  I'm sure there aren't any, so this output section is empty.  

    To fix it, remove the MyLibrary section outside the GROUP.  Inside the group, right after the MyLibrary line, write this ...

    DSPGER said:

    {

    -l..\path\to\my\library.lib(.text)

    }

    DSPGER said:
    2) I've read I can define -l..\path\to\my\library.lib at the top of the file and then just use the name library.lib. Where / how do I need to define it?

    That's a matter of preference.  The linker needs to know 3 things.

    1. The name of the library
    2. The directory where the library is located
    3. What output section gets the input sections from the library

    There are multiple ways to supply this information.  The Primer article shows one.  You show another.  Another one is shown in the section titled Specifying Library or Archive Members as Input to Output Sections in the C28x assembly tools manual.  Use whatever method you think will make the linker command file easier to use.

    Thanks and regards,

    -George

  • Hello George,

    like this?

    GROUP : >> RAMLS0 | RAMLS1 | RAMLS2 | RAMLS3 | RAMLS4, PAGE = 0
    {
    	.text
    	MyLibrary
    	{
    		-l..\path\to\my\library.lib(.text)
    	}
    	.cinit
    	.econst
    }

    I've tried this before and the linker places MyLibrary before .text:

    TEXT Section .text (Little Endian), 0x460 words at 0x00008835
    TEXT Section MyLibrary.1 (Little Endian), 0x800 words at 0x00008000
    TEXT Section MyLibrary.2 (Little Endian), 0x35 words at 0x00008800
    DATA Section .cinit (Little Endian), 0x18 words at 0x00008c95

  • DSPGER said:
    like this?

    Yes

    DSPGER said:
    I've tried this before and the linker places MyLibrary before .text:

    That's because GROUP and section splitting (the >> syntax) work at cross purposes.  And section splitting wins out.  Section splitting says it is OK to split an output section or GROUP into pieces, on input section boundaries, and attempt to place those pieces in as little memory as possible.  The ordering normally imposed by GROUP is ignored.

    If you really need the output sections in that order .... I only see one way to do it.  It is likely those memory ranges are defined like this ...

       RAMLS0          	: origin = 0x008000, length = 0x000800
       RAMLS1          	: origin = 0x008800, length = 0x000800
       RAMLS2      		: origin = 0x009000, length = 0x000800
       RAMLS3      		: origin = 0x009800, length = 0x000800
       RAMLS4      		: origin = 0x00A000, length = 0x000800
    

    Those memory ranges are all adjacent.  Collapse them into a single memory range ...

       RAMLS0_4             : origin = 0x008000, length = 0x002800

    Then write your GROUP ...

        GROUP > RAMLS0_4
        {
            /* same as before */
        }

    Obviously, any other use of RAMLS0 etc will need a similar change.

    Note this means that functions or data will start to span across the 0x800 address boundaries.  I presume there is no reason to be concerned about that.  But maybe there is?

    Thanks and regards,

    -George

  • Not the answer I wanted to have, but good to know. Thanks.

    George Mock said:

    Note this means that functions or data will start to span across the 0x800 address boundaries.  I presume there is no reason to be concerned about that.  But maybe there is?

    Not sure.

  • Hello

    You are fine to collapse the memories together and span the boundaries. This shouldn't cause you any issues.

    Best regards
    Chris