Re: Fix AArch64 "$x" symbols

[Andrew H. <ap...@re...>]

On 07/31/2014 02:42 PM, Maynard Johnson wrote:
> 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.

> 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.

Why?  As far as I'm aware the $x symbols only ever overlap real
symbols -- they are never the only symbol that refers to an object --
so they can just be ignored, and we could pick the true symbols
instead..

> In your initial posting on the topic, the percentages for $x samples
> were very low.

Some of them were as much as 1% of the total run time.  The total
attributed to "$x" symbols is maybe 5%.

> 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 continue 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.

OK, will do.

Thanks,
Andrew.