[GIT PULL 0/4] perf/urgent fixes

[GIT PULL 0/4] perf/urgent fixes

[Jiri Olsa]

hi Ingo,
please consider pulling

thanks,
jirka


The following changes since commit fd741edc25600e1660abd00b5c1bbe967018c6a0:

  Merge tag 'perf-urgent-for-mingo' of git://git.kernel.org/pub/scm/linux/kernel/git/jolsa/perf into perf/urgent (2014-04-20 09:53:55 +0200)

are available in the git repository at:


  git://git.kernel.org/pub/scm/linux/kernel/git/jolsa/perf.git tags/perf-urgent-for-mingo

for you to fetch changes up to de04f8657de9d3351a2d5880f1f7080b23b798cf:

  tools lib traceevent: Fix memory leak in pretty_print() (2014-04-23 13:19:30 +0200)

----------------------------------------------------------------
perf/urgent fixes:

Developer stuff:
. Fix memory leak and backward compatibility macros for pevent
  filter enums in traceevent library (Steven Rostedt)

. Disable libdw unwind for all but x86 arch (Jiri Olsa)

. Fix memory leak in sample_ustack (Masanari Iida)

Signed-off-by: Jiri Olsa <jolsa@redhat.com>

----------------------------------------------------------------
Jiri Olsa (1):
      perf tools: Disable libdw unwind for all but x86 arch

Masanari Iida (1):
      perf tests x86: Fix memory leak in sample_ustack()

Steven Rostedt (2):
      tools lib traceevent: Fix backward compatibility macros for pevent filter enums
      tools lib traceevent: Fix memory leak in pretty_print()

 tools/lib/traceevent/event-parse.c       | 1 +
 tools/lib/traceevent/event-parse.h       | 4 ++--
 tools/perf/arch/x86/tests/dwarf-unwind.c | 1 +
 tools/perf/config/Makefile               | 8 ++++++++
 4 files changed, 12 insertions(+), 2 deletions(-)

[PATCH 1/4] perf tests x86: Fix memory leak in sample_ustack()

[Jiri Olsa]

From: Masanari Iida <standby24x7@gmail.com>

The buf is not freed, when kernel failed to get stack map
and return.

Signed-off-by: Masanari Iida <standby24x7@gmail.com>
Link: http://lkml.kernel.org/r/1398091024-7901-1-git-send-email-standby24x7@gmail.com
Signed-off-by: Jiri Olsa <jolsa@redhat.com>
---
 tools/perf/arch/x86/tests/dwarf-unwind.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tools/perf/arch/x86/tests/dwarf-unwind.c b/tools/perf/arch/x86/tests/dwarf-unwind.c
index b602ad9..b8c0102 100644
--- a/tools/perf/arch/x86/tests/dwarf-unwind.c
+++ b/tools/perf/arch/x86/tests/dwarf-unwind.c
@@ -26,6 +26,7 @@ static int sample_ustack(struct perf_sample *sample,
 	map = map_groups__find(&thread->mg, MAP__FUNCTION, (u64) sp);
 	if (!map) {
 		pr_debug("failed to get stack map\n");
+		free(buf);
 		return -1;
 	}
 
-- 
1.8.3.1

[PATCH 2/4] perf tools: Disable libdw unwind for all but x86 arch

[Jiri Olsa]

So far there's only x86 libdw unwind support merged in perf.
Disable it on all other architectures in case libdw unwind
support is detected in system.

Cc: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
Cc: Corey Ashford <cjashfor@linux.vnet.ibm.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Jean Pihet <jean.pihet@linaro.org>
Cc: Josh Boyer <jwboyer@fedoraproject.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/1397988006-14158-1-git-send-email-jolsa@redhat.com
Signed-off-by: Jiri Olsa <jolsa@redhat.com>
---
 tools/perf/config/Makefile | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/tools/perf/config/Makefile b/tools/perf/config/Makefile
index ee21fa9..a71fb39 100644
--- a/tools/perf/config/Makefile
+++ b/tools/perf/config/Makefile
@@ -34,6 +34,14 @@ ifeq ($(ARCH),arm)
   LIBUNWIND_LIBS = -lunwind -lunwind-arm
 endif
 
+# So far there's only x86 libdw unwind support merged in perf.
+# Disable it on all other architectures in case libdw unwind
+# support is detected in system. Add supported architectures
+# to the check.
+ifneq ($(ARCH),x86)
+  NO_LIBDW_DWARF_UNWIND := 1
+endif
+
 ifeq ($(LIBUNWIND_LIBS),)
   NO_LIBUNWIND := 1
 else
-- 
1.8.3.1

[PATCH 3/4] tools lib traceevent: Fix backward compatibility macros for pevent filter enums

[Jiri Olsa]

From: Steven Rostedt <rostedt@goodmis.org>

The return value for pevent_filter_match() is suppose to return FILTER_NONE
if the event doesn't have a filter, and FILTER_NOEXIST if there is no filter
at all. But the change 41e12e580a7 "tools lib traceevent: Refactor
pevent_filter_match() to get rid of die()" replaced the return value
with PEVENT_ERRNO__* values and added "backward compatibility" macros
that used the old names. Unfortunately, the NOEXIST and NONE macros were
swapped, and this broke users that use the old return names.

Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Link: http://lkml.kernel.org/r/20140421222346.0351ced4@gandalf.local.home
Signed-off-by: Jiri Olsa <jolsa@redhat.com>
---
 tools/lib/traceevent/event-parse.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/lib/traceevent/event-parse.h b/tools/lib/traceevent/event-parse.h
index 791c539..feab942 100644
--- a/tools/lib/traceevent/event-parse.h
+++ b/tools/lib/traceevent/event-parse.h
@@ -876,8 +876,8 @@ struct event_filter {
 struct event_filter *pevent_filter_alloc(struct pevent *pevent);
 
 /* for backward compatibility */
-#define FILTER_NONE		PEVENT_ERRNO__FILTER_NOT_FOUND
-#define FILTER_NOEXIST		PEVENT_ERRNO__NO_FILTER
+#define FILTER_NONE		PEVENT_ERRNO__NO_FILTER
+#define FILTER_NOEXIST		PEVENT_ERRNO__FILTER_NOT_FOUND
 #define FILTER_MISS		PEVENT_ERRNO__FILTER_MISS
 #define FILTER_MATCH		PEVENT_ERRNO__FILTER_MATCH
 
-- 
1.8.3.1

[PATCH 4/4] tools lib traceevent: Fix memory leak in pretty_print()

[Jiri Olsa]

From: Steven Rostedt <rostedt@goodmis.org>

Commit 12e55569a244 "tools lib traceevent: Use helper trace-seq in print
functions like kernel does" added a extra trace_seq helper to process
string arguments like the kernel does it. But the difference between the
kernel and the userspace library is that the kernel's trace_seq structure
has a static allocated buffer. The userspace one has a dynamically
allocated one. It requires a trace_seq_destroy(), otherwise it produces
a nasty memory leak.

Cc: stable@vger.kernel.org # 3.14+
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Link: http://lkml.kernel.org/r/20140422192330.6bb09bf8@gandalf.local.home
Signed-off-by: Jiri Olsa <jolsa@redhat.com>
---
 tools/lib/traceevent/event-parse.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tools/lib/traceevent/event-parse.c b/tools/lib/traceevent/event-parse.c
index baec7d8..b83184f 100644
--- a/tools/lib/traceevent/event-parse.c
+++ b/tools/lib/traceevent/event-parse.c
@@ -4344,6 +4344,7 @@ static void pretty_print(struct trace_seq *s, void *data, int size, struct event
 					      format, len_arg, arg);
 				trace_seq_terminate(&p);
 				trace_seq_puts(s, p.buffer);
+				trace_seq_destroy(&p);
 				arg = arg->next;
 				break;
 			default:
-- 
1.8.3.1

Re: [GIT PULL 0/4] perf/urgent fixes

[Ingo Molnar]

* Jiri Olsa <jolsa@redhat.com> wrote:

> hi Ingo,
> please consider pulling
> 
> thanks,
> jirka
> 
> 
> The following changes since commit fd741edc25600e1660abd00b5c1bbe967018c6a0:
> 
>   Merge tag 'perf-urgent-for-mingo' of git://git.kernel.org/pub/scm/linux/kernel/git/jolsa/perf into perf/urgent (2014-04-20 09:53:55 +0200)
> 
> are available in the git repository at:
> 
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/jolsa/perf.git tags/perf-urgent-for-mingo
> 
> for you to fetch changes up to de04f8657de9d3351a2d5880f1f7080b23b798cf:
> 
>   tools lib traceevent: Fix memory leak in pretty_print() (2014-04-23 13:19:30 +0200)
> 
> ----------------------------------------------------------------
> perf/urgent fixes:
> 
> Developer stuff:
> . Fix memory leak and backward compatibility macros for pevent
>   filter enums in traceevent library (Steven Rostedt)
> 
> . Disable libdw unwind for all but x86 arch (Jiri Olsa)
> 
> . Fix memory leak in sample_ustack (Masanari Iida)
> 
> Signed-off-by: Jiri Olsa <jolsa@redhat.com>
> 
> ----------------------------------------------------------------
> Jiri Olsa (1):
>       perf tools: Disable libdw unwind for all but x86 arch
> 
> Masanari Iida (1):
>       perf tests x86: Fix memory leak in sample_ustack()
> 
> Steven Rostedt (2):
>       tools lib traceevent: Fix backward compatibility macros for pevent filter enums
>       tools lib traceevent: Fix memory leak in pretty_print()
> 
>  tools/lib/traceevent/event-parse.c       | 1 +
>  tools/lib/traceevent/event-parse.h       | 4 ++--
>  tools/perf/arch/x86/tests/dwarf-unwind.c | 1 +
>  tools/perf/config/Makefile               | 8 ++++++++
>  4 files changed, 12 insertions(+), 2 deletions(-)

Pulled, thanks a lot Jiri!

	Ingo

Re: [GIT PULL 0/4] perf/urgent fixes

[Ingo Molnar]

(Just reporting two bugs I found today - unrelated to your the 
perf/urgent pull request.)

1)

Even when the most modern unwind library is found, the autodetection 
is spammy:


 Auto-detecting system features:
 ...                         dwarf: [ on  ]
 ...                         glibc: [ on  ]
 ...                          gtk2: [ on  ]
 ...                      libaudit: [ on  ]
 ...                        libbfd: [ on  ]
 ...                        libelf: [ on  ]
 ...                       libnuma: [ on  ]
 ...                       libperl: [ on  ]
 ...                     libpython: [ on  ]
 ...                      libslang: [ on  ]
 ...                     libunwind: [ on  ]
 ...            libdw-dwarf-unwind: [ on  ]
 ...     DWARF post unwind library: libunwind

The 'DWARF post unwind library' line is somewhat superfluous. I 
realize that it prints out the library selected - but that's obvious 
from the 'libdw-dwarf-unwind' line above it already, right?

Furthermore, it breaks the autodetection output format.

2)

On latest Ubuntu (14.04) the tip:master build fails with:

 /usr/bin/ld: cannot find -liberty
 collect2: error: ld returned 1 exit status

The autodetection sequence reports all green entries, so something's 
funky going on there.

Thanks,

	Ingo

Re: [GIT PULL 0/4] perf/urgent fixes

[Jiri Olsa]

On Wed, Apr 23, 2014 at 03:14:33PM +0200, Ingo Molnar wrote:
> 
> (Just reporting two bugs I found today - unrelated to your the 
> perf/urgent pull request.)
> 
> 1)
> 
> Even when the most modern unwind library is found, the autodetection 
> is spammy:
> 
> 
>  Auto-detecting system features:
>  ...                         dwarf: [ on  ]
>  ...                         glibc: [ on  ]
>  ...                          gtk2: [ on  ]
>  ...                      libaudit: [ on  ]
>  ...                        libbfd: [ on  ]
>  ...                        libelf: [ on  ]
>  ...                       libnuma: [ on  ]
>  ...                       libperl: [ on  ]
>  ...                     libpython: [ on  ]
>  ...                      libslang: [ on  ]
>  ...                     libunwind: [ on  ]
>  ...            libdw-dwarf-unwind: [ on  ]
>  ...     DWARF post unwind library: libunwind
> 
> The 'DWARF post unwind library' line is somewhat superfluous. I 
> realize that it prints out the library selected - but that's obvious 
> from the 'libdw-dwarf-unwind' line above it already, right?

nope, the on/off output is only whats detected in system,
you've got both libunwind and libdw-dwarf-unwind detected

libunwind is default unless you use NO_LIBUNWIND=1

> 
> Furthermore, it breaks the autodetection output format.

we could move it to the 'make VF=1' output ;-) like:

Auto-detecting system features:
...                         dwarf: [ on  ]
...                         glibc: [ on  ]
...                          gtk2: [ on  ]
...                      libaudit: [ on  ]
...                        libbfd: [ on  ]
...                        libelf: [ on  ]
...                       libnuma: [ on  ]
...                       libperl: [ on  ]
...                     libpython: [ on  ]
...                      libslang: [ on  ]
...                     libunwind: [ on  ]
...            libdw-dwarf-unwind: [ on  ]
...                     backtrace: [ on  ]
...                fortify-source: [ on  ]
...                  gtk2-infobar: [ on  ]
...             libelf-getphdrnum: [ on  ]
...                   libelf-mmap: [ on  ]
...             libpython-version: [ on  ]
...                       on-exit: [ on  ]
...            stackprotector-all: [ on  ]
...                       timerfd: [ on  ]
...         libunwind-debug-frame: [ OFF ]
...                        bionic: [ OFF ]

...                        prefix: /home/jolsa
...                        bindir: /home/jolsa/bin
...                        libdir: /home/jolsa/lib64
...                    sysconfdir: /home/jolsa/etc
...                 LIBUNWIND_DIR: 
...                     LIBDW_DIR: 

...     DWARF post unwind library: libunwind


jirka

Re: [GIT PULL 0/4] perf/urgent fixes

[Jiri Olsa]

On Wed, Apr 23, 2014 at 03:14:33PM +0200, Ingo Molnar wrote:
> 
> (Just reporting two bugs I found today - unrelated to your the 
> perf/urgent pull request.)
> 
> 1)
> 
> Even when the most modern unwind library is found, the autodetection 
> is spammy:
> 
> 
>  Auto-detecting system features:
>  ...                         dwarf: [ on  ]
>  ...                         glibc: [ on  ]
>  ...                          gtk2: [ on  ]
>  ...                      libaudit: [ on  ]
>  ...                        libbfd: [ on  ]
>  ...                        libelf: [ on  ]
>  ...                       libnuma: [ on  ]
>  ...                       libperl: [ on  ]
>  ...                     libpython: [ on  ]
>  ...                      libslang: [ on  ]
>  ...                     libunwind: [ on  ]
>  ...            libdw-dwarf-unwind: [ on  ]
>  ...     DWARF post unwind library: libunwind
> 
> The 'DWARF post unwind library' line is somewhat superfluous. I 
> realize that it prints out the library selected - but that's obvious 
> from the 'libdw-dwarf-unwind' line above it already, right?
> 
> Furthermore, it breaks the autodetection output format.
> 
> 2)
> 
> On latest Ubuntu (14.04) the tip:master build fails with:
> 
>  /usr/bin/ld: cannot find -liberty
>  collect2: error: ld returned 1 exit status
> 
> The autodetection sequence reports all green entries, so something's 
> funky going on there.

we add -liberty once -lbfd is detected, I guess we
assumed that was common case

  perf tools: fix BFD detection on opensuse
  commit 280e7c48c3b873e4987a63da276ecab25383f494
  Author: Andi Kleen <ak@linux.intel.com>
  Date:   Sat Jan 11 11:42:51 2014 -0800

could you please try patch below? it adds that only
if thats detected

'make VF=1' should display more status now

Andi,
could you please try that on opensuse?

thanks,
jirka


---
diff --git a/tools/perf/config/Makefile b/tools/perf/config/Makefile
index ee21fa9..f511658 100644
--- a/tools/perf/config/Makefile
+++ b/tools/perf/config/Makefile
@@ -186,7 +186,10 @@ VF_FEATURE_TESTS =			\
 	stackprotector-all		\
 	timerfd				\
 	libunwind-debug-frame		\
-	bionic
+	bionic				\
+	liberty				\
+	liberty-z			\
+	cplus-demangle
 
 # Set FEATURE_CHECK_(C|LD)FLAGS-all for all CORE_FEATURE_TESTS features.
 # If in the future we need per-feature checks/flags for features not
@@ -504,7 +507,21 @@ else
 endif
 
 ifeq ($(feature-libbfd), 1)
-  EXTLIBS += -lbfd -lz -liberty
+  EXTLIBS += -lbfd
+
+  # call all detections now so we get correct
+  # status in VF output
+  $(call feature_check,liberty)
+  $(call feature_check,liberty-z)
+  $(call feature_check,cplus-demangle)
+
+  ifeq ($(feature-liberty), 1)
+    EXTLIBS += -lbfd -liberty
+  else
+    ifeq ($(feature-liberty-z), 1)
+      EXTLIBS += -lbfd -liberty -lz
+    endif
+  endif
 endif
 
 ifdef NO_DEMANGLE
@@ -515,15 +532,10 @@ else
     CFLAGS += -DHAVE_CPLUS_DEMANGLE_SUPPORT
   else
     ifneq ($(feature-libbfd), 1)
-      $(call feature_check,liberty)
-      ifeq ($(feature-liberty), 1)
-        EXTLIBS += -lbfd -liberty
-      else
-        $(call feature_check,liberty-z)
-        ifeq ($(feature-liberty-z), 1)
-          EXTLIBS += -lbfd -liberty -lz
-        else
-          $(call feature_check,cplus-demangle)
+      ifneq ($(feature-liberty), 1)
+        ifneq ($(feature-liberty-z), 1)
+          # we dont have neither HAVE_CPLUS_DEMANGLE_SUPPORT
+          # or any of 'bfd iberty z' trinity
           ifeq ($(feature-cplus-demangle), 1)
             EXTLIBS += -liberty
             CFLAGS += -DHAVE_CPLUS_DEMANGLE_SUPPORT

Re: [GIT PULL 0/4] perf/urgent fixes

[Ingo Molnar]

* Jiri Olsa <jolsa@redhat.com> wrote:

> On Wed, Apr 23, 2014 at 03:14:33PM +0200, Ingo Molnar wrote:
> > 
> > (Just reporting two bugs I found today - unrelated to your the 
> > perf/urgent pull request.)
> > 
> > 1)
> > 
> > Even when the most modern unwind library is found, the autodetection 
> > is spammy:
> > 
> > 
> >  Auto-detecting system features:
> >  ...                         dwarf: [ on  ]
> >  ...                         glibc: [ on  ]
> >  ...                          gtk2: [ on  ]
> >  ...                      libaudit: [ on  ]
> >  ...                        libbfd: [ on  ]
> >  ...                        libelf: [ on  ]
> >  ...                       libnuma: [ on  ]
> >  ...                       libperl: [ on  ]
> >  ...                     libpython: [ on  ]
> >  ...                      libslang: [ on  ]
> >  ...                     libunwind: [ on  ]
> >  ...            libdw-dwarf-unwind: [ on  ]
> >  ...     DWARF post unwind library: libunwind
> > 
> > The 'DWARF post unwind library' line is somewhat superfluous. I 
> > realize that it prints out the library selected - but that's obvious 
> > from the 'libdw-dwarf-unwind' line above it already, right?
> 
> nope, the on/off output is only whats detected in system,
> you've got both libunwind and libdw-dwarf-unwind detected
> 
> libunwind is default unless you use NO_LIBUNWIND=1

Okay, so the problem is that we don't have a simple binary-state 
feature in this case, but three possible states: 'libunwind', or 
'libdw-dwarf-unwind', or 'OFF', right?

If so then the solution would be to replace those 3 last lines with 
just this line:

     ...        DWARF unwind library: [ libunwind ]

Where 'libunwind' is printed in green (like the 'on' lines are 
printed). If there's no suitable library available then output:

     ...        DWARF unwind library: [ OFF ]

Because the user looking at the output is really only interested in 
'is an unwind library available', and maybe in 'which one'.

Is there preference between library choices? I.e. is 'libunwind' 
preferred over 'libdw-dwarf-unwind', or the other way around? If yes 
then if we pick an inferior library we could print it in yellow color 
- and only use green if it's the 'best' choice.

That way the color codes also still keep working: red means problem, 
green means OK, yellow something inbetween.

But in any case we should try to keep the 'one feature, one line' 
fundamental output concept.

( Under V=1 we can output whatever details might be useful to
  developers, there's no restriction on what to output there. )

Thanks,

	Ingo

Re: [GIT PULL 0/4] perf/urgent fixes

[Ingo Molnar]

* Jiri Olsa <jolsa@redhat.com> wrote:

> On Wed, Apr 23, 2014 at 03:14:33PM +0200, Ingo Molnar wrote:
> > 
> > (Just reporting two bugs I found today - unrelated to your the 
> > perf/urgent pull request.)
> > 
> > 1)
> > 
> > Even when the most modern unwind library is found, the autodetection 
> > is spammy:
> > 
> > 
> >  Auto-detecting system features:
> >  ...                         dwarf: [ on  ]
> >  ...                         glibc: [ on  ]
> >  ...                          gtk2: [ on  ]
> >  ...                      libaudit: [ on  ]
> >  ...                        libbfd: [ on  ]
> >  ...                        libelf: [ on  ]
> >  ...                       libnuma: [ on  ]
> >  ...                       libperl: [ on  ]
> >  ...                     libpython: [ on  ]
> >  ...                      libslang: [ on  ]
> >  ...                     libunwind: [ on  ]
> >  ...            libdw-dwarf-unwind: [ on  ]
> >  ...     DWARF post unwind library: libunwind
> > 
> > The 'DWARF post unwind library' line is somewhat superfluous. I 
> > realize that it prints out the library selected - but that's obvious 
> > from the 'libdw-dwarf-unwind' line above it already, right?
> > 
> > Furthermore, it breaks the autodetection output format.
> > 
> > 2)
> > 
> > On latest Ubuntu (14.04) the tip:master build fails with:
> > 
> >  /usr/bin/ld: cannot find -liberty
> >  collect2: error: ld returned 1 exit status
> > 
> > The autodetection sequence reports all green entries, so something's 
> > funky going on there.
> 
> we add -liberty once -lbfd is detected, I guess we
> assumed that was common case
> 
>   perf tools: fix BFD detection on opensuse
>   commit 280e7c48c3b873e4987a63da276ecab25383f494
>   Author: Andi Kleen <ak@linux.intel.com>
>   Date:   Sat Jan 11 11:42:51 2014 -0800
> 
> could you please try patch below? it adds that only
> if thats detected
> 
> 'make VF=1' should display more status now
> 
> Andi,
> could you please try that on opensuse?
> 
> thanks,
> jirka
> 
> 
> ---
> diff --git a/tools/perf/config/Makefile b/tools/perf/config/Makefile
> index ee21fa9..f511658 100644
> --- a/tools/perf/config/Makefile
> +++ b/tools/perf/config/Makefile
> @@ -186,7 +186,10 @@ VF_FEATURE_TESTS =			\
>  	stackprotector-all		\
>  	timerfd				\
>  	libunwind-debug-frame		\
> -	bionic
> +	bionic				\
> +	liberty				\
> +	liberty-z			\
> +	cplus-demangle

In any case, your patch fixes the bug. With VF=1 I get this output:

Auto-detecting system features:
...                         dwarf: [ on  ]
...                         glibc: [ on  ]
...                          gtk2: [ on  ]
...                      libaudit: [ on  ]
...                        libbfd: [ on  ]
...                        libelf: [ on  ]
...                       libnuma: [ on  ]
...                       libperl: [ on  ]
...                     libpython: [ on  ]
...                      libslang: [ on  ]
...                     libunwind: [ on  ]
...            libdw-dwarf-unwind: [ on  ]
...     DWARF post unwind library: libunwind
...                     backtrace: [ on  ]
...                fortify-source: [ on  ]
...                  gtk2-infobar: [ on  ]
...             libelf-getphdrnum: [ on  ]
...                   libelf-mmap: [ on  ]
...             libpython-version: [ on  ]
...                       on-exit: [ on  ]
...            stackprotector-all: [ on  ]
...                       timerfd: [ on  ]
...         libunwind-debug-frame: [ OFF ]
...                        bionic: [ OFF ]
...                       liberty: [ OFF ]
...                     liberty-z: [ OFF ]
...                cplus-demangle: [ OFF ]

So yes, your obervation that it's the -liberty +libbfd combination is 
correct.

Tested-by: Ingo Molnar <mingo@kernel.org>

Btw., when reading the patch and the Makefile it was not obvious to me 
what 'VF' stood for. It's pretty clear what CORE_FEATURE_TESTS and 
LIB_FEATURE_TESTS means, but there's no comment for VF_FEATURE_TESTS 
and the name is not self-explanatory.

I figured it out from a bit of git log digging that its purpose is to 
generate the 'verbose feature check' output. But the variable is not 
commented and the features it lists overlaps CORE_FEATURE_TESTS and 
LIB_FEATURE_TESTS - so perhaps a bit more explanation (and possible 
reduction in duplication) might be useful?

If it said ALL_FEATURE_TESTS and used $(CORE_FEATURE_TESTS) as a 
baseline then that would be self-explanatory.

(In a separate patch from the fix.)

Thanks,

	Ingo

Re: [GIT PULL 0/4] perf/urgent fixes

[Jiri Olsa]

On Thu, Apr 24, 2014 at 08:47:18AM +0200, Ingo Molnar wrote:

SNIP

> 
> In any case, your patch fixes the bug. With VF=1 I get this output:
> 
> Auto-detecting system features:
> ...                         dwarf: [ on  ]
> ...                         glibc: [ on  ]
> ...                          gtk2: [ on  ]
> ...                      libaudit: [ on  ]
> ...                        libbfd: [ on  ]
> ...                        libelf: [ on  ]
> ...                       libnuma: [ on  ]
> ...                       libperl: [ on  ]
> ...                     libpython: [ on  ]
> ...                      libslang: [ on  ]
> ...                     libunwind: [ on  ]
> ...            libdw-dwarf-unwind: [ on  ]
> ...     DWARF post unwind library: libunwind
> ...                     backtrace: [ on  ]
> ...                fortify-source: [ on  ]
> ...                  gtk2-infobar: [ on  ]
> ...             libelf-getphdrnum: [ on  ]
> ...                   libelf-mmap: [ on  ]
> ...             libpython-version: [ on  ]
> ...                       on-exit: [ on  ]
> ...            stackprotector-all: [ on  ]
> ...                       timerfd: [ on  ]
> ...         libunwind-debug-frame: [ OFF ]
> ...                        bionic: [ OFF ]
> ...                       liberty: [ OFF ]
> ...                     liberty-z: [ OFF ]
> ...                cplus-demangle: [ OFF ]
> 
> So yes, your obervation that it's the -liberty +libbfd combination is 
> correct.
> 
> Tested-by: Ingo Molnar <mingo@kernel.org>
> 
> Btw., when reading the patch and the Makefile it was not obvious to me 
> what 'VF' stood for. It's pretty clear what CORE_FEATURE_TESTS and 

VF - Verbose for Features ;-)

> LIB_FEATURE_TESTS means, but there's no comment for VF_FEATURE_TESTS 
> and the name is not self-explanatory.
> 
> I figured it out from a bit of git log digging that its purpose is to 
> generate the 'verbose feature check' output. But the variable is not 
> commented and the features it lists overlaps CORE_FEATURE_TESTS and 
> LIB_FEATURE_TESTS - so perhaps a bit more explanation (and possible 
> reduction in duplication) might be useful?
> 
> If it said ALL_FEATURE_TESTS and used $(CORE_FEATURE_TESTS) as a 
> baseline then that would be self-explanatory.
> 
> (In a separate patch from the fix.)

ok, will add something along those lines ;-)

thanks,
jirka

Re: [GIT PULL 0/4] perf/urgent fixes

[Jiri Olsa]

SNIP

> 
> Okay, so the problem is that we don't have a simple binary-state 
> feature in this case, but three possible states: 'libunwind', or 
> 'libdw-dwarf-unwind', or 'OFF', right?
> 
> If so then the solution would be to replace those 3 last lines with 
> just this line:
> 
>      ...        DWARF unwind library: [ libunwind ]
> 
> Where 'libunwind' is printed in green (like the 'on' lines are 
> printed). If there's no suitable library available then output:
> 
>      ...        DWARF unwind library: [ OFF ]
> 
> Because the user looking at the output is really only interested in 
> 'is an unwind library available', and maybe in 'which one'.
> 
> Is there preference between library choices? I.e. is 'libunwind' 
> preferred over 'libdw-dwarf-unwind', or the other way around? If yes 
> then if we pick an inferior library we could print it in yellow color 
> - and only use green if it's the 'best' choice.
> 
> That way the color codes also still keep working: red means problem, 
> green means OK, yellow something inbetween.

sounds good.. TODO list updated ;-)

> 
> But in any case we should try to keep the 'one feature, one line' 
> fundamental output concept.
> 
> ( Under V=1 we can output whatever details might be useful to
>   developers, there's no restriction on what to output there. )

thats what we put VF for.. maybe we should for verbose
features code detection output for V=1 as well

jirka

Re: [GIT PULL 0/4] perf/urgent fixes

[Ingo Molnar]

* Jiri Olsa <jolsa@redhat.com> wrote:

> SNIP
> 
> > 
> > Okay, so the problem is that we don't have a simple binary-state 
> > feature in this case, but three possible states: 'libunwind', or 
> > 'libdw-dwarf-unwind', or 'OFF', right?
> > 
> > If so then the solution would be to replace those 3 last lines with 
> > just this line:
> > 
> >      ...        DWARF unwind library: [ libunwind ]
> > 
> > Where 'libunwind' is printed in green (like the 'on' lines are 
> > printed). If there's no suitable library available then output:
> > 
> >      ...        DWARF unwind library: [ OFF ]
> > 
> > Because the user looking at the output is really only interested in 
> > 'is an unwind library available', and maybe in 'which one'.
> > 
> > Is there preference between library choices? I.e. is 'libunwind' 
> > preferred over 'libdw-dwarf-unwind', or the other way around? If yes 
> > then if we pick an inferior library we could print it in yellow color 
> > - and only use green if it's the 'best' choice.
> > 
> > That way the color codes also still keep working: red means problem, 
> > green means OK, yellow something inbetween.
> 
> sounds good.. TODO list updated ;-)
> 
> > 
> > But in any case we should try to keep the 'one feature, one line' 
> > fundamental output concept.
> > 
> > ( Under V=1 we can output whatever details might be useful to
> >   developers, there's no restriction on what to output there. )
> 
> thats what we put VF for.. maybe we should for verbose
> features code detection output for V=1 as well

Yeah, I think it's only rarely needed, so might make sense to merge it 
into V=1.

Thanks,

	Ingo

Re: [GIT PULL 0/4] perf/urgent fixes

[Andi Kleen]

> Andi,
> could you please try that on opensuse?

Works on opensuse 13.1. I don't have the old version
I tested on previously anymore.

-Andi