Please note: We are aware of an issue affecting replies on the Arm Community forums, which may not be loading as expected.

We apologize for any inconvenience and appreciate your patience while we investigate and work to resolve the issue.

Thank you for your understanding.

  • State Accepted Answer
  • Locked Locked
  • Replies 1 reply
  • Subscribers 119 subscribers
  • Views 1376 views
  • Users 0 members are here
Options
Related
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Two Call Path When There Is Only One Function Call When Using Streamline

NoahZuo

Hi,

I am currently profiling performance using streamline, whose version is 7.8.0.

We have a function: `Dummy_BuildAnimTrackPairs_Switch` and this function is only called in function `BuildAnimTrackPairs` in worker thread.

But it is strange that there are two call paths of `Dummy_BuildAnimTrackPairs_Switch` with different sample number in `Call Paths` tab like this:

What does this mean please? Is one of them the function-call overhead?

Parents
  • +1 Arm Employee Badge

    Hi NoahZuo

    This most likely just means that the kernel's unwinder did not correctly unwind the call stack; the unwinder is very simple and expects a fixed stack frame layout when unwinding. There is a small chance the sample landed in the function prologue/epilogue, or as a side affect of how the compiler might have performed inlining, or if the compiler had introduced a tail call, or some other similar optimisation, then the frame layout on the stack / contents of LR may not have been as the unwinder expected causing it to miss the parent function.

    I'd suggest that if you know that `Dummy_BuildAnimTrackPairs_Switch` is only ever called from `BuildAnimTrackPairs`, then you treat those two entries as the same call path.

    HTH
    Ben

Reply
  • +1 Arm Employee Badge

    Hi NoahZuo

    This most likely just means that the kernel's unwinder did not correctly unwind the call stack; the unwinder is very simple and expects a fixed stack frame layout when unwinding. There is a small chance the sample landed in the function prologue/epilogue, or as a side affect of how the compiler might have performed inlining, or if the compiler had introduced a tail call, or some other similar optimisation, then the frame layout on the stack / contents of LR may not have been as the unwinder expected causing it to miss the parent function.

    I'd suggest that if you know that `Dummy_BuildAnimTrackPairs_Switch` is only ever called from `BuildAnimTrackPairs`, then you treat those two entries as the same call path.

    HTH
    Ben

Children
No data