C6678: too huge ELF executable file?

Please post the output of this command:

% ofd6x --obj_display=none,sections file.out

This alone will probably not reveal the source of the problem.  But it will help direct us.

Thanks and regards,

-George

The output of ofd6x follows.  The debug info are very big, but I'm not able to strip them out. "strip6x" produce a file big as the input one. If I apply the ofd6x command on the stripped .out, I get exactly the same info but without the items from 49 to 59 (.debug*).

 Section Information

    id name                      load addr  run addr         size    align alloc
    -- ----                      ---------  --------         ----    ----- -----
     0 (no name)                 0x00000000 0x00000000        0x0        0   N 
     1 .boot_stack               0x00800000 0x00800000      0x400        1   Y 
     2 .boot_text                0x0c020000 0x0c020000        0x0        1   Y 
     3 .text                     0x0c020000 0x0c020000    0x60260       32   Y 
     4 .switch                   0x0c080260 0x0c080260      0x3e0        4   Y 
     5 .const                    0x0c080640 0x0c080640    0x11ae2       16   Y 
     6 .rodata                   0x0c092122 0x0c092122        0x0        1   Y 
     7 .init_array               0x0c092124 0x0c092124       0x28        4   Y 
     8 .chimera_code             0x0c092400 0x0c092400    0x14600     1024   Y 
     9 .cinit                    0x0c0a6a00 0x0c0a6a00      0xef0        4   Y 
    10 .ovly                     0x0c0a78f0 0x0c0a78f0       0x80        4   Y 
    11 .mcsm_common              0xf0000000 0xf0000000    0x14b48        8   Y 
    12 .mcsm_sharedregions       0xf0014c00 0xf0014c00        0x0      256   Y 
    13 .lnk_ram_begin_marker     0xc0000000 0xc0000000        0x0 16777216   Y 
    14 .stack                    0xc0000000 0xc0000000     0x4e20        8   Y 
    15 .cio                      0xc0004e20 0xc0004e20      0x120        4   Y 
    16 .neardata                 0xc0004f40 0xc0004f40      0x248        4   Y 
    17 .data                     0xc0005188 0xc0005188        0x0        1   Y 
    18 .bss                      0xc0005190 0xc0005190     0x55b0       16   Y 
    19 .far                      0xc000a780 0xc000a780   0x5e6244      128   Y 
    20 .fardata                  0xc05f09d0 0xc05f09d0     0xcee2       16   Y 
    21 .chimera_ram              0xc05fd8c0 0xc05fd8c0      0x9ed       16   Y 
    22 .chimera_bss              0xc05fe2b0 0xc05fe2b0    0x1417c       16   Y 
    23 .sysmem                   0xc0612430 0xc0612430    0xf4240        8   Y 
    24 .lnk_ram_end_marker       0xc0706670 0xc0706670        0x0        1   Y 
    25 .core_runtime_0           0x80000000 0x80000000   0x800000        1   Y 
    26 .core_runtime_1           0x80800000 0x80800000   0x800000        1   Y 
    27 .core_runtime_2           0x81000000 0x81000000   0x800000        1   Y 
    28 .core_runtime_3           0x81800000 0x81800000   0x800000        1   Y 
    29 .core_runtime_4           0x82000000 0x82000000   0x800000        1   Y 
    30 .core_runtime_5           0x82800000 0x82800000   0x800000        1   Y 
    31 .core_runtime_6           0x83000000 0x83000000   0x800000        1   Y 
    32 .core_runtime_7           0x83800000 0x83800000   0x800000        1   Y 
    33 .core_private_noinit_0    0x84000000 0x84000000 0x1b100000      256   Y 
    34 .core_private_0           0x9f100000 0x9f100000    0x462a0      256   Y 
    35 .core_private_noinit_1    0x9f146300 0x9f146300        0x0      256   Y 
    36 .core_private_1           0x9f146300 0x9f146300        0x4      256   Y 
    37 .core_private_noinit_2    0x9f146400 0x9f146400        0x0      256   Y 
    38 .core_private_2           0x9f146400 0x9f146400        0x4      256   Y 
    39 .core_private_noinit_3    0x9f146500 0x9f146500        0x0      256   Y 
    40 .core_private_3           0x9f146500 0x9f146500        0x4      256   Y 
    41 .core_private_noinit_4    0x9f146600 0x9f146600        0x0      256   Y 
    42 .core_private_4           0x9f146600 0x9f146600        0x4      256   Y 
    43 .core_private_noinit_5    0x9f146700 0x9f146700        0x0      256   Y 
    44 .core_private_5           0x9f146700 0x9f146700        0x4      256   Y 
    45 .core_private_noinit_6    0x9f146800 0x9f146800        0x0      256   Y 
    46 .core_private_6           0x9f146800 0x9f146800        0x4      256   Y 
    47 .core_private_noinit_7    0x9f146900 0x9f146900        0x0      256   Y 
    48 .core_private_7           0x9f146900 0x9f146900        0x4      256   Y 
    49 .debug_info               0x00000000 0x00000000   0x25a8b4        1   N 
    50 .debug_line               0x00000000 0x00000000    0x62d60        1   N 
    51 .debug_frame              0x00000000 0x00000000    0x2298e        1   N 
    52 .debug_abbrev             0x00000000 0x00000000    0x53ae9        1   N 
    53 .debug_pubnames           0x00000000 0x00000000    0x25756        1   N 
    54 .debug_aranges            0x00000000 0x00000000     0x9868        1   N 
    55 .debug_str                0x00000000 0x00000000    0xe3edb        1   N 
    56 .debug_pubtypes           0x00000000 0x00000000    0x39546        1   N 
    57 .core_private_0.load      0x0c092200 0x0c092200       0xb2        4   Y 
    58 .core_private_5.load      0x0c0a7d00 0x0c0a7d00        0x4        4   Y 
    59 .core_private_6.load      0x0c0a7e00 0x0c0a7e00        0x4        4   Y 
    60 .core_private_3.load      0x0c0a7b00 0x0c0a7b00        0x4        4   Y 
    61 .core_private_4.load      0x0c0a7c00 0x0c0a7c00        0x4        4   Y 
    62 .core_private_7.load      0x0c0a7f00 0x0c0a7f00        0x4        4   Y 
    63 .core_private_1.load      0x0c092300 0x0c092300        0x4        4   Y 
    64 .core_private_2.load      0x0c0a7a00 0x0c0a7a00        0x4        4   Y 
    65 .c6xabi.attributes        0x00000000 0x00000000       0x42        0   N 
    66 .symtab                   0x00000000 0x00000000    0x8dc70        0   N 
    67 .TI.section.flags         0x00000000 0x00000000       0x23        0   N 
    68 .strtab                   0x00000000 0x00000000    0x49fcb        0   N 
    69 .shstrtab                 0x00000000 0x00000000      0x404        0   N 

After strip:

    1..48: as before

    49 .core_private_0.load      0x0c092200 0x0c092200       0xb2        4   Y 
    50 .core_private_5.load      0x0c0a7d00 0x0c0a7d00        0x4        4   Y 
    51 .core_private_6.load      0x0c0a7e00 0x0c0a7e00        0x4        4   Y 
    52 .core_private_3.load      0x0c0a7b00 0x0c0a7b00        0x4        4   Y 
    53 .core_private_4.load      0x0c0a7c00 0x0c0a7c00        0x4        4   Y 
    54 .core_private_7.load      0x0c0a7f00 0x0c0a7f00        0x4        4   Y 
    55 .core_private_1.load      0x0c092300 0x0c092300        0x4        4   Y 
    56 .core_private_2.load      0x0c0a7a00 0x0c0a7a00        0x4        4   Y 
    57 .c6xabi.attributes        0x00000000 0x00000000       0x42        0   N 
    58 .symtab                   0x00000000 0x00000000       0x40        0   N 
    59 .TI.section.flags         0x00000000 0x00000000       0x23        0   N 
    60 .strtab                   0x00000000 0x00000000       0x1b        0   N 
    61 .shstrtab                 0x00000000 0x00000000      0x397        0   N 

The alloc column says whether that particular section takes up space in target memory.  According to what you said earlier, we should see about 15.5 megabytes of stuff where the alloc column is N.  But we don't.  I'm not sure what to make of that.

What's in all these .core_something sections?  Is the size on that expected?

Thanks and regards,

-George

The rows masked with alloc=Y takes space in target memory but not all that sections generate data to be included in the .out file. The biggest one, ".core_private_noinit_0 has type=NOINIT and should take no space in the loadable image, while the "core_private_0" is RLE compressed and takes only 0xB2 bytes (.core_private_0.load).

The size of the .core_* sections is as expected. Since I don't use MAD, I have my methiods to allocate memory for multi core section.

• The code, const and so on  is common to all cores, allocated onto MCSM
• The data are allocated at 0xC000000 for all cores, a virtual area remapped to a per core area (8M byes maximum) via PAX registers
• The ".core_runtime_*" are the physical areas reserved for each core for the data remapping (type=NOINIT)
• The ".core_private_noinit_*" are sections available to explicit map non initialized data private to the algorithms that have to run on a specific core only (type=NONIT)
• The ".core_priva_*" are sections available to explicit map initialized data private to the algorithms that have to run on a specific core only
• ".mcsm_common" holds some shared control data and is a non cacheable alias for the MCSM (type=NOINIT)

So far, only core 0 allocate private data, in particular a big memory buffer used for a custom memory heap of multicore shared memory.The other privates are not used and supplied as a provision (I only put a single unsigned int in each section)

By the way, the size is a problem since I have to flash it on the NOR flash of the EVM6678 and the nor writer say me it is too big. I can convert it to Motorola S3 (dimension about 1M, that is coherent with the expect size since one byte takes two chars) but this is unusable for the nor write. I read there was a tool to convert from elf to bin for the nor writer but I cannot find it in my installation and I read, somewhere in the TI forums, that it is not longer supplied since the nor writer is able to parse the elf format.

Hi,

I have found the problem. I have used the directive " .lnk_ram_begin_marker: ALIGN(0x01000000)". The linker insert a zero filled padding of 16M.

removing the ALIGN() resolve the problem. Since the directive was placed on the first symbol of a group that map to a named memory and the named memory is placed at an address aligned 0x01000000, the directive is not stricly required.

I belived the linker add padding only if the palign directive is used. Is it a problme in my interpretation of the documentation or a sort of linker bug?

So, you're saying the linker inserted alignment padding where it isn't needed.  That sounds like a bug to me.  I realize linker test cases are difficult to produce.  But I don't see how we can advance your issue without one.

Thanks and regards,

-George 

HI,

With the following lnk.cmd and hello.c example files, I get a 16M .out file, with the variable x of hello.c mapped at 0x80000000. If I remove the ALIGN directive, the .out is 28K only and the variable x is always mapped at 0x80000000. I supposed to have the 16M zero filled section only in presence of the PALIGN directive, while the ALIGN should only create an empty hole (By the way, so far I don't needthe align since the section is mapped on a memory aread that is already aligned).

------ link.cmd

MEMORY
{
    L2SRAM: origin=00800000h, length=080000h
    SH_RAM: o=0x0C000000, l=0x00400000
    EXT_RAM: o=0x80000000, l=0x10000000
}

SECTIONS
{
  .text > L2SRAM
  .cinit > L2SRAM
  .switch > L2SRAM
  .const > L2SRAM
  .init_array > L2SRAM
  .rodata > L2SRAM
  .cio > L2SRAM
  .neardata > L2SRAM
  .data > L2SRAM
  .bss > L2SRAM
  .far > L2SRAM
  .fardata > L2SRAM
    
  .stack > L2SRAM
  .sysmem > L2SRAM
 
  .shared >> SH_RAM
 
  .my_data: ALIGN(0x01000000) //<------- ALIGN 16M !!!!!!!!!
  {
    hello.obj(.far)
  }  > EXT_RAM
}

--hello.c

far volatile unsigned int x;

int main()
{
  x=10;
  return 0;
}
--------

Thank you for the test case.  I can use it to build an .out file that is 16 MB.  But there is no reason I can see for the file to be that big.  I filed SDSCM00043622 in the SDOWP system to have this issue fixed.  Feel free to track it with the SDOWP link below in my signature.

Thanks and regards,

-George