CCS/OMAP-L138: Huge COFF .out file

Amir Azadi

Expert 1105 points

Part Number: OMAP-L138

Tool/software: Code Composer Studio

Hi,

I have project running NDK on C674x side of omap-l138 , the output file was always around 300 KBytes.

Recently I have added http server support to it. The output file went huge! It is around 26Mbytes now!

I did not change nor add anything to linker.cmd file.

I think it is something with .far section. For some reason I don't know why, it inserts padding of size 0x17e4bae filled with "A" in the .far section.

Here is the output of % ofd6x --obj_display=none,sections MyApp.out

OBJECT FILE:  MyApp.out

 Section Information

    id name                      load addr  run addr        size align alloc
    -- ----                      ---------  --------        ---- ----- -----
     1 $build.attributes         0x00000000 0x00000000      0x24     1   N  
     2 .stack                    0xc17e4bb0 0xc17e4bb0  0x100000     8   Y  
     3 .bss                      0xc1938e00 0xc1938e00     0x2cc     8   Y  
     4 .cinit                    0xc1935a40 0xc1935a40    0x2e24     8   Y  
     5 .pinit                    0x00000000 0x00000000       0x0     1   N  
     6 .data                     0xc0000000 0xc0000000       0x0     1   Y  
     7 .sysmem                   0x00000000 0x00000000       0x0     1   N  
     8 .args                     0xc0000000 0xc0000000       0x0     4   N  
     9 xdc.meta                  0xc0000000 0xc0000000      0xe7     8   N  
    10 .text:_c_int00            0x80010000 0x80010000      0xe0    32   Y  
    11 .debug_info               0x00000000 0x00000000   0xf2c2a     1   N  
    12 .debug_frame              0x00000000 0x00000000    0x44e9     1   N  
    13 .debug_line               0x00000000 0x00000000   0x14596     1   N  
    14 .text                     0xc18e4bc0 0xc18e4bc0   0x47120    32   Y  
    15 .const.1                  0xc18e4bb0 0xc18e4bb0      0x10     4   Y  
    16 .const.2                  0xc192bce0 0xc192bce0    0x9d5e     8   Y  
    17 .switch                   0xc1938864 0xc1938864     0x37c     4   Y  
    18 .far                      0xc0000000 0xc0000000 0x17e4bae   128   Y  
    19 .cio                      0xc19390cc 0xc19390cc     0x120     4   Y  
    20 .vecs                     0xc1938c00 0xc1938c00     0x200  1024   Y  
    21 .debug_abbrev             0x00000000 0x00000000     0xc3e     1   N

And in the output of % ofd6x -x -g MyApp.out the .far section is filled with some thirty million "A"

         <section>
            <name>.far</name>
            <index>0x12</index>
            <physical_addr>0xc0000000</physical_addr>
            <virtual_addr>0xc0000000</virtual_addr>
            <raw_data_size>0x17e4bae</raw_data_size>
            <reloc_count>0x0</reloc_count>
            <line_count>0x0</line_count>
            <addr_size>0x1</addr_size>
            <alignment>0x80</alignment>
            <data>true</data>
            <file_offsets>
               <raw_data_ptr>0x15fce4</raw_data_ptr>
               <reloc_ptr>0x0</reloc_ptr>
               <line_ptr>0x0</line_ptr>
            </file_offsets>
            <raw_data>
  AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Repeated around 460,000 lines!

CCS 5.3

CGT 7.4.1

XDC 3.24.5.48

SYS/BIOS 6.34.2.18

NDK 2.21.0.32

Any suggestions?

over 7 years ago

0 George Mock over 7 years ago

TI__Guru**** 253410 points

Aidin Haddadi said:
it inserts padding of size 0x17e4bae filled with "A" in the .far section

What you see in the OFD XML file is not the actual binary values, but the MIME base64 encoding of those binary values. The character A represents the binary value 0. So, your .far section is filled with a large number of bytes with the value 0.

The .far section is uninitialized. But in your case, it is initialized, and filled with 0. Typically, this occurs because some input section named .far, from one object file, is initialized. We need to find out which object file supplies this initialized .far section.

Please attach your map file to your next post. So the forum will accept it, add the file extension .txt.

Thanks and regards,

-George

0 Amir Azadi over 7 years ago in reply to George Mock

Expert 1105 points

Hi George

Thank you very much for your quick reply. There are [fill = 0] at every line in .far section.

MyApp.map.txt

Fullscreen linker.cmd.txt Download

/*
 * Do not modify this file; it is automatically generated from the template
 * linkcmd.xdt in the ti.targets package and will be overwritten.
 */

/*
 * put '"'s around paths because, without this, the linker
 * considers '-' as minus operator, not a file name character.
 */


-l"D:\My PC Folders\workspace_v5_3\BlureFiCM_test\Debug\configPkg\package\cfg\CoreClient_p674.o674"
-l"C:\ti\nsp_1_10_00_03\packages\ti\drv\omapl138\lib\debug\ti.drv.omapl138.a674"
-l"C:\ti\ndk_2_21_00_32\packages\ti\ndk\miniPrintf\lib\miniPrintf.a674"
-l"C:\ti\ndk_2_21_00_32\packages\ti\ndk\hal\ser_stub\lib\hal_ser_stub.a674"
-l"C:\ti\ndk_2_21_00_32\packages\ti\ndk\hal\timer_bios\lib\hal_timer_bios.a674"
-l"C:\ti\ndk_2_21_00_32\packages\ti\ndk\os\lib\os.a674"
-l"C:\ti\ndk_2_21_00_32\packages\ti\ndk\hal\userled_stub\lib\hal_userled_stub.a674"
-l"C:\ti\ndk_2_21_00_32\packages\ti\ndk\hal\eth_stub\lib\hal_eth_stub.a674"
-l"C:\ti\ndk_2_21_00_32\packages\ti\ndk\tools\cgi\lib\cgi.a674"
-l"C:\ti\ndk_2_21_00_32\packages\ti\ndk\tools\hdlc\lib\hdlc.a674"
-l"C:\ti\ndk_2_21_00_32\packages\ti\ndk\tools\console\lib\console_min_ipv4.a674"
-l"C:\ti\ndk_2_21_00_32\packages\ti\ndk\netctrl\lib\netctrl_ipv4.a674"
-l"C:\ti\ndk_2_21_00_32\packages\ti\ndk\nettools\lib\nettool_ipv4.a674"
-l"C:\ti\ndk_2_21_00_32\packages\ti\ndk\tools\servers\lib\servers_min_ipv4.a674"
-l"C:\ti\ndk_2_21_00_32\packages\ti\ndk\stack\lib\stk_ppp.a674"
-l"C:\ti\bios_6_34_02_18\packages\ti\sysbios\lib\sysbios\instrumented\sysbios.a674"
-l"C:\ti\xdctools_3_24_05_48\packages\ti\targets\rts6000\lib\ti.targets.rts6000.a674"
-l"C:\ti\xdctools_3_24_05_48\packages\ti\targets\rts6000\lib\boot.a674"


/* function aliases */
/* ignore error about def and ref in the same file */
--diag_remark=10268
--symbol_map _xdc_runtime_Text_putSite__E=_xdc_runtime_Text_putSite__F
--symbol_map _xdc_runtime_Text_putLab__E=_xdc_runtime_Text_putLab__F
--symbol_map _ti_sysbios_family_c64p_EventCombiner_unused__E=_ti_sysbios_family_c64p_EventCombiner_unused__F
--symbol_map _ti_sysbios_family_c64p_Hwi_getStackInfo__E=_ti_sysbios_family_c64p_Hwi_getStackInfo__F
--symbol_map _xdc_runtime_Registry_getModuleId__E=_xdc_runtime_Registry_getModuleId__F
--symbol_map _xdc_runtime_Error_check__E=_xdc_runtime_Error_check__F
--symbol_map _xdc_runtime_System_sprintf_va__E=_xdc_runtime_System_sprintf_va__F
--symbol_map _xdc_runtime_Text_cordText__E=_xdc_runtime_Text_cordText__F
--symbol_map _xdc_runtime_Registry_findByName__E=_xdc_runtime_Registry_findByName__F
--symbol_map _xdc_runtime_System_avsprintf__E=_xdc_runtime_System_avsprintf__F
--symbol_map _xdc_runtime_Registry_getMask__E=_xdc_runtime_Registry_getMask__F
--symbol_map _xdc_runtime_Memory_getMaxDefaultTypeAlign__E=_xdc_runtime_Memory_getMaxDefaultTypeAlign__F
--symbol_map _xdc_runtime_Gate_leaveSystem__E=_xdc_runtime_Gate_leaveSystem__F
--symbol_map _ti_sysbios_family_c64p_EventCombiner_disableEvent__E=_ti_sysbios_family_c64p_EventCombiner_disableEvent__F
--symbol_map _xdc_runtime_Error_getSite__E=_xdc_runtime_Error_getSite__F
--symbol_map _xdc_runtime_System_printf_va__E=_xdc_runtime_System_printf_va__F
--symbol_map _xdc_runtime_System_vsprintf__E=_xdc_runtime_System_vsprintf__F
--symbol_map _xdc_runtime_Log_doPrint__E=_xdc_runtime_Log_doPrint__F
--symbol_map _xdc_runtime_SysMin_ready__E=_xdc_runtime_SysMin_ready__F
--symbol_map _xdc_runtime_SysMin_abort__E=_xdc_runtime_SysMin_abort__F
--symbol_map _xdc_runtime_Text_matchRope__E=_xdc_runtime_Text_matchRope__F
--symbol_map _xdc_runtime_SysMin_putch__E=_xdc_runtime_SysMin_putch__F
--symbol_map _xdc_runtime_Error_init__E=_xdc_runtime_Error_init__F
--symbol_map _xdc_runtime_Error_getId__E=_xdc_runtime_Error_getId__F
--symbol_map _xdc_runtime_Error_raiseX__E=_xdc_runtime_Error_raiseX__F
--symbol_map _xdc_runtime_Registry_getModuleName__E=_xdc_runtime_Registry_getModuleName__F
--symbol_map _xdc_runtime_System_putch__E=_xdc_runtime_System_putch__F
--symbol_map _xdc_runtime_System_abort__E=_xdc_runtime_System_abort__F
--symbol_map _xdc_runtime_Diags_setMask__E=_xdc_runtime_Diags_setMask__F
--symbol_map _xdc_runtime_System_aprintf_va__E=_xdc_runtime_System_aprintf_va__F
--symbol_map _xdc_runtime_Registry_getNextModule__E=_xdc_runtime_Registry_getNextModule__F
--symbol_map _xdc_runtime_Error_getData__E=_xdc_runtime_Error_getData__F
--symbol_map _xdc_runtime_Registry_isMember__E=_xdc_runtime_Registry_isMember__F
--symbol_map _xdc_runtime_Text_putMod__E=_xdc_runtime_Text_putMod__F
--symbol_map _xdc_runtime_Memory_getStats__E=_xdc_runtime_Memory_getStats__F
--symbol_map _xdc_runtime_Memory_free__E=_xdc_runtime_Memory_free__F
--symbol_map _xdc_runtime_Startup_exec__E=_xdc_runtime_Startup_exec__F
--symbol_map _ti_sysbios_family_c64p_EventCombiner_enableEvent__E=_ti_sysbios_family_c64p_EventCombiner_enableEvent__F
--symbol_map _xdc_runtime_Memory_query__E=_xdc_runtime_Memory_query__F
--symbol_map _xdc_runtime_System_vprintf__E=_xdc_runtime_System_vprintf__F
--symbol_map _ti_sysbios_gates_GateMutex_query__E=_ti_sysbios_gates_GateMutex_query__F
--symbol_map _ti_sysbios_hal_Hwi_getStackInfo__E=_ti_sysbios_hal_Hwi_getStackInfo__F
--symbol_map _ti_sysbios_family_c64p_EventCombiner_dispatchPlug__E=_ti_sysbios_family_c64p_EventCombiner_dispatchPlug__F
--symbol_map _xdc_runtime_SysMin_flush__E=_xdc_runtime_SysMin_flush__F
--symbol_map _xdc_runtime_System_exit__E=_xdc_runtime_System_exit__F
--symbol_map _xdc_runtime_Error_getCode__E=_xdc_runtime_Error_getCode__F
--symbol_map _xdc_runtime_Registry_findById__E=_xdc_runtime_Registry_findById__F
--symbol_map _xdc_runtime_Startup_rtsDone__E=_xdc_runtime_Startup_rtsDone__F
--symbol_map _ti_sysbios_gates_GateHwi_query__E=_ti_sysbios_gates_GateHwi_query__F
--symbol_map _xdc_runtime_Error_getMsg__E=_xdc_runtime_Error_getMsg__F
--symbol_map _xdc_runtime_Registry_addModule__E=_xdc_runtime_Registry_addModule__F
--symbol_map _xdc_runtime_Memory_alloc__E=_xdc_runtime_Memory_alloc__F
--symbol_map _xdc_runtime_System_flush__E=_xdc_runtime_System_flush__F
--symbol_map _xdc_runtime_System_avprintf__E=_xdc_runtime_System_avprintf__F
--symbol_map _xdc_runtime_Text_ropeText__E=_xdc_runtime_Text_ropeText__F
--symbol_map _xdc_runtime_Error_print__E=_xdc_runtime_Error_print__F
--symbol_map _xdc_runtime_Memory_calloc__E=_xdc_runtime_Memory_calloc__F
--symbol_map _ti_sysbios_family_c64p_EventCombiner_dispatch__E=_ti_sysbios_family_c64p_EventCombiner_dispatch__F
--symbol_map _xdc_runtime_System_asprintf_va__E=_xdc_runtime_System_asprintf_va__F
--symbol_map _xdc_runtime_System_atexit__E=_xdc_runtime_System_atexit__F
--symbol_map _xdc_runtime_SysMin_exit__E=_xdc_runtime_SysMin_exit__F
--symbol_map _xdc_runtime_Registry_findByNamePattern__E=_xdc_runtime_Registry_findByNamePattern__F
--symbol_map _xdc_runtime_Gate_enterSystem__E=_xdc_runtime_Gate_enterSystem__F
--symbol_map _xdc_runtime_Memory_valloc__E=_xdc_runtime_Memory_valloc__F


/* Elf symbols */
--symbol_map ___TI_STACK_BASE=__stack
--symbol_map ___TI_STACK_SIZE=__STACK_SIZE
--symbol_map ___TI_STATIC_BASE=___bss__
--symbol_map __c_int00=_c_int00




--args 0x0
-heap  0x0
-stack 0x10000

MEMORY
{
    IROM (RX) : org = 0x11700000, len = 0x100000
    L3_CBA_RAM (RWX) : org = 0x80000000, len = 0x20000
    DDR (RWX) : org = 0xc0000000, len = 0x8000000
}

/*
 * Linker command file contributions from all loaded packages:
 */

/* Content from xdc.services.global (null): */

/* Content from xdc (null): */

/* Content from xdc.corevers (null): */

/* Content from xdc.shelf (null): */

/* Content from xdc.services.spec (null): */

/* Content from xdc.services.intern.xsr (null): */

/* Content from xdc.services.intern.gen (null): */

/* Content from xdc.services.intern.cmd (null): */

/* Content from xdc.bld (null): */

/* Content from ti.targets (null): */

/* Content from xdc.rov (null): */

/* Content from xdc.runtime (null): */

/* Content from ti.targets.rts6000 (null): */

/* Content from ti.sysbios.interfaces (null): */

/* Content from ti.sysbios.family (null): */

/* Content from ti.sysbios (null): */

/* Content from xdc.services.getset (null): */

/* Content from ti.sysbios.hal (null): */

/* Content from ti.sysbios.knl (null): */

/* Content from ti.sysbios.family.c64p (null): */

/* Content from ti.ndk.rov (null): */

/* Content from ti.ndk.config (null): */

/* Content from ti.drv.omapl138 (null): */

/* Content from ti.ndk.config.family (null): */

/* Content from xdc.runtime.knl (null): */

/* Content from ti.sysbios.gates (null): */

/* Content from ti.sysbios.heaps (null): */

/* Content from ti.sysbios.xdcruntime (null): */

/* Content from ti.sysbios.timers.timer64 (null): */

/* Content from ti.sysbios.family.c64p.primus (null): */

/* Content from ti.sysbios.family.c62 (null): */

/* Content from ti.sysbios.utils (null): */

/* Content from ti.catalog.c6000 (null): */

/* Content from ti.catalog (null): */

/* Content from ti.catalog.peripherals.hdvicp2 (null): */

/* Content from xdc.platform (null): */

/* Content from xdc.cfg (null): */

/* Content from ti.platforms.generic (null): */

/* Content from myBoard (null): */

/* Content from configPkg (null): */


/*
 * symbolic aliases for numeric constants or 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
    .stack: load > DDR
    .bss: load > DDR
    .cinit: load > DDR
    .pinit: load > DDR
    .const: load >> DDR
    .data: load >> DDR
    .switch: load >> DDR
    .sysmem: load > DDR
    .far: load >> DDR
    .args: load > DDR align = 0x4, fill = 0 {_argsize = 0x0; }
    .cio: load >> DDR
    .vecs: load >> DDR
    xdc.meta: load >> DDR, type = COPY

}

0 George Mock over 7 years ago in reply to Amir Azadi

TI__Guru**** 253410 points

All of the input sections in the output section .far show [fill = 0], except this one ...

                  c179cb80    0001b706     webpage.obj (.far:NDK_OBJMEM)

That input section, from the file webpage.c (or maybe webpage.cpp), is initialized. Please inspect it and find out why that happened.

This one initialized input section is what causes the .far output section to be initialized, which means all the other uninitialized input sections in it are filled with 0.

Thanks and regards,

-George

0 Amir Azadi over 7 years ago in reply to George Mock

Expert 1105 points

In the webpage.c file which is added to the project by NDK http server, there are header files containing web data with DATA_SECTION directive:

#pragma DATA_SECTION(DEFAULT, ".far:NDK_OBJMEM");
#include <webdata/default.h>
#pragma DATA_SECTION(LOGOBAR, ".far:NDK_OBJMEM");
#include <webdata/logobar.h>

I removed the

#pragma DATA_SECTION

lines and the .out file size came back in normal range. The application also works fine on the target so far.

These are NDK samples. Why this happens?

Update:

My application just work fine on debug mode on target. When I make .bin with ASIgen and flash it to the SPI flash, some features won't work.

0 Sahin Okur over 7 years ago in reply to Amir Azadi

TI__Mastermind 27355 points

Hi Aidin,

To clarify, is your application working fine when loaded over JTAG, but not working when booting from SPI flash?
If this is the case, can you please create a new thread with the details regarding your AISgen configuration and boot settings?

0 Amir Azadi over 7 years ago in reply to Sahin Okur

Expert 1105 points

Hi Sahin

Sahin Okur said:
To clarify, is your application working fine when loaded over JTAG, but not working when booting from SPI flash?

Yes that this exactly what I meant.

Sahin Okur said:
can you please create a new thread with the details regarding your AISgen configuration and boot settings?

OK, I will.

But what does those #pragma do with the application ?

0 Sahin Okur over 7 years ago in reply to Amir Azadi

TI__Mastermind 27355 points

Hi Aidin,

The pragma is used to define some special memory segments used by the NDK. The ".far:NDK_OBJMEM" section is a catch-all for other large data buffer declarations. It is used by the example application code and the OS adaptation layer (for print buffers). Please see section 3.1.3 of the NDK User's Guide for more information.

Can you try placing the sections in a different memory segment other than .far?

Code Composer Studio™︎

Code Composer Studio forum

CCS/OMAP-L138: Huge COFF .out file