From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1752625AbbCXNSX (ORCPT <rfc822;w@1wt.eu>);
	Tue, 24 Mar 2015 09:18:23 -0400
Received: from mx1.redhat.com ([209.132.183.28]:58566 "EHLO mx1.redhat.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1752580AbbCXNSU (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Tue, 24 Mar 2015 09:18:20 -0400
Date: Tue, 24 Mar 2015 14:16:56 +0100
From: Jiri Olsa <jolsa@redhat.com>
To: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: Ingo Molnar <mingo@kernel.org>, Jiri Olsa <jolsa@kernel.org>,
        Namhyung Kim <namhyung@kernel.org>, linux-kernel@vger.kernel.org,
        Adrian Hunter <adrian.hunter@intel.com>,
        Andi Kleen <ak@linux.intel.com>, Borislav Petkov <bp@suse.de>,
        David Ahern <david.ahern@oracle.com>, Don Zickus <dzickus@redhat.com>,
        Frederic Weisbecker <fweisbec@gmail.com>,
        He Kuang <hekuang@huawei.com>, "H . Peter Anvin" <hpa@zytor.com>,
        Kaixu Xia <xiakaixu@huawei.com>, Kan Liang <kan.liang@intel.com>,
        Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>,
        Naohiro Aota <naota@elisp.net>, Peter Zijlstra <peterz@infradead.org>,
        Stephane Eranian <eranian@google.com>,
        "Suzuki K . Poulose" <suzuki.poulose@arm.com>,
        Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [RFC] propagating symtab load errors. was: Re: [GIT PULL 00/20]
 perf/core improvements and fixes
Message-ID: <20150324131656.GD5337@krava.brq.redhat.com>
References: <1425353169-21436-1-git-send-email-acme@kernel.org>
 <20150310100331.GA20950@gmail.com>
 <20150323221837.GA30343@kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20150323221837.GA30343@kernel.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Mon, Mar 23, 2015 at 07:18:37PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Tue, Mar 10, 2015 at 11:03:31AM +0100, Ingo Molnar escreveu:
> > So I got this error today:
> > 
> >                     ┌─Warning:───────────────────────────┐
> >                     │The vmlinux file can't be used.     │
> >                     │Kernel samples will not be resolved.│
> >                     │                                    │
> >                     │                                    │
> >                     │Press any key...                    │
> >                     └────────────────────────────────────┘
> > ... and sadly perf is being passive-aggressive again: being negative 
> > but refusing to say why! :-)
> > 
> > Is there a way to figure out why it did not like the vmlinux?
> 
> So, we need some infrastructure for that, i.e. a strerror like routine
> like we have for other classes, because there are lots of things that
> can go wrong while loading a file: ELF error, decompression stuff, you
> name it, so, with the patch below it ends up as:
> 
> 
> # perf top --vmlinux /dev/null
> 
>            ┌─Warning:───────────────────────────────────────────┐
>            │The /tmp/passwd file can't be used: Invalid ELF file│
>            │Kernel samples will not be resolved.                │
>            │                                                    │
>            │                                                    │
>            │Press any key...                                    │
>            └────────────────────────────────────────────────────┘
> 
> 
> Basically save the errno, that may be an elf_errno (in this case I just came up
> with a DSO_LOAD_ERRNO__INVALID_ELF), an errno or some other error that needs
> propagating.
> 
> Just a heads up, I'll polish it a bit more before submitting, sounds OK?
> 
> Jiri, Namhyung, this would go down to the decompression code, etc.
> 
> Right now some of this can be obtained via the pr_debug calls, but that is too
> ä passive aggressive, and we don't want to do the error report syncronously,
> this is up for the tools/UI used, so saving it and providing a strerror routine
> looks sane, right?

right, DSO_LOAD_ERRNO__DECOMPRESSION_FAILURE seems ok

jirka