[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 10 Oct 2016 21:18:12 +1100
From: Anton Blanchard <anton@...ba.org>
To: Michael Ellerman <mpe@...erman.id.au>
Cc: Benjamin Herrenschmidt <benh@...nel.crashing.org>,
Paul Mackerras <paulus@...ba.org>,
Nicholas Piggin <npiggin@...il.com>,
ravi.bangoria@...ux.vnet.ibm.com, acme@...hat.com,
peterz@...radead.org, mingo@...hat.com,
alexander.shishkin@...ux.intel.com, linux-kernel@...r.kernel.org,
linuxppc-dev@...ts.ozlabs.org
Subject: Re: perf TUI fails with "failed to process type: 64"
Hi Michael,
> > 14c00-14c00 g exc_virt_0x4c00_system_call
> ^
> What's this? The address? If so it's wrong?
Offset into the binary I think, there's one 64kB page of ELF gunk at
the start.
> Seems likely. But I can't see why.
>
> AFAICS we have never emitted a size for those symbols:
>
> Old:
> $ nm --print-size build/vmlinux | grep -w system_call_relon_pSeries
> c000000000004c00 T system_call_relon_pSeries
>
> New:
> $ nm --print-size build/vmlinux | grep -w exc_virt_0x4c00_system_call
> c000000000004c00 T exc_virt_0x4c00_system_call
>
>
> It also doesn't look like we're emitting another symbol with the same
> address, which has caused confusion in the past:
>
> Old:
> c000000000004c00 T exc_virt_0x4c00_system_call
> c000000000004d00 T exc_virt_0x4d00_single_step
>
> New:
> c000000000004c00 T system_call_relon_pSeries
> c000000000004d00 T single_step_relon_pSeries
>
> So more digging required.
Thanks for checking, it's starting to sound like a perf bug.
Anton
Powered by blists - more mailing lists