We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Hi all
I'm developing on an A53 based platform, and I'm trying to use streamline to profile my (embedded) Linux application.
I can successfully connect streamline to my target and see data being collected live by the gator daemon and gator kernel module.
When I analyze my recorded data, given the application code and shared libraries it uses - I see weird behavior:
When I analyze with the application binary - I can see call stack and source code for the parts in my application that are originated in the "main" source code.
When I re-analyze with the application binary and library X that it is using - I can see call stack and source code for the parts in my application that are originated from the "main" source code and the libraries I analyzed with.
BUT - when I re-analyze by adding library Y as well - I can't see any call stack for code related to library Y, but I also cannot see code related to library X nor to the "main" source code.
Analyzing with library Y alone also fails displaying call stack. So I suppose the problem is somewhere between library Y and streamline - but why does it affect library X source tracing as well?
This problem disappear when I remove all optimization flags from the compilation command line - in which case I can see all call stacks. But I cannot measure the actual run time obviously.
I've been trying hard to root cause this behavior by changing optimization flags, but the fact is that even adding "-O" brings this problem to life.
Needless to say I added the -fno-omit-frame-pointer flag everywhere.
Streamline error log looks clean, and I don't get any relevant indication for this failure.
I verified I'm analyzing with the correct libraries (by running the application with strace and verifying paths)
I verified I don't do any direct static linking to my app.
What am I missing?
Streamline: version 5.26.2 (Version 6.1.0, Build 20161110_164139)
Compiler: aarch64-linux-gnu-g++ (Linaro GCC 2014.11) 4.9.3 20141031 (prerelease)
Thanks,
Ofer
Hi Ofer,
As advised in the support case we believe the issue is related to one of your libraries (libnn_light.so). Please try to rebuild using the following flags:
libnn_light.so
-fno-inline
-fno-optimize-sibling-calls
These are described here.
Thanks, Otilia