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.

CGT 8.1.2 for C6000 not initializing static variables (even in EABI mode )

Other Parts Discussed in Thread: SYSBIOS, OMAPL138

Hey,


it seems to be expected that static variables aren't initialized in COFF mode, but all the sources seem to assume that it is different by default for the EABI compiler. Yet I'm still experiencing the problem with the current compiler set to EABI.


I'm running CCS6.2 with XDCtools 3.25.3.72 and sys/bios 6.35.6.56, targeting OMAP L138.


There is custom linker script added to the project in addition to the generated ones. The variables not being initialized do NOT belong to the custom defined sections:

SECTIONS
{

// !!! IMPORTANT: IROM is not programmable on OMAP-L138 !!!

// -------------  ACQ hwi stuff into L2 ------------------------

.text_fast: { *.*(.text.fast*) } > IRAM
.data_fast: { *.*(.data.fast*) } > IRAM
.data_quick: { *.*(.data.quick*) } > L3_CBA_RAM

// ------------- Kernel stuff into fast memory -----------------

/* place all the knl APIs in IRAM */
.knl: { *.*(.text:*ti_sysbios_knl*) } > IRAM

/* place all the Hwi APIs in IROM */
.hwi: { *.*(.text:*ti_sysbios*_Hwi_*) } > IRAM

/* place the remainder of the SYS/BIOS APIs in DDR */
.sysbios: { *.*(.text:*ti_sysbios*) } > DDR

}

The linker script generated by XDCtools under Debug/configPkg looks as follows (I've removed the commented out stuff to reduce size):

-l"/home/maverick/ccsworkspace/_SCARY_PROJECT_NAME_/Debug/configPkg/package/cfg/sysbios_pe674.oe674"
-l"/home/maverick/ti/syslink_2_21_03_11/packages/ti/syslink/ipc/rtos/lib/debug/ti.syslink.ipc.rtos.ae674"
-l"/home/maverick/ccsworkspace/_SCARY_PROJECT_NAME_/src/ipc/ipc.ae674"
-l"/home/maverick/ccsworkspace/_SCARY_PROJECT_NAME_/src/sysbios/sysbios.ae674"
-l"/home/maverick/ti/syslink_2_21_03_11/packages/ti/syslink/utils/rtos/bios6/lib/debug/ti.syslink.utils.rtos.bios6.ae674"
-l"/home/maverick/ti/edma3_lld_02_12_00_20/packages/ti/sdo/edma3/drv/lib/674/debug/edma3_lld_drv.ae674"
-l"/home/maverick/ti/edma3_lld_02_12_00_20/packages/ti/sdo/edma3/rm/lib/omapl138-evm/674/debug/edma3_lld_rm.ae674"
-l"/home/maverick/ti/xdctools_3_25_03_72/packages/ti/targets/rts6000/lib/ti.targets.rts6000.ae674"
-l"/home/maverick/ti/xdctools_3_25_03_72/packages/ti/targets/rts6000/lib/boot.ae674"

--retain="*(xdc.meta)"


--args 0x64
-heap  0x0
-stack 0x1000

MEMORY
{
    IROM (RX) : org = 0x11700000, len = 0x100000
    IRAM (RWX) : org = 0x11800000, len = 0x20000
    L3_CBA_RAM (RWX) : org = 0x80000000, len = 0x20000
    DDR (RWX) : org = 0xc6800000, len = 0x1800000
    DDR_SHARED (RWX) : org = 0xc6000000, len = 0x800000
}


SECTIONS
{
    ti.sdo.ipc.SharedRegion_0:  { . += 0x800000;} run > 0xc6000000, type = NOLOAD

    ti_sdo_ipc_init: load > DDR, type = NOINIT 
}



    /*
     *  Set entry point to the HWI reset vector 0 to automatically satisfy
     *  any alignment constraints for the boot vector.
     */
    -eti_sysbios_family_c64p_Hwi0

    /*
     * We just modified the entry point, so suppress the "entry point symbol other
     * than _c_int00 specified" warning.
     */
    --diag_suppress=10063

    /* Add the flags needed for SysLink ELF build. */
    --dynamic
    --retain=_Ipc_ResetVector

    /* 
     * Added symbol to ensure SysBios code is retained when entrypoint is
     * something other than _c_int00.  This workaround will be removed once
     * fixed in the SysBios package
     */
    -u _c_int00


/*
 * symbolic aliases for static instance objects
 */
xdc_runtime_Startup__EXECFXN__C = 1;
xdc_runtime_Startup__RESETFXN__C = 1;
TSK_idle = ti_sysbios_knl_Task_Object__table__V + 228;

SECTIONS
{
    .text: load >> DDR
    .ti.decompress: load > DDR
    .stack: load > L3_CBA_RAM
    GROUP: load > DDR
    {
        .bss:
        .neardata:
        .rodata:
    }
    .cinit: load > DDR
    .pinit: load >> DDR
    .init_array: load > DDR
    .const: load >> DDR
    .data: load >> DDR
    .fardata: load >> DDR
    .switch: load >> DDR
    .sysmem: load > DDR
    .far: load >> DDR
    .args: load > DDR align = 0x4, fill = 0 {_argsize = 0x64; }
    .cio: load >> DDR
    .ti.handler_table: load > DDR
    .c6xabi.exidx: load > DDR
    .c6xabi.extab: load >> DDR
    .heap: load > DDR
    .vecs: load > DDR
    .plt: load > DDR
    xdc.meta: load > DDR, type = COPY

}



It seems to be an option to add "fill" attribute to the .bss and other sections via sysbios.cfg, but considering the TI documentation says I shouldn't have to change anything for the EABI compiler - I'm confused. The compiler and linker settings seem to be normal:

Compiler flags:
-mv6740 --abi=eabi -Ooff --include_path="/home/maverick/ti/ti-cgt-c6000_8.1.2/include" -g --c99 --define=omapl138 --diag_warning=225 --display_error_number --diag_wrap=off

Linker flags:
-mv6740 --abi=eabi -Ooff -g --c99 --define=omapl138 --diag_warning=225 --display_error_number --diag_wrap=off -z -m"_SCARY_PROJECT_NAME_.map" --heap_size=0x300000 --stack_size=0x1000 -i"/home/maverick/ti/ti-cgt-c6000_8.1.2/lib" -i"/home/maverick/ti/ti-cgt-c6000_8.1.2/include" --reread_libs --define=DSP_CORE=1 --diag_wrap=off --warn_sections --display_error_number --xml_link_info="_SCARY_PROJECT_NAME_linkInfo.xml" --rom_model --zero_init=on



Thank you in advance,
Mav

  • Ilya Elenskiy said:
    Yet I'm still experiencing the problem with the current compiler set to EABI.

    Exactly what do you see that makes you think these variables are not initialized?  How do you see it?

    Thanks and regards,

    -George

  • I have a variable defined like "static SomeStructType *moduleScopeVar". In main a function is called which does something like "if (moduleScopeVar != NULL) free(moduleScopeVar);". The free gets called and the debugger also shows a non-zero value if the variables are investigated with. It is right at the beginning of main, so an accidental overwrite beforehand is unlikely.

  • Take a look at the linker map file.  Find the lines similar to these ...

    LINKER GENERATED COPY TABLES
    
    __TI_cinit_table @ 0000fd78 records: 2, size/record: 8, table size: 16
    	.fardata: load addr=0000fcf8, load size=0000006a bytes, run addr=0000f600, run size=0000031c bytes, compression=rle
    	.far: load addr=0000fd70, load size=00000008 bytes, run addr=0000f920, run size=00000148 bytes, compression=zero_init

    Look at the line(s) with compression=zero_init.  In the example above, this line says zero initialization occurs starting at the run addr of 0xf920, and going for the run size of 0x148 bytes.  Is there a zero_init entry which covers the address for the variable moduleScopeVar?

    Thanks and regards,

    -George

  • It seems like my map file does not contain something like this. Search finds neither a "copy tables" section, nor anything containing "cinit_table". In fact, the only reference to .cinit is an empty section at the beginning of the DDR...
  • That's very odd.  I have no idea how that happened.  I'd like to reproduce it, then file a formal entry in the SDOWP system, to have our development experts work out how this occurred.  

    I hope this is organized as a CCS project.  That means you only have to submit the project.  It is a good guess you are not willing to post it to this forum thread.  Are you willing to send it just to me?

    Thanks and regards,

    -George

  • It's always a week before the deadline when such weird stuff starts to happen =) Unfortunately, I think I won't be able to send the whole project (I mean the sources beyond the project files like .cproject and sysbios.cfg) without OK from some other people...

    However now that I know what I'm looking for I'll try to see if I can figure out what has triggered it, I'll let you know if I can come up with a minimal example of what happened.

    Thank you very much for you quick help!

    Ilya
  • What I've found so far is that adding xdc.useModule('ti.syslink.ipc.rtos.Syslink'); to sysbios.cfg causes the section in the map file to disappear and addresses of __TI_CINIT_Base and __TI_CINIT_Limit to become UNDEFINED. Syslink seems to work OK otherwise..

    Syslink (2.21.03.11) has the correct CGT path in its products.mak and compiles fine.. Any hints what I should look into?

  • OK, i've found the problem I guess. In Debug/configPkg/linker.cmd there are the following lines:

    /* Content from ti.syslink.ipc.rtos (ti/syslink/ipc/rtos/linkcmd.xdt): */
    /*
    * Set entry point to the HWI reset vector 0 to automatically satisfy
    * any alignment constraints for the boot vector.
    */
    -eti_sysbios_family_c64p_Hwi0
    /*
    * We just modified the entry point, so suppress the "entry point symbol other
    * than _c_int00 specified" warning.
    */
    --diag_suppress=10063
    /* Add the flags needed for SysLink ELF build. */
    --dynamic
    --retain=_Ipc_ResetVector
    /*
    * Added symbol to ensure SysBios code is retained when entrypoint is
    * something other than _c_int00. This workaround will be removed once
    * fixed in the SysBios package
    */
    -u _c_int00


    What is "--dynamic" doing here? Removing it results in the expected linker-generated section in the map file and a proper .bss initialization.

    Other people use syslink, so how could it possibly work for everyone else?

    EDIT: The downside of not having --dynamic turns out to be syslink loader not being able to find _Ipc_ResetVector in the binary. The symbol address has to be provided manually to load callback as a workaround.

  • I don't have any expertise with syslink.  But these changes appear wrong to me.  I suspect there is a better way to handle it.  That being the case, this thread is being moved to OMAP devices forum.

    Thanks and regards,

    -George

  • SYSLINK code has not been validated with CGT 8.1.2. I would recommend reverting the project to use ealier version of CGT that is recommended in the Release notes to avoid such issues.

    CCS ships with CGT 7.4.x and CGT 8.1.2 . I would first try to see if CGT 7.4.x resolves this issue. If not, I would stick to the version with which the SYSLINK was verified.

    Regards,
    Rahul
  • It would most likely solve the problem, but CGT 7.4.19 doesn't support C99, which is the standard for our whole codebase so far, so I can't compile it just like that and I would prefer to avoid rewriting everything just to meet an obsolete C standard.

    Compiling syslink with a cgt 7.x but the project with 8.x does not make any difference.

    I've hoped the compiler people may come up with suggestion how to get a proper initialization in CGT 8.x with "--dynamic" enabled.

    Thank you for your time and your fast replys so far!