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