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-RTOS
Hello,
I work on project with linux/gcc build of sysbios for Sitara.
Recently I had to increase heap size to 24MB and noticed that heap region is included in binary, so it also grown above 24MB.
Toolchain I use: arm-none-eabi-gcc (4.8.4-1+11-1) 4.8.4 20141219 (release)
This is my heap configuration:
var mainHeap = HeapMem.create() mainHeap.size = 25165824; mainHeap.sectionName = ".biosheap"; Memory.defaultHeapInstance = mainHeap; Program.sectMap[".c_int00"] = new Program.SectionSpec(); Program.sectMap[".c_int00"].loadAddress = 0x80000000; Program.sectMap[".c_int00"].runAddress = 0x80000000; Program.sectMap[".biosheap"] = new Program.SectionSpec(); Program.sectMap[".biosheap"].runSegment = "DDR2"
Program.sectMap[".biosheap"].type = "NOLOAD";
it results in linker.cmd section:
.biosheap (NOLOAD) : {*(.biosheap)} > DDR2
objdump shows:
Size VMA LMA File off Algn .biosheap 01800000 80027040 80027040 00037040 2**3 ALLOC .bss 0002f748 81863930 81863930 0187392c 2**3 ALLOC
size output:
text data bss dec hex
231373 44892 25507656 25783921 1896e71
resulting binary size: 25573676
It looks like section type "NOLOAD" is ignored. Changing it to "DSECT" also does not help.
Can anyone help me with this issue?
Thanks in advance!
Solution in this post is pretty much the same as my .cfg file, except that instead of "NOINIT" heap section type, there is "NOLOAD".
I understood, that it should work well on gcc, but it isn't. Also workaround did not help. It caused expansion of stack section instead of dedicated heap section, and this big stack section is not removed by objcopy, even with "--remove-section .stack" argument.
Before starting this thread I tried also to remove my .biosheap section in the same way as in this workaround, using objcopy, and it failed.
It seems that something prevents objcopy from removing section containing heap.
Can you try the following :
Program.sectionsExclude = ".stack" Program.sectionsExclude = ".heap"
I found the cause and solution of this behavior. It was hard to notice, because in single objcopy call I was removing heap section and converting from elf to binary.
When I split it into 2 steps, I noticed, that heap section has been removed. So objcopy worked properly, but still binary size was big, like it'd still contain removed section.
My sections configuration in .cfg file looked like that:
Program.sectMap[".c_int00"] = new Program.SectionSpec(); Program.sectMap[".c_int00"].loadAddress = 0x80000000; Program.sectMap[".c_int00"].runAddress = 0x80000000; Program.sectMap[".nonCachedRAM"] = new Program.SectionSpec(); Program.sectMap[".nonCachedRAM"].loadSegment = "OCMC_SRAM"; Program.sectMap[".xAltera"] = new Program.SectionSpec(); Program.sectMap[".xAltera"].loadSegment = "ALTERA_MEM"; Program.sectMap[".xAltera"].type = "NOLOAD"; Program.sectMap[".stack"] = new Program.SectionSpec(); Program.sectMap[".stack"].loadSegment = "DDR2"; Program.sectMap[".rodata"] = new Program.SectionSpec(); Program.sectMap[".rodata"].loadSegment = "DDR2"; Program.sectMap[".neardata"] = new Program.SectionSpec(); Program.sectMap[".neardata"].loadSegment = "DDR2"; Program.sectMap[".biosheap"] = new Program.SectionSpec(); Program.sectMap[".biosheap"].loadSegment = "DDR2"; Program.sectMap[".biosheap"].type = "NOLOAD"; Program.sectMap["ti.sysbios.family.arm.a8.mmuTableSection"] = new Program.SectionSpec(); Program.sectMap["ti.sysbios.family.arm.a8.mmuTableSection"].loadSegment = "SRAM_HI"; Program.sectMap["ti.sysbios.family.arm.a8.mmuTableSection"].type = "NOLOAD";
Which resulted in following elf sections:
Idx Name Size VMA LMA File off Algn 0 .c_int00 000000b4 80000000 80000000 00010000 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE 1 .stack 00020000 800000b8 800000b8 000100b4 2**3 ALLOC 2 .rodata 00006e39 800200b8 800200b8 000300b8 2**3 CONTENTS, ALLOC, LOAD, READONLY, DATA 3 .vectors 00000040 80027000 80027000 00037000 2**10 CONTENTS, ALLOC, LOAD, READONLY, DATA 4 .biosheap 01800000 80027040 80027040 00037040 2**3 ALLOC 5 ti.sysbios.family.arm.a8.mmuTableSection 00004000 402f4000 402f4000 00004000 2**14 ALLOC 6 xdc.meta 000000e2 81827040 81827040 0187392c 2**2 CONTENTS, READONLY 7 .text 00031898 81827130 81827130 01837130 2**4 CONTENTS, ALLOC, LOAD, READONLY, CODE 8 .ARM.exidx 00000008 818589c8 818589c8 018689c8 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 9 .data 0000af5c 818589d0 818589d0 018689d0 2**2 CONTENTS, ALLOC, LOAD, DATA 10 .bss 0002f748 81863930 81863930 0187392c 2**3 ALLOC 11 .comment 0000007f 00000000 00000000 01873a0e 2**0 CONTENTS, READONLY 12 .ARM.attributes 0000003b 00000000 00000000 01873a8d 2**0 CONTENTS, READONLY
You can notice that .text section is at the offset 0x01827130 from beginning of .c_int00, which is also text. Becayse of that, all space between .text and .c_init00 not allocated for some section, was filled with 0. Linker script generator puts all sections, that are needed, but not defined in .cfg file after all those defined in .cfg file.
So solution was to define all sections that will occur in output file in right order in .cfg file:
Program.sectMap[".c_int00"] = new Program.SectionSpec(); Program.sectMap[".c_int00"].loadAddress = 0x80000000; Program.sectMap[".c_int00"].runAddress = 0x80000000; Program.sectMap[".text"] = new Program.SectionSpec(); Program.sectMap[".text"].loadSegment = "DDR2"; Program.sectMap[".nonCachedRAM"] = new Program.SectionSpec(); Program.sectMap[".nonCachedRAM"].loadSegment = "OCMC_SRAM"; Program.sectMap[".xAltera"] = new Program.SectionSpec(); Program.sectMap[".xAltera"].loadSegment = "ALTERA_MEM"; Program.sectMap[".xAltera"].type = "NOLOAD"; Program.sectMap[".rodata"] = new Program.SectionSpec(); Program.sectMap[".rodata"].loadSegment = "DDR2"; Program.sectMap[".neardata"] = new Program.SectionSpec(); Program.sectMap[".neardata"].loadSegment = "DDR2"; Program.sectMap["ti.sysbios.family.arm.a8.mmuTableSection"] = new Program.SectionSpec(); Program.sectMap["ti.sysbios.family.arm.a8.mmuTableSection"].loadSegment = "SRAM_HI"; Program.sectMap["ti.sysbios.family.arm.a8.mmuTableSection"].type = "NOLOAD"; Program.sectMap["xdc.meta"] = new Program.SectionSpec(); Program.sectMap["xdc.meta"].loadSegment = "DDR2"; Program.sectMap[".ARM.exidx"] = new Program.SectionSpec(); Program.sectMap[".ARM.exidx"].loadSegment = "DDR2"; Program.sectMap[".data"] = new Program.SectionSpec(); Program.sectMap[".data"].loadSegment = "DDR2"; Program.sectMap[".bss"] = new Program.SectionSpec(); Program.sectMap[".bss"].loadSegment = "DDR2"; Program.sectMap[".biosheap"] = new Program.SectionSpec(); Program.sectMap[".biosheap"].runSegment = "DDR2" Program.sectMap[".biosheap"].type = "NOLOAD"; Program.sectMap[".stack"] = new Program.SectionSpec(); Program.sectMap[".stack"].loadSegment = "DDR2"; Program.sectMap[".stack"].type = "NOLOAD";
And resulting binary file has size 276616 bytes and elf sections looks like:
Idx Name Size VMA LMA File off Algn 0 .c_int00 000000b4 80000000 80000000 00010000 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE 1 .text 0003189c 800000c0 800000c0 000100c0 2**4 CONTENTS, ALLOC, LOAD, READONLY, CODE 2 .rodata 00006e39 80031960 80031960 00041960 2**3 CONTENTS, ALLOC, LOAD, READONLY, DATA 3 .vectors 00000040 80038800 80038800 00048800 2**10 CONTENTS, ALLOC, LOAD, READONLY, DATA 4 ti.sysbios.family.arm.a8.mmuTableSection 00004000 402f4000 402f4000 00004000 2**14 ALLOC 5 xdc.meta 000000e2 80038840 80038840 00048840 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 6 .ARM.exidx 00000008 80038924 80038924 00048924 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 7 .data 0000af5c 8003892c 8003892c 0004892c 2**2 CONTENTS, ALLOC, LOAD, DATA 8 .bss 0002f748 80043888 80043888 00053888 2**3 ALLOC 9 .biosheap 01800000 80072fd0 80072fd0 00053888 2**3 ALLOC 10 .stack 00020000 81872fd0 81872fd0 00053888 2**3 ALLOC 11 .comment 0000007f 00000000 00000000 00053888 2**0 CONTENTS, READONLY 12 .ARM.attributes 0000003b 00000000 00000000 00053907 2**0 CONTENTS, READONLY
So thank you for help, it directed me to right solution.