Re: [PATCH 2/3] perf tools: Fix build for hardened environments

2017-12-05 Thread Jiri Olsa
On Mon, Dec 04, 2017 at 12:35:14PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Mon, Dec 04, 2017 at 09:24:37AM +0100, Jiri Olsa escreveu:
> > On Mon, Dec 04, 2017 at 08:34:31AM +0100, Jiri Olsa wrote:
> > > On Fri, Dec 01, 2017 at 11:11:37AM +0900, Namhyung Kim wrote:
> > > > Hi Jiri,
> > > > 
> > > > On Wed, Nov 08, 2017 at 11:27:38AM +0100, Jiri Olsa wrote:
> > > > > From: Jiri Olsa 
> > > > > 
> > > > > On Fedora systems the perl and python CFLAGS/LDFLAGS include the
> > > > > hardened specs from redhat-rpm-config package. We apply them only
> > > > > for perl/python objects, which makes them not compatible with the
> > > > > rest of the objects and the build fails with:
> > > > > 
> > > > >   /usr/bin/ld: perf-in.o: relocation R_X86_64_32 against 
> > > > > `.rodata.str1.1' can not be used when making a shared object; 
> > > > > recompile with -fPIC
> > > > >   /usr/bin/ld: libperf.a(libperf-in.o): relocation R_X86_64_32S 
> > > > > against `.text' can not be used when making a shared object; 
> > > > > recompile with -fPIC
> > > > >   /usr/bin/ld: final link failed: Nonrepresentable section on output
> > > > >   collect2: error: ld returned 1 exit status
> > > > >   make[2]: *** [Makefile.perf:507: perf] Error 1
> > > > >   make[1]: *** [Makefile.perf:210: sub-make] Error 2
> > > > >   make: *** [Makefile:69: all] Error 2
> > > > > 
> > > > > Mainly it's caused by perl/python objects being compiled with:
> > > > > 
> > > > >   -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
> > > > > 
> > > > > which prevent the final link impossible, because it will check
> > > > > for 'proper' objects with following option:
> > > > > 
> > > > >   -specs=/usr/lib/rpm/redhat/redhat-hardened-ld
> > > > 
> > > > Just for curiousity, could you please show me the contents of the two
> > > > files?  (Are they big?)
> > > 
> > > # cat /usr/lib/rpm/redhat/redhat-hardened-ld
> > > *self_spec:
> > > + %{!static:%{!shared:%{!r:-pie}}}
> > > 
> > > *link:
> > > + -z now
> > > 
> > > 
> > > # cat /usr/lib/rpm/redhat/redhat-hardened-cc1 
> > > *cc1_options:
> > > + %{!r:%{!fpie:%{!fPIE:%{!fpic:%{!fPIC:%{!fno-pic:-fPIE}}
> > 
> > 
> > looks like we could remove that spec totaly and get things working
> > we already do that for CC_NO_CLANG
> > 
> > could you guys test patch below? works on my setup
> 
> Works for me as well, builds in f27 with gcc and with clang, I've added
> it to my perf/core branch with the original commig message modulo the
> description of the original fix.
> 
> If you want to have a different message, feel free to send it to me and
> I'll make the adjustments if this takes place before my next pull req to
> Ingo :-)

saw it, looks good, thanks

jirka


Re: [PATCH 2/3] perf tools: Fix build for hardened environments

2017-12-05 Thread Jiri Olsa
On Mon, Dec 04, 2017 at 12:35:14PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Mon, Dec 04, 2017 at 09:24:37AM +0100, Jiri Olsa escreveu:
> > On Mon, Dec 04, 2017 at 08:34:31AM +0100, Jiri Olsa wrote:
> > > On Fri, Dec 01, 2017 at 11:11:37AM +0900, Namhyung Kim wrote:
> > > > Hi Jiri,
> > > > 
> > > > On Wed, Nov 08, 2017 at 11:27:38AM +0100, Jiri Olsa wrote:
> > > > > From: Jiri Olsa 
> > > > > 
> > > > > On Fedora systems the perl and python CFLAGS/LDFLAGS include the
> > > > > hardened specs from redhat-rpm-config package. We apply them only
> > > > > for perl/python objects, which makes them not compatible with the
> > > > > rest of the objects and the build fails with:
> > > > > 
> > > > >   /usr/bin/ld: perf-in.o: relocation R_X86_64_32 against 
> > > > > `.rodata.str1.1' can not be used when making a shared object; 
> > > > > recompile with -fPIC
> > > > >   /usr/bin/ld: libperf.a(libperf-in.o): relocation R_X86_64_32S 
> > > > > against `.text' can not be used when making a shared object; 
> > > > > recompile with -fPIC
> > > > >   /usr/bin/ld: final link failed: Nonrepresentable section on output
> > > > >   collect2: error: ld returned 1 exit status
> > > > >   make[2]: *** [Makefile.perf:507: perf] Error 1
> > > > >   make[1]: *** [Makefile.perf:210: sub-make] Error 2
> > > > >   make: *** [Makefile:69: all] Error 2
> > > > > 
> > > > > Mainly it's caused by perl/python objects being compiled with:
> > > > > 
> > > > >   -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
> > > > > 
> > > > > which prevent the final link impossible, because it will check
> > > > > for 'proper' objects with following option:
> > > > > 
> > > > >   -specs=/usr/lib/rpm/redhat/redhat-hardened-ld
> > > > 
> > > > Just for curiousity, could you please show me the contents of the two
> > > > files?  (Are they big?)
> > > 
> > > # cat /usr/lib/rpm/redhat/redhat-hardened-ld
> > > *self_spec:
> > > + %{!static:%{!shared:%{!r:-pie}}}
> > > 
> > > *link:
> > > + -z now
> > > 
> > > 
> > > # cat /usr/lib/rpm/redhat/redhat-hardened-cc1 
> > > *cc1_options:
> > > + %{!r:%{!fpie:%{!fPIE:%{!fpic:%{!fPIC:%{!fno-pic:-fPIE}}
> > 
> > 
> > looks like we could remove that spec totaly and get things working
> > we already do that for CC_NO_CLANG
> > 
> > could you guys test patch below? works on my setup
> 
> Works for me as well, builds in f27 with gcc and with clang, I've added
> it to my perf/core branch with the original commig message modulo the
> description of the original fix.
> 
> If you want to have a different message, feel free to send it to me and
> I'll make the adjustments if this takes place before my next pull req to
> Ingo :-)

saw it, looks good, thanks

jirka


Re: [PATCH 2/3] perf tools: Fix build for hardened environments

2017-12-04 Thread Arnaldo Carvalho de Melo
Em Mon, Dec 04, 2017 at 09:24:37AM +0100, Jiri Olsa escreveu:
> On Mon, Dec 04, 2017 at 08:34:31AM +0100, Jiri Olsa wrote:
> > On Fri, Dec 01, 2017 at 11:11:37AM +0900, Namhyung Kim wrote:
> > > Hi Jiri,
> > > 
> > > On Wed, Nov 08, 2017 at 11:27:38AM +0100, Jiri Olsa wrote:
> > > > From: Jiri Olsa 
> > > > 
> > > > On Fedora systems the perl and python CFLAGS/LDFLAGS include the
> > > > hardened specs from redhat-rpm-config package. We apply them only
> > > > for perl/python objects, which makes them not compatible with the
> > > > rest of the objects and the build fails with:
> > > > 
> > > >   /usr/bin/ld: perf-in.o: relocation R_X86_64_32 against 
> > > > `.rodata.str1.1' can not be used when making a shared object; recompile 
> > > > with -fPIC
> > > >   /usr/bin/ld: libperf.a(libperf-in.o): relocation R_X86_64_32S against 
> > > > `.text' can not be used when making a shared object; recompile with 
> > > > -fPIC
> > > >   /usr/bin/ld: final link failed: Nonrepresentable section on output
> > > >   collect2: error: ld returned 1 exit status
> > > >   make[2]: *** [Makefile.perf:507: perf] Error 1
> > > >   make[1]: *** [Makefile.perf:210: sub-make] Error 2
> > > >   make: *** [Makefile:69: all] Error 2
> > > > 
> > > > Mainly it's caused by perl/python objects being compiled with:
> > > > 
> > > >   -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
> > > > 
> > > > which prevent the final link impossible, because it will check
> > > > for 'proper' objects with following option:
> > > > 
> > > >   -specs=/usr/lib/rpm/redhat/redhat-hardened-ld
> > > 
> > > Just for curiousity, could you please show me the contents of the two
> > > files?  (Are they big?)
> > 
> > # cat /usr/lib/rpm/redhat/redhat-hardened-ld
> > *self_spec:
> > + %{!static:%{!shared:%{!r:-pie}}}
> > 
> > *link:
> > + -z now
> > 
> > 
> > # cat /usr/lib/rpm/redhat/redhat-hardened-cc1 
> > *cc1_options:
> > + %{!r:%{!fpie:%{!fPIE:%{!fpic:%{!fPIC:%{!fno-pic:-fPIE}}
> 
> 
> looks like we could remove that spec totaly and get things working
> we already do that for CC_NO_CLANG
> 
> could you guys test patch below? works on my setup

Works for me as well, builds in f27 with gcc and with clang, I've added
it to my perf/core branch with the original commig message modulo the
description of the original fix.

If you want to have a different message, feel free to send it to me and
I'll make the adjustments if this takes place before my next pull req to
Ingo :-)

Thanks,

- Arnaldo


Re: [PATCH 2/3] perf tools: Fix build for hardened environments

2017-12-04 Thread Arnaldo Carvalho de Melo
Em Mon, Dec 04, 2017 at 09:24:37AM +0100, Jiri Olsa escreveu:
> On Mon, Dec 04, 2017 at 08:34:31AM +0100, Jiri Olsa wrote:
> > On Fri, Dec 01, 2017 at 11:11:37AM +0900, Namhyung Kim wrote:
> > > Hi Jiri,
> > > 
> > > On Wed, Nov 08, 2017 at 11:27:38AM +0100, Jiri Olsa wrote:
> > > > From: Jiri Olsa 
> > > > 
> > > > On Fedora systems the perl and python CFLAGS/LDFLAGS include the
> > > > hardened specs from redhat-rpm-config package. We apply them only
> > > > for perl/python objects, which makes them not compatible with the
> > > > rest of the objects and the build fails with:
> > > > 
> > > >   /usr/bin/ld: perf-in.o: relocation R_X86_64_32 against 
> > > > `.rodata.str1.1' can not be used when making a shared object; recompile 
> > > > with -fPIC
> > > >   /usr/bin/ld: libperf.a(libperf-in.o): relocation R_X86_64_32S against 
> > > > `.text' can not be used when making a shared object; recompile with 
> > > > -fPIC
> > > >   /usr/bin/ld: final link failed: Nonrepresentable section on output
> > > >   collect2: error: ld returned 1 exit status
> > > >   make[2]: *** [Makefile.perf:507: perf] Error 1
> > > >   make[1]: *** [Makefile.perf:210: sub-make] Error 2
> > > >   make: *** [Makefile:69: all] Error 2
> > > > 
> > > > Mainly it's caused by perl/python objects being compiled with:
> > > > 
> > > >   -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
> > > > 
> > > > which prevent the final link impossible, because it will check
> > > > for 'proper' objects with following option:
> > > > 
> > > >   -specs=/usr/lib/rpm/redhat/redhat-hardened-ld
> > > 
> > > Just for curiousity, could you please show me the contents of the two
> > > files?  (Are they big?)
> > 
> > # cat /usr/lib/rpm/redhat/redhat-hardened-ld
> > *self_spec:
> > + %{!static:%{!shared:%{!r:-pie}}}
> > 
> > *link:
> > + -z now
> > 
> > 
> > # cat /usr/lib/rpm/redhat/redhat-hardened-cc1 
> > *cc1_options:
> > + %{!r:%{!fpie:%{!fPIE:%{!fpic:%{!fPIC:%{!fno-pic:-fPIE}}
> 
> 
> looks like we could remove that spec totaly and get things working
> we already do that for CC_NO_CLANG
> 
> could you guys test patch below? works on my setup

Works for me as well, builds in f27 with gcc and with clang, I've added
it to my perf/core branch with the original commig message modulo the
description of the original fix.

If you want to have a different message, feel free to send it to me and
I'll make the adjustments if this takes place before my next pull req to
Ingo :-)

Thanks,

- Arnaldo


Re: [PATCH 2/3] perf tools: Fix build for hardened environments

2017-12-04 Thread Jiri Olsa
On Mon, Dec 04, 2017 at 08:34:31AM +0100, Jiri Olsa wrote:
> On Fri, Dec 01, 2017 at 11:11:37AM +0900, Namhyung Kim wrote:
> > Hi Jiri,
> > 
> > On Wed, Nov 08, 2017 at 11:27:38AM +0100, Jiri Olsa wrote:
> > > From: Jiri Olsa 
> > > 
> > > On Fedora systems the perl and python CFLAGS/LDFLAGS include the
> > > hardened specs from redhat-rpm-config package. We apply them only
> > > for perl/python objects, which makes them not compatible with the
> > > rest of the objects and the build fails with:
> > > 
> > >   /usr/bin/ld: perf-in.o: relocation R_X86_64_32 against `.rodata.str1.1' 
> > > can not be used when making a shared object; recompile with -fPIC
> > >   /usr/bin/ld: libperf.a(libperf-in.o): relocation R_X86_64_32S against 
> > > `.text' can not be used when making a shared object; recompile with -fPIC
> > >   /usr/bin/ld: final link failed: Nonrepresentable section on output
> > >   collect2: error: ld returned 1 exit status
> > >   make[2]: *** [Makefile.perf:507: perf] Error 1
> > >   make[1]: *** [Makefile.perf:210: sub-make] Error 2
> > >   make: *** [Makefile:69: all] Error 2
> > > 
> > > Mainly it's caused by perl/python objects being compiled with:
> > > 
> > >   -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
> > > 
> > > which prevent the final link impossible, because it will check
> > > for 'proper' objects with following option:
> > > 
> > >   -specs=/usr/lib/rpm/redhat/redhat-hardened-ld
> > 
> > Just for curiousity, could you please show me the contents of the two
> > files?  (Are they big?)
> 
> # cat /usr/lib/rpm/redhat/redhat-hardened-ld
> *self_spec:
> + %{!static:%{!shared:%{!r:-pie}}}
> 
> *link:
> + -z now
> 
> 
> # cat /usr/lib/rpm/redhat/redhat-hardened-cc1 
> *cc1_options:
> + %{!r:%{!fpie:%{!fPIE:%{!fpic:%{!fPIC:%{!fno-pic:-fPIE}}


looks like we could remove that spec totaly and get things working
we already do that for CC_NO_CLANG

could you guys test patch below? works on my setup

thanks,
jirka


---
 tools/perf/Makefile.config | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/tools/perf/Makefile.config b/tools/perf/Makefile.config
index c17472cb50f5..d702d21eacf6 100644
--- a/tools/perf/Makefile.config
+++ b/tools/perf/Makefile.config
@@ -184,9 +184,7 @@ ifdef PYTHON_CONFIG
   PYTHON_EMBED_LDFLAGS := $(call strip-libs,$(PYTHON_EMBED_LDOPTS))
   PYTHON_EMBED_LIBADD := $(call grep-libs,$(PYTHON_EMBED_LDOPTS)) -lutil
   PYTHON_EMBED_CCOPTS := $(shell $(PYTHON_CONFIG_SQ) --cflags 2>/dev/null)
-  ifeq ($(CC_NO_CLANG), 1)
-PYTHON_EMBED_CCOPTS := $(filter-out -specs=%,$(PYTHON_EMBED_CCOPTS))
-  endif
+  PYTHON_EMBED_CCOPTS := $(filter-out -specs=%,$(PYTHON_EMBED_CCOPTS))
   FLAGS_PYTHON_EMBED := $(PYTHON_EMBED_CCOPTS) $(PYTHON_EMBED_LDOPTS)
 endif
 
@@ -572,7 +570,6 @@ ifndef NO_GTK2
   endif
 endif
 
-
 ifdef NO_LIBPERL
   CFLAGS += -DNO_LIBPERL
 else
@@ -580,6 +577,8 @@ else
   PERL_EMBED_LDFLAGS = $(call strip-libs,$(PERL_EMBED_LDOPTS))
   PERL_EMBED_LIBADD = $(call grep-libs,$(PERL_EMBED_LDOPTS))
   PERL_EMBED_CCOPTS = $(shell perl -MExtUtils::Embed -e ccopts 2>/dev/null)
+  PERL_EMBED_CCOPTS := $(filter-out -specs=%,$(PERL_EMBED_CCOPTS))
+  PERL_EMBED_LDOPTS := $(filter-out -specs=%,$(PERL_EMBED_LDOPTS))
   FLAGS_PERL_EMBED=$(PERL_EMBED_CCOPTS) $(PERL_EMBED_LDOPTS)
 
   ifneq ($(feature-libperl), 1)
-- 
2.14.3



Re: [PATCH 2/3] perf tools: Fix build for hardened environments

2017-12-04 Thread Jiri Olsa
On Mon, Dec 04, 2017 at 08:34:31AM +0100, Jiri Olsa wrote:
> On Fri, Dec 01, 2017 at 11:11:37AM +0900, Namhyung Kim wrote:
> > Hi Jiri,
> > 
> > On Wed, Nov 08, 2017 at 11:27:38AM +0100, Jiri Olsa wrote:
> > > From: Jiri Olsa 
> > > 
> > > On Fedora systems the perl and python CFLAGS/LDFLAGS include the
> > > hardened specs from redhat-rpm-config package. We apply them only
> > > for perl/python objects, which makes them not compatible with the
> > > rest of the objects and the build fails with:
> > > 
> > >   /usr/bin/ld: perf-in.o: relocation R_X86_64_32 against `.rodata.str1.1' 
> > > can not be used when making a shared object; recompile with -fPIC
> > >   /usr/bin/ld: libperf.a(libperf-in.o): relocation R_X86_64_32S against 
> > > `.text' can not be used when making a shared object; recompile with -fPIC
> > >   /usr/bin/ld: final link failed: Nonrepresentable section on output
> > >   collect2: error: ld returned 1 exit status
> > >   make[2]: *** [Makefile.perf:507: perf] Error 1
> > >   make[1]: *** [Makefile.perf:210: sub-make] Error 2
> > >   make: *** [Makefile:69: all] Error 2
> > > 
> > > Mainly it's caused by perl/python objects being compiled with:
> > > 
> > >   -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
> > > 
> > > which prevent the final link impossible, because it will check
> > > for 'proper' objects with following option:
> > > 
> > >   -specs=/usr/lib/rpm/redhat/redhat-hardened-ld
> > 
> > Just for curiousity, could you please show me the contents of the two
> > files?  (Are they big?)
> 
> # cat /usr/lib/rpm/redhat/redhat-hardened-ld
> *self_spec:
> + %{!static:%{!shared:%{!r:-pie}}}
> 
> *link:
> + -z now
> 
> 
> # cat /usr/lib/rpm/redhat/redhat-hardened-cc1 
> *cc1_options:
> + %{!r:%{!fpie:%{!fPIE:%{!fpic:%{!fPIC:%{!fno-pic:-fPIE}}


looks like we could remove that spec totaly and get things working
we already do that for CC_NO_CLANG

could you guys test patch below? works on my setup

thanks,
jirka


---
 tools/perf/Makefile.config | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/tools/perf/Makefile.config b/tools/perf/Makefile.config
index c17472cb50f5..d702d21eacf6 100644
--- a/tools/perf/Makefile.config
+++ b/tools/perf/Makefile.config
@@ -184,9 +184,7 @@ ifdef PYTHON_CONFIG
   PYTHON_EMBED_LDFLAGS := $(call strip-libs,$(PYTHON_EMBED_LDOPTS))
   PYTHON_EMBED_LIBADD := $(call grep-libs,$(PYTHON_EMBED_LDOPTS)) -lutil
   PYTHON_EMBED_CCOPTS := $(shell $(PYTHON_CONFIG_SQ) --cflags 2>/dev/null)
-  ifeq ($(CC_NO_CLANG), 1)
-PYTHON_EMBED_CCOPTS := $(filter-out -specs=%,$(PYTHON_EMBED_CCOPTS))
-  endif
+  PYTHON_EMBED_CCOPTS := $(filter-out -specs=%,$(PYTHON_EMBED_CCOPTS))
   FLAGS_PYTHON_EMBED := $(PYTHON_EMBED_CCOPTS) $(PYTHON_EMBED_LDOPTS)
 endif
 
@@ -572,7 +570,6 @@ ifndef NO_GTK2
   endif
 endif
 
-
 ifdef NO_LIBPERL
   CFLAGS += -DNO_LIBPERL
 else
@@ -580,6 +577,8 @@ else
   PERL_EMBED_LDFLAGS = $(call strip-libs,$(PERL_EMBED_LDOPTS))
   PERL_EMBED_LIBADD = $(call grep-libs,$(PERL_EMBED_LDOPTS))
   PERL_EMBED_CCOPTS = $(shell perl -MExtUtils::Embed -e ccopts 2>/dev/null)
+  PERL_EMBED_CCOPTS := $(filter-out -specs=%,$(PERL_EMBED_CCOPTS))
+  PERL_EMBED_LDOPTS := $(filter-out -specs=%,$(PERL_EMBED_LDOPTS))
   FLAGS_PERL_EMBED=$(PERL_EMBED_CCOPTS) $(PERL_EMBED_LDOPTS)
 
   ifneq ($(feature-libperl), 1)
-- 
2.14.3



Re: [PATCH 2/3] perf tools: Fix build for hardened environments

2017-12-03 Thread Jiri Olsa
On Fri, Dec 01, 2017 at 11:11:37AM +0900, Namhyung Kim wrote:
> Hi Jiri,
> 
> On Wed, Nov 08, 2017 at 11:27:38AM +0100, Jiri Olsa wrote:
> > From: Jiri Olsa 
> > 
> > On Fedora systems the perl and python CFLAGS/LDFLAGS include the
> > hardened specs from redhat-rpm-config package. We apply them only
> > for perl/python objects, which makes them not compatible with the
> > rest of the objects and the build fails with:
> > 
> >   /usr/bin/ld: perf-in.o: relocation R_X86_64_32 against `.rodata.str1.1' 
> > can not be used when making a shared object; recompile with -fPIC
> >   /usr/bin/ld: libperf.a(libperf-in.o): relocation R_X86_64_32S against 
> > `.text' can not be used when making a shared object; recompile with -fPIC
> >   /usr/bin/ld: final link failed: Nonrepresentable section on output
> >   collect2: error: ld returned 1 exit status
> >   make[2]: *** [Makefile.perf:507: perf] Error 1
> >   make[1]: *** [Makefile.perf:210: sub-make] Error 2
> >   make: *** [Makefile:69: all] Error 2
> > 
> > Mainly it's caused by perl/python objects being compiled with:
> > 
> >   -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
> > 
> > which prevent the final link impossible, because it will check
> > for 'proper' objects with following option:
> > 
> >   -specs=/usr/lib/rpm/redhat/redhat-hardened-ld
> 
> Just for curiousity, could you please show me the contents of the two
> files?  (Are they big?)

# cat /usr/lib/rpm/redhat/redhat-hardened-ld
*self_spec:
+ %{!static:%{!shared:%{!r:-pie}}}

*link:
+ -z now


# cat /usr/lib/rpm/redhat/redhat-hardened-cc1 
*cc1_options:
+ %{!r:%{!fpie:%{!fPIE:%{!fpic:%{!fPIC:%{!fno-pic:-fPIE}}


jirka


Re: [PATCH 2/3] perf tools: Fix build for hardened environments

2017-12-03 Thread Jiri Olsa
On Fri, Dec 01, 2017 at 11:11:37AM +0900, Namhyung Kim wrote:
> Hi Jiri,
> 
> On Wed, Nov 08, 2017 at 11:27:38AM +0100, Jiri Olsa wrote:
> > From: Jiri Olsa 
> > 
> > On Fedora systems the perl and python CFLAGS/LDFLAGS include the
> > hardened specs from redhat-rpm-config package. We apply them only
> > for perl/python objects, which makes them not compatible with the
> > rest of the objects and the build fails with:
> > 
> >   /usr/bin/ld: perf-in.o: relocation R_X86_64_32 against `.rodata.str1.1' 
> > can not be used when making a shared object; recompile with -fPIC
> >   /usr/bin/ld: libperf.a(libperf-in.o): relocation R_X86_64_32S against 
> > `.text' can not be used when making a shared object; recompile with -fPIC
> >   /usr/bin/ld: final link failed: Nonrepresentable section on output
> >   collect2: error: ld returned 1 exit status
> >   make[2]: *** [Makefile.perf:507: perf] Error 1
> >   make[1]: *** [Makefile.perf:210: sub-make] Error 2
> >   make: *** [Makefile:69: all] Error 2
> > 
> > Mainly it's caused by perl/python objects being compiled with:
> > 
> >   -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
> > 
> > which prevent the final link impossible, because it will check
> > for 'proper' objects with following option:
> > 
> >   -specs=/usr/lib/rpm/redhat/redhat-hardened-ld
> 
> Just for curiousity, could you please show me the contents of the two
> files?  (Are they big?)

# cat /usr/lib/rpm/redhat/redhat-hardened-ld
*self_spec:
+ %{!static:%{!shared:%{!r:-pie}}}

*link:
+ -z now


# cat /usr/lib/rpm/redhat/redhat-hardened-cc1 
*cc1_options:
+ %{!r:%{!fpie:%{!fPIE:%{!fpic:%{!fPIC:%{!fno-pic:-fPIE}}


jirka


Re: [PATCH 2/3] perf tools: Fix build for hardened environments

2017-11-30 Thread Namhyung Kim
Hi Jiri,

On Wed, Nov 08, 2017 at 11:27:38AM +0100, Jiri Olsa wrote:
> From: Jiri Olsa 
> 
> On Fedora systems the perl and python CFLAGS/LDFLAGS include the
> hardened specs from redhat-rpm-config package. We apply them only
> for perl/python objects, which makes them not compatible with the
> rest of the objects and the build fails with:
> 
>   /usr/bin/ld: perf-in.o: relocation R_X86_64_32 against `.rodata.str1.1' can 
> not be used when making a shared object; recompile with -fPIC
>   /usr/bin/ld: libperf.a(libperf-in.o): relocation R_X86_64_32S against 
> `.text' can not be used when making a shared object; recompile with -fPIC
>   /usr/bin/ld: final link failed: Nonrepresentable section on output
>   collect2: error: ld returned 1 exit status
>   make[2]: *** [Makefile.perf:507: perf] Error 1
>   make[1]: *** [Makefile.perf:210: sub-make] Error 2
>   make: *** [Makefile:69: all] Error 2
> 
> Mainly it's caused by perl/python objects being compiled with:
> 
>   -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
> 
> which prevent the final link impossible, because it will check
> for 'proper' objects with following option:
> 
>   -specs=/usr/lib/rpm/redhat/redhat-hardened-ld

Just for curiousity, could you please show me the contents of the two
files?  (Are they big?)

Thanks,
Namhyung


> 
> Fixing this by using the perl/python CFLAGS/LDFLAGS options
> for all the objects.
> 
> Link: http://lkml.kernel.org/n/tip-bib4nb5dei0ubk83534ef...@git.kernel.org
> Signed-off-by: Jiri Olsa 
> ---
>  tools/perf/Makefile.config  | 2 ++
>  tools/perf/scripts/perl/Perf-Trace-Util/Build   | 2 +-
>  tools/perf/scripts/python/Perf-Trace-Util/Build | 2 +-
>  tools/perf/util/block-range.c   | 2 +-
>  tools/perf/util/scripting-engines/Build | 4 ++--
>  5 files changed, 7 insertions(+), 5 deletions(-)
> 
> diff --git a/tools/perf/Makefile.config b/tools/perf/Makefile.config
> index f6786fa2419f..5e3734e4c1e4 100644
> --- a/tools/perf/Makefile.config
> +++ b/tools/perf/Makefile.config
> @@ -587,6 +587,7 @@ else
>  NO_LIBPERL := 1
>  msg := $(warning Missing perl devel files. Disabling perl scripting 
> support, please install perl-ExtUtils-Embed/libperl-dev);
>else
> +CFLAGS  += $(PERL_EMBED_CCOPTS)
>  LDFLAGS += $(PERL_EMBED_LDFLAGS)
>  EXTLIBS += $(PERL_EMBED_LIBADD)
>  $(call detected,CONFIG_LIBPERL)
> @@ -636,6 +637,7 @@ else
>$(warning $(and ,))
>$(error   $(and ,))
>  else
> +  CFLAGS  += $(PYTHON_EMBED_CCOPTS)
>LDFLAGS += $(PYTHON_EMBED_LDFLAGS)
>EXTLIBS += $(PYTHON_EMBED_LIBADD)
>LANG_BINDINGS += $(obj-perf)python/perf.so
> diff --git a/tools/perf/scripts/perl/Perf-Trace-Util/Build 
> b/tools/perf/scripts/perl/Perf-Trace-Util/Build
> index 34faecf774ae..ff9a452677fc 100644
> --- a/tools/perf/scripts/perl/Perf-Trace-Util/Build
> +++ b/tools/perf/scripts/perl/Perf-Trace-Util/Build
> @@ -1,5 +1,5 @@
>  libperf-y += Context.o
>  
> -CFLAGS_Context.o += $(PERL_EMBED_CCOPTS) -Wno-redundant-decls 
> -Wno-strict-prototypes
> +CFLAGS_Context.o += -Wno-redundant-decls -Wno-strict-prototypes
>  CFLAGS_Context.o += -Wno-unused-parameter -Wno-nested-externs -Wno-undef
>  CFLAGS_Context.o += -Wno-switch-default -Wno-shadow
> diff --git a/tools/perf/scripts/python/Perf-Trace-Util/Build 
> b/tools/perf/scripts/python/Perf-Trace-Util/Build
> index aefc15c9444a..cd4da129c017 100644
> --- a/tools/perf/scripts/python/Perf-Trace-Util/Build
> +++ b/tools/perf/scripts/python/Perf-Trace-Util/Build
> @@ -1,3 +1,3 @@
>  libperf-y += Context.o
>  
> -CFLAGS_Context.o += $(PYTHON_EMBED_CCOPTS) -Wno-redundant-decls 
> -Wno-strict-prototypes -Wno-unused-parameter -Wno-nested-externs
> +CFLAGS_Context.o += -Wno-redundant-decls -Wno-strict-prototypes 
> -Wno-unused-parameter -Wno-nested-externs
> diff --git a/tools/perf/util/block-range.c b/tools/perf/util/block-range.c
> index f1451c987eec..ff76d5f1d96f 100644
> --- a/tools/perf/util/block-range.c
> +++ b/tools/perf/util/block-range.c
> @@ -15,7 +15,7 @@ static void block_range__debug(void)
>*/
>  #if 1
>   struct rb_node *rb;
> - u64 old = 0; /* NULL isn't executable */
> + u64 old __maybe_unused = 0; /* NULL isn't executable */
>  
>   for (rb = rb_first(_ranges.root); rb; rb = rb_next(rb)) {
>   struct block_range *entry = rb_entry(rb, struct block_range, 
> node);
> diff --git a/tools/perf/util/scripting-engines/Build 
> b/tools/perf/util/scripting-engines/Build
> index 82d28c67e0f3..38cd25ce1503 100644
> --- a/tools/perf/util/scripting-engines/Build
> +++ b/tools/perf/util/scripting-engines/Build
> @@ -1,6 +1,6 @@
>  libperf-$(CONFIG_LIBPERL)   += trace-event-perl.o
>  libperf-$(CONFIG_LIBPYTHON) += trace-event-python.o
>  
> -CFLAGS_trace-event-perl.o += $(PERL_EMBED_CCOPTS) -Wno-redundant-decls 
> -Wno-strict-prototypes -Wno-unused-parameter -Wno-shadow -Wno-nested-externs 
> 

Re: [PATCH 2/3] perf tools: Fix build for hardened environments

2017-11-30 Thread Namhyung Kim
Hi Jiri,

On Wed, Nov 08, 2017 at 11:27:38AM +0100, Jiri Olsa wrote:
> From: Jiri Olsa 
> 
> On Fedora systems the perl and python CFLAGS/LDFLAGS include the
> hardened specs from redhat-rpm-config package. We apply them only
> for perl/python objects, which makes them not compatible with the
> rest of the objects and the build fails with:
> 
>   /usr/bin/ld: perf-in.o: relocation R_X86_64_32 against `.rodata.str1.1' can 
> not be used when making a shared object; recompile with -fPIC
>   /usr/bin/ld: libperf.a(libperf-in.o): relocation R_X86_64_32S against 
> `.text' can not be used when making a shared object; recompile with -fPIC
>   /usr/bin/ld: final link failed: Nonrepresentable section on output
>   collect2: error: ld returned 1 exit status
>   make[2]: *** [Makefile.perf:507: perf] Error 1
>   make[1]: *** [Makefile.perf:210: sub-make] Error 2
>   make: *** [Makefile:69: all] Error 2
> 
> Mainly it's caused by perl/python objects being compiled with:
> 
>   -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
> 
> which prevent the final link impossible, because it will check
> for 'proper' objects with following option:
> 
>   -specs=/usr/lib/rpm/redhat/redhat-hardened-ld

Just for curiousity, could you please show me the contents of the two
files?  (Are they big?)

Thanks,
Namhyung


> 
> Fixing this by using the perl/python CFLAGS/LDFLAGS options
> for all the objects.
> 
> Link: http://lkml.kernel.org/n/tip-bib4nb5dei0ubk83534ef...@git.kernel.org
> Signed-off-by: Jiri Olsa 
> ---
>  tools/perf/Makefile.config  | 2 ++
>  tools/perf/scripts/perl/Perf-Trace-Util/Build   | 2 +-
>  tools/perf/scripts/python/Perf-Trace-Util/Build | 2 +-
>  tools/perf/util/block-range.c   | 2 +-
>  tools/perf/util/scripting-engines/Build | 4 ++--
>  5 files changed, 7 insertions(+), 5 deletions(-)
> 
> diff --git a/tools/perf/Makefile.config b/tools/perf/Makefile.config
> index f6786fa2419f..5e3734e4c1e4 100644
> --- a/tools/perf/Makefile.config
> +++ b/tools/perf/Makefile.config
> @@ -587,6 +587,7 @@ else
>  NO_LIBPERL := 1
>  msg := $(warning Missing perl devel files. Disabling perl scripting 
> support, please install perl-ExtUtils-Embed/libperl-dev);
>else
> +CFLAGS  += $(PERL_EMBED_CCOPTS)
>  LDFLAGS += $(PERL_EMBED_LDFLAGS)
>  EXTLIBS += $(PERL_EMBED_LIBADD)
>  $(call detected,CONFIG_LIBPERL)
> @@ -636,6 +637,7 @@ else
>$(warning $(and ,))
>$(error   $(and ,))
>  else
> +  CFLAGS  += $(PYTHON_EMBED_CCOPTS)
>LDFLAGS += $(PYTHON_EMBED_LDFLAGS)
>EXTLIBS += $(PYTHON_EMBED_LIBADD)
>LANG_BINDINGS += $(obj-perf)python/perf.so
> diff --git a/tools/perf/scripts/perl/Perf-Trace-Util/Build 
> b/tools/perf/scripts/perl/Perf-Trace-Util/Build
> index 34faecf774ae..ff9a452677fc 100644
> --- a/tools/perf/scripts/perl/Perf-Trace-Util/Build
> +++ b/tools/perf/scripts/perl/Perf-Trace-Util/Build
> @@ -1,5 +1,5 @@
>  libperf-y += Context.o
>  
> -CFLAGS_Context.o += $(PERL_EMBED_CCOPTS) -Wno-redundant-decls 
> -Wno-strict-prototypes
> +CFLAGS_Context.o += -Wno-redundant-decls -Wno-strict-prototypes
>  CFLAGS_Context.o += -Wno-unused-parameter -Wno-nested-externs -Wno-undef
>  CFLAGS_Context.o += -Wno-switch-default -Wno-shadow
> diff --git a/tools/perf/scripts/python/Perf-Trace-Util/Build 
> b/tools/perf/scripts/python/Perf-Trace-Util/Build
> index aefc15c9444a..cd4da129c017 100644
> --- a/tools/perf/scripts/python/Perf-Trace-Util/Build
> +++ b/tools/perf/scripts/python/Perf-Trace-Util/Build
> @@ -1,3 +1,3 @@
>  libperf-y += Context.o
>  
> -CFLAGS_Context.o += $(PYTHON_EMBED_CCOPTS) -Wno-redundant-decls 
> -Wno-strict-prototypes -Wno-unused-parameter -Wno-nested-externs
> +CFLAGS_Context.o += -Wno-redundant-decls -Wno-strict-prototypes 
> -Wno-unused-parameter -Wno-nested-externs
> diff --git a/tools/perf/util/block-range.c b/tools/perf/util/block-range.c
> index f1451c987eec..ff76d5f1d96f 100644
> --- a/tools/perf/util/block-range.c
> +++ b/tools/perf/util/block-range.c
> @@ -15,7 +15,7 @@ static void block_range__debug(void)
>*/
>  #if 1
>   struct rb_node *rb;
> - u64 old = 0; /* NULL isn't executable */
> + u64 old __maybe_unused = 0; /* NULL isn't executable */
>  
>   for (rb = rb_first(_ranges.root); rb; rb = rb_next(rb)) {
>   struct block_range *entry = rb_entry(rb, struct block_range, 
> node);
> diff --git a/tools/perf/util/scripting-engines/Build 
> b/tools/perf/util/scripting-engines/Build
> index 82d28c67e0f3..38cd25ce1503 100644
> --- a/tools/perf/util/scripting-engines/Build
> +++ b/tools/perf/util/scripting-engines/Build
> @@ -1,6 +1,6 @@
>  libperf-$(CONFIG_LIBPERL)   += trace-event-perl.o
>  libperf-$(CONFIG_LIBPYTHON) += trace-event-python.o
>  
> -CFLAGS_trace-event-perl.o += $(PERL_EMBED_CCOPTS) -Wno-redundant-decls 
> -Wno-strict-prototypes -Wno-unused-parameter -Wno-shadow -Wno-nested-externs 
> -Wno-undef -Wno-switch-default
> 

Re: [PATCH 2/3] perf tools: Fix build for hardened environments

2017-11-30 Thread Jiri Olsa
On Wed, Nov 29, 2017 at 05:00:19PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Wed, Nov 29, 2017 at 04:54:46PM -0300, Arnaldo Carvalho de Melo escreveu:
> > Em Fri, Nov 10, 2017 at 10:43:25AM +0100, Jiri Olsa escreveu:
> > > On Thu, Nov 09, 2017 at 09:52:12AM -0300, Arnaldo Carvalho de Melo wrote:
> > > > Right, since we want to honour what the distro makers decided was the
> > > > best set for them, and to be able to link with other libraries, etc.
> > 
> > > > But then I think this should be done more explicitely, right? Do you
> > > > envision some way to do that without having to try to build perl or
> > > > python, that may not be installed, etc?
> > 
> > > I'll check on it.. I think we could use feature detection and
> > > enable that by default and add NO_HARDENED_BUILD variable as
> > > we do for features.. and detect that python/perl or whatever
> > > else is using that and warn
> >  
> > > > Of course users wanting to use something different may just set CFLAGS
> > > > and be done with it, in which case I think this should also affect the
> > > > perl and python CFLAGS, removing that distro specific stuff since the
> > > > user is changing something different.
> >  
> > > yep
> > 
> > Even with this patch applied, as a stopgap solution to allow me to build
> > a full featured tool on f27, I get this leftover:
> > 
> >   LINK /tmp/build/perf/perf
> > /usr/bin/ld: /tmp/build/perf/libperf.a(libperf-in.o): relocation 
> > R_X86_64_32S against symbol `inat_primary_table' can not be used when 
> > making a shared object; recompile with -fPIC
> > /usr/bin/ld: final link failed: Nonrepresentable section on output
> > collect2: error: ld returned 1 exit status
> > 
> > 
> > Looking at the Intel PT bits now...
> 
> Nevermind, I did a full rebuild and this is not there anymore, some
> build artifact with that file :-\

I keep posponing this fix.. maybe I should update to F27 ;-)

I'll send new version soon

jirka


Re: [PATCH 2/3] perf tools: Fix build for hardened environments

2017-11-30 Thread Jiri Olsa
On Wed, Nov 29, 2017 at 05:00:19PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Wed, Nov 29, 2017 at 04:54:46PM -0300, Arnaldo Carvalho de Melo escreveu:
> > Em Fri, Nov 10, 2017 at 10:43:25AM +0100, Jiri Olsa escreveu:
> > > On Thu, Nov 09, 2017 at 09:52:12AM -0300, Arnaldo Carvalho de Melo wrote:
> > > > Right, since we want to honour what the distro makers decided was the
> > > > best set for them, and to be able to link with other libraries, etc.
> > 
> > > > But then I think this should be done more explicitely, right? Do you
> > > > envision some way to do that without having to try to build perl or
> > > > python, that may not be installed, etc?
> > 
> > > I'll check on it.. I think we could use feature detection and
> > > enable that by default and add NO_HARDENED_BUILD variable as
> > > we do for features.. and detect that python/perl or whatever
> > > else is using that and warn
> >  
> > > > Of course users wanting to use something different may just set CFLAGS
> > > > and be done with it, in which case I think this should also affect the
> > > > perl and python CFLAGS, removing that distro specific stuff since the
> > > > user is changing something different.
> >  
> > > yep
> > 
> > Even with this patch applied, as a stopgap solution to allow me to build
> > a full featured tool on f27, I get this leftover:
> > 
> >   LINK /tmp/build/perf/perf
> > /usr/bin/ld: /tmp/build/perf/libperf.a(libperf-in.o): relocation 
> > R_X86_64_32S against symbol `inat_primary_table' can not be used when 
> > making a shared object; recompile with -fPIC
> > /usr/bin/ld: final link failed: Nonrepresentable section on output
> > collect2: error: ld returned 1 exit status
> > 
> > 
> > Looking at the Intel PT bits now...
> 
> Nevermind, I did a full rebuild and this is not there anymore, some
> build artifact with that file :-\

I keep posponing this fix.. maybe I should update to F27 ;-)

I'll send new version soon

jirka


Re: [PATCH 2/3] perf tools: Fix build for hardened environments

2017-11-29 Thread Arnaldo Carvalho de Melo
Em Wed, Nov 29, 2017 at 04:54:46PM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Fri, Nov 10, 2017 at 10:43:25AM +0100, Jiri Olsa escreveu:
> > On Thu, Nov 09, 2017 at 09:52:12AM -0300, Arnaldo Carvalho de Melo wrote:
> > > Right, since we want to honour what the distro makers decided was the
> > > best set for them, and to be able to link with other libraries, etc.
> 
> > > But then I think this should be done more explicitely, right? Do you
> > > envision some way to do that without having to try to build perl or
> > > python, that may not be installed, etc?
> 
> > I'll check on it.. I think we could use feature detection and
> > enable that by default and add NO_HARDENED_BUILD variable as
> > we do for features.. and detect that python/perl or whatever
> > else is using that and warn
>  
> > > Of course users wanting to use something different may just set CFLAGS
> > > and be done with it, in which case I think this should also affect the
> > > perl and python CFLAGS, removing that distro specific stuff since the
> > > user is changing something different.
>  
> > yep
> 
> Even with this patch applied, as a stopgap solution to allow me to build
> a full featured tool on f27, I get this leftover:
> 
>   LINK /tmp/build/perf/perf
> /usr/bin/ld: /tmp/build/perf/libperf.a(libperf-in.o): relocation R_X86_64_32S 
> against symbol `inat_primary_table' can not be used when making a shared 
> object; recompile with -fPIC
> /usr/bin/ld: final link failed: Nonrepresentable section on output
> collect2: error: ld returned 1 exit status
> 
> 
> Looking at the Intel PT bits now...

Nevermind, I did a full rebuild and this is not there anymore, some
build artifact with that file :-\

- Arnaldo


Re: [PATCH 2/3] perf tools: Fix build for hardened environments

2017-11-29 Thread Arnaldo Carvalho de Melo
Em Wed, Nov 29, 2017 at 04:54:46PM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Fri, Nov 10, 2017 at 10:43:25AM +0100, Jiri Olsa escreveu:
> > On Thu, Nov 09, 2017 at 09:52:12AM -0300, Arnaldo Carvalho de Melo wrote:
> > > Right, since we want to honour what the distro makers decided was the
> > > best set for them, and to be able to link with other libraries, etc.
> 
> > > But then I think this should be done more explicitely, right? Do you
> > > envision some way to do that without having to try to build perl or
> > > python, that may not be installed, etc?
> 
> > I'll check on it.. I think we could use feature detection and
> > enable that by default and add NO_HARDENED_BUILD variable as
> > we do for features.. and detect that python/perl or whatever
> > else is using that and warn
>  
> > > Of course users wanting to use something different may just set CFLAGS
> > > and be done with it, in which case I think this should also affect the
> > > perl and python CFLAGS, removing that distro specific stuff since the
> > > user is changing something different.
>  
> > yep
> 
> Even with this patch applied, as a stopgap solution to allow me to build
> a full featured tool on f27, I get this leftover:
> 
>   LINK /tmp/build/perf/perf
> /usr/bin/ld: /tmp/build/perf/libperf.a(libperf-in.o): relocation R_X86_64_32S 
> against symbol `inat_primary_table' can not be used when making a shared 
> object; recompile with -fPIC
> /usr/bin/ld: final link failed: Nonrepresentable section on output
> collect2: error: ld returned 1 exit status
> 
> 
> Looking at the Intel PT bits now...

Nevermind, I did a full rebuild and this is not there anymore, some
build artifact with that file :-\

- Arnaldo


Re: [PATCH 2/3] perf tools: Fix build for hardened environments

2017-11-29 Thread Arnaldo Carvalho de Melo
Em Fri, Nov 10, 2017 at 10:43:25AM +0100, Jiri Olsa escreveu:
> On Thu, Nov 09, 2017 at 09:52:12AM -0300, Arnaldo Carvalho de Melo wrote:
> > Right, since we want to honour what the distro makers decided was the
> > best set for them, and to be able to link with other libraries, etc.

> > But then I think this should be done more explicitely, right? Do you
> > envision some way to do that without having to try to build perl or
> > python, that may not be installed, etc?

> I'll check on it.. I think we could use feature detection and
> enable that by default and add NO_HARDENED_BUILD variable as
> we do for features.. and detect that python/perl or whatever
> else is using that and warn
 
> > Of course users wanting to use something different may just set CFLAGS
> > and be done with it, in which case I think this should also affect the
> > perl and python CFLAGS, removing that distro specific stuff since the
> > user is changing something different.
 
> yep

Even with this patch applied, as a stopgap solution to allow me to build
a full featured tool on f27, I get this leftover:

  LINK /tmp/build/perf/perf
/usr/bin/ld: /tmp/build/perf/libperf.a(libperf-in.o): relocation R_X86_64_32S 
against symbol `inat_primary_table' can not be used when making a shared 
object; recompile with -fPIC
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: error: ld returned 1 exit status


Looking at the Intel PT bits now...

- Arnaldo


Re: [PATCH 2/3] perf tools: Fix build for hardened environments

2017-11-29 Thread Arnaldo Carvalho de Melo
Em Fri, Nov 10, 2017 at 10:43:25AM +0100, Jiri Olsa escreveu:
> On Thu, Nov 09, 2017 at 09:52:12AM -0300, Arnaldo Carvalho de Melo wrote:
> > Right, since we want to honour what the distro makers decided was the
> > best set for them, and to be able to link with other libraries, etc.

> > But then I think this should be done more explicitely, right? Do you
> > envision some way to do that without having to try to build perl or
> > python, that may not be installed, etc?

> I'll check on it.. I think we could use feature detection and
> enable that by default and add NO_HARDENED_BUILD variable as
> we do for features.. and detect that python/perl or whatever
> else is using that and warn
 
> > Of course users wanting to use something different may just set CFLAGS
> > and be done with it, in which case I think this should also affect the
> > perl and python CFLAGS, removing that distro specific stuff since the
> > user is changing something different.
 
> yep

Even with this patch applied, as a stopgap solution to allow me to build
a full featured tool on f27, I get this leftover:

  LINK /tmp/build/perf/perf
/usr/bin/ld: /tmp/build/perf/libperf.a(libperf-in.o): relocation R_X86_64_32S 
against symbol `inat_primary_table' can not be used when making a shared 
object; recompile with -fPIC
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: error: ld returned 1 exit status


Looking at the Intel PT bits now...

- Arnaldo


Re: [PATCH 2/3] perf tools: Fix build for hardened environments

2017-11-23 Thread Jiri Olsa
On Thu, Nov 23, 2017 at 11:15:32AM -0300, Arnaldo Carvalho de Melo wrote:

SNIP

> 
> I stumbled it on a recently created perf build container for fedora 27:
> 
> fedora:27
> Downloading http://192.168.124.1/perf/perf-4.14.0.tar.xz...
>   % Total% Received % Xferd  Average Speed   TimeTime Time  
> Current
>  Dload  Upload   Total   SpentLeft  Speed
> 
> make: Entering directory '/git/linux/tools/perf'
>   BUILD:   Doing 'make -j4 parallel build
>   HOSTCC   /tmp/build/perf/fixdep.o
>   HOSTLD   /tmp/build/perf/fixdep-in.o
>   LINK /tmp/build/perf/fixdep
> 
> Auto-detecting system features:
> ... 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 ]
> 
> Makefile.config:813: No openjdk development package found, please install JDK 
> package
>   GEN  /tmp/build/perf/common-cmds.h
>   PERF_VERSION = 4.14.geae86e
>   MKDIR/tmp/build/perf/fd/
>   CC   /tmp/build/perf/fd/array.o
>   CC   /tmp/build/perf/exec-cmd.o
>   CC   /tmp/build/perf/util/parse-events-flex.o
> 
>   LD   /tmp/build/perf/util/libperf-in.o
>   LD   /tmp/build/perf/libperf-in.o
>   AR   /tmp/build/perf/libperf.a
>   LINK /tmp/build/perf/perf
>   LINK /tmp/build/perf/libperf-gtk.so
> /usr/bin/ld: /tmp/build/perf/perf-in.o: relocation R_X86_64_32 against 
> `.rodata.str1.1' can not be used when making a shared object; recompile with 
> -fPIC
> /usr/bin/ld: /tmp/build/perf/libperf.a(libperf-in.o): relocation R_X86_64_32S 
> against `.text' can not be used when making a shared object; recompile with 
> -fPIC
> /usr/bin/ld: final link failed: Nonrepresentable section on output
> collect2: error: ld returned 1 exit status
> make[2]: *** [Makefile.perf:507: /tmp/build/perf/perf] Error 1
> make[1]: *** [Makefile.perf:210: sub-make] Error 2
> make: *** [Makefile:70: all] Error 2
> make: Leaving directory '/git/linux/tools/perf'

yep, thats the one ;-) I'll try to repost shortly

jirka


Re: [PATCH 2/3] perf tools: Fix build for hardened environments

2017-11-23 Thread Jiri Olsa
On Thu, Nov 23, 2017 at 11:15:32AM -0300, Arnaldo Carvalho de Melo wrote:

SNIP

> 
> I stumbled it on a recently created perf build container for fedora 27:
> 
> fedora:27
> Downloading http://192.168.124.1/perf/perf-4.14.0.tar.xz...
>   % Total% Received % Xferd  Average Speed   TimeTime Time  
> Current
>  Dload  Upload   Total   SpentLeft  Speed
> 
> make: Entering directory '/git/linux/tools/perf'
>   BUILD:   Doing 'make -j4 parallel build
>   HOSTCC   /tmp/build/perf/fixdep.o
>   HOSTLD   /tmp/build/perf/fixdep-in.o
>   LINK /tmp/build/perf/fixdep
> 
> Auto-detecting system features:
> ... 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 ]
> 
> Makefile.config:813: No openjdk development package found, please install JDK 
> package
>   GEN  /tmp/build/perf/common-cmds.h
>   PERF_VERSION = 4.14.geae86e
>   MKDIR/tmp/build/perf/fd/
>   CC   /tmp/build/perf/fd/array.o
>   CC   /tmp/build/perf/exec-cmd.o
>   CC   /tmp/build/perf/util/parse-events-flex.o
> 
>   LD   /tmp/build/perf/util/libperf-in.o
>   LD   /tmp/build/perf/libperf-in.o
>   AR   /tmp/build/perf/libperf.a
>   LINK /tmp/build/perf/perf
>   LINK /tmp/build/perf/libperf-gtk.so
> /usr/bin/ld: /tmp/build/perf/perf-in.o: relocation R_X86_64_32 against 
> `.rodata.str1.1' can not be used when making a shared object; recompile with 
> -fPIC
> /usr/bin/ld: /tmp/build/perf/libperf.a(libperf-in.o): relocation R_X86_64_32S 
> against `.text' can not be used when making a shared object; recompile with 
> -fPIC
> /usr/bin/ld: final link failed: Nonrepresentable section on output
> collect2: error: ld returned 1 exit status
> make[2]: *** [Makefile.perf:507: /tmp/build/perf/perf] Error 1
> make[1]: *** [Makefile.perf:210: sub-make] Error 2
> make: *** [Makefile:70: all] Error 2
> make: Leaving directory '/git/linux/tools/perf'

yep, thats the one ;-) I'll try to repost shortly

jirka


Re: [PATCH 2/3] perf tools: Fix build for hardened environments

2017-11-23 Thread Arnaldo Carvalho de Melo
Em Fri, Nov 10, 2017 at 10:43:25AM +0100, Jiri Olsa escreveu:
> On Thu, Nov 09, 2017 at 09:52:12AM -0300, Arnaldo Carvalho de Melo wrote:
> > Em Thu, Nov 09, 2017 at 08:36:22AM +0100, Jiri Olsa escreveu:
> > > On Wed, Nov 08, 2017 at 01:03:21PM -0300, Arnaldo Carvalho de Melo wrote:
> > > > Em Wed, Nov 08, 2017 at 11:27:38AM +0100, Jiri Olsa escreveu:
> > > > > Mainly it's caused by perl/python objects being compiled with:

> > > > >   -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1

> > > > > which prevent the final link impossible, because it will check
> > > > > for 'proper' objects with following option:

> > > > >   -specs=/usr/lib/rpm/redhat/redhat-hardened-ld

> > > > > Fixing this by using the perl/python CFLAGS/LDFLAGS options
> > > > > for all the objects.

> > > > Humm, so we're basically using the hardened config only we build with
> > > > PERL or PYTHON, should we use that always, i.e. ask the distro what set
> > > > of flags we should use?

> > > right, I think this needs to be detected like we do for features,
> > > since there maybe some supported gcc versions to detect

> > Right, since we want to honour what the distro makers decided was the
> > best set for them, and to be able to link with other libraries, etc.

> > But then I think this should be done more explicitely, right? Do you
> > envision some way to do that without having to try to build perl or
> > python, that may not be installed, etc?
 
> I'll check on it.. I think we could use feature detection and
> enable that by default and add NO_HARDENED_BUILD variable as
> we do for features.. and detect that python/perl or whatever
> else is using that and warn

I stumbled it on a recently created perf build container for fedora 27:

fedora:27
Downloading http://192.168.124.1/perf/perf-4.14.0.tar.xz...
  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
 Dload  Upload   Total   SpentLeft  Speed

make: Entering directory '/git/linux/tools/perf'
  BUILD:   Doing 'make -j4 parallel build
  HOSTCC   /tmp/build/perf/fixdep.o
  HOSTLD   /tmp/build/perf/fixdep-in.o
  LINK /tmp/build/perf/fixdep

Auto-detecting system features:
... 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 ]

Makefile.config:813: No openjdk development package found, please install JDK 
package
  GEN  /tmp/build/perf/common-cmds.h
  PERF_VERSION = 4.14.geae86e
  MKDIR/tmp/build/perf/fd/
  CC   /tmp/build/perf/fd/array.o
  CC   /tmp/build/perf/exec-cmd.o
  CC   /tmp/build/perf/util/parse-events-flex.o

  LD   /tmp/build/perf/util/libperf-in.o
  LD   /tmp/build/perf/libperf-in.o
  AR   /tmp/build/perf/libperf.a
  LINK /tmp/build/perf/perf
  LINK /tmp/build/perf/libperf-gtk.so
/usr/bin/ld: /tmp/build/perf/perf-in.o: relocation R_X86_64_32 against 
`.rodata.str1.1' can not be used when making a shared object; recompile with 
-fPIC
/usr/bin/ld: /tmp/build/perf/libperf.a(libperf-in.o): relocation R_X86_64_32S 
against `.text' can not be used when making a shared object; recompile with 
-fPIC
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: error: ld returned 1 exit status
make[2]: *** [Makefile.perf:507: /tmp/build/perf/perf] Error 1
make[1]: *** [Makefile.perf:210: sub-make] Error 2
make: *** [Makefile:70: all] Error 2
make: Leaving directory '/git/linux/tools/perf'


Re: [PATCH 2/3] perf tools: Fix build for hardened environments

2017-11-23 Thread Arnaldo Carvalho de Melo
Em Fri, Nov 10, 2017 at 10:43:25AM +0100, Jiri Olsa escreveu:
> On Thu, Nov 09, 2017 at 09:52:12AM -0300, Arnaldo Carvalho de Melo wrote:
> > Em Thu, Nov 09, 2017 at 08:36:22AM +0100, Jiri Olsa escreveu:
> > > On Wed, Nov 08, 2017 at 01:03:21PM -0300, Arnaldo Carvalho de Melo wrote:
> > > > Em Wed, Nov 08, 2017 at 11:27:38AM +0100, Jiri Olsa escreveu:
> > > > > Mainly it's caused by perl/python objects being compiled with:

> > > > >   -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1

> > > > > which prevent the final link impossible, because it will check
> > > > > for 'proper' objects with following option:

> > > > >   -specs=/usr/lib/rpm/redhat/redhat-hardened-ld

> > > > > Fixing this by using the perl/python CFLAGS/LDFLAGS options
> > > > > for all the objects.

> > > > Humm, so we're basically using the hardened config only we build with
> > > > PERL or PYTHON, should we use that always, i.e. ask the distro what set
> > > > of flags we should use?

> > > right, I think this needs to be detected like we do for features,
> > > since there maybe some supported gcc versions to detect

> > Right, since we want to honour what the distro makers decided was the
> > best set for them, and to be able to link with other libraries, etc.

> > But then I think this should be done more explicitely, right? Do you
> > envision some way to do that without having to try to build perl or
> > python, that may not be installed, etc?
 
> I'll check on it.. I think we could use feature detection and
> enable that by default and add NO_HARDENED_BUILD variable as
> we do for features.. and detect that python/perl or whatever
> else is using that and warn

I stumbled it on a recently created perf build container for fedora 27:

fedora:27
Downloading http://192.168.124.1/perf/perf-4.14.0.tar.xz...
  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
 Dload  Upload   Total   SpentLeft  Speed

make: Entering directory '/git/linux/tools/perf'
  BUILD:   Doing 'make -j4 parallel build
  HOSTCC   /tmp/build/perf/fixdep.o
  HOSTLD   /tmp/build/perf/fixdep-in.o
  LINK /tmp/build/perf/fixdep

Auto-detecting system features:
... 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 ]

Makefile.config:813: No openjdk development package found, please install JDK 
package
  GEN  /tmp/build/perf/common-cmds.h
  PERF_VERSION = 4.14.geae86e
  MKDIR/tmp/build/perf/fd/
  CC   /tmp/build/perf/fd/array.o
  CC   /tmp/build/perf/exec-cmd.o
  CC   /tmp/build/perf/util/parse-events-flex.o

  LD   /tmp/build/perf/util/libperf-in.o
  LD   /tmp/build/perf/libperf-in.o
  AR   /tmp/build/perf/libperf.a
  LINK /tmp/build/perf/perf
  LINK /tmp/build/perf/libperf-gtk.so
/usr/bin/ld: /tmp/build/perf/perf-in.o: relocation R_X86_64_32 against 
`.rodata.str1.1' can not be used when making a shared object; recompile with 
-fPIC
/usr/bin/ld: /tmp/build/perf/libperf.a(libperf-in.o): relocation R_X86_64_32S 
against `.text' can not be used when making a shared object; recompile with 
-fPIC
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: error: ld returned 1 exit status
make[2]: *** [Makefile.perf:507: /tmp/build/perf/perf] Error 1
make[1]: *** [Makefile.perf:210: sub-make] Error 2
make: *** [Makefile:70: all] Error 2
make: Leaving directory '/git/linux/tools/perf'


Re: [PATCH 2/3] perf tools: Fix build for hardened environments

2017-11-10 Thread Jiri Olsa
On Thu, Nov 09, 2017 at 09:52:12AM -0300, Arnaldo Carvalho de Melo wrote:
> Em Thu, Nov 09, 2017 at 08:36:22AM +0100, Jiri Olsa escreveu:
> > On Wed, Nov 08, 2017 at 01:03:21PM -0300, Arnaldo Carvalho de Melo wrote:
> > > Em Wed, Nov 08, 2017 at 11:27:38AM +0100, Jiri Olsa escreveu:
> > > > From: Jiri Olsa 
> > > > 
> > > > On Fedora systems the perl and python CFLAGS/LDFLAGS include the
> > > > hardened specs from redhat-rpm-config package. We apply them only
> > > > for perl/python objects, which makes them not compatible with the
> > > > rest of the objects and the build fails with:
> > > > 
> > > >   /usr/bin/ld: perf-in.o: relocation R_X86_64_32 against 
> > > > `.rodata.str1.1' can not be used when making a shared object; recompile 
> > > > with -fPIC
> > > >   /usr/bin/ld: libperf.a(libperf-in.o): relocation R_X86_64_32S against 
> > > > `.text' can not be used when making a shared object; recompile with 
> > > > -fPIC
> > > >   /usr/bin/ld: final link failed: Nonrepresentable section on output
> > > >   collect2: error: ld returned 1 exit status
> > > >   make[2]: *** [Makefile.perf:507: perf] Error 1
> > > >   make[1]: *** [Makefile.perf:210: sub-make] Error 2
> > > >   make: *** [Makefile:69: all] Error 2
> > > > 
> > > > Mainly it's caused by perl/python objects being compiled with:
> > > > 
> > > >   -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
> > > > 
> > > > which prevent the final link impossible, because it will check
> > > > for 'proper' objects with following option:
> > > > 
> > > >   -specs=/usr/lib/rpm/redhat/redhat-hardened-ld
> > > > 
> > > > Fixing this by using the perl/python CFLAGS/LDFLAGS options
> > > > for all the objects.
> > > 
> > > Humm, so we're basically using the hardened config only we build with
> > > PERL or PYTHON, should we use that always, i.e. ask the distro what set
> > > of flags we should use?
> > 
> > right, I think this needs to be detected like we do for features,
> > since there maybe some supported gcc versions to detect
> 
> Right, since we want to honour what the distro makers decided was the
> best set for them, and to be able to link with other libraries, etc.
> 
> But then I think this should be done more explicitely, right? Do you
> envision some way to do that without having to try to build perl or
> python, that may not be installed, etc?
> 

I'll check on it.. I think we could use feature detection and
enable that by default and add NO_HARDENED_BUILD variable as
we do for features.. and detect that python/perl or whatever
else is using that and warn

> Of course users wanting to use something different may just set CFLAGS
> and be done with it, in which case I think this should also affect the
> perl and python CFLAGS, removing that distro specific stuff since the
> user is changing something different.

yep

jirka


Re: [PATCH 2/3] perf tools: Fix build for hardened environments

2017-11-10 Thread Jiri Olsa
On Thu, Nov 09, 2017 at 09:52:12AM -0300, Arnaldo Carvalho de Melo wrote:
> Em Thu, Nov 09, 2017 at 08:36:22AM +0100, Jiri Olsa escreveu:
> > On Wed, Nov 08, 2017 at 01:03:21PM -0300, Arnaldo Carvalho de Melo wrote:
> > > Em Wed, Nov 08, 2017 at 11:27:38AM +0100, Jiri Olsa escreveu:
> > > > From: Jiri Olsa 
> > > > 
> > > > On Fedora systems the perl and python CFLAGS/LDFLAGS include the
> > > > hardened specs from redhat-rpm-config package. We apply them only
> > > > for perl/python objects, which makes them not compatible with the
> > > > rest of the objects and the build fails with:
> > > > 
> > > >   /usr/bin/ld: perf-in.o: relocation R_X86_64_32 against 
> > > > `.rodata.str1.1' can not be used when making a shared object; recompile 
> > > > with -fPIC
> > > >   /usr/bin/ld: libperf.a(libperf-in.o): relocation R_X86_64_32S against 
> > > > `.text' can not be used when making a shared object; recompile with 
> > > > -fPIC
> > > >   /usr/bin/ld: final link failed: Nonrepresentable section on output
> > > >   collect2: error: ld returned 1 exit status
> > > >   make[2]: *** [Makefile.perf:507: perf] Error 1
> > > >   make[1]: *** [Makefile.perf:210: sub-make] Error 2
> > > >   make: *** [Makefile:69: all] Error 2
> > > > 
> > > > Mainly it's caused by perl/python objects being compiled with:
> > > > 
> > > >   -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
> > > > 
> > > > which prevent the final link impossible, because it will check
> > > > for 'proper' objects with following option:
> > > > 
> > > >   -specs=/usr/lib/rpm/redhat/redhat-hardened-ld
> > > > 
> > > > Fixing this by using the perl/python CFLAGS/LDFLAGS options
> > > > for all the objects.
> > > 
> > > Humm, so we're basically using the hardened config only we build with
> > > PERL or PYTHON, should we use that always, i.e. ask the distro what set
> > > of flags we should use?
> > 
> > right, I think this needs to be detected like we do for features,
> > since there maybe some supported gcc versions to detect
> 
> Right, since we want to honour what the distro makers decided was the
> best set for them, and to be able to link with other libraries, etc.
> 
> But then I think this should be done more explicitely, right? Do you
> envision some way to do that without having to try to build perl or
> python, that may not be installed, etc?
> 

I'll check on it.. I think we could use feature detection and
enable that by default and add NO_HARDENED_BUILD variable as
we do for features.. and detect that python/perl or whatever
else is using that and warn

> Of course users wanting to use something different may just set CFLAGS
> and be done with it, in which case I think this should also affect the
> perl and python CFLAGS, removing that distro specific stuff since the
> user is changing something different.

yep

jirka


Re: [PATCH 2/3] perf tools: Fix build for hardened environments

2017-11-09 Thread Arnaldo Carvalho de Melo
Em Thu, Nov 09, 2017 at 08:36:22AM +0100, Jiri Olsa escreveu:
> On Wed, Nov 08, 2017 at 01:03:21PM -0300, Arnaldo Carvalho de Melo wrote:
> > Em Wed, Nov 08, 2017 at 11:27:38AM +0100, Jiri Olsa escreveu:
> > > From: Jiri Olsa 
> > > 
> > > On Fedora systems the perl and python CFLAGS/LDFLAGS include the
> > > hardened specs from redhat-rpm-config package. We apply them only
> > > for perl/python objects, which makes them not compatible with the
> > > rest of the objects and the build fails with:
> > > 
> > >   /usr/bin/ld: perf-in.o: relocation R_X86_64_32 against `.rodata.str1.1' 
> > > can not be used when making a shared object; recompile with -fPIC
> > >   /usr/bin/ld: libperf.a(libperf-in.o): relocation R_X86_64_32S against 
> > > `.text' can not be used when making a shared object; recompile with -fPIC
> > >   /usr/bin/ld: final link failed: Nonrepresentable section on output
> > >   collect2: error: ld returned 1 exit status
> > >   make[2]: *** [Makefile.perf:507: perf] Error 1
> > >   make[1]: *** [Makefile.perf:210: sub-make] Error 2
> > >   make: *** [Makefile:69: all] Error 2
> > > 
> > > Mainly it's caused by perl/python objects being compiled with:
> > > 
> > >   -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
> > > 
> > > which prevent the final link impossible, because it will check
> > > for 'proper' objects with following option:
> > > 
> > >   -specs=/usr/lib/rpm/redhat/redhat-hardened-ld
> > > 
> > > Fixing this by using the perl/python CFLAGS/LDFLAGS options
> > > for all the objects.
> > 
> > Humm, so we're basically using the hardened config only we build with
> > PERL or PYTHON, should we use that always, i.e. ask the distro what set
> > of flags we should use?
> 
> right, I think this needs to be detected like we do for features,
> since there maybe some supported gcc versions to detect

Right, since we want to honour what the distro makers decided was the
best set for them, and to be able to link with other libraries, etc.

But then I think this should be done more explicitely, right? Do you
envision some way to do that without having to try to build perl or
python, that may not be installed, etc?

Of course users wanting to use something different may just set CFLAGS
and be done with it, in which case I think this should also affect the
perl and python CFLAGS, removing that distro specific stuff since the
user is changing something different.
 
> > What other impacts this may have on using this for all of the tools?
> > I.e. we could conceivably just remove that part from the perl/python
> > builds and make them use what has been used for the rest of the tools
> > instead?
> 
> hum, so those are the flags the perl/python extensions are built with
> 
> we have both perl/python extensions built in the perf for the script cmd,
> which creates dependencies:
> 
>   [jolsa@krava perf]$ ldd ./perf  |grep perl
>   libperl.so.5.24 => /lib64/libperl.so.5.24 (0x7f72b33b3000)
>   [jolsa@krava perf]$ ldd ./perf  |grep python
>   libpython2.7.so.1.0 => /lib64/libpython2.7.so.1.0 
> (0x7f927cfe7000)
> 
>   not sure we could be affected here if we remove that hardened spec 
> option
> 
> and then we have the python module extension which is used separately of
> perf binary, which should be fine
> 
> jirka


Re: [PATCH 2/3] perf tools: Fix build for hardened environments

2017-11-09 Thread Arnaldo Carvalho de Melo
Em Thu, Nov 09, 2017 at 08:36:22AM +0100, Jiri Olsa escreveu:
> On Wed, Nov 08, 2017 at 01:03:21PM -0300, Arnaldo Carvalho de Melo wrote:
> > Em Wed, Nov 08, 2017 at 11:27:38AM +0100, Jiri Olsa escreveu:
> > > From: Jiri Olsa 
> > > 
> > > On Fedora systems the perl and python CFLAGS/LDFLAGS include the
> > > hardened specs from redhat-rpm-config package. We apply them only
> > > for perl/python objects, which makes them not compatible with the
> > > rest of the objects and the build fails with:
> > > 
> > >   /usr/bin/ld: perf-in.o: relocation R_X86_64_32 against `.rodata.str1.1' 
> > > can not be used when making a shared object; recompile with -fPIC
> > >   /usr/bin/ld: libperf.a(libperf-in.o): relocation R_X86_64_32S against 
> > > `.text' can not be used when making a shared object; recompile with -fPIC
> > >   /usr/bin/ld: final link failed: Nonrepresentable section on output
> > >   collect2: error: ld returned 1 exit status
> > >   make[2]: *** [Makefile.perf:507: perf] Error 1
> > >   make[1]: *** [Makefile.perf:210: sub-make] Error 2
> > >   make: *** [Makefile:69: all] Error 2
> > > 
> > > Mainly it's caused by perl/python objects being compiled with:
> > > 
> > >   -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
> > > 
> > > which prevent the final link impossible, because it will check
> > > for 'proper' objects with following option:
> > > 
> > >   -specs=/usr/lib/rpm/redhat/redhat-hardened-ld
> > > 
> > > Fixing this by using the perl/python CFLAGS/LDFLAGS options
> > > for all the objects.
> > 
> > Humm, so we're basically using the hardened config only we build with
> > PERL or PYTHON, should we use that always, i.e. ask the distro what set
> > of flags we should use?
> 
> right, I think this needs to be detected like we do for features,
> since there maybe some supported gcc versions to detect

Right, since we want to honour what the distro makers decided was the
best set for them, and to be able to link with other libraries, etc.

But then I think this should be done more explicitely, right? Do you
envision some way to do that without having to try to build perl or
python, that may not be installed, etc?

Of course users wanting to use something different may just set CFLAGS
and be done with it, in which case I think this should also affect the
perl and python CFLAGS, removing that distro specific stuff since the
user is changing something different.
 
> > What other impacts this may have on using this for all of the tools?
> > I.e. we could conceivably just remove that part from the perl/python
> > builds and make them use what has been used for the rest of the tools
> > instead?
> 
> hum, so those are the flags the perl/python extensions are built with
> 
> we have both perl/python extensions built in the perf for the script cmd,
> which creates dependencies:
> 
>   [jolsa@krava perf]$ ldd ./perf  |grep perl
>   libperl.so.5.24 => /lib64/libperl.so.5.24 (0x7f72b33b3000)
>   [jolsa@krava perf]$ ldd ./perf  |grep python
>   libpython2.7.so.1.0 => /lib64/libpython2.7.so.1.0 
> (0x7f927cfe7000)
> 
>   not sure we could be affected here if we remove that hardened spec 
> option
> 
> and then we have the python module extension which is used separately of
> perf binary, which should be fine
> 
> jirka


Re: [PATCH 2/3] perf tools: Fix build for hardened environments

2017-11-08 Thread Jiri Olsa
On Wed, Nov 08, 2017 at 01:03:21PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Wed, Nov 08, 2017 at 11:27:38AM +0100, Jiri Olsa escreveu:
> > From: Jiri Olsa 
> > 
> > On Fedora systems the perl and python CFLAGS/LDFLAGS include the
> > hardened specs from redhat-rpm-config package. We apply them only
> > for perl/python objects, which makes them not compatible with the
> > rest of the objects and the build fails with:
> > 
> >   /usr/bin/ld: perf-in.o: relocation R_X86_64_32 against `.rodata.str1.1' 
> > can not be used when making a shared object; recompile with -fPIC
> >   /usr/bin/ld: libperf.a(libperf-in.o): relocation R_X86_64_32S against 
> > `.text' can not be used when making a shared object; recompile with -fPIC
> >   /usr/bin/ld: final link failed: Nonrepresentable section on output
> >   collect2: error: ld returned 1 exit status
> >   make[2]: *** [Makefile.perf:507: perf] Error 1
> >   make[1]: *** [Makefile.perf:210: sub-make] Error 2
> >   make: *** [Makefile:69: all] Error 2
> > 
> > Mainly it's caused by perl/python objects being compiled with:
> > 
> >   -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
> > 
> > which prevent the final link impossible, because it will check
> > for 'proper' objects with following option:
> > 
> >   -specs=/usr/lib/rpm/redhat/redhat-hardened-ld
> > 
> > Fixing this by using the perl/python CFLAGS/LDFLAGS options
> > for all the objects.
> 
> Humm, so we're basically using the hardened config only we build with
> PERL or PYTHON, should we use that always, i.e. ask the distro what set
> of flags we should use?

right, I think this needs to be detected like we do for features,
since there maybe some supported gcc versions to detect

> What other impacts this may have on using this for all of the tools?
> I.e. we could conceivably just remove that part from the perl/python
> builds and make them use what has been used for the rest of the tools
> instead?

hum, so those are the flags the perl/python extensions are built with

we have both perl/python extensions built in the perf for the script cmd,
which creates dependencies:

[jolsa@krava perf]$ ldd ./perf  |grep perl
libperl.so.5.24 => /lib64/libperl.so.5.24 (0x7f72b33b3000)
[jolsa@krava perf]$ ldd ./perf  |grep python
libpython2.7.so.1.0 => /lib64/libpython2.7.so.1.0 
(0x7f927cfe7000)

not sure we could be affected here if we remove that hardened spec 
option

and then we have the python module extension which is used separately of
perf binary, which should be fine

jirka


Re: [PATCH 2/3] perf tools: Fix build for hardened environments

2017-11-08 Thread Jiri Olsa
On Wed, Nov 08, 2017 at 01:03:21PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Wed, Nov 08, 2017 at 11:27:38AM +0100, Jiri Olsa escreveu:
> > From: Jiri Olsa 
> > 
> > On Fedora systems the perl and python CFLAGS/LDFLAGS include the
> > hardened specs from redhat-rpm-config package. We apply them only
> > for perl/python objects, which makes them not compatible with the
> > rest of the objects and the build fails with:
> > 
> >   /usr/bin/ld: perf-in.o: relocation R_X86_64_32 against `.rodata.str1.1' 
> > can not be used when making a shared object; recompile with -fPIC
> >   /usr/bin/ld: libperf.a(libperf-in.o): relocation R_X86_64_32S against 
> > `.text' can not be used when making a shared object; recompile with -fPIC
> >   /usr/bin/ld: final link failed: Nonrepresentable section on output
> >   collect2: error: ld returned 1 exit status
> >   make[2]: *** [Makefile.perf:507: perf] Error 1
> >   make[1]: *** [Makefile.perf:210: sub-make] Error 2
> >   make: *** [Makefile:69: all] Error 2
> > 
> > Mainly it's caused by perl/python objects being compiled with:
> > 
> >   -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
> > 
> > which prevent the final link impossible, because it will check
> > for 'proper' objects with following option:
> > 
> >   -specs=/usr/lib/rpm/redhat/redhat-hardened-ld
> > 
> > Fixing this by using the perl/python CFLAGS/LDFLAGS options
> > for all the objects.
> 
> Humm, so we're basically using the hardened config only we build with
> PERL or PYTHON, should we use that always, i.e. ask the distro what set
> of flags we should use?

right, I think this needs to be detected like we do for features,
since there maybe some supported gcc versions to detect

> What other impacts this may have on using this for all of the tools?
> I.e. we could conceivably just remove that part from the perl/python
> builds and make them use what has been used for the rest of the tools
> instead?

hum, so those are the flags the perl/python extensions are built with

we have both perl/python extensions built in the perf for the script cmd,
which creates dependencies:

[jolsa@krava perf]$ ldd ./perf  |grep perl
libperl.so.5.24 => /lib64/libperl.so.5.24 (0x7f72b33b3000)
[jolsa@krava perf]$ ldd ./perf  |grep python
libpython2.7.so.1.0 => /lib64/libpython2.7.so.1.0 
(0x7f927cfe7000)

not sure we could be affected here if we remove that hardened spec 
option

and then we have the python module extension which is used separately of
perf binary, which should be fine

jirka


Re: [PATCH 2/3] perf tools: Fix build for hardened environments

2017-11-08 Thread Arnaldo Carvalho de Melo
Em Wed, Nov 08, 2017 at 11:27:38AM +0100, Jiri Olsa escreveu:
> From: Jiri Olsa 
> 
> On Fedora systems the perl and python CFLAGS/LDFLAGS include the
> hardened specs from redhat-rpm-config package. We apply them only
> for perl/python objects, which makes them not compatible with the
> rest of the objects and the build fails with:
> 
>   /usr/bin/ld: perf-in.o: relocation R_X86_64_32 against `.rodata.str1.1' can 
> not be used when making a shared object; recompile with -fPIC
>   /usr/bin/ld: libperf.a(libperf-in.o): relocation R_X86_64_32S against 
> `.text' can not be used when making a shared object; recompile with -fPIC
>   /usr/bin/ld: final link failed: Nonrepresentable section on output
>   collect2: error: ld returned 1 exit status
>   make[2]: *** [Makefile.perf:507: perf] Error 1
>   make[1]: *** [Makefile.perf:210: sub-make] Error 2
>   make: *** [Makefile:69: all] Error 2
> 
> Mainly it's caused by perl/python objects being compiled with:
> 
>   -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
> 
> which prevent the final link impossible, because it will check
> for 'proper' objects with following option:
> 
>   -specs=/usr/lib/rpm/redhat/redhat-hardened-ld
> 
> Fixing this by using the perl/python CFLAGS/LDFLAGS options
> for all the objects.

Humm, so we're basically using the hardened config only we build with
PERL or PYTHON, should we use that always, i.e. ask the distro what set
of flags we should use?

What other impacts this may have on using this for all of the tools?
I.e. we could conceivably just remove that part from the perl/python
builds and make them use what has been used for the rest of the tools
instead?

- Arnaldo


Re: [PATCH 2/3] perf tools: Fix build for hardened environments

2017-11-08 Thread Arnaldo Carvalho de Melo
Em Wed, Nov 08, 2017 at 11:27:38AM +0100, Jiri Olsa escreveu:
> From: Jiri Olsa 
> 
> On Fedora systems the perl and python CFLAGS/LDFLAGS include the
> hardened specs from redhat-rpm-config package. We apply them only
> for perl/python objects, which makes them not compatible with the
> rest of the objects and the build fails with:
> 
>   /usr/bin/ld: perf-in.o: relocation R_X86_64_32 against `.rodata.str1.1' can 
> not be used when making a shared object; recompile with -fPIC
>   /usr/bin/ld: libperf.a(libperf-in.o): relocation R_X86_64_32S against 
> `.text' can not be used when making a shared object; recompile with -fPIC
>   /usr/bin/ld: final link failed: Nonrepresentable section on output
>   collect2: error: ld returned 1 exit status
>   make[2]: *** [Makefile.perf:507: perf] Error 1
>   make[1]: *** [Makefile.perf:210: sub-make] Error 2
>   make: *** [Makefile:69: all] Error 2
> 
> Mainly it's caused by perl/python objects being compiled with:
> 
>   -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
> 
> which prevent the final link impossible, because it will check
> for 'proper' objects with following option:
> 
>   -specs=/usr/lib/rpm/redhat/redhat-hardened-ld
> 
> Fixing this by using the perl/python CFLAGS/LDFLAGS options
> for all the objects.

Humm, so we're basically using the hardened config only we build with
PERL or PYTHON, should we use that always, i.e. ask the distro what set
of flags we should use?

What other impacts this may have on using this for all of the tools?
I.e. we could conceivably just remove that part from the perl/python
builds and make them use what has been used for the rest of the tools
instead?

- Arnaldo


[PATCH 2/3] perf tools: Fix build for hardened environments

2017-11-08 Thread Jiri Olsa
From: Jiri Olsa 

On Fedora systems the perl and python CFLAGS/LDFLAGS include the
hardened specs from redhat-rpm-config package. We apply them only
for perl/python objects, which makes them not compatible with the
rest of the objects and the build fails with:

  /usr/bin/ld: perf-in.o: relocation R_X86_64_32 against `.rodata.str1.1' can 
not be used when making a shared object; recompile with -fPIC
  /usr/bin/ld: libperf.a(libperf-in.o): relocation R_X86_64_32S against `.text' 
can not be used when making a shared object; recompile with -fPIC
  /usr/bin/ld: final link failed: Nonrepresentable section on output
  collect2: error: ld returned 1 exit status
  make[2]: *** [Makefile.perf:507: perf] Error 1
  make[1]: *** [Makefile.perf:210: sub-make] Error 2
  make: *** [Makefile:69: all] Error 2

Mainly it's caused by perl/python objects being compiled with:

  -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1

which prevent the final link impossible, because it will check
for 'proper' objects with following option:

  -specs=/usr/lib/rpm/redhat/redhat-hardened-ld

Fixing this by using the perl/python CFLAGS/LDFLAGS options
for all the objects.

Link: http://lkml.kernel.org/n/tip-bib4nb5dei0ubk83534ef...@git.kernel.org
Signed-off-by: Jiri Olsa 
---
 tools/perf/Makefile.config  | 2 ++
 tools/perf/scripts/perl/Perf-Trace-Util/Build   | 2 +-
 tools/perf/scripts/python/Perf-Trace-Util/Build | 2 +-
 tools/perf/util/block-range.c   | 2 +-
 tools/perf/util/scripting-engines/Build | 4 ++--
 5 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/tools/perf/Makefile.config b/tools/perf/Makefile.config
index f6786fa2419f..5e3734e4c1e4 100644
--- a/tools/perf/Makefile.config
+++ b/tools/perf/Makefile.config
@@ -587,6 +587,7 @@ else
 NO_LIBPERL := 1
 msg := $(warning Missing perl devel files. Disabling perl scripting 
support, please install perl-ExtUtils-Embed/libperl-dev);
   else
+CFLAGS  += $(PERL_EMBED_CCOPTS)
 LDFLAGS += $(PERL_EMBED_LDFLAGS)
 EXTLIBS += $(PERL_EMBED_LIBADD)
 $(call detected,CONFIG_LIBPERL)
@@ -636,6 +637,7 @@ else
   $(warning $(and ,))
   $(error   $(and ,))
 else
+  CFLAGS  += $(PYTHON_EMBED_CCOPTS)
   LDFLAGS += $(PYTHON_EMBED_LDFLAGS)
   EXTLIBS += $(PYTHON_EMBED_LIBADD)
   LANG_BINDINGS += $(obj-perf)python/perf.so
diff --git a/tools/perf/scripts/perl/Perf-Trace-Util/Build 
b/tools/perf/scripts/perl/Perf-Trace-Util/Build
index 34faecf774ae..ff9a452677fc 100644
--- a/tools/perf/scripts/perl/Perf-Trace-Util/Build
+++ b/tools/perf/scripts/perl/Perf-Trace-Util/Build
@@ -1,5 +1,5 @@
 libperf-y += Context.o
 
-CFLAGS_Context.o += $(PERL_EMBED_CCOPTS) -Wno-redundant-decls 
-Wno-strict-prototypes
+CFLAGS_Context.o += -Wno-redundant-decls -Wno-strict-prototypes
 CFLAGS_Context.o += -Wno-unused-parameter -Wno-nested-externs -Wno-undef
 CFLAGS_Context.o += -Wno-switch-default -Wno-shadow
diff --git a/tools/perf/scripts/python/Perf-Trace-Util/Build 
b/tools/perf/scripts/python/Perf-Trace-Util/Build
index aefc15c9444a..cd4da129c017 100644
--- a/tools/perf/scripts/python/Perf-Trace-Util/Build
+++ b/tools/perf/scripts/python/Perf-Trace-Util/Build
@@ -1,3 +1,3 @@
 libperf-y += Context.o
 
-CFLAGS_Context.o += $(PYTHON_EMBED_CCOPTS) -Wno-redundant-decls 
-Wno-strict-prototypes -Wno-unused-parameter -Wno-nested-externs
+CFLAGS_Context.o += -Wno-redundant-decls -Wno-strict-prototypes 
-Wno-unused-parameter -Wno-nested-externs
diff --git a/tools/perf/util/block-range.c b/tools/perf/util/block-range.c
index f1451c987eec..ff76d5f1d96f 100644
--- a/tools/perf/util/block-range.c
+++ b/tools/perf/util/block-range.c
@@ -15,7 +15,7 @@ static void block_range__debug(void)
 */
 #if 1
struct rb_node *rb;
-   u64 old = 0; /* NULL isn't executable */
+   u64 old __maybe_unused = 0; /* NULL isn't executable */
 
for (rb = rb_first(_ranges.root); rb; rb = rb_next(rb)) {
struct block_range *entry = rb_entry(rb, struct block_range, 
node);
diff --git a/tools/perf/util/scripting-engines/Build 
b/tools/perf/util/scripting-engines/Build
index 82d28c67e0f3..38cd25ce1503 100644
--- a/tools/perf/util/scripting-engines/Build
+++ b/tools/perf/util/scripting-engines/Build
@@ -1,6 +1,6 @@
 libperf-$(CONFIG_LIBPERL)   += trace-event-perl.o
 libperf-$(CONFIG_LIBPYTHON) += trace-event-python.o
 
-CFLAGS_trace-event-perl.o += $(PERL_EMBED_CCOPTS) -Wno-redundant-decls 
-Wno-strict-prototypes -Wno-unused-parameter -Wno-shadow -Wno-nested-externs 
-Wno-undef -Wno-switch-default
+CFLAGS_trace-event-perl.o += -Wno-redundant-decls -Wno-strict-prototypes 
-Wno-unused-parameter -Wno-shadow -Wno-nested-externs -Wno-undef 
-Wno-switch-default
 
-CFLAGS_trace-event-python.o += $(PYTHON_EMBED_CCOPTS) -Wno-redundant-decls 
-Wno-strict-prototypes -Wno-unused-parameter -Wno-shadow
+CFLAGS_trace-event-python.o += -Wno-redundant-decls 

[PATCH 2/3] perf tools: Fix build for hardened environments

2017-11-08 Thread Jiri Olsa
From: Jiri Olsa 

On Fedora systems the perl and python CFLAGS/LDFLAGS include the
hardened specs from redhat-rpm-config package. We apply them only
for perl/python objects, which makes them not compatible with the
rest of the objects and the build fails with:

  /usr/bin/ld: perf-in.o: relocation R_X86_64_32 against `.rodata.str1.1' can 
not be used when making a shared object; recompile with -fPIC
  /usr/bin/ld: libperf.a(libperf-in.o): relocation R_X86_64_32S against `.text' 
can not be used when making a shared object; recompile with -fPIC
  /usr/bin/ld: final link failed: Nonrepresentable section on output
  collect2: error: ld returned 1 exit status
  make[2]: *** [Makefile.perf:507: perf] Error 1
  make[1]: *** [Makefile.perf:210: sub-make] Error 2
  make: *** [Makefile:69: all] Error 2

Mainly it's caused by perl/python objects being compiled with:

  -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1

which prevent the final link impossible, because it will check
for 'proper' objects with following option:

  -specs=/usr/lib/rpm/redhat/redhat-hardened-ld

Fixing this by using the perl/python CFLAGS/LDFLAGS options
for all the objects.

Link: http://lkml.kernel.org/n/tip-bib4nb5dei0ubk83534ef...@git.kernel.org
Signed-off-by: Jiri Olsa 
---
 tools/perf/Makefile.config  | 2 ++
 tools/perf/scripts/perl/Perf-Trace-Util/Build   | 2 +-
 tools/perf/scripts/python/Perf-Trace-Util/Build | 2 +-
 tools/perf/util/block-range.c   | 2 +-
 tools/perf/util/scripting-engines/Build | 4 ++--
 5 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/tools/perf/Makefile.config b/tools/perf/Makefile.config
index f6786fa2419f..5e3734e4c1e4 100644
--- a/tools/perf/Makefile.config
+++ b/tools/perf/Makefile.config
@@ -587,6 +587,7 @@ else
 NO_LIBPERL := 1
 msg := $(warning Missing perl devel files. Disabling perl scripting 
support, please install perl-ExtUtils-Embed/libperl-dev);
   else
+CFLAGS  += $(PERL_EMBED_CCOPTS)
 LDFLAGS += $(PERL_EMBED_LDFLAGS)
 EXTLIBS += $(PERL_EMBED_LIBADD)
 $(call detected,CONFIG_LIBPERL)
@@ -636,6 +637,7 @@ else
   $(warning $(and ,))
   $(error   $(and ,))
 else
+  CFLAGS  += $(PYTHON_EMBED_CCOPTS)
   LDFLAGS += $(PYTHON_EMBED_LDFLAGS)
   EXTLIBS += $(PYTHON_EMBED_LIBADD)
   LANG_BINDINGS += $(obj-perf)python/perf.so
diff --git a/tools/perf/scripts/perl/Perf-Trace-Util/Build 
b/tools/perf/scripts/perl/Perf-Trace-Util/Build
index 34faecf774ae..ff9a452677fc 100644
--- a/tools/perf/scripts/perl/Perf-Trace-Util/Build
+++ b/tools/perf/scripts/perl/Perf-Trace-Util/Build
@@ -1,5 +1,5 @@
 libperf-y += Context.o
 
-CFLAGS_Context.o += $(PERL_EMBED_CCOPTS) -Wno-redundant-decls 
-Wno-strict-prototypes
+CFLAGS_Context.o += -Wno-redundant-decls -Wno-strict-prototypes
 CFLAGS_Context.o += -Wno-unused-parameter -Wno-nested-externs -Wno-undef
 CFLAGS_Context.o += -Wno-switch-default -Wno-shadow
diff --git a/tools/perf/scripts/python/Perf-Trace-Util/Build 
b/tools/perf/scripts/python/Perf-Trace-Util/Build
index aefc15c9444a..cd4da129c017 100644
--- a/tools/perf/scripts/python/Perf-Trace-Util/Build
+++ b/tools/perf/scripts/python/Perf-Trace-Util/Build
@@ -1,3 +1,3 @@
 libperf-y += Context.o
 
-CFLAGS_Context.o += $(PYTHON_EMBED_CCOPTS) -Wno-redundant-decls 
-Wno-strict-prototypes -Wno-unused-parameter -Wno-nested-externs
+CFLAGS_Context.o += -Wno-redundant-decls -Wno-strict-prototypes 
-Wno-unused-parameter -Wno-nested-externs
diff --git a/tools/perf/util/block-range.c b/tools/perf/util/block-range.c
index f1451c987eec..ff76d5f1d96f 100644
--- a/tools/perf/util/block-range.c
+++ b/tools/perf/util/block-range.c
@@ -15,7 +15,7 @@ static void block_range__debug(void)
 */
 #if 1
struct rb_node *rb;
-   u64 old = 0; /* NULL isn't executable */
+   u64 old __maybe_unused = 0; /* NULL isn't executable */
 
for (rb = rb_first(_ranges.root); rb; rb = rb_next(rb)) {
struct block_range *entry = rb_entry(rb, struct block_range, 
node);
diff --git a/tools/perf/util/scripting-engines/Build 
b/tools/perf/util/scripting-engines/Build
index 82d28c67e0f3..38cd25ce1503 100644
--- a/tools/perf/util/scripting-engines/Build
+++ b/tools/perf/util/scripting-engines/Build
@@ -1,6 +1,6 @@
 libperf-$(CONFIG_LIBPERL)   += trace-event-perl.o
 libperf-$(CONFIG_LIBPYTHON) += trace-event-python.o
 
-CFLAGS_trace-event-perl.o += $(PERL_EMBED_CCOPTS) -Wno-redundant-decls 
-Wno-strict-prototypes -Wno-unused-parameter -Wno-shadow -Wno-nested-externs 
-Wno-undef -Wno-switch-default
+CFLAGS_trace-event-perl.o += -Wno-redundant-decls -Wno-strict-prototypes 
-Wno-unused-parameter -Wno-shadow -Wno-nested-externs -Wno-undef 
-Wno-switch-default
 
-CFLAGS_trace-event-python.o += $(PYTHON_EMBED_CCOPTS) -Wno-redundant-decls 
-Wno-strict-prototypes -Wno-unused-parameter -Wno-shadow
+CFLAGS_trace-event-python.o += -Wno-redundant-decls -Wno-strict-prototypes 
-Wno-unused-parameter