From: Jiri Olsa <jolsa@redhat.com>
To: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: "Jin, Yao" <yao.jin@linux.intel.com>,
jolsa@kernel.org, peterz@infradead.org, mingo@redhat.com,
alexander.shishkin@linux.intel.com, Linux-kernel@vger.kernel.org,
ak@linux.intel.com, kan.liang@intel.com, yao.jin@intel.com
Subject: Re: [PATCH] perf util: Display warning when perf report/annotate is missing some libs
Date: Wed, 21 Mar 2018 20:02:33 +0100 [thread overview]
Message-ID: <20180321190233.GG2707@krava> (raw)
In-Reply-To: <20180321185237.GF24312@kernel.org>
On Wed, Mar 21, 2018 at 03:52:37PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Wed, Mar 21, 2018 at 05:04:46PM +0100, Jiri Olsa escreveu:
> > On Wed, Mar 21, 2018 at 12:43:15PM -0300, Arnaldo Carvalho de Melo wrote:
> > > Em Wed, Mar 21, 2018 at 12:40:35PM -0300, Arnaldo Carvalho de Melo escreveu:
> > > > Em Wed, Mar 21, 2018 at 04:38:07PM +0100, Jiri Olsa escreveu:
> > > > > On Wed, Mar 21, 2018 at 10:11:10AM +0800, Jin, Yao wrote:
> > > > > > Hi Jiri,
> > > > > >
> > > > > > I'm still thinking it's worth displaying the warning when perf missing some
> > > > > > libraries.
> > > > > >
> > > > > > Somebody just told me that perf didn't work well. While after some
> > > > > > investigations, I found it's just missing some libraries when building the
> > > > > > perf.
> > > > > >
> > > > > > But I have spent some time on getting the root cause. If with this patch, it
> > > > > > should be very easily to know that.
>
> > > > > true.. Arnaldo, any feedback on this one?
>
> > > > Lemme re-read the thread...
>
> > > Well, how about we make it harder to build without key libraries? I.e.
> > > if we detect that what we consider a core set of libraries isn't found
> > > in the system, then we stop the build, warn about it and ask the user to
> > > confirm that the build should proceed by passing some explicit
> > > -DI_KNOW_WHAT_I_AM_DOING___PROCEED=doit
>
> > hum, not sure we want to complicate the build even more than it
> > is now :-\ and IMO it still won't help much in Jin's problem,
> > if user forces the build anyway
>
> Well, if a user _forces_ a build, not taking into consideration a
> warning that _is_ emitted and _stops_ the build, about the functionality
> it will lose by doing forcing the build, then comes back and complains
> that that functionality is not present, then it becomes difficult to
> help this user... :-)
>
> On the other hand, if the user forgets to install an important library,
> the warning is emitted but the build proceeds, no explicit action was
> performed, just a warning wasn't noticed, and the user complains, then
> I'd say: "hey, are you sure library foo devel files were present when
> you build it?", i.e. the support back and forth Jin is trying to avoid.
>
> And for users that _saw_ the warning, _knew_ they _didn't_ want that
> functionality, to be reminded while running, say 'perf report' that
> something they _decided not to have_ isn't present, then that could be
> annoying, no?
>
> Lemme try another idea: what if we do something like gcc does and print
> the features present when showing the version?
>
> I.e.:
>
> [acme@jouet perf]$ gcc -v
> Using built-in specs.
> COLLECT_GCC=/usr/bin/gcc
> COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/7/lto-wrapper
> OFFLOAD_TARGET_NAMES=nvptx-none
> OFFLOAD_TARGET_DEFAULT=1
> Target: x86_64-redhat-linux
> Configured with: ../configure --enable-bootstrap --enable-languages=c,c++,objc,obj-c++,fortran,ada,go,lto --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared --enable-threads=posix --enable-checking=release --enable-multilib --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-gcc-major-version-only --with-linker-hash-style=gnu --enable-plugin --enable-initfini-array --with-isl --enable-libmpx --enable-offload-targets=nvptx-none --without-cuda-driver --enable-gnu-indirect-function --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
> Thread model: posix
> gcc version 7.3.1 20180303 (Red Hat 7.3.1-5) (GCC)
> [acme@jouet perf]$
>
> - Arnaldo
yep I guess you overlooked it in my previous reply ;-)
jirka
---
> how about displaying libraries separately with -vv output,
> that would mimic the build message, like:
>
> $ ./perf -vv
> perf version 4.16.rc6.g18fd48
>
> dwarf: [ on ]
> dwarf_getlocations: [ on ]
> glibc: [ on ]
> gtk2: [ on ]
> libaudit: [ on ]
> libbfd: [ on ]
> libelf: [ on ]
> libnuma: [ on ]
> numa_num_possible_cpus: [ on ]
> libperl: [ on ]
> libpython: [ on ]
> libslang: [ on ]
> libcrypto: [ on ]
> libunwind: [ on ]
> libdw-dwarf-unwind: [ on ]
> zlib: [ on ]
> lzma: [ on ]
> get_cpuid: [ on ]
> bpf: [ on ]
>
> and perf -vvv could display the 'make VF=1' info
>
> jirka
next prev parent reply other threads:[~2018-03-21 19:02 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-11 11:03 [PATCH] perf util: Display warning when perf report/annotate is missing some libs Jin Yao
2018-01-11 15:30 ` Jiri Olsa
2018-01-12 2:22 ` Jin, Yao
2018-03-21 2:11 ` Jin, Yao
2018-03-21 15:38 ` Jiri Olsa
2018-03-21 15:40 ` Arnaldo Carvalho de Melo
2018-03-21 15:43 ` Arnaldo Carvalho de Melo
2018-03-21 15:45 ` Arnaldo Carvalho de Melo
2018-03-21 16:04 ` Jiri Olsa
2018-03-21 18:52 ` Arnaldo Carvalho de Melo
2018-03-21 19:02 ` Jiri Olsa [this message]
2018-03-22 1:31 ` Jin, Yao
2018-03-22 1:04 ` Jin, Yao
2018-03-22 8:51 ` Jiri Olsa
2018-03-23 3:09 ` Jin, Yao
2018-03-23 14:50 ` Arnaldo Carvalho de Melo
2018-03-23 15:17 ` Jiri Olsa
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180321190233.GG2707@krava \
--to=jolsa@redhat.com \
--cc=Linux-kernel@vger.kernel.org \
--cc=acme@kernel.org \
--cc=ak@linux.intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=jolsa@kernel.org \
--cc=kan.liang@intel.com \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=yao.jin@intel.com \
--cc=yao.jin@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.