• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 53 subscribers
  • Views 2951 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

CCS/MSP430FG4618: CCS 7.2 Stack Usage can under-report the stack size requirement when Function Symbol Aliasing occurs

Chester Gillon
Guru 92251 points
Part Number: MSP430FG4618

Tool/software: Code Composer Studio

The attached project is a test for calculating the stack size usage for a program.3441.MSP430FG4618_trig_stack_size.zip

The CCS 7.2.0.00013 Stack Usage view reports the stack usage for _c_int00_noargs_noexit as 878 bytes:

In the above the floorl and scalbnl functions are reported as having No definition found. And the floor and scalbn functions are shown as not being called in the Stack Usage view:

In the attached zip file Debug\MSP430FG4618_trig_stack_size_call_graph.txt is the output from the call_graph cg_xml tool; a post build rule was added to project to run call_graph on the generated build file.

Comparing the stack size calculated by the cg_xml tool against that shown in the CCS 7.2 Stack Usage view shows:

1) call_graph has calculated a higher stack size for the _c_int00_noargs_noexit function of 908 bytes, as opposed to the 878 bytes reported by the CCS Stack Usage view.

2) call_graph isn't reporting the floor and scalbn functions as orphans.

The reason is that call_graph has detected that (floor floorl) and (scalbn  scalbnl) are Function Symbol Aliases, and included the stack size for (floor floorl) and (scalbn  scalbnl) inside the stack usage for _c_int00_noargs_noexit.

As a result, the CCS Stack Usage view is under-reporting the stack requirement when Function Symbol Aliases occur (where Function Symbol Aliases means two symbols with the same address).

Can the CCS Stack Usage view be changed to match the cg_xml call_graph behaviour in the event of Function Symbol Aliases?

  • 0
    TI__Guru**** 232640 points

    Thank you for notifying us of this problem, and submitting a concise test case.  I can reproduce the same results.  I filed CODEGEN-3595 in the SDOWP system to have this investigated.  You are welcome to follow it with the SDOWP link below in my signature.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Guru 92251 points

    Looking at the example again another anomaly is that both the CCS 7.2 Stack Usage view and cg_xml call_graph are reporting that the _auto_init_hold_wdt function is an orphan (in that  _auto_init_hold_wdt doesn't appear under the call tree for the _c_int00_noargs_noexit entry point).

    Running dis430 on the out file shows that _auto_init_hold_wdt is directly being called by _c_int00_noargs_noexit:

    $ /cygdrive/C/ti/ccs720/ccsv7/tools/compiler/ti-cgt-msp430_16.9.4.LTS/bin/dis430.exe MSP430FG4618_trig_stack_size.out | head -40

Disassembly of MSP430FG4618_trig_stack_size.out:

TEXT Section .text:_isr, 0x22 bytes at 0x3100
003100:              _c_int00_noargs_noexit:
003100:              .text:_isr:_c_int00_noargs_noexit:
003100:              .text:_isr:
003100: 8100             MOVA    #0x03100,SP
003102: 0031
003104: B113             CALLA   #_system_pre_init
003106: D23E
003108: 0C93             TST.W   R12
00310a: 0224             JEQ     ($C$L4)
00310c: B113             CALLA   #_auto_init_hold_wdt
00310e: A439
003110:              $C$L4:
003110: 0C43             CLR.W   R12
003112: B113             CALLA   #main
003114: E63D
003116: B113             CALLA   #abort
003118: CC3E
00311a:              __TI_ISR_TRAP:

    Therefore, not sure why _auto_init_hold_wdt isn't being reported under the call tree for_c_int00_noargs_noexit.

  • 0 in reply to Chester Gillon
    TI__Guru**** 232640 points

    Chester Gillon said:
    not sure why _auto_init_hold_wdt isn't being reported under the call tree for_c_int00_noargs_noexit.

    The call graph is developed by processing the Dwarf debug information.  In this case, that information is wrong.

    I filed CODEGEN-3603 to have this investigated.  You are welcome to follow it with the SDOWP link below in my signature.

    With regard to the total amount of stack needed for this particular test case, this error in the Dwarf debug information has no impact.  That said, thank you so much for letting us know.

    Thanks and regards,

    -George