Re: Fix AArch64 "$x" symbols

On 07/31/2014 04:21 AM, Andrew Haley wrote:
> On 30/07/14 23:15, Maynard Johnson wrote:
>> On 07/30/2014 11:37 AM, Andrew Haley wrote:
>>> There's a bug in Oprofile for AArch64 where "opreport -l" prints out lots
>>> of symbols as "x".  Like this:
>>>
>>> 21690    604433         1.0010  27.8939    libjvm.so                PhaseChaitin::build_ifg_physical(ResourceArea*)
>>> 20856    625289         0.9625  28.8564    libjvm.so                ConnectionGraph::add_fields_to_worklist(FieldNode*, PointsToNode*)
>>> 20707    645996         0.9556  29.8120    libjvm.so                $x
>>> 19824    665820         0.9149  30.7269    libjvm.so                PhaseIdealLoop::is_dominator(Node*, Node*)
>>> 19483    685303         0.8991  31.6260    libjvm.so                $x
>>> 17863    703166         0.8244  32.4504    libjvm.so                SymbolTable::lookup_only(char const*, int, unsigned int&)
>>> 17530    720696         0.8090  33.2593    libjvm.so                PhaseChaitin::interfere_with_live(unsigned int, IndexSet*)
>>> 16381    737077         0.7560  34.0153    libjvm.so                PhaseIdealLoop::Dominators()
>>> 16124    753201         0.7441  34.7594    libjvm.so                MachNode::rematerialize() const
>>> 15886    769087         0.7331  35.4925    libjvm.so                SpinPause
>>> 14797    783884         0.6829  36.1754    libjvm.so                $x
>>>
>>>
>>> It turns out that these "$x" symbols aren't symbols at all, but
>>> "mapping symbols".  The AArch64 ELF specification requires that
>>> special symbols be inserted into object files to mark certain
>>> features:
>>>
>>> $x
>>>     At the start of a region of code containing AArch64 instructions.
>>>
>>> $d
>>>     At the start of a region of data.
>>>
>>> These symbols should be ignored by tools.  The fix in Oprofile is
>>> trivial:
>>>
>>> diff --git a/libpp/profile_container.cpp b/libpp/profile_container.cpp
>>> index e543f51..ec8438c 100644
>>> --- a/libpp/profile_container.cpp
>>> +++ b/libpp/profile_container.cpp
>>> @@ -81,6 +81,9 @@ void profile_container::add(profile_t const & profile,
>>>
>>>         for (symbol_index_t i = 0; i < abfd.syms.size(); ++i) {
>>>
>>> +               if (abfd.syms[i].name() == "$x")
>>> +                       continue;
> 
>> 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?
> 


Hi Andrew,

Have you tried running the same experiment on x86-64 and compared the resulting output?  I suspect that the "$x" map to some methods but for some reason oprofile is not getting the right location/name and ends up with "$x".  It would be good to compare the output to get some clue what "$x" might be.  You might also use "opreport --detail --symbols" to see where the samples are actually recorded and see where those $x functions are being located.  The "--detail" will provide a huge amount of output.

The sample skid is unlikely to be causing the problem.  That would just be different address in the same method or another method, so it should still have a mapping for the real method name.

-Will

> I don't really know Oprofile well enough.  I take it that those symbols
> are read earlier in the process?  Al  we need to do is throw them away
> at that stage.  I'll have a look.
> 
> 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