From: Arnaldo Carvalho de Melo <[email protected]>
Hi Ingo,
Please consider pulling,
- Arnaldo
The following changes since commit b6e53f321ee6f4b237d8cc54fbace3217fa96e05:
Merge tag 'perf-urgent-for-mingo' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/urgent (2014-02-27 12:47:59 +0100)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux tags/perf-urgent-for-mingo
for you to fetch changes up to b39c2a57a00a841f057a75b41df4c26173288b66:
perf tools: Fix strict alias issue for find_first_bit (2014-02-28 10:39:40 -0300)
----------------------------------------------------------------
perf/urgent build fixes:
. Problem on recent gcc on x86-32 related to strict alias issue for
find_first_bit (Jiri Olsa).
. OpenSuSE: BFD detection problems related to not explicitely listing all
required libraries (Andi Kleen)
Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
----------------------------------------------------------------
Andi Kleen (1):
perf tools: fix BFD detection on opensuse
Jiri Olsa (1):
perf tools: Fix strict alias issue for find_first_bit
tools/perf/config/Makefile | 2 +-
tools/perf/config/feature-checks/Makefile | 2 +-
tools/perf/util/include/linux/bitops.h | 4 +++-
3 files changed, 5 insertions(+), 3 deletions(-)
From: Jiri Olsa <[email protected]>
When compiling perf tool code with gcc 4.4.7 I'm getting
following error:
CC util/session.o
cc1: warnings being treated as errors
util/session.c: In function ‘perf_session_deliver_event’:
tools/perf/util/include/linux/bitops.h:109: error: dereferencing pointer ‘p’ does break strict-aliasing rules
tools/perf/util/include/linux/bitops.h:101: error: dereferencing pointer ‘p’ does break strict-aliasing rules
util/session.c:697: note: initialized from here
tools/perf/util/include/linux/bitops.h:101: note: initialized from here
make[1]: *** [util/session.o] Error 1
make: *** [util/session.o] Error 2
The aliased types here are u64 and unsigned long pointers, which is safe
for the find_first_bit processing.
This error shows up for me only for gcc 4.4 on 32bit x86, even for
-Wstrict-aliasing=3, while newer gcc are quiet and scream here for
-Wstrict-aliasing={2,1}. Looks like newer gcc changed the rules for
strict alias warnings.
The gcc documentation offers workaround for valid aliasing by using
__may_alias__ attribute:
http://gcc.gnu.org/onlinedocs/gcc-4.4.0/gcc/Type-Attributes.html
Using this workaround for the find_first_bit function.
Signed-off-by: Jiri Olsa <[email protected]>
Cc: Corey Ashford <[email protected]>
Cc: David Ahern <[email protected]>
Cc: Frederic Weisbecker <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Namhyung Kim <[email protected]>
Cc: Paul Mackerras <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
---
tools/perf/util/include/linux/bitops.h | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/tools/perf/util/include/linux/bitops.h b/tools/perf/util/include/linux/bitops.h
index 45cf10a562bd..dadfa7e54287 100644
--- a/tools/perf/util/include/linux/bitops.h
+++ b/tools/perf/util/include/linux/bitops.h
@@ -87,13 +87,15 @@ static __always_inline unsigned long __ffs(unsigned long word)
return num;
}
+typedef const unsigned long __attribute__((__may_alias__)) long_alias_t;
+
/*
* Find the first set bit in a memory region.
*/
static inline unsigned long
find_first_bit(const unsigned long *addr, unsigned long size)
{
- const unsigned long *p = addr;
+ long_alias_t *p = (long_alias_t *) addr;
unsigned long result = 0;
unsigned long tmp;
--
1.8.1.4
From: Andi Kleen <[email protected]>
opensuse libbfd requires -lz -liberty to build. Add those to the BFD
feature detection.
Signed-off-by: Andi Kleen <[email protected]>
Acked-by: David Ahern <[email protected]>
Acked-by: Jiri Olsa <[email protected]>
Cc: Adrian Hunter <[email protected]>
Cc: David Ahern <[email protected]>
Cc: Frederic Weisbecker <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Jiri Olsa <[email protected]>
Cc: Namhyung Kim <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
---
tools/perf/config/Makefile | 2 +-
tools/perf/config/feature-checks/Makefile | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/perf/config/Makefile b/tools/perf/config/Makefile
index c48d44958172..0331ea2701a3 100644
--- a/tools/perf/config/Makefile
+++ b/tools/perf/config/Makefile
@@ -478,7 +478,7 @@ else
endif
ifeq ($(feature-libbfd), 1)
- EXTLIBS += -lbfd
+ EXTLIBS += -lbfd -lz -liberty
endif
ifdef NO_DEMANGLE
diff --git a/tools/perf/config/feature-checks/Makefile b/tools/perf/config/feature-checks/Makefile
index 12e551346fa6..523b7bc10553 100644
--- a/tools/perf/config/feature-checks/Makefile
+++ b/tools/perf/config/feature-checks/Makefile
@@ -121,7 +121,7 @@ test-libpython-version.bin:
$(BUILD) $(FLAGS_PYTHON_EMBED)
test-libbfd.bin:
- $(BUILD) -DPACKAGE='"perf"' -lbfd -ldl
+ $(BUILD) -DPACKAGE='"perf"' -lbfd -lz -liberty -ldl
test-liberty.bin:
$(CC) -o $(OUTPUT)$@ test-libbfd.c -DPACKAGE='"perf"' -lbfd -ldl -liberty
--
1.8.1.4
On Fri, Feb 28, 2014 at 06:25:51PM -0300, Arnaldo Carvalho de Melo wrote:
> From: Jiri Olsa <[email protected]>
>
> When compiling perf tool code with gcc 4.4.7 I'm getting
> following error:
>
> CC util/session.o
> cc1: warnings being treated as errors
> util/session.c: In function ‘perf_session_deliver_event’:
> tools/perf/util/include/linux/bitops.h:109: error: dereferencing pointer ‘p’ does break strict-aliasing rules
> tools/perf/util/include/linux/bitops.h:101: error: dereferencing pointer ‘p’ does break strict-aliasing rules
> util/session.c:697: note: initialized from here
> tools/perf/util/include/linux/bitops.h:101: note: initialized from here
> make[1]: *** [util/session.o] Error 1
> make: *** [util/session.o] Error 2
>
> The aliased types here are u64 and unsigned long pointers, which is safe
> for the find_first_bit processing.
>
> This error shows up for me only for gcc 4.4 on 32bit x86, even for
> -Wstrict-aliasing=3, while newer gcc are quiet and scream here for
> -Wstrict-aliasing={2,1}. Looks like newer gcc changed the rules for
> strict alias warnings.
>
> The gcc documentation offers workaround for valid aliasing by using
> __may_alias__ attribute:
>
> http://gcc.gnu.org/onlinedocs/gcc-4.4.0/gcc/Type-Attributes.html
>
> Using this workaround for the find_first_bit function.
Hurm; didn't I suggest using -fno-strict-aliasing just like the kernel
does? Because the C aliasing rules are bonghits heavy?
On 2/28/14, 2:29 PM, Peter Zijlstra wrote:
> Hurm; didn't I suggest using -fno-strict-aliasing just like the kernel
> does? Because the C aliasing rules are bonghits heavy?
you, and Ingo in 2009 -- 65014ab3