Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752001AbcJJKS7 (ORCPT ); Mon, 10 Oct 2016 06:18:59 -0400 Received: from hr2.samba.org ([144.76.82.148]:35890 "EHLO hr2.samba.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752045AbcJJKS6 (ORCPT ); Mon, 10 Oct 2016 06:18:58 -0400 Date: Mon, 10 Oct 2016 21:18:12 +1100 From: Anton Blanchard To: Michael Ellerman Cc: Benjamin Herrenschmidt , Paul Mackerras , Nicholas Piggin , ravi.bangoria@linux.vnet.ibm.com, acme@redhat.com, peterz@infradead.org, mingo@redhat.com, alexander.shishkin@linux.intel.com, linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org Subject: Re: perf TUI fails with "failed to process type: 64" Message-ID: <20161010211812.13eb89d5@kryten> In-Reply-To: <874m4k7q5s.fsf@concordia.ellerman.id.au> References: <20161009121232.174915eb@kryten> <874m4k7q5s.fsf@concordia.ellerman.id.au> X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.30; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 996 Lines: 38 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