Re: Fix AArch64 "$x" symbols

On 07/31/2014 05:43 AM, Andrew Haley wrote:
> On 07/30/2014 11:15 PM, Maynard Johnson wrote:
> 
>> This seems to be just applying a band aid to the problem.  We end up
>> losing samples that were incorrectly attributed to this special
>> symbol, right? Those samples are probably for a real symbol I would
>> expect.  Is there any way to figure that out?
> 
> I don't know what's going on at this level.  Does perf do the mapping
> from addresses to symbols, or is that done later by oprofile?  I
> haven't yet been able to find the code which takes an address and
> figures out which symbol that address maps to.
Hi, Andrew,
It may turn out that, due to sampling skid (where sample addresses can be off by a few instructions, we just simply can't avoid attributing a small number of samples to this $x symbol.  In your initial posting on the topic, the percentages for $x samples were very low.  Do you ever see a relatively high percentage of samples for $x symbols?  Or, if you were to total up all samples for $x symbols, is it a relatively high number compared to the total samples?  If the answer is "no", it's never a high percentage of samples being attributed to $x symbols, then the best way to handle this is to filter them out at the point where we first gather the symbols for the op_bfd object.  Look at the libutil++/bfd_support.cpp:interesting_symbol function.  As a matter of fact, you'll see where we already
  filter out some ARM assembler internal mapping symbols.  On the other hand, if the percentage of samples you'd be throwing away is pretty high, then further debugging is needed . . . so co!
 ntinue rea
ding the "OPROFILE INTERNALS" part of my reply.

OPROFILE INTERNALS
------------------
When you run one of oprofile's post-profiling tools (e.g., opreport), it identifies all of the binary files (executables, shared libs) for which samples have been collected.  For each binary, an "op_bfd" object is created, which is backed by a bfd obtained from libbfd via the bfd_fdopenr() function. It's during the construction of the op_bfd object that the symbols for the corresponding binary are gathered, using libbfd functions.  Then, in libpp/profile_container.cpp:add, for a given op_bfd object, oprofile iterates over the symbols and matches up the addresses of profile samples with each symbol.  In particular, when "abfd.get_symbol_range()" is called for the symbol "$x" to get the start and end addresses, we use profile.samples_range() to get an iterator pair to accumulate the samples 
 that fit in that range.  And evidently, the count of samples returned from accumulate for $x is non-zero!  Your patch simply throws away those samples. 

I suggest running opreport with the "--verbose=all --symbols" and search for the debug output for "$x" symbol which will give you the start and end addresses for it.  How big is the range?  Is the range accurate? Then do an 'objdump -d' on one of these binaries having a $x symbol and try to figure out if libbfd is handling this symbol properly.


-Maynard
> 
> Andrew.
> 


------------------------------------------------------------------------------
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls. 
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk