• State Resolved
  • Locked Locked
  • Replies 10 replies
  • Subscribers 53 subscribers
  • Views 1695 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Uninitialized sections in .map file and multiple sections

Chris Johnson1
Expert 1715 points

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

  • 0
    TI__Guru* 84225 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 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 in reply to Chris Johnson1
    TI__Guru* 84225 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 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 in reply to Chris Johnson1
    TI__Guru* 84225 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 in reply to Chris Johnson1
    TI__Guru**** 244930 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 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 in reply to Chris Johnson1
    TI__Guru**** 244930 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 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 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