Uninitialized sections in .map file and multiple sections

Chris Johnson1

Hello,

First off, we are working with a C6678 device using CCS 5.2, BIOS 6.33 and xdctools 3.23.

We have been working on moving a C6415 project to the C6678. One of the things that has come up is after creating a BIOS6 project and making necessary changes to the code to get a build-able project, the .map file shows two .cinit sections and the first two sections (one of which is one of the .cinit sections) show up as UNINITIALIZED. Here is the start of the section allocation map to show what I am referring to:

SECTION ALLOCATION MAP

output                                  attributes/
section   page    origin      length       input sections
-------- ---- ---------- ----------   ----------------
.init_array
*          0    0080c200    00000000     UNINITIALIZED

.cinit     0    0080c200    00000000     UNINITIALIZED

Another issue we face with this transition is having to switch from COFF format to ELF format .out files. We are in the process of porting the TI ELF loader to host-side C/C++ software. So far, we see multiple of 2 (byte) and multiple of 4 segment sizes. Should we also code to expect odd byte segment sizes? Can that happen with C66x code generation?

Regards,

Chris

Signalogic

over 13 years ago

0 Archaeologist over 13 years ago

TI__Guru* 84285 points

The length of those two sections is 0, so whether they are initialized or not is irrelevant. It's very unusual for .cinit to be of size 0; does this program have any global/static data objects?

Yes, I think segments can have odd size or alignment.

0 Chris Johnson1 over 13 years ago in reply to Archaeologist

Expert 1715 points

Well there is a second .cinit section further down that isn't size 0 and is initialized with data in it. I'm puzzled as to why there are two .cinit sections but since the first one is size 0 and uinitialized maybe it's not an issue.

Thanks,

Chris

Signalogic

0 Archaeologist over 13 years ago in reply to Chris Johnson1

TI__Guru* 84285 points

There should not be two .cinit sections in any executable file. The existence of the zero-length .cinit section is probably an asymptomatic bug, as long as all of the special .cinit symbols (e.g. __TI_CINIT_Base) point into the non-zero-length .cinit section. I cannot guess why there are two .cinit sections without a test case.

0 Chris Johnson1 over 13 years ago in reply to Archaeologist

Expert 1715 points

I see that __TI_cinit_table is in the non-zero-length .cinit section. I noticed that we had a section declaration for .cinit in our .cmd file. I commented out this line and the zero-length .cinit section went away while the non-zero-length .cinit section had no change. Is it no longer necessary to declare a .cinit section in the .cmd file with newer versions of software or when using ELF files?

Thanks,

Chris

Signalogic

0 Archaeologist over 13 years ago in reply to Chris Johnson1

TI__Guru* 84285 points

It's still necessary to place the .cinit section (.cinit > MEM), but you should not create a .cinit section in the linker command file. Could you show me the "section declaration for .cinit" portion of your linker command file?

0 George Mock over 13 years ago in reply to Chris Johnson1

TI__Guru**** 253380 points

BIOS auto-generates a linker command file (LCF) which probably creates a .cinit section. It appears you provide a second LCF which also creates a .cinit section. If that is correct, that explains why you don't need to create a .cinit section in the second LCF.

Thanks and regards,

-George

0 Chris Johnson1 over 13 years ago in reply to George Mock

Expert 1715 points

Hmm, I am using my own LCF and in it I have this code:

SECTIONS {

...
.cinit > IPRAM
...

}

I'm not sure if I'm using all the correct terminology. This should only be placing the .cinit section into IPRAM but since this is a second LCF to the LCF created by BIOS a second .cinit section is being created. This is what I understand based on the last two posts. Is my understanding correct? Any ideas on why the other uninitialized section shows up in the .map file? I don't have an .init_array section in my LCF.

Thanks,

Chris

Signalogic

0 George Mock over 13 years ago in reply to Chris Johnson1

TI__Guru**** 253380 points

If you are good with where BIOS is placing the .cinit section, then just remove it from your LCF.

Thanks and regards,

-George

0 Chris Johnson1 over 13 years ago in reply to George Mock

Expert 1715 points

George,

I don't see any issues with where BIOS is placing the .cinit section right now, but for future reference, if there was an issue with where BIOS was placing the .cinit section how would I change this?

Regards,

Chris

Signalogic

0 ScottG over 13 years ago in reply to Chris Johnson1

TI__Mastermind 26780 points

Chris,

You can steer individual sections using the Program.sectMap configuration parameter. For example, to place .cinit into a "FLASH2" region you can add something like this to the application’s .cfg configuration file:

Program.sectMap[".cinit"] = new Program.SectionSpec();
Program.sectMap[".cinit"].loadSegment = "FLASH2";

This is technique is described here: http://rtsc.eclipse.org/docs-tip/Memory_Management#Controlling_the_generated_linker_command_file

Scott

Code Composer Studio™︎

Code Composer Studio forum

Uninitialized sections in .map file and multiple sections