• State TI Thinks Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 54 subscribers
  • Views 434 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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/TMS320F28335: Are there any cases where an array declared in a user-defined function is placed in the ebss area rather than the stack area?

Han SeungJae
Intellectual 980 points

Part Number: TMS320F28335

Tool/software: TI C/C++ Compiler

Hello,

After calling the user-defined function from the main function, the array declared in the called function exists in the ebss area, not the stack area.

Why do these cases exist?

MEMORY
{
/* Program Memory. */
PAGE 0:
BEGIN : origin = 0x000000, length = 0x000002
RAMM0 : origin = 0x000050, length = 0x0003B0

RAMLP : origin = 0x008000, length = 0x005000
CSM_RSVD : origin = 0x33FF80, length = 0x000076 /* Part of FLASHA. Program with all 0x0000 when ... */
/* ... CSM is in use. */
CSM_PWL : origin = 0x33FFF8, length = 0x000008 /* Part of FLASHA. CSM password locations in FLASHA */
ADC_CAL : origin = 0x380080, length = 0x000009

BOOTROM : origin = 0x3FF27C, length = 0x000D44
VECTORS : origin = 0x3FFFC0, length = 0x000040

/* Data Memory. */
PAGE 1 :
BOOT_RSVD : origin = 0x000002, length = 0x00004E /* Part of M0, BOOT rom will use this for stack. */
RAMM1 : origin = 0x000400, length = 0x000400
PIE_VRAM : origin = 0x000D00, length = 0x000100
RAMLD : origin = 0x00D000, length = 0x001000
RAMLE : origin = 0x00E000, length = 0x001000
RAMLF : origin = 0x00F000, length = 0x001000


}

SECTIONS
{
/* Program sections. */
ram_start : > BEGIN, PAGE = 0 /* codestart branches to c_int00(). */
ramfuncs : > RAMLP, PAGE = 0
.text : > RAMLP, PAGE = 0
.cinit : > RAMLP, PAGE = 0
.pinit : > RAMLP, PAGE = 0
.switch : > RAMLP, PAGE = 0
/* Default reset handler. Not used. */
.reset : > VECTORS, PAGE = 0, TYPE = DSECT
/* Data sections. */
.stack : > RAMM1, PAGE = 1
pie_vram : > PIE_VRAM, PAGE = 1
.ebss : > RAMLD, PAGE = 1 /* Global and static variable */
.econst : > RAMLE, PAGE = 1 /* Constant data */
.esysmem : > RAMLF, PAGE = 1 /* Memory for malloc type functions */
/* 128-bit CSM Password. Not used. */
csm_rsvd : > CSM_RSVD, PAGE = 0, TYPE = DSECT
csmpasswds : > CSM_PWL, PAGE = 0, TYPE = DSECT
/* ADC Calibration. */
.adc_cal : load = ADC_CAL, PAGE = 0, TYPE = NOLOAD
}

And, my sample code is

void stack_overflow()
{
char overflowable[10]="BBBBBBBBBB";

int len2=100;
int i;
char *buff2;
buff2 = &overflowable;

char s2[100] = {"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"};

memcpy(overflowable, s2, len2);

for(i=0; i<100; i++){
printf("%s", buff2[i]);

}

}

please refer to the attached photo for the address and data confirmed through the Memory Browser.

char overflowable[10] array's address id 0xD44C.

Thanks, Regards 

Han

  • 0
    TI__Guru**** 253010 points

    Please submit your linker map file.  It has the same name as the project, with the file extension .map.  It is found in the directory named after the current build configuration, often Debug.  So the forum will accept it, add the file extension .txt.  Attach it to your next post.

    Consider the possibility the SP register is corrupted.  Does it contain an address that corresponds to the memory range allocated to the stack?

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Intellectual 980 points

    Thanks reply for my questions.

    I attached my mapping.txt file

    mapping.txt

    Thanks and Regards

    Han,

  • 0 in reply to Han SeungJae
    TI__Guru**** 253010 points

    Your map file includes these lines that show the address of those symbols ...

    1     0000d440  _App_TaskPendStk                
1     0000d540  _App_TaskPostStk                
1     0000d640  _App_TaskStartStk

    Your memory window screen shot starts at address 0xd44c, within range of the symbol _App_TaskPendStk.  The function begins by copying constant strings filled with the character A (0x0041) and B (0x0042) into the local arrays overflowable and s2.  All things considered, it is likely the SP is not within the range of the .stack section, but within the range of the symbol _App_TaskPendStk in the .ebss section.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Intellectual 980 points

    Thanks for the answer.

    I don't seem to understand the answer yet.

    1. Can the SP be located in the .ebss section, not the .stack section?

    2. I still don't understand why overflowable and s arrays exist in .ebss rather than .stack.

    Sorry, please help me more

    Regards,

    Han

  • 0 in reply to Han SeungJae
    TI__Guru**** 253010 points

    Han SeungJae said:
    1. Can the SP be located in the .ebss section, not the .stack section?

    That's not supposed to happen.  But, that is probably what happened in your case.  You need to investigate to determine whether the SP contains the address for the wrong memory range, and how that occurred.

    Han SeungJae said:
    2. I still don't understand why overflowable and s arrays exist in .ebss rather than .stack.

    Like all local variables, they are accessed at a constant offset from the SP.  If the SP becomes corrupted, their addresses will be corrupted as well.

    Thanks and regards,

    -George