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

Hi Will,
 
Thanks for your prompt response.
 
The use case we had is to profile a program which is stripped for symbols.
But we can have the debug_info file of the same build.
 
Going through what you suggested below to move the analysis part to other compatible machine.
Will it work the following way that I understand ?
 
1. Run the oprofile on my program(without symbols)
2. perform 'oparchive' on this profile to collect the profile data, and respective executables and debug_info files.
3. Move/transfer the captured data to a Host system.
4. install/include the associated debug info to the archied data tree (Though not sure how I can do this !!)
5. then run 'opreport' on this archived profiling data
 
We have the flexibilty to profile the archived data on the same target system, but by adding symbol files to the tree.
 
Please let me know if I have gone anything wrong here.
 
BR
Srini

 
> Subject: Re: Oprofile support - read symbol table of the binary separately ??
> To: [email protected]; [email protected]
> From: [email protected]
> Date: Tue, 8 Sep 2015 11:43:32 -0400
> 
> 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

------------------------------------------------------------------------------
Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
Get real-time metrics from all of your servers, apps and tools
in one place.
SourceForge users - Click here to start your Free Trial of Datadog now!
http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140

_______________________________________________
oprofile-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/oprofile-list