On 2015/09/29 08:53AM, Jiri Olsa wrote:

On Tue, Sep 29, 2015 at 11:06:17AM +0530, Naveen N. Rao wrote:

quoted

On 2015/09/24 10:15PM, Naveen N Rao wrote:

quoted

On 2015/09/24 08:32AM, Stephane Eranian wrote:

quoted

On Thu, Sep 24, 2015 at 5:57 AM, Jiri Olsa [off-list ref] wrote:

quoted

On Thu, Sep 24, 2015 at 05:41:58PM +0530, Naveen N. Rao wrote:

quoted

perf build currently fails on powerpc:

  LINK     perf
libperf.a(libperf-in.o):(.toc+0x120): undefined reference to
`sample_reg_masks'
libperf.a(libperf-in.o):(.toc+0x130): undefined reference to
`sample_reg_masks'
collect2: error: ld returned 1 exit status
make[1]: *** [perf] Error 1
make: *** [all] Error 2

This is due to parse-regs-options.c using sample_reg_masks, which is
defined only with CONFIG_PERF_REGS.

In addition, perf record -I is only useful if the arch supports
PERF_REGS. Hence, let's expose -I conditionally.

Signed-off-by: Naveen N. Rao <redacted>

hum, I wonder why we have sample_reg_masks defined as weak in util/perf_regs.c
which is also built only via CONFIG_PERF_REGS

I wonder we could get rid of the weak definition via attached patch, Stephane?

But the whole point of having it weak is to avoid this error scenario
on any arch without support
and avoid ugly #ifdef HAVE_ in generic files.

if perf_regs.c is compiled on PPC, then why do we get the undefined?

As Jiri Olsa pointed out, powerpc and many other architectures don't 
(yet) have support for perf regs.

But, the larger reason to introduce #ifdef is so the user doesn't see 
options (s)he can't use on a specific architecture, along the same lines 
as builtin-probe.c

Stephane, Arnaldo,
Suka has also posted a fix for this with a different approach [1]. Can 
you please ack/pull one of these versions? Building perf is broken on 
v4.3-rc due to this.

I did not get any answer for additional comments I made to the patch
(couldnt get marc.info working, sending the patch again)

Hi Jiri,
I concur with the changes you proposed to my patch here (getting rid of 
the weak variant):
http://article.gmane.org/gmane.linux.kernel/2046108

I am aware of the other approach you posted (and the one attached 
below). When I said "please ack/pull one of these versions", I meant one 
of: your version, Suka's and mine.

quoted

[1] http://article.gmane.org/gmane.linux.kernel/2046370

I dont have this last version, which seems to have other changes
and patch in above link looks mangled, could you please repost it?

Can you please check the raw version:
http://article.gmane.org/gmane.linux.kernel/2046370/raw


Thanks,
Naveen