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.

Compiler: Section initialization

Tool/software: TI C/C++ Compiler

Hello,

I would like to verify something regarding section initialization (using TI tools, cortex M4 , TDA2xx)

If i have a linker file with the following:

GROUP (G1)
{
.sec1 : {}
.sec2 :
{
*(.sec2) {}
.=0x8;
}
.sec3 :
{
*(.sec3) {}
.=0x8;
}
} load = (0)

if nothing is actually assigned to either sec2 or sec3 while the other section is assigned when some data , i can see in the map file that the section that was not referred to in the code is UNINITIALIZED and that there is a hole (--HOLE--), while the section that was referred to does contain the assigned input section and on the remaining space (when i.e. only 4 bytes where assigned to it) there is also a hole but this time it says --HOLE-- [fill = 0] .

When running this application and after reaching main i can see that the above makes sense in the way that the memory area of the section that was marked as HOLE only is never initialized (not set to zero) and the memory stays intact (meaning whatever was there before stays as it was), while the initialized section the area marked as HOLE [fill=0] is indeed cleared to zero.

What i want to verify is if this indeed the expected behavior and that i can rely on this if i would like to create holes in memory and also be sure that they will NOT get written at all (no zero initialization ,...).

(as a note: in this specific case i CANNOT use the NOLOAD type on the linker file which will for sure achieve the above so i would like to know if what i am seeing is something i can actually trust and use)

B.T.W

when looking at the ELF segments all of these sections are marked as allocated but for the segment that includes the "unassigned" section the fileSize < memSize which means that the memory area will indeed wont be loaded but it (according to ELF general rules) mean that the area that is not loaded (from fileSize to memSize) is supposed to be initialized to zero, so i am not sure how am i suppose to understand this behavior and according to what, on TI tools, holes are getting initialized to zero.

Thanks

Guy

  • Guy Mardiks said:
    i would like to create holes in memory and also be sure that they will NOT get written at all (no zero initialization ,...).

    There are two methods to accomplish this task.  From C or C++ code, use #pragma NOINIT.  In the linker command file, apply type = NOINIT to the output section.  Both of these methods presume the underlying variable or section is uninitialized.

    There is a third method that I suspect does not make sense in your case.  The linker option --zero_init=off means all uninitialized sections do not get zero initialized.

    Thanks and regards,

    -George

  • Hi and Thanks.
    The specific code i am referring to is in assembly so the C pragma is out.
    If (and it looks like it according to everything i have seen so far) the type=(NOINIT) in the linker only prevent the data from going through the C initialization routine and has no bearing on whether the section in loaded or not and also if since the code is an assembly code writing:
    .sect .sec2
    .word 10
    will still set the memory to 10 (in this example) after load (when .sec2 has type=(NOINIT)) then i can set both of the sections from the post above to type=(NOINIT) just to be on the safe side. but what about what i have described above, it seems to be working also (with out any type=(NOINIT)) -- the documentation only describes holes on initialized sections which are filled with zero - as was seen in the section that was written, but it does not say anything about holes in output sections that are not assigned any input section -- it seems to having the GROUP advances the SPC regardless of if the middle section is used which gives the result i am seeing.

    I will appreciate your feedback and comments about the best way to go (i need both sections in the linker to be the same type)

    Thanks
    Guy
  • Guy Mardiks said:
    I will appreciate your feedback and comments about the best way to go (i need both sections in the linker to be the same type)

    I don't like to admit that I'm still confused about what overall problem you mean to solve. I'd appreciate if you would describe what you want to do, without any regard to the details of how it might be implemented.

    Guy Mardiks said:
    the code is an assembly code writing:
    .sect .sec2
    .word 10
    will still set the memory to 10 (in this example) after load (when .sec2 has type=(NOINIT))

    Please do not mark an initialized section with type = NOINIT.  That is not supported.

    Thanks and regards,

    -George

  • Hi, Thank you.
    I have two sections at specific shared memory location and depending on the build i write (initialize in ASM) a word on one of these sections while the other is never referenced. both sections are retained. as a result the section that is not reference on the build is also NOT getting initialized to zero and this is what i wanted to achieve - and actually achieved as i described above.
    I am no longer sure regarding what is supported or not but the fact of the matter is that this is the behavior and it is consistent (and also makes some sense otherwise as i mentioned before i cant see what would be the difference between type NOLOAD and type NOINIT - i still could not understand it from what you tried to describe so far if it is not suppose to behave as it is behaving ).

    (B.T.W: i looked again at the latest ARM Assembly tools manual and it says 

    A NOINIT section is not C auto-initialized by the linker. It is your responsibility to initialize this section
    as needed.

    which according to my understanding of it is exactly what i am seeing as the linker behavior) 


    Thanks
    Guy