CCS/CC1310: Stack usage missing when --printf_support nofloat

AartiG said:

With the rfEasyLinkNp_CC1310_LAUNCHXL_tirtos_ccs project compiled with --printf_support=nofloat, I see the following (__TI_printfi_nofloat and __TI_scanfi_nofloat)
in the Stack Usage view. As Chester pointed out the function names are different when code is built with nofloat option.

In the attached example which uses --printf_support=nofloat a post-build rule was added to run the cg_xml call_graph utility. The output of call_graph (Debug/TM4C_sprintf_stack_usage_call_graph.txt) in the attached project shows the same issue as the CCS Stack Usage view is that __TI_printfi_nofloat is shown as an orphan function whose stack usage does not contribute to the stack usage of sprintf:

__TI_printfi_nofloat : wcs = 632
|  __aeabi_errno_addr : wcs = 0
|  _ltostr : wcs = 32
|  |  ULL$DIV : wcs = ???
|  |  strlen : wcs = 0
|  atoi : wcs = 16
|  memccpy : wcs = 8
|  memset : wcs = 20
|  strlen : wcs = 0
|  wcslen : wcs = 0

__aeabi_uldivmod : wcs = 20

_c_int00_noargs : wcs = 136
|  __TI_auto_init : wcs = ???
|  __mpu_init : wcs = ???
|  _system_pre_init : wcs = 0
|  exit : wcs = ???
|  main : wcs = 128
|  |  sprintf : wcs = 40
|  |  |  __TI_printfi : wcs = ???

Looking at how sprintf is implemented in the TI ARM v18.1.3.LTS shows:

a) The lib/src/sprintf.c source file contains the implementation of sprintf which simply calls __TI_printfi to perform the work. The implementation of sprintf is the same regardless of the --printf_support option.

b) The lib/src directory contains three .c source files used to compile different implementations of printf support:

_printfi.c implements the __TI_printfi function for use by --printf_support=full

_printfi_min.c implements the __TI_printfi_minimal function for use by --printf_support=minimal

_printfi_nf.c implements the __TI_printfi_nofloat function for use by --printf_support=nofloat

I think the linker uses the --printf_support to modify a call to __TI_printfi to either a call to __TI_printfi / __TI_printfi_minimal / __TI_printfi_nofloat function depending upon the use of either --printf_support=full / --printf_support=minimal / --printf_support=nofloat.

If armdis is used to disassemble the out file created with --printf_support=nofloat then sprintf is shown as calling __TI_printfi_nofloat which is OK:

~/ti/ccs810/ccsv8/tools/compiler/ti-cgt-arm_18.1.3.LTS/bin/armdis TM4C_sprintf_stack_usage.out 
Disassembly of TM4C_sprintf_stack_usage.out:
<snip>
000d30:              sprintf:
000d30:               .thumb
000d30:              .text:sprintf:
000d30: 0FB4             PUSH            {R0, R1, R2, R3}
000d32: 80B5             PUSH            {R7, LR}
000d34: 02AF             ADD             R7, SP, #8 
000d36: ADF1100D         SUB.W           R13, R13, #16
000d3a: 0290             STR             R0, [SP, #8]
000d3c: 7A68             LDR             R2, [R7, #4]
000d3e: 0192             STR             R2, [SP, #4]
000d40: 094B             LDR             R3, $C$CON1 [0xd68]
000d42: 0093             STR             R3, [SP]
000d44: 094B             LDR             R3, $C$CON2 [0xd6c]
000d46: 391D             ADDS            R1, R7, #4
000d48: 21F00301         BIC.W           R1, R1, #3
000d4c: 091D             ADDS            R1, R1, #4
000d4e: 01A8             ADD             R0, SP, #4 
000d50: 02AA             ADD             R2, SP, #8 
000d52: FFF759FA         BL              __TI_printfi_nofloat [0x208]
000d56: 0299             LDR             R1, [SP, #8]
000d58: 0022             MOVS            R2, #0
000d5a: 0A70             STRB            R2, [R1]
000d5c: 04B0             ADD             SP, #16
000d5e: BDE88040         LDMIA.W         R13!, {R7, R14}
000d62: 04B0             ADD             SP, #16
000d64: 7047             BX              R14
000d66: C046             MOV             R8, R8
000d68:              $d:
000d68:              $C$CON1:
000d68: F30D            .half		 0x0DF3
000d6a: 0000            .half		 0x0000
000d6c:              $C$CON2:
000d6c: 4B0E            .half		 0x0E4B
000d6e: 0000            .half		 0x0000

However the output from armofd -cg, which is extracted from the debug information and forms the input to the CCS Stack Usage view, shows sprintf is shown as calling __TI_printfi, rather than the actual __TI_printfi_nofloat which is linked to the program:

~/ti/ccs810/ccsv8/tools/compiler/ti-cgt-arm_18.1.3.LTS/bin/armofd -cg TM4C_sprintf_stack_usage.out 
<?xml version="1.0" encoding="ISO-8859-1" ?>
<ofd>
   <banner>TI ARM Object File Display Unix v18.1.3.LTS</banner>
   <copyright>Copyright (c) 1996-2017 Texas Instruments Incorporated</copyright>
   <name>TM4C_sprintf_stack_usage.out</name>
   <call_graph>
      <function>
         <name>sprintf</name>
         <stack_size>0x28</stack_size>
         <makes_indirect_call>false</makes_indirect_call>
         <file>sprintf.c</file>
         <line>0x40</line>
         <address>0xd30</address>
         <is_combined>false</is_combined>
         <definition_seen>true</definition_seen>
         <has_stack_usage_info>true</has_stack_usage_info>
         <producer>TI TI ARM C/C++ Codegen Unix v18.1.3.LTS Copyright (c) 1996-2017 Texas Instruments Incorporated</producer>
         <callee>__TI_printfi</callee>
      </function>

I think the TI linker needs to be changed so that when --printf_support changes the actual implementation of the __TI_printfi function in the RTS which gets linked, that the debug information is updated accordingly so programs which process the call graph to determine the worst case stack usage can follow the actual called functions.

6708.6443.TM4C_sprintf_stack_usage.zip

Thanks to Chester Gillon for a test case.  I used it to analyze the situation.  I agree with his analysis ...

Chester Gillon said:

I think the TI linker needs to be changed so that when --printf_support changes the actual implementation of the __TI_printfi function in the RTS which gets linked, that the debug information is updated accordingly so programs which process the call graph to determine the worst case stack usage can follow the actual called functions.

I filed CODEGEN-5179 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