CCSv6.1.1 (C2000 compiler v6.2.11): Why is compiler creating .sysmem section, i.e. warning #10210-D: creating ".sysmem" section with default size of 0x400; use the -heap option to change the default size

The memory map refers to memory.obj for that section. The code shown below is the reason for the creation of the .sysmem section.

Why does the compiler allow an unsized array in the Run Time Library?


In memory.c (runtime system libary):
/*****************************************************************************/
/* Declare the memory pool as a .usect called .sysmem. The size of the */
/* section .sysmem is determined by the linker via the -heap option */
/*****************************************************************************/
#pragma DATA_SECTION(_sys_memory, ".sysmem")
int _sys_memory[];

stevenh said:

I thought .sysmem was replaced with .esysmem

The section .sysmem is used for malloc and related functions.  The section .esysmem is used for far_malloc and related functions.

stevenh said:

 My program is not performing any dynamic memory allocation, so why is either of those two section being created?

I don't know.  Is malloc the only unusual thing that appears in the map file?  Do you see unexpected printf calls, or anything else like that?

Thanks and regards,

-George

Hello George,

From my previous post I thought I understood why the sysmem section was showing up, i.e.

#pragma DATA_SECTION(_sys_memory, ".sysmem")
int _sys_memory[];

The original reason for my question was because of the "creating .sysmem section..." warning.

I never examined the memory map file that carefully; However, I am certain that my code doesn't contain malloc. 

I wouldn't be able to tell if something strange was showing up because some functions use other function, however, I don't think any of the rts functions in my code are using malloc.  The only rts functions I am using in my code (that I can remember) are memset, memcpy and sprintf.

Stephen

Hello George,

I don't need/ don't want to use dynamic memory allocation in my program. Is there any way to exclude those type of functions from the build?

Stephen

Hello George,

Thanks.

I did what you said (see below).  I had to do it twice since the first time the linker output referred to the new_.obj file.  

The final linked result from the sample project I previously at attached is as follows:

 undefined                   first referenced
  symbol                         in file     
 ---------                   ----------------
 operator new(unsigned long) ./main.obj      

I included both the c++ code and its associated disassembly (from the debugger) below. A pointer to __sti___6_main_c_d7ce1b44 (at the bottom of the disassembly) is located in the pinit table.  __sti___6_main_c_d7ce1b44 calls the object's constructor.

I stepped through program and found out that "new" (i.e. LCR  operator new) is never called (because XAR4 != 0) in the constructor (i.e. Test::Test():) , so what is the purpose of the call to "new"?

 If I remove constructor from the program, the call to "new" goes away

C++ Code:

/*
 * main.c
 */
class Test
{
public:
    long int a;
    long int b;
    int x[10];
    Test(void);
    void aTest(void);

};

Test::Test(void)
{
    int i;

    a=1000000000l;
    b=1000000000l;

    for(i=0;i<10;i++)
    {
        x[i] = i;
    }
}

void Test::aTest(void)
{
    a = 2l;
    b = 3l;
}

Test TestIt;


int main(void)
{

    TestIt.aTest();


	return 0;
}

Assmebly Code (from debugger):

        main():
32021d:   8F008400    MOVL         XAR4, #0x008400
32021f:   76720247    LCR          aTest
44      	return 0;
320221:   9A00        MOVB         AL, #0x0
45      }
320222:   0006        LRETR        
17      {
       Test::Test():
320223:   FE04        ADDB         SP, #4
320224:   A842        MOVL         *-SP[2], XAR4
320225:   0642        MOVL         ACC, *-SP[2]
320226:   ED07        SBF          C$L1, NEQ
320227:   020E        MOVB         ACC, #14
320228:   76720277    LCR          operator new
32022a:   A8A9        MOVL         @ACC, XAR4
32022b:   A842        MOVL         *-SP[2], XAR4
32022c:   EC18        SBF          C$L3, EQ
20          a=1000000000l;
        C$L1:
32022d:   8A42        MOVL         XAR4, *-SP[2]
32022e:   28A9CA00    MOV          @AL, #0xca00
320230:   28A83B9A    MOV          @AH, #0x3b9a
320232:   1EC4        MOVL         *+XAR4[0], ACC
21          b=1000000000l;
320233:   8A42        MOVL         XAR4, *-SP[2]
320234:   1ED4        MOVL         *+XAR4[2], ACC
23          for(i=0;i<10;i++)
320235:   2B43        MOV          *-SP[3], #0
320236:   9243        MOV          AL, *-SP[3]
320237:   520A        CMPB         AL, #0xa
320238:   630C        SB           C$L3, GEQ
25              x[i] = i;
        C$L2:
320239:   8A42        MOVL         XAR4, *-SP[2]
32023a:   3B01        SETC         SXM
32023b:   8543        MOV          ACC, *-SP[3]
32023c:   8843        MOVZ         AR6, *-SP[3]
32023d:   560100A4    ADDL         @XAR4, ACC
32023f:   7EE4        MOV          *+XAR4[4], AR6
23          for(i=0;i<10;i++)
320240:   0A43        INC          *-SP[3]
320241:   9243        MOV          AL, *-SP[3]
320242:   520A        CMPB         AL, #0xa
320243:   64F6        SB           C$L2, LT
27      }
        C$L3:
320244:   8A42        MOVL         XAR4, *-SP[2]
320245:   FE84        SUBB         SP, #4
320246:   0006        LRETR        
30      {
        Test::aTest():
320247:   FE02        ADDB         SP, #2
320248:   A842        MOVL         *-SP[2], XAR4
31          a = 2l;
320249:   8A42        MOVL         XAR4, *-SP[2]
32024a:   0202        MOVB         ACC, #2
32024b:   1EC4        MOVL         *+XAR4[0], ACC
32          b = 3l;
32024c:   8A42        MOVL         XAR4, *-SP[2]
32024d:   0203        MOVB         ACC, #3
32024e:   1ED4        MOVL         *+XAR4[2], ACC
33      }
32024f:   FE82        SUBB         SP, #2
320250:   0006        LRETR        
35      Test TestIt;
        __sti___6_main_c_d7ce1b44():
320251:   8F008400    MOVL         XAR4, #0x008400
320253:   76720223    LCR          Test
320255:   0006        LRETR        

I would still like to know why the compiler allows an unsized array in the rts library? i.e.

In memory.c (runtime system libary):
/*****************************************************************************/
/* Declare the memory pool as a .usect called .sysmem. The size of the */
/* section .sysmem is determined by the linker via the -heap option */
/*****************************************************************************/
#pragma DATA_SECTION(_sys_memory, ".sysmem")
int _sys_memory[];

That code sets the global variable _sys_memory to the beginning of the section .sysmem.  The section .sysmem is sized by the linker according to the value of the -heap option.

Thanks and regards,

-George