Re: Fix AArch64 "$x" symbols

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?

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