zero:ing of UNINITIALIZED ELF-sections

Niklas Persson

I'm having an issue with the Cortex-M3 ELF-linker, the one supplied with the 5.1.0.06 version of CCS.

My goal is to skip zero:ing of uninitialized sections, i.e. zero:ing of global buffers in memory. If I use linker flag --zero_init=off, I see that the linker removes the zero_init blocks present in .cinit, and my program starts up much faster once loaded, so far so good.

Unfortunately, --zero_init seems to have no effect on the ELF-binary itself . The program headers in the output ELF-file is identical with --zero_init=off and --zero_init=on, so my loader still zeros uninitialized data.

Is this a bug in the linker?, if not, is there another why to skip loading uninitialized sections?

BR
Niklas

over 13 years ago

0 David Friedland over 13 years ago

TI__Mastermind 18320 points

Niklas,

Your issue does not appear to be really BIOS specific, so I am moving this thread to the Compiler Forum in hopes that it will get a faster response there.

Dave

0 George Mock over 13 years ago

TI__Guru**** 244710 points

Niklas Persson said:
Unfortunately, --zero_init seems to have no effect on the ELF-binary itself . The program headers in the output ELF-file is identical with --zero_init=off and --zero_init=on, so my loader still zeros uninitialized data.

I cannot reproduce this result. Please show me the lines from the .map file which show the composition of the .cinit section. And show me that for both builds, with --zero_init=off and --zero_init=on.

Thanks and regards,

-George

0 Niklas Persson over 13 years ago in reply to George Mock

Intellectual 700 points

Hi George

I wanted to send you a couple of files, but I don't understand this web-tool, doesn't seem to support attaching more than 1 file (and it has to be .txt). Is there an ftp or something else where I can upload the files?.

diff between .map-files

--zero_init=off
============

LINKER GENERATED COPY TABLES

__TI_cinit_table @ 811309e4 records: 1, size/record: 8, table size: 8
.data: load addr=81130470, load size=0000056b bytes, run addr=8112f9f8, run size=00000a78 bytes, compression=rle

LINKER GENERATED HANDLER TABLE

__TI_handler_table @ 811309dc records: 2, size/record: 4, table size: 8
index: 0, handler: __TI_decompress_rle24
index: 1, handler: __TI_decompress_none

--zero_init=on
============

__TI_cinit_table @ 81130a08 records: 3, size/record: 8, table size: 24
.data: load addr=81130480, load size=0000056c bytes, run addr=8112fa08, run size=00000a78 bytes, compression=rle
.EasyLinkQueues: load addr=811309f8, load size=00000008 bytes, run addr=82000000, run size=00061e80 bytes, compression=zero_init
.bss: load addr=81130a00, load size=00000008 bytes, run addr=81000000, run size=0012204c bytes, compression=zero_init

LINKER GENERATED HANDLER TABLE

__TI_handler_table @ 811309ec records: 3, size/record: 4, table size: 12
index: 0, handler: __TI_zero_init
index: 1, handler: __TI_decompress_rle24
index: 2, handler: __TI_decompress_none

My global variable resides at address 0x82000000 and is 0x61e80 bytes long, and you can see it in program header 8 below (printed from the elf file)

Program headers in binary, zero_init=on

**********************
* Program Header 00 *
**********************
p_type =0x00000001
p_offset =0x00000034
p_vaddr =0x00000000
p_paddr =0x00000000
p_filesz =0x0000003c
p_memsz =0x0000003c
p_flags =0x00000005
p_align =0x00000004

**********************
* Program Header 01 *
**********************
p_type =0x00000001
p_offset =0x00000070
p_vaddr =0x00000400
p_paddr =0x00000400
p_filesz =0x00000140
p_memsz =0x00000140
p_flags =0x00000004
p_align =0x00000004

**********************
* Program Header 02 *
**********************
p_type =0x00000001
p_offset =0x000001b0
p_vaddr =0x000007f0
p_paddr =0x000007f0
p_filesz =0x00000000
p_memsz =0x00000010
p_flags =0x00000006
p_align =0x00000004

**********************
* Program Header 03 *
**********************
p_type =0x00000001
p_offset =0x000001b0
p_vaddr =0x81000000
p_paddr =0x81000000
p_filesz =0x00000000
p_memsz =0x0012204c
p_flags =0x00000006
p_align =0x00000008

**********************
* Program Header 04 *
**********************
p_type =0x00000001
p_offset =0x000001b0
p_vaddr =0x8112204c
p_paddr =0x8112204c
p_filesz =0x0000c9b9
p_memsz =0x0000c9b9
p_flags =0x00000005
p_align =0x00000004

**********************
* Program Header 05 *
**********************
p_type =0x00000001
p_offset =0x0000cb6c
p_vaddr =0x8112ea08
p_paddr =0x8112ea08
p_filesz =0x00000000
p_memsz =0x00001000
p_flags =0x00000006
p_align =0x00000004

**********************
* Program Header 06 *
**********************
p_type =0x00000001
p_offset =0x0000cb70
p_vaddr =0x8112fa08
p_paddr =0x8112fa08
p_filesz =0x00000000
p_memsz =0x00000a78
p_flags =0x00000006
p_align =0x00000008

**********************
* Program Header 07 *
**********************
p_type =0x00000001
p_offset =0x0000cb70
p_vaddr =0x81130480
p_paddr =0x81130480
p_filesz =0x000005a0
p_memsz =0x000005a0
p_flags =0x00000004
p_align =0x00000008

**********************
* Program Header 08 *
**********************
p_type =0x00000001
p_offset =0x0000d180
p_vaddr =0x82000000
p_paddr =0x82000000
p_filesz =0x00000000
p_memsz =0x00061e80
p_flags =0x00000006
p_align =0x00000080

Program headers in binary, zero_init=off

**********************
* Program Header 04 *
**********************
p_type =0x00000001
p_offset =0x000001b0
p_vaddr =0x8112204c
p_paddr =0x8112204c
p_filesz =0x0000c9a5
p_memsz =0x0000c9a5
p_flags =0x00000005
p_align =0x00000004

**********************
* Program Header 05 *
**********************
p_type =0x00000001
p_offset =0x0000cb58
p_vaddr =0x8112e9f4
p_paddr =0x8112e9f4
p_filesz =0x00000000
p_memsz =0x00001000
p_flags =0x00000006
p_align =0x00000004

**********************
* Program Header 06 *
**********************
p_type =0x00000001
p_offset =0x0000cb58
p_vaddr =0x8112f9f8
p_paddr =0x8112f9f8
p_filesz =0x00000000
p_memsz =0x00000a78
p_flags =0x00000006
p_align =0x00000008

**********************
* Program Header 07 *
**********************
p_type =0x00000001
p_offset =0x0000cb58
p_vaddr =0x81130470
p_paddr =0x81130470
p_filesz =0x0000057c
p_memsz =0x0000057c
p_flags =0x00000004
p_align =0x00000008

**********************
* Program Header 08 *
**********************
p_type =0x00000001
p_offset =0x0000d100
p_vaddr =0x82000000
p_paddr =0x82000000
p_filesz =0x00000000
p_memsz =0x00061e80
p_flags =0x00000006
p_align =0x00000080

Niklas

0 George Mock over 13 years ago in reply to Niklas Persson

TI__Guru**** 244710 points

Well, everything appears normal. There is nothing to be concerned about here. I see that the --zero_init=off build does not use the __TI_zero_init handler function, but the --zero_init=on build does. Moreover, I see all sorts of expected differences in the program headers. Attached below is a screenshot of how they look in Beyond Compare.

Thanks and regards,

-George

0 Archaeologist over 13 years ago

TI__Guru* 84225 points

What loader are you using?

0 Niklas Persson over 13 years ago in reply to George Mock

Intellectual 700 points

Hi again

Start up time is critical for us, and I would therefore like to avoid the zeroing of my own unitialized sections when I load my software. My loader goes through all program headers in the ELF file and loads each block specified there. Therefore, it will also zero the memory specified by program header 3 and 8, where my global uninitialized vectors reside. As you can see, program header 3 and 8 have the same p_filesz and p_memsz elements for both zero_init=off and zero_init=on, so the loader will zero my vectors regardless if I use use zero_init=off or zero_init=on.

So, is there any way for me to avoid the zeroing of my own unitialized vectors in my binary?

BR
Niklas

0 Niklas Persson over 13 years ago in reply to Archaeologist

Intellectual 700 points

I'm using a "home made" elf2bin converter that extracts the program headers and the raw data from the .out ELF-file, and create a binary with just that. My "home made" loader then just parses the program header and loads the raw data ( and zeros the p_memsz - p_filesz block following the raw data)

Niklas

0 Cody Addison over 13 years ago in reply to Niklas Persson

TI__Expert 4540 points

Niklas,

I think your problem stems from the fact that the segments you want to not zero initialize have PT_LOAD segments at all. We support a NOLOAD section type that will cause the section to not be placed in a PT_LOAD segment. The syntax for this is:

SECTIONS
{
.bss {} > RAM type=NOLOAD
}

Please try this option and see if it addresses your problem.

0 Niklas Persson over 13 years ago in reply to Cody Addison

Intellectual 700 points

This was very helpful, thanks for the help

BR
Niklas

Code Composer Studio™︎

Code Composer Studio forum

zero:ing of UNINITIALIZED ELF-sections