Re: [RFC] propagating symtab load errors. was: Re: [GIT PULL 00/20] perf/core improvements and fixes

[Jiri Olsa <jolsa@redhat.com>]

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