Re: Oprofile support - read symbol table of the binary separately ??

On 09/08/2015 09:19 AM, Srinivas Manem wrote:
>  
> 
> Hi Group,
> 
>  
> 
> I would like to hear any suggestions or solution for the functional use of the *oprofile* for my use case.
> 
>  
> 
> Is it possible to profile on a binary (without symbol table), but a way to provide the symbol file of the running binary externally or separately ?
> 
> (To put that  more simple, I would like to profile on a program which is without symbol table, but flexible enough to provide the symbol file with any other option.)
> 
>  
> 
> Something like this:
> 
> *>> opreport -l -dg test/bin/sample_exe  -i sample_exe.debug_info*
> 
> Where sample_exe is the binary to profile
> 
> Sample_exe.debug_info is the symbol file of above binary.
> 
>  
> 
> Or any other suggestion from members ?
> 
>  
> 
> Thanks in advance for any help !!
> 
>  
> 
> BR
> 
> Srinivas

Hi Srinivas,

On Fedora and other distributions the executable is compiled with the gcc "-g" option which generates the executable and then when building the package the executable has the debuginfo stripped out and placed in a separate file.  The original binary has a link to the separate debug info.  For this work the debuginfo must be from the same compile for the checksum or build-id checks to work.  You can't build the package without debugging info and then use a debug info from another build because checksum and build-id are going to differ.

Is space limitations the reason for not having the symbol information? You could move the analysis over to a machine with more space using oparchive and install the associated debuginfo in the tree that oparchive produced to do the analysis.  http://oprofile.sourceforge.net/doc/oparchive.html

There were some additions to oprofile to allow it to make use of the /proc/kallsyms for mapping samples to functions in the kernel:

http://sourceforge.net/p/oprofile/oprofile/ci/a5f539c58be9e278b4397d64d8dd65f46f291860/
http://sourceforge.net/p/oprofile/oprofile/ci/4f3e2555289273f682013cfe16c38d16bdd1e4c5/

Maybe those could be extended to binaries other than the vmlinux.

-Will

------------------------------------------------------------------------------