linker is making zero-fill segment "alloc=Y".

My guess is that some .o file contributes a zfill_uncached input section that is initialized.  Just one such initialized section, when combined with many other uninitialized sections, causes the linker to create one very large initialized output section.  Thus, our quest is to find the .o file that supplies the initialized zfill_uncached input section.

For every entry the map file shows in the zfill_uncached output section, please run commands similar to ...

% ar6x -x libname.a file.o
% ofd6x --obj_display=none,sections -v file.o

Both ar6x and ofd6x are in the same /bin directory as the other compiler tools.  The first command extracts the object file from the library.  The second command displays information about the sections in the file.  A normal zfill_uncached section looks like this ...

Focus on the field Section Type.  If you see something other than SHT_NOBITS, then we found our culprit.  The next step is figure out why that zfill_cached section is somehow getting initialized.

Thanks and regards,

-George

George,

Thanks for the very quick turnaround.  Great support.

On this one though, your "guess" did not pan out.  For the four files in the map for "zfill_uncached", all have NOBITS in the ofd listing you suggest.

 <59> "zfill_uncached" Load Address: 0x00000000 Run Address: 0x00000000 Size: 0x100000 Alignment: 8 Loaded Onto Device: Yes Address Unit Size: 8 bits File Offset: 0x00000580 # Relocs: 0 Section Type: SHT_NOBITS ELF sh_flags: 0x00000003 ELF sh_flag: SHF_WRITE ELF sh_flag: SHF_ALLOC TI ext_flags: 0x0 <73> "zfill_uncached" Load Address: 0x00000000 Run Address: 0x00000000 Size: 0x5b08 Alignment: 8 Loaded Onto Device: Yes Address Unit Size: 8 bits File Offset: 0x00000730 # Relocs: 0 Section Type: SHT_NOBITS ELF sh_flags: 0x00000003 ELF sh_flag: SHF_WRITE ELF sh_flag: SHF_ALLOC TI ext_flags: 0x0 <122> "zfill_uncached" Load Address: 0x00000000 Run Address: 0x00000000 Size: 0xd0c Alignment: 8 Loaded Onto Device: Yes Address Unit Size: 8 bits File Offset: 0x00000c28 # Relocs: 0 Section Type: SHT_NOBITS ELF sh_flags: 0x00000003 ELF sh_flag: SHF_WRITE ELF sh_flag: SHF_ALLOC TI ext_flags: 0x0 <68> "zfill_uncached" Load Address: 0x00000000 Run Address: 0x00000000 Size: 0x840 Alignment: 8 Loaded Onto Device: Yes Address Unit Size: 8 bits File Offset: 0x00000650 # Relocs: 0 Section Type: SHT_NOBITS ELF sh_flags: 0x00000003 ELF sh_flag: SHF_WRITE ELF sh_flag: SHF_ALLOC TI ext_flags: 0x0

I want to segregate my uncached from my cached (for obvious reasons...)  but I am placing zero-fill and initialized uncached data in a linker GROUP.  Obviously from the map, the GROUPings are resolved into there own segments but I am running out of track.

Thanks again.

Linker.cmd:

GROUP(UNCACHED)
{
   GROUP(ZFILL_UNCACHED)
   {
      zfill_uncached:           // zero-fill uncached

      GROUP(L2_LOCKED_ZFILL)
      {
         locked_l2_zfill:  // locked critical data into L2
      }
      ALIGN(32), // cache line aligned
      START(__start_locked_l2_zfill),
      END  (__end_locked_l2_zfill)
   }
   // this is shared initialized data that is read-only after load
   GROUP(LOAD_UNCACHED)
   {
      SpecialData:  // readonly but no AMMU to enforce
      load_uncached: // initialized uncached
   }

The truncation is repeatable.  Great.  Bottom line: all four ofd's show NOBITS for "zfill_uncached"

Section Type:        SHT_NOBITS

Section Type:        SHT_NOBITS

Section Type:        SHT_NOBITS

Section Type:        SHT_NOBITS

It seems the linker command file snippet you show is edited down a bit from the one you actually use.  Please post the full file contents, exactly as the linker sees it.  I suspect you are combining zfill_uncached into a GROUP with some other initialized section, and that is causing the undesired zero fill.  I further suspect there is a different way to solve your problem without using GROUP, and thus avoid the zero fill.  

Thanks and regards,

-George

George,

I gave you all the linker.cmd with the far uncached data in it.  Other groups should not affect that grouping.

I found the workaround.  I had a 2 DATA_SECTIONs with odd-sized 16bit array data that required padding for alignment.

In the map the pad was listed as "--HOLE-- [fill = 0]".  If I add 16bits to both those arrays odd-16bit sized arrays, the zfill_uncached section "magically" becomes init-size=0.

uint16_t foo[99];  // fails  forces alignment via --HOLE-- [fill = 0]

uint16_t foo[100];  // works no HOLE required

This seems like a bug to me -- specifically since the ofd you had me run says the compiler correctly specifies "NOBITS" and the linker should know that "fill=0" does not require initialization (esp. with --zero_init=off on the command line).

Thanks for you help.

Unfortunately, I am unable to reproduce what you describe.  Please post your entire linker command file, along with exact options you use when invoking the linker.  I may be able to reproduce the issue with that information.

Thanks and regards,

-George