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