C29-CGT: c29ofd --call_graph misses compiler inserted functions from callee lists

Part Number: C29-CGT

The c29ofd utility with `--call_graph` (as of v2.2.2.LTS) correctly shows that compiler inserted functions (like `__udivsi3` or `__muldf3`) are included in the binary by including them in the list of functions and correctly reports their individual stack usage, for example:

<function>
    <name>__muldf3</name>
    <stack_size>0x50</stack_size>
    <makes_indirect_call>false</makes_indirect_call>
    <file>muldf3.c</file>
    <line>0x11</line>
    <address>0x201041a0</address>
    <is_combined>false</is_combined>
    <definition_seen>true</definition_seen>
    <has_stack_usage_info>true</has_stack_usage_info>
    <producer>TI clang version 22.1.8 (ssh://git@bitbucket.itg.ti.com/code/llvm-project.git 2abc17f66b23b994165bf064ce86bacb596942d3)</producer>
</function>

However, it misses them from the `<callee>` list of functions that use them which can result in a lower than true calculated max stack usage. This is generally not a massive issue because most of these functions don't have stack usage themselves (such as `__udivsi3`), but something like `__muldf3` (double float multiply) uses 80 bytes of stack, which then gets missed from calculations and views like 'Stack Usage' in CCS. For example I added a double multiply to `main` (with volatiles to prevent it from being optimised out), and it is visible in the generated assembly, but `c29ofd` reports:

<function>
    <name>main</name>
    <stack_size>0x0</stack_size>
    <makes_indirect_call>false</makes_indirect_call>
    <file>../main_cpu2.c</file>
    <line>0x29</line>
    <address>0x2010a1f0</address>
    <is_combined>false</is_combined>
    <definition_seen>true</definition_seen>
    <has_stack_usage_info>true</has_stack_usage_info>
    <producer>TI clang version 22.1.8 (ssh://git@bitbucket.itg.ti.com/code/llvm-project.git 2abc17f66b23b994165bf064ce86bacb596942d3)</producer>
    <callee>Device_Init</callee>
    <callee>IPC_Sync</callee>
    <callee>InitPeripherals_Init</callee>
    <callee>ApplicationInputsOutputs_Initialise</callee>
</function>
  • Thank you for notifying us of this problem.  I am unable to reproduce this exact behavior.  But I did create a test case which shows very similar behavior.  I filed the entry EXT_EP-13680 to have this investigated.  You are welcome to follow it with that link.

    Thanks and regards,

    -George