[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20160601131424.GB20142@krava>
Date: Wed, 1 Jun 2016 15:14:24 +0200
From: Jiri Olsa <jolsa@...hat.com>
To: Arnaldo Carvalho de Melo <acme@...nel.org>
Cc: He Kuang <hekuang@...wei.com>, peterz@...radead.org,
mingo@...hat.com, alexander.shishkin@...ux.intel.com,
wangnan0@...wei.com, jpoimboe@...hat.com, ak@...ux.intel.com,
eranian@...gle.com, namhyung@...nel.org, adrian.hunter@...el.com,
sukadev@...ux.vnet.ibm.com, masami.hiramatsu.pt@...achi.com,
tumanova@...ux.vnet.ibm.com, kan.liang@...el.com,
penberg@...nel.org, dsahern@...il.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v7 13/14] perf callchain: Support x86 target platform
On Wed, Jun 01, 2016 at 09:47:50AM -0300, Arnaldo Carvalho de Melo wrote:
> Em Wed, Jun 01, 2016 at 10:40:15AM +0200, Jiri Olsa escreveu:
> > On Tue, May 31, 2016 at 11:19:11AM +0000, He Kuang wrote:
>
> > SNIP
> > > + ifeq ($(feature-libunwind-x86), 1)
> > > + $(call detected,CONFIG_LIBUNWIND_X86)
> > > + CFLAGS += -DHAVE_LIBUNWIND_X86_SUPPORT
> > > + LDFLAGS += -lunwind-x86
> > > + have_libunwind = 1
> > > + endif
>
> > > ifneq ($(feature-libunwind), 1)
> > > msg := $(warning No libunwind found. Please install libunwind-dev[el] >= 1.1 and/or set LIBUNWIND_DIR);
> > > NO_LOCAL_LIBUNWIND := 1
> > > +++ b/tools/perf/util/Build
> > > @@ -101,6 +101,7 @@ libperf-$(CONFIG_DWARF) += dwarf-aux.o
> > > libperf-$(CONFIG_LIBDW_DWARF_UNWIND) += unwind-libdw.o
> > > libperf-$(CONFIG_LOCAL_LIBUNWIND) += unwind-libunwind-local.o
> > > libperf-$(CONFIG_LIBUNWIND) += unwind-libunwind.o
> > > +libperf-$(CONFIG_LIBUNWIND_X86) += libunwind/x86_32.o
> >
> > seems odd but I dont have any better idea.. let's see what
> > others have to say ;-)
>
> There was a lot of discussion in this patchkit, so I lost track of why I
> should consider the above odd :-)
>
> I.e. I take the above as: if x86 libunwind was detected or explicitely
> selected, link support for it when generating the perf tool in any
> architecture, which seems sensible, no?
yep.. the x86_32 name under generic dir is what seems odd to me,
but it's like you said.. anyway we can always change if we find
some better solution ;-)
jirka
Powered by blists - more mailing lists