Hi all,
I've uploaded today's linux-next tree to the master branch of the
repository below:
git://gitorious.org/thierryreding/linux-next.git
A next-20131024 tag is also provided for convenience.
Quite a few new conflicts. Some of them non-trivial. I've fixed another
set of build failures, so 32-bit and 64-bit allmodconfigs build fine on
x86. ARM and x86 default configurations also build fine. PowerPC is in
pretty bad shape, mostly due to some OF header rework going on.
I'm somewhat short on time today, so I probably won't manage to send out
detailed conflict reports out today. I'll try to do that tomorrow,
though.
Thierry
On 10/24/13 09:31, Thierry Reding wrote:
> Hi all,
>
> I've uploaded today's linux-next tree to the master branch of the
> repository below:
>
> git://gitorious.org/thierryreding/linux-next.git
>
> A next-20131024 tag is also provided for convenience.
>
> Quite a few new conflicts. Some of them non-trivial. I've fixed another
> set of build failures, so 32-bit and 64-bit allmodconfigs build fine on
> x86. ARM and x86 default configurations also build fine. PowerPC is in
> pretty bad shape, mostly due to some OF header rework going on.
>
> I'm somewhat short on time today, so I probably won't manage to send out
> detailed conflict reports out today. I'll try to do that tomorrow,
> though.
on i386:
drivers/tty/serial/xilinx_uartps.c: In function 'xuartps_clk_notifier_cb':
drivers/tty/serial/xilinx_uartps.c:436:7: error: 'PRE_RATE_CHANGE' undeclared (first use in this function)
drivers/tty/serial/xilinx_uartps.c:436:7: note: each undeclared identifier is reported only once for each function it appears in
drivers/tty/serial/xilinx_uartps.c:446:36: error: dereferencing pointer to incomplete type
drivers/tty/serial/xilinx_uartps.c:461:7: error: 'POST_RATE_CHANGE' undeclared (first use in this function)
drivers/tty/serial/xilinx_uartps.c:470:24: error: dereferencing pointer to incomplete type
drivers/tty/serial/xilinx_uartps.c:475:7: error: 'ABORT_RATE_CHANGE' undeclared (first use in this function)
drivers/tty/serial/xilinx_uartps.c: In function 'xuartps_probe':
drivers/tty/serial/xilinx_uartps.c:1385:2: error: implicit declaration of function 'clk_notifier_register' [-Werror=implicit-function-declaration]
drivers/tty/serial/xilinx_uartps.c:1418:2: error: implicit declaration of function 'clk_notifier_unregister' [-Werror=implicit-function-declaration]
Full randconfig file is attached.
--
~Randy
On 10/24/2013 09:31 AM, Thierry Reding wrote:
> Hi all,
>
> I've uploaded today's linux-next tree to the master branch of the
> repository below:
>
> git://gitorious.org/thierryreding/linux-next.git
>
> A next-20131024 tag is also provided for convenience.
>
> Quite a few new conflicts. Some of them non-trivial. I've fixed another
> set of build failures, so 32-bit and 64-bit allmodconfigs build fine on
> x86. ARM and x86 default configurations also build fine. PowerPC is in
> pretty bad shape, mostly due to some OF header rework going on.
>
Hmm ... I see
Building arm:defconfig ... failed
--------------
Error log:
drivers/built-in.o: In function `mmc_gpio_request_cd':
clkdev.c:(.text+0x74cf8): undefined reference to `devm_gpio_request_one'
make: *** [vmlinux] Error 1
Otherwise pretty much the same as yesterday, with a build log of
total: 110 pass: 88 skipped: 4 fail: 18
This is with "v3.12-rc5-7941-g765f88c".
Guenter
On Thu, Oct 24, 2013 at 10:02:22PM -0700, Guenter Roeck wrote:
> On 10/24/2013 09:31 AM, Thierry Reding wrote:
> >Hi all,
> >
> >I've uploaded today's linux-next tree to the master branch of the
> >repository below:
> >
> > git://gitorious.org/thierryreding/linux-next.git
> >
> >A next-20131024 tag is also provided for convenience.
> >
> >Quite a few new conflicts. Some of them non-trivial. I've fixed another
> >set of build failures, so 32-bit and 64-bit allmodconfigs build fine on
> >x86. ARM and x86 default configurations also build fine. PowerPC is in
> >pretty bad shape, mostly due to some OF header rework going on.
> >
>
> Hmm ... I see
>
> Building arm:defconfig ... failed
> --------------
> Error log:
> drivers/built-in.o: In function `mmc_gpio_request_cd':
> clkdev.c:(.text+0x74cf8): undefined reference to `devm_gpio_request_one'
> make: *** [vmlinux] Error 1
>
> Otherwise pretty much the same as yesterday, with a build log of
> total: 110 pass: 88 skipped: 4 fail: 18
>
> This is with "v3.12-rc5-7941-g765f88c".
Yeah, I saw the devm_gpio_request_one() errors too. They happened for 3
boards on ARM I think. Must have forgotten to update the summary email.
I'll see if I can come up with a patch to fix the GPIO related build
failures, or at least report it to LinusW or Alexandre.
Thierry
Today's linux-next merge of the c6x tree got a conflict in
arch/arm/Kconfig
caused by commits 148104c (ARM: 7854/1: lockref: add support for lockless
lockrefs using cmpxchg64) and commit d701884 (arm: select
ARCH_MIGHT_HAVE_PC_PARPORT).
I fixed it up (see below). Please verify that the resolution looks good.
Thanks,
Thierry
---
diff --cc arch/arm/Kconfig
index c06647d,7db8abe0..b6a708e
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@@ -5,7 -5,7 +5,8 @@@ config AR
select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
select ARCH_HAVE_CUSTOM_GPIO_H
+ select ARCH_USE_CMPXCHG_LOCKREF
+ select ARCH_MIGHT_HAVE_PC_PARPORT
select ARCH_WANT_IPC_PARSE_VERSION
select BUILDTIME_EXTABLE_SORT if MMU
select CLONE_BACKWARDS
Today's linux-next tree of the h8300-remove tree got a conflict in
drivers/parport/Kconfig
caused by commits e9783b0 (Revert "drivers: parport: Kconfig: exclude h8300
for PARPORT_PC") and d90c3eb (Kconfig cleanup (PARPORT_PC dependencies)).
I fixed it up (see below). Please verify that the resolution looks good.
Thanks,
Thierry
---
diff --cc drivers/parport/Kconfig
index f536685,dc82ef0..2225237
--- a/drivers/parport/Kconfig
+++ b/drivers/parport/Kconfig
@@@ -41,8 -35,10 +41,7 @@@ if PARPOR
config PARPORT_PC
tristate "PC-style hardware"
- depends on (!SPARC64 || PCI) && !SPARC32 && !M32R && !FRV && !S390 && \
- (!M68K || ISA) && !MN10300 && !AVR32 && !BLACKFIN && \
- !XTENSA && !CRIS
-
+ depends on ARCH_MIGHT_HAVE_PC_PARPORT
-
---help---
You should say Y here if you have a PC-style parallel port. All
IBM PC compatible computers and some Alphas have PC-style
Today's linux-next merge of the imx-mxs tree got a conflict in
arch/arm/mach-imx/mach-imx6q.c
caused by commits 6aec339 (PM / OPP: rename header to linux/pm_opp.h) and
0794410 (imx: add PCI fixup for PEX860X on Gateworks board).
I fixed it up (see below). Please verify that the resolution looks good.
Thanks,
Thierry
---
diff --cc arch/arm/mach-imx/mach-imx6q.c
index eae5642,1ac719d..bc98799
--- a/arch/arm/mach-imx/mach-imx6q.c
+++ b/arch/arm/mach-imx/mach-imx6q.c
@@@ -23,8 -23,9 +23,10 @@@
#include <linux/of_address.h>
#include <linux/of_irq.h>
#include <linux/of_platform.h>
- #include <linux/pm_opp.h>
+ #include <linux/opp.h>
+ #include <linux/pci.h>
#include <linux/phy.h>
++#include <linux/pm_opp.h>
#include <linux/reboot.h>
#include <linux/regmap.h>
#include <linux/micrel_phy.h>
Today's linux-next merge of the tip tree got conflicts in
tools/perf/config/Makefile
tools/perf/config/feature-tests.mak
caused by commits 405ffbd (perf tools: Check libunwind for availability of
dwarf parsing feature) and mostly 308e1e7 (tools/perf/build: Clean up the
libunwind logic in config/Makefile) as well as various follow-up patches.
I fixed it up (see below). Please verify that the resolution looks good.
Also note that this isn't really a trivial resolution of a conflict, but
required modifying various other files. That causes rerere magic not to
work and needs part of conflict to be resolved manually. Perhaps a good
idea would be to rebase Jean's patch on top of the cleanups going on in
the tip tree? Perhaps even carry the patch in the tip tree?
Thanks,
Thierry
---
diff --cc tools/perf/config/Makefile
index 75b93d7,c516d6b..e4d06b2
--- a/tools/perf/config/Makefile
+++ b/tools/perf/config/Makefile
@@@ -29,13 -29,9 +29,13 @@@ ifeq ($(ARCH),x86_64
NO_PERF_REGS := 0
LIBUNWIND_LIBS = -lunwind -lunwind-x86_64
endif
+ifeq ($(ARCH),arm)
+ NO_PERF_REGS := 0
+ LIBUNWIND_LIBS = -lunwind -lunwind-arm
+endif
ifeq ($(NO_PERF_REGS),0)
- CFLAGS += -DHAVE_PERF_REGS
+ CFLAGS += -DHAVE_PERF_REGS_SUPPORT
endif
ifeq ($(src-perf),)
@@@ -93,20 -85,125 +89,126 @@@ CFLAGS += -std=gnu9
EXTLIBS = -lelf -lpthread -lrt -lm -ldl
- ifeq ($(call try-cc,$(SOURCE_HELLO),$(CFLAGS) -Werror -fstack-protector-all,-fstack-protector-all),y)
- CFLAGS += -fstack-protector-all
+ ifneq ($(OUTPUT),)
+ OUTPUT_FEATURES = $(OUTPUT)config/feature-checks/
+ $(shell mkdir -p $(OUTPUT_FEATURES))
endif
- ifeq ($(call try-cc,$(SOURCE_HELLO),$(CFLAGS) -Werror -Wstack-protector,-Wstack-protector),y)
- CFLAGS += -Wstack-protector
+ feature_check = $(eval $(feature_check_code))
+ define feature_check_code
+ feature-$(1) := $(shell $(MAKE) OUTPUT=$(OUTPUT_FEATURES) LDFLAGS=$(LDFLAGS) -C config/feature-checks test-$1 >/dev/null 2>/dev/null && echo 1 || echo 0)
+ endef
+
+ feature_set = $(eval $(feature_set_code))
+ define feature_set_code
+ feature-$(1) := 1
+ endef
+
+ #
+ # Build the feature check binaries in parallel, ignore errors, ignore return value and suppress output:
+ #
+
+ #
+ # Note that this is not a complete list of all feature tests, just
+ # those that are typically built on a fully configured system.
+ #
+ # [ Feature tests not mentioned here have to be built explicitly in
+ # the rule that uses them - an example for that is the 'bionic'
+ # feature check. ]
+ #
+ CORE_FEATURE_TESTS = \
+ backtrace \
+ dwarf \
+ fortify-source \
+ glibc \
+ gtk2 \
+ gtk2-infobar \
+ libaudit \
+ libbfd \
+ libelf \
+ libelf-getphdrnum \
+ libelf-mmap \
+ libnuma \
+ libperl \
+ libpython \
+ libpython-version \
+ libslang \
+ libunwind \
++ libunwind-debug-frame \
+ on-exit \
+ stackprotector \
+ stackprotector-all
+
+ #
+ # So here we detect whether test-all was rebuilt, to be able
+ # to skip the print-out of the long features list if the file
+ # existed before and after it was built:
+ #
+ ifeq ($(wildcard $(OUTPUT)config/feature-checks/test-all),)
+ test-all-failed := 1
+ else
+ test-all-failed := 0
+ endif
+
+ #
+ # Special fast-path for the 'all features are available' case:
+ #
+ $(call feature_check,all,$(MSG))
+
+ #
+ # Just in case the build freshly failed, make sure we print the
+ # feature matrix:
+ #
+ ifeq ($(feature-all), 0)
+ test-all-failed := 1
+ endif
+
+ ifeq ($(test-all-failed),1)
+ $(info )
+ $(info Auto-detecting system features:)
+ endif
+
+ ifeq ($(feature-all), 1)
+ #
+ # test-all.c passed - just set all the core feature flags to 1:
+ #
+ $(foreach feat,$(CORE_FEATURE_TESTS),$(call feature_set,$(feat)))
+ else
+ $(shell $(MAKE) OUTPUT=$(OUTPUT_FEATURES) LDFLAGS=$(LDFLAGS) -i -j -C config/feature-checks $(CORE_FEATURE_TESTS) >/dev/null 2>&1)
+ $(foreach feat,$(CORE_FEATURE_TESTS),$(call feature_check,$(feat)))
+ endif
+
+ #
+ # Print the result of the feature test:
+ #
+ feature_print = $(eval $(feature_print_code)) $(info $(MSG))
+
+ define feature_print_code
+ ifeq ($(feature-$(1)), 1)
+ MSG = $(shell printf '...%30s: [ \033[32mon\033[m ]' $(1))
+ else
+ MSG = $(shell printf '...%30s: [ \033[31mOFF\033[m ]' $(1))
+ endif
+ endef
+
+ #
+ # Only print out our features if we rebuilt the testcases or if a test failed:
+ #
+ ifeq ($(test-all-failed), 1)
+ $(foreach feat,$(CORE_FEATURE_TESTS),$(call feature_print,$(feat)))
+ $(info )
endif
- ifeq ($(call try-cc,$(SOURCE_HELLO),$(CFLAGS) -Werror -Wvolatile-register-var,-Wvolatile-register-var),y)
- CFLAGS += -Wvolatile-register-var
+ ifeq ($(feature-stackprotector-all), 1)
+ CFLAGS += -fstack-protector-all
+ endif
+
+ ifeq ($(feature-stackprotector), 1)
+ CFLAGS += -Wstack-protector
endif
- ifndef PERF_DEBUG
- ifeq ($(call try-cc,$(SOURCE_HELLO),$(CFLAGS) -D_FORTIFY_SOURCE=2,-D_FORTIFY_SOURCE=2),y)
+ ifeq ($(DEBUG),0)
+ ifeq ($(feature-fortify-source), 1)
CFLAGS += -D_FORTIFY_SOURCE=2
endif
endif
@@@ -179,64 -274,55 +279,59 @@@ els
endif # NO_LIBELF
ifndef NO_LIBELF
- CFLAGS += -DLIBELF_SUPPORT
- FLAGS_LIBELF=$(CFLAGS) $(LDFLAGS) $(EXTLIBS)
- ifeq ($(call try-cc,$(SOURCE_ELF_MMAP),$(FLAGS_LIBELF),-DLIBELF_MMAP),y)
- CFLAGS += -DLIBELF_MMAP
- endif
- ifeq ($(call try-cc,$(SOURCE_ELF_GETPHDRNUM),$(FLAGS_LIBELF),-DHAVE_ELF_GETPHDRNUM),y)
- CFLAGS += -DHAVE_ELF_GETPHDRNUM
- endif
+ CFLAGS += -DHAVE_LIBELF_SUPPORT
- # include ARCH specific config
- -include $(src-perf)/arch/$(ARCH)/Makefile
+ ifeq ($(feature-libelf-mmap), 1)
+ CFLAGS += -DHAVE_LIBELF_MMAP_SUPPORT
+ endif
- ifndef NO_DWARF
- ifeq ($(origin PERF_HAVE_DWARF_REGS), undefined)
- msg := $(warning DWARF register mappings have not been defined for architecture $(ARCH), DWARF support disabled);
- NO_DWARF := 1
- else
- CFLAGS += -DDWARF_SUPPORT $(LIBDW_CFLAGS)
- LDFLAGS += $(LIBDW_LDFLAGS)
- EXTLIBS += -lelf -ldw
- endif # PERF_HAVE_DWARF_REGS
- endif # NO_DWARF
+ ifeq ($(feature-libelf-getphdrnum), 1)
+ CFLAGS += -DHAVE_ELF_GETPHDRNUM_SUPPORT
+ endif
- endif # NO_LIBELF
+ # include ARCH specific config
+ -include $(src-perf)/arch/$(ARCH)/Makefile
- ifndef NO_LIBELF
- CFLAGS += -DLIBELF_SUPPORT
- FLAGS_LIBELF=$(CFLAGS) $(LDFLAGS) $(EXTLIBS)
- ifeq ($(call try-cc,$(SOURCE_ELF_MMAP),$(FLAGS_LIBELF),-DLIBELF_MMAP),y)
- CFLAGS += -DLIBELF_MMAP
- endif # try-cc
+ ifndef NO_DWARF
+ ifeq ($(origin PERF_HAVE_DWARF_REGS), undefined)
+ msg := $(warning DWARF register mappings have not been defined for architecture $(ARCH), DWARF support disabled);
+ NO_DWARF := 1
+ else
+ CFLAGS += -DHAVE_DWARF_SUPPORT $(LIBDW_CFLAGS)
+ LDFLAGS += $(LIBDW_LDFLAGS)
+ EXTLIBS += -lelf -ldw
+ endif # PERF_HAVE_DWARF_REGS
+ endif # NO_DWARF
endif # NO_LIBELF
-# There's only x86 (both 32 and 64) support for CFI unwind so far
-ifneq ($(ARCH),x86)
+ifeq ($(LIBUNWIND_LIBS),)
NO_LIBUNWIND := 1
endif
ifndef NO_LIBUNWIND
- # for linking with debug library, run like:
- # make DEBUG=1 LIBUNWIND_DIR=/opt/libunwind/
- ifdef LIBUNWIND_DIR
- LIBUNWIND_CFLAGS := -I$(LIBUNWIND_DIR)/include
- LIBUNWIND_LDFLAGS := -L$(LIBUNWIND_DIR)/lib
- endif
+ #
+ # For linking with debug library, run like:
+ #
+ # make DEBUG=1 LIBUNWIND_DIR=/opt/libunwind/
+ #
+ ifdef LIBUNWIND_DIR
+ LIBUNWIND_CFLAGS := -I$(LIBUNWIND_DIR)/include
+ LIBUNWIND_LDFLAGS := -L$(LIBUNWIND_DIR)/lib
+ endif
- FLAGS_UNWIND=$(LIBUNWIND_CFLAGS) $(CFLAGS) $(LIBUNWIND_LDFLAGS) $(LDFLAGS) $(EXTLIBS) $(LIBUNWIND_LIBS)
- ifneq ($(call try-cc,$(SOURCE_LIBUNWIND),$(FLAGS_UNWIND),libunwind),y)
- msg := $(warning No libunwind found, disabling post unwind support. Please install libunwind-dev[el] >= 1.1);
- NO_LIBUNWIND := 1
- endif # Libunwind support
- ifneq ($(call try-cc,$(SOURCE_LIBUNWIND_DEBUG_FRAME),$(FLAGS_UNWIND),libunwind debug_frame),y)
- msg := $(warning No debug_frame support found in libunwind);
- CFLAGS += -DNO_LIBUNWIND_DEBUG_FRAME
- endif # debug_frame support in libunwind
- endif # NO_LIBUNWIND
+ ifneq ($(feature-libunwind), 1)
- msg := $(warning No libunwind found, disabling post unwind support. Please install libunwind-dev[el] >= 0.99);
++ msg := $(warning No libunwind found, disabling post unwind support. Please install libunwind-dev[el] >= 1.1);
+ NO_LIBUNWIND := 1
++ else
++ ifneq ($(feature-libunwind-debug-frame), 1)
++ msg := $(warning No debug_frame support found in libunwind);
++ CFLAGS += -DNO_LIBUNWIND_DEBUG_FRAME
++ endif
+ endif
+ endif
ifndef NO_LIBUNWIND
- CFLAGS += -DLIBUNWIND_SUPPORT
+ CFLAGS += -DHAVE_LIBUNWIND_SUPPORT
EXTLIBS += $(LIBUNWIND_LIBS)
CFLAGS += $(LIBUNWIND_CFLAGS)
LDFLAGS += $(LIBUNWIND_LDFLAGS)
diff --cc tools/perf/config/feature-checks/Makefile
index 0000000,452b67c..abaf8f4
mode 000000,100644..100644
--- a/tools/perf/config/feature-checks/Makefile
+++ b/tools/perf/config/feature-checks/Makefile
@@@ -1,0 -1,144 +1,148 @@@
+
+ FILES= \
+ test-all \
+ test-backtrace \
+ test-bionic \
+ test-dwarf \
+ test-fortify-source \
+ test-glibc \
+ test-gtk2 \
+ test-gtk2-infobar \
+ test-hello \
+ test-libaudit \
+ test-libbfd \
+ test-liberty \
+ test-liberty-z \
+ test-cplus-demangle \
+ test-libelf \
+ test-libelf-getphdrnum \
+ test-libelf-mmap \
+ test-libnuma \
+ test-libperl \
+ test-libpython \
+ test-libpython-version \
+ test-libslang \
+ test-libunwind \
++ test-libunwind-debug-frame \
+ test-on-exit \
+ test-stackprotector-all \
+ test-stackprotector
+
+ CC := $(CC) -MD
+
+ all: $(FILES)
+
+ BUILD = $(CC) $(LDFLAGS) -o $(OUTPUT)$@ [email protected]
+
+ ###############################
+
+ test-all:
+ $(BUILD) -Werror -fstack-protector -fstack-protector-all -O2 -Werror -D_FORTIFY_SOURCE=2 -ldw -lelf -lnuma -lunwind -lunwind-x86_64 -lelf -laudit -I/usr/include/slang -lslang $(shell pkg-config --libs --cflags gtk+-2.0 2>/dev/null) $(FLAGS_PERL_EMBED) $(FLAGS_PYTHON_EMBED) -DPACKAGE='"perf"' -lbfd -ldl
+
+ test-hello:
+ $(BUILD)
+
+ test-stackprotector-all:
+ $(BUILD) -Werror -fstack-protector-all
+
+ test-stackprotector:
+ $(BUILD) -Werror -fstack-protector -Wstack-protector
+
+ test-fortify-source:
+ $(BUILD) -O2 -Werror -D_FORTIFY_SOURCE=2
+
+ test-bionic:
+ $(BUILD)
+
+ test-libelf:
+ $(BUILD) -lelf
+
+ test-glibc:
+ $(BUILD)
+
+ test-dwarf:
+ $(BUILD) -ldw
+
+ test-libelf-mmap:
+ $(BUILD) -lelf
+
+ test-libelf-getphdrnum:
+ $(BUILD) -lelf
+
+ test-libnuma:
+ $(BUILD) -lnuma
+
+ test-libunwind:
+ $(BUILD) -lunwind -lunwind-x86_64 -lelf
+
++test-libunwind-debug-frame:
++ $(BUILD) -lunwind -lunwind-x86_64 -lelf
++
+ test-libaudit:
+ $(BUILD) -laudit
+
+ test-libslang:
+ $(BUILD) -I/usr/include/slang -lslang
+
+ test-gtk2:
+ $(BUILD) $(shell pkg-config --libs --cflags gtk+-2.0 2>/dev/null)
+
+ test-gtk2-infobar:
+ $(BUILD) $(shell pkg-config --libs --cflags gtk+-2.0 2>/dev/null)
+
+ grep-libs = $(filter -l%,$(1))
+ strip-libs = $(filter-out -l%,$(1))
+
+ PERL_EMBED_LDOPTS = $(shell perl -MExtUtils::Embed -e ldopts 2>/dev/null)
+ PERL_EMBED_LDFLAGS = $(call strip-libs,$(PERL_EMBED_LDOPTS))
+ PERL_EMBED_LIBADD = $(call grep-libs,$(PERL_EMBED_LDOPTS))
+ PERL_EMBED_CCOPTS = `perl -MExtUtils::Embed -e ccopts 2>/dev/null`
+ FLAGS_PERL_EMBED=$(PERL_EMBED_CCOPTS) $(PERL_EMBED_LDOPTS)
+
+ test-libperl:
+ $(BUILD) $(FLAGS_PERL_EMBED)
+
+ override PYTHON := python
+ override PYTHON_CONFIG := python-config
+
+ escape-for-shell-sq = $(subst ','\'',$(1))
+ shell-sq = '$(escape-for-shell-sq)'
+
+ PYTHON_CONFIG_SQ = $(call shell-sq,$(PYTHON_CONFIG))
+
+ PYTHON_EMBED_LDOPTS = $(shell $(PYTHON_CONFIG_SQ) --ldflags 2>/dev/null)
+ PYTHON_EMBED_LDFLAGS = $(call strip-libs,$(PYTHON_EMBED_LDOPTS))
+ PYTHON_EMBED_LIBADD = $(call grep-libs,$(PYTHON_EMBED_LDOPTS))
+ PYTHON_EMBED_CCOPTS = $(shell $(PYTHON_CONFIG_SQ) --cflags 2>/dev/null)
+ FLAGS_PYTHON_EMBED = $(PYTHON_EMBED_CCOPTS) $(PYTHON_EMBED_LDOPTS)
+
+ test-libpython:
+ $(BUILD) $(FLAGS_PYTHON_EMBED)
+
+ test-libpython-version:
+ $(BUILD) $(FLAGS_PYTHON_EMBED)
+
+ test-libbfd:
+ $(BUILD) -DPACKAGE='"perf"' -lbfd -ldl
+
+ test-liberty:
+ $(CC) -o $(OUTPUT)$@ test-libbfd.c -DPACKAGE='"perf"' -lbfd -ldl -liberty
+
+ test-liberty-z:
+ $(CC) -o $(OUTPUT)$@ test-libbfd.c -DPACKAGE='"perf"' -lbfd -ldl -liberty -lz
+
+ test-cplus-demangle:
+ $(BUILD) -liberty
+
+ test-on-exit:
+ $(BUILD)
+
+ test-backtrace:
+ $(BUILD)
+
+ -include *.d
+
+ ###############################
+
+ clean:
+ rm -f $(FILES) *.d
diff --cc tools/perf/config/feature-checks/test-all.c
index 0000000,50d4318..ed8aa7b
mode 000000,100644..100644
--- a/tools/perf/config/feature-checks/test-all.c
+++ b/tools/perf/config/feature-checks/test-all.c
@@@ -1,0 -1,106 +1,111 @@@
+ /*
+ * test-all.c: Try to build all the main testcases at once.
+ *
+ * A well-configured system will have all the prereqs installed, so we can speed
+ * up auto-detection on such systems.
+ */
+
+ /*
+ * Quirk: Python and Perl headers cannot be in arbitrary places, so keep
+ * these 3 testcases at the top:
+ */
+ #define main main_test_libpython
+ # include "test-libpython.c"
+ #undef main
+
+ #define main main_test_libpython_version
+ # include "test-libpython-version.c"
+ #undef main
+
+ #define main main_test_libperl
+ # include "test-libperl.c"
+ #undef main
+
+ #define main main_test_hello
+ # include "test-hello.c"
+ #undef main
+
+ #define main main_test_libelf
+ # include "test-libelf.c"
+ #undef main
+
+ #define main main_test_libelf_mmap
+ # include "test-libelf-mmap.c"
+ #undef main
+
+ #define main main_test_glibc
+ # include "test-glibc.c"
+ #undef main
+
+ #define main main_test_dwarf
+ # include "test-dwarf.c"
+ #undef main
+
+ #define main main_test_libelf_getphdrnum
+ # include "test-libelf-getphdrnum.c"
+ #undef main
+
+ #define main main_test_libunwind
+ # include "test-libunwind.c"
+ #undef main
+
++#define main main_test_libunwind_debug_frame
++# include "test-libunwind-debug-frame.c"
++#undef main
++
+ #define main main_test_libaudit
+ # include "test-libaudit.c"
+ #undef main
+
+ #define main main_test_libslang
+ # include "test-libslang.c"
+ #undef main
+
+ #define main main_test_gtk2
+ # include "test-gtk2.c"
+ #undef main
+
+ #define main main_test_gtk2_infobar
+ # include "test-gtk2-infobar.c"
+ #undef main
+
+ #define main main_test_libbfd
+ # include "test-libbfd.c"
+ #undef main
+
+ #define main main_test_on_exit
+ # include "test-on-exit.c"
+ #undef main
+
+ #define main main_test_backtrace
+ # include "test-backtrace.c"
+ #undef main
+
+ #define main main_test_libnuma
+ # include "test-libnuma.c"
+ #undef main
+
+ int main(int argc, char *argv[])
+ {
+ main_test_libpython();
+ main_test_libpython_version();
+ main_test_libperl();
+ main_test_hello();
+ main_test_libelf();
+ main_test_libelf_mmap();
+ main_test_glibc();
+ main_test_dwarf();
+ main_test_libelf_getphdrnum();
+ main_test_libunwind();
++ main_test_libunwind_debug_frame();
+ main_test_libaudit();
+ main_test_libslang();
+ main_test_gtk2(argc, argv);
+ main_test_gtk2_infobar(argc, argv);
+ main_test_libbfd();
+ main_test_on_exit();
+ main_test_backtrace();
+ main_test_libnuma();
+
+ return 0;
+ }
diff --cc tools/perf/config/feature-checks/test-libunwind-debug-frame.c
index 0000000,0000000..0ef8087
new file mode 100644
--- /dev/null
+++ b/tools/perf/config/feature-checks/test-libunwind-debug-frame.c
@@@ -1,0 -1,0 +1,16 @@@
++#include <libunwind.h>
++#include <stdlib.h>
++
++extern int
++UNW_OBJ(dwarf_find_debug_frame) (int found, unw_dyn_info_t *di_debug,
++ unw_word_t ip, unw_word_t segbase,
++ const char *obj_name, unw_word_t start,
++ unw_word_t end);
++
++#define dwarf_find_debug_frame UNW_OBJ(dwarf_find_debug_frame)
++
++int main(void)
++{
++ dwarf_find_debug_frame(0, NULL, 0, 0, NULL, 0, 0);
++ return 0;
++}
Today's linux-next merge of the kvm-arm tree got a conflict in
arch/arm/kvm/reset.c
caused by commits e8c2d99 (KVM: ARM: Add support for Cortex-A7) and 7999b4d
(ARM: KVM: drop limitation to 4 CPU VMs).
I fixed it up (see below). Please verify that the resolution looks good.
Thanks,
Thierry
---
diff --cc arch/arm/kvm/reset.c
index d153e64,2c5add0..f558c07
--- a/arch/arm/kvm/reset.c
+++ b/arch/arm/kvm/reset.c
@@@ -64,9 -62,7 +62,7 @@@ int kvm_reset_vcpu(struct kvm_vcpu *vcp
switch (vcpu->arch.target) {
case KVM_ARM_TARGET_CORTEX_A7:
case KVM_ARM_TARGET_CORTEX_A15:
- if (vcpu->vcpu_id > cortexa_max_cpu_idx)
- return -EINVAL;
- cpu_reset = &cortexa_regs_reset;
+ reset_regs = &cortexa_regs_reset;
vcpu->arch.midr = read_cpuid_id();
cpu_vtimer_irq = &cortexa_vtimer_irq;
break;
Today's linux-next merge of the mfd-lj tree got conflicts in
sound/soc/codecs/mc13783.c
caused by commits 9f6f0af (ASoC: mc13783: add spi errata fix), fd792f8
(mfd: mc13xxx: Move SPI erratum workaround into SPI I/O function) and
2d9215c (ASoC: mc13783: Use regmap directly from ASoC).
I fixed it up and the diff turned up empty, so I think it can't be all
that wrong.
Thanks,
Thierry
On 25/10/13 14:03, Thierry Reding wrote:
> Today's linux-next merge of the kvm-arm tree got a conflict in
>
> arch/arm/kvm/reset.c
>
> caused by commits e8c2d99 (KVM: ARM: Add support for Cortex-A7) and 7999b4d
> (ARM: KVM: drop limitation to 4 CPU VMs).
>
> I fixed it up (see below). Please verify that the resolution looks good.
Looks good. Thanks Thierry.
M.
> Thanks,
> Thierry
> ---
> diff --cc arch/arm/kvm/reset.c
> index d153e64,2c5add0..f558c07
> --- a/arch/arm/kvm/reset.c
> +++ b/arch/arm/kvm/reset.c
> @@@ -64,9 -62,7 +62,7 @@@ int kvm_reset_vcpu(struct kvm_vcpu *vcp
> switch (vcpu->arch.target) {
> case KVM_ARM_TARGET_CORTEX_A7:
> case KVM_ARM_TARGET_CORTEX_A15:
> - if (vcpu->vcpu_id > cortexa_max_cpu_idx)
> - return -EINVAL;
> - cpu_reset = &cortexa_regs_reset;
> + reset_regs = &cortexa_regs_reset;
> vcpu->arch.midr = read_cpuid_id();
> cpu_vtimer_irq = &cortexa_vtimer_irq;
> break;
>
--
Jazz is not dead. It just smells funny...
On Fri, Oct 25, 2013 at 1:35 AM, Thierry Reding
<[email protected]> wrote:
> On Thu, Oct 24, 2013 at 10:02:22PM -0700, Guenter Roeck wrote:
>> On 10/24/2013 09:31 AM, Thierry Reding wrote:
>> >Hi all,
>> >
>> >I've uploaded today's linux-next tree to the master branch of the
>> >repository below:
>> >
>> > git://gitorious.org/thierryreding/linux-next.git
>> >
>> >A next-20131024 tag is also provided for convenience.
>> >
>> >Quite a few new conflicts. Some of them non-trivial. I've fixed another
>> >set of build failures, so 32-bit and 64-bit allmodconfigs build fine on
>> >x86. ARM and x86 default configurations also build fine. PowerPC is in
>> >pretty bad shape, mostly due to some OF header rework going on.
>> >
>>
>> Hmm ... I see
>>
>> Building arm:defconfig ... failed
>> --------------
>> Error log:
>> drivers/built-in.o: In function `mmc_gpio_request_cd':
>> clkdev.c:(.text+0x74cf8): undefined reference to `devm_gpio_request_one'
>> make: *** [vmlinux] Error 1
>>
>> Otherwise pretty much the same as yesterday, with a build log of
>> total: 110 pass: 88 skipped: 4 fail: 18
>>
>> This is with "v3.12-rc5-7941-g765f88c".
>
> Yeah, I saw the devm_gpio_request_one() errors too. They happened for 3
> boards on ARM I think. Must have forgotten to update the summary email.
> I'll see if I can come up with a patch to fix the GPIO related build
> failures, or at least report it to LinusW or Alexandre.
Hmm.
Please don't apply fixes like these directly to your tree, keep the
broken parts (or drop the tree that introduced it). It makes the
process of getting the fixes in where they really have to go much more
error prone, since there's no way to track whether they have landed in
the right place yet or not.
-Olof
On Fri, 2013-10-25 at 15:03 +0200, Thierry Reding wrote:
> Today's linux-next merge of the c6x tree got a conflict in
>
> arch/arm/Kconfig
>
> caused by commits 148104c (ARM: 7854/1: lockref: add support for lockless
> lockrefs using cmpxchg64) and commit d701884 (arm: select
> ARCH_MIGHT_HAVE_PC_PARPORT).
>
> I fixed it up (see below). Please verify that the resolution looks good.
> Thanks,
> Thierry
> ---
> diff --cc arch/arm/Kconfig
> index c06647d,7db8abe0..b6a708e
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@@ -5,7 -5,7 +5,8 @@@ config AR
> select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
> select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
> select ARCH_HAVE_CUSTOM_GPIO_H
> + select ARCH_USE_CMPXCHG_LOCKREF
> + select ARCH_MIGHT_HAVE_PC_PARPORT
> select ARCH_WANT_IPC_PARSE_VERSION
> select BUILDTIME_EXTABLE_SORT if MMU
> select CLONE_BACKWARDS
ARCH_USE_CMPXCHG_LOCKREF needs to come after ARCH_MIGHT_HAVE_PC_PARPORT
to keep things sorted alphabetically. Other than that, its fine.
--Mark
On Fri, Oct 25, 2013 at 06:16:02AM -0700, Olof Johansson wrote:
> On Fri, Oct 25, 2013 at 1:35 AM, Thierry Reding
> > Yeah, I saw the devm_gpio_request_one() errors too. They happened for 3
> > boards on ARM I think. Must have forgotten to update the summary email.
> > I'll see if I can come up with a patch to fix the GPIO related build
> > failures, or at least report it to LinusW or Alexandre.
> Hmm.
> Please don't apply fixes like these directly to your tree, keep the
> broken parts (or drop the tree that introduced it). It makes the
> process of getting the fixes in where they really have to go much more
> error prone, since there's no way to track whether they have landed in
> the right place yet or not.
The rule I was applying (which I think is the same as Stephen applies)
is that I'd fix anything that was definitely the result of a merge issue
(like the build failure in misc due to a sysfs API change in the sysfs
tree) but not anything that was just plain broken in the tree in
isolation.
On Fri, Oct 25, 2013 at 02:03:42PM +0100, Thierry Reding wrote:
> Today's linux-next merge of the tip tree got conflicts in
>
> tools/perf/config/Makefile
> tools/perf/config/feature-tests.mak
>
> caused by commits 405ffbd (perf tools: Check libunwind for availability of
> dwarf parsing feature) and mostly 308e1e7 (tools/perf/build: Clean up the
> libunwind logic in config/Makefile) as well as various follow-up patches.
>
> I fixed it up (see below). Please verify that the resolution looks good.
> Also note that this isn't really a trivial resolution of a conflict, but
> required modifying various other files. That causes rerere magic not to
> work and needs part of conflict to be resolved manually. Perhaps a good
> idea would be to rebase Jean's patch on top of the cleanups going on in
> the tip tree? Perhaps even carry the patch in the tip tree?
These came via my tree (arm perf) after discussion here:
http://lists.infradead.org/pipermail/linux-arm-kernel/2013-October/203077.html
Now that they've been pulled by rmk, we can't back them out with ugly
reverts, so I'm not sure what we can do to resolve in the ARM tree; it looks
like the perf Makefile has changed significantly in -tip.
Will
On Fri, Oct 25, 2013 at 6:24 AM, Mark Brown <[email protected]> wrote:
> On Fri, Oct 25, 2013 at 06:16:02AM -0700, Olof Johansson wrote:
>> On Fri, Oct 25, 2013 at 1:35 AM, Thierry Reding
>
>> > Yeah, I saw the devm_gpio_request_one() errors too. They happened for 3
>> > boards on ARM I think. Must have forgotten to update the summary email.
>> > I'll see if I can come up with a patch to fix the GPIO related build
>> > failures, or at least report it to LinusW or Alexandre.
>
>> Hmm.
>
>> Please don't apply fixes like these directly to your tree, keep the
>> broken parts (or drop the tree that introduced it). It makes the
>> process of getting the fixes in where they really have to go much more
>> error prone, since there's no way to track whether they have landed in
>> the right place yet or not.
>
> The rule I was applying (which I think is the same as Stephen applies)
> is that I'd fix anything that was definitely the result of a merge issue
> (like the build failure in misc due to a sysfs API change in the sysfs
> tree) but not anything that was just plain broken in the tree in
> isolation.
Some of those might still make sense, but as many as possible of them
should be pushed down into the trees where they belong, even if
they're strictly not needed there (as long as they don't break the
standalone tree, of course).
-Olof
On Fri, Oct 25, 2013 at 06:16:02AM -0700, Olof Johansson wrote:
> On Fri, Oct 25, 2013 at 1:35 AM, Thierry Reding
> <[email protected]> wrote:
> > On Thu, Oct 24, 2013 at 10:02:22PM -0700, Guenter Roeck wrote:
> >> On 10/24/2013 09:31 AM, Thierry Reding wrote:
> >> >Hi all,
> >> >
> >> >I've uploaded today's linux-next tree to the master branch of the
> >> >repository below:
> >> >
> >> > git://gitorious.org/thierryreding/linux-next.git
> >> >
> >> >A next-20131024 tag is also provided for convenience.
> >> >
> >> >Quite a few new conflicts. Some of them non-trivial. I've fixed another
> >> >set of build failures, so 32-bit and 64-bit allmodconfigs build fine on
> >> >x86. ARM and x86 default configurations also build fine. PowerPC is in
> >> >pretty bad shape, mostly due to some OF header rework going on.
> >> >
> >>
> >> Hmm ... I see
> >>
> >> Building arm:defconfig ... failed
> >> --------------
> >> Error log:
> >> drivers/built-in.o: In function `mmc_gpio_request_cd':
> >> clkdev.c:(.text+0x74cf8): undefined reference to `devm_gpio_request_one'
> >> make: *** [vmlinux] Error 1
> >>
> >> Otherwise pretty much the same as yesterday, with a build log of
> >> total: 110 pass: 88 skipped: 4 fail: 18
> >>
> >> This is with "v3.12-rc5-7941-g765f88c".
> >
> > Yeah, I saw the devm_gpio_request_one() errors too. They happened for 3
> > boards on ARM I think. Must have forgotten to update the summary email.
> > I'll see if I can come up with a patch to fix the GPIO related build
> > failures, or at least report it to LinusW or Alexandre.
>
> Hmm.
>
> Please don't apply fixes like these directly to your tree, keep the
> broken parts (or drop the tree that introduced it). It makes the
> process of getting the fixes in where they really have to go much more
> error prone, since there's no way to track whether they have landed in
> the right place yet or not.
I've found that fixing one build error often subsequent build failures,
which would go unnoticed if I dropped the trees or let the breakage
unfixed.
Except for very few occasions I've immediately sent out patches to the
respective subsystem maintainers, so they should've gotten picked up.
What's the difference if I do it as part of linux-next to if somebody
does it outside? At least this way they are part of the linux-next tree
so if I create the next one and cherry-pick the patches and they still
apply I can be reasonably sure that they haven't landed in the right
place yet.
Thierry
On Fri, 2013-10-25 at 15:03 +0200, Thierry Reding wrote:
> Today's linux-next tree of the h8300-remove tree got a conflict in
>
> drivers/parport/Kconfig
>
> caused by commits e9783b0 (Revert "drivers: parport: Kconfig: exclude h8300
> for PARPORT_PC") and d90c3eb (Kconfig cleanup (PARPORT_PC dependencies)).
>
> I fixed it up (see below). Please verify that the resolution looks good.
>
> Thanks,
> Thierry
> ---
> diff --cc drivers/parport/Kconfig
> index f536685,dc82ef0..2225237
> --- a/drivers/parport/Kconfig
> +++ b/drivers/parport/Kconfig
> @@@ -41,8 -35,10 +41,7 @@@ if PARPOR
>
> config PARPORT_PC
> tristate "PC-style hardware"
> - depends on (!SPARC64 || PCI) && !SPARC32 && !M32R && !FRV && !S390 && \
> - (!M68K || ISA) && !MN10300 && !AVR32 && !BLACKFIN && \
> - !XTENSA && !CRIS
> -
> + depends on ARCH_MIGHT_HAVE_PC_PARPORT
> -
> ---help---
> You should say Y here if you have a PC-style parallel port. All
> IBM PC compatible computers and some Alphas have PC-style
Yes, that looks right. With the PC_PARPORT cleanup, h8300 doesn't need
to exclude itself. It is now excluded by default.
On Fri, Oct 25, 2013 at 09:22:57AM -0400, Mark Salter wrote:
> On Fri, 2013-10-25 at 15:03 +0200, Thierry Reding wrote:
> > Today's linux-next merge of the c6x tree got a conflict in
> >
> > arch/arm/Kconfig
> >
> > caused by commits 148104c (ARM: 7854/1: lockref: add support for lockless
> > lockrefs using cmpxchg64) and commit d701884 (arm: select
> > ARCH_MIGHT_HAVE_PC_PARPORT).
> >
> > I fixed it up (see below). Please verify that the resolution looks good.
>
> > Thanks,
> > Thierry
> > ---
> > diff --cc arch/arm/Kconfig
> > index c06647d,7db8abe0..b6a708e
> > --- a/arch/arm/Kconfig
> > +++ b/arch/arm/Kconfig
> > @@@ -5,7 -5,7 +5,8 @@@ config AR
> > select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
> > select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
> > select ARCH_HAVE_CUSTOM_GPIO_H
> > + select ARCH_USE_CMPXCHG_LOCKREF
> > + select ARCH_MIGHT_HAVE_PC_PARPORT
> > select ARCH_WANT_IPC_PARSE_VERSION
> > select BUILDTIME_EXTABLE_SORT if MMU
> > select CLONE_BACKWARDS
>
> ARCH_USE_CMPXCHG_LOCKREF needs to come after ARCH_MIGHT_HAVE_PC_PARPORT
> to keep things sorted alphabetically. Other than that, its fine.
Right, I missed that. Will keep it in mind, although I guess today will
be my last tree for a while since Stephen mentioned that he would
probably take over on Monday.
Thierry
On Fri, Oct 25, 2013 at 6:35 AM, Thierry Reding
<[email protected]> wrote:
> On Fri, Oct 25, 2013 at 06:16:02AM -0700, Olof Johansson wrote:
>> On Fri, Oct 25, 2013 at 1:35 AM, Thierry Reding
>> <[email protected]> wrote:
>> > On Thu, Oct 24, 2013 at 10:02:22PM -0700, Guenter Roeck wrote:
>> >> On 10/24/2013 09:31 AM, Thierry Reding wrote:
>> >> >Hi all,
>> >> >
>> >> >I've uploaded today's linux-next tree to the master branch of the
>> >> >repository below:
>> >> >
>> >> > git://gitorious.org/thierryreding/linux-next.git
>> >> >
>> >> >A next-20131024 tag is also provided for convenience.
>> >> >
>> >> >Quite a few new conflicts. Some of them non-trivial. I've fixed another
>> >> >set of build failures, so 32-bit and 64-bit allmodconfigs build fine on
>> >> >x86. ARM and x86 default configurations also build fine. PowerPC is in
>> >> >pretty bad shape, mostly due to some OF header rework going on.
>> >> >
>> >>
>> >> Hmm ... I see
>> >>
>> >> Building arm:defconfig ... failed
>> >> --------------
>> >> Error log:
>> >> drivers/built-in.o: In function `mmc_gpio_request_cd':
>> >> clkdev.c:(.text+0x74cf8): undefined reference to `devm_gpio_request_one'
>> >> make: *** [vmlinux] Error 1
>> >>
>> >> Otherwise pretty much the same as yesterday, with a build log of
>> >> total: 110 pass: 88 skipped: 4 fail: 18
>> >>
>> >> This is with "v3.12-rc5-7941-g765f88c".
>> >
>> > Yeah, I saw the devm_gpio_request_one() errors too. They happened for 3
>> > boards on ARM I think. Must have forgotten to update the summary email.
>> > I'll see if I can come up with a patch to fix the GPIO related build
>> > failures, or at least report it to LinusW or Alexandre.
>>
>> Hmm.
>>
>> Please don't apply fixes like these directly to your tree, keep the
>> broken parts (or drop the tree that introduced it). It makes the
>> process of getting the fixes in where they really have to go much more
>> error prone, since there's no way to track whether they have landed in
>> the right place yet or not.
>
> I've found that fixing one build error often subsequent build failures,
> which would go unnoticed if I dropped the trees or let the breakage
> unfixed.
Yeah, that's what happened with the GPIO subsystem on this release --
there are two build errors but your fix resolves one of them such at
the other one is exposed. It makes it confusing to bisect down to root
cause. I'd almost rather have your tree just being broken, but patches
submitted and sent in to the maintainer in question if you want to get
it fixed ASAP.
In particular, the gpio fix in the tree right now has no description, etc.
-Olof
On Fri, Oct 25, 2013 at 06:43:53AM -0700, Olof Johansson wrote:
> On Fri, Oct 25, 2013 at 6:35 AM, Thierry Reding
> <[email protected]> wrote:
> > On Fri, Oct 25, 2013 at 06:16:02AM -0700, Olof Johansson wrote:
> >> On Fri, Oct 25, 2013 at 1:35 AM, Thierry Reding
> >> <[email protected]> wrote:
> >> > On Thu, Oct 24, 2013 at 10:02:22PM -0700, Guenter Roeck wrote:
> >> >> On 10/24/2013 09:31 AM, Thierry Reding wrote:
> >> >> >Hi all,
> >> >> >
> >> >> >I've uploaded today's linux-next tree to the master branch of the
> >> >> >repository below:
> >> >> >
> >> >> > git://gitorious.org/thierryreding/linux-next.git
> >> >> >
> >> >> >A next-20131024 tag is also provided for convenience.
> >> >> >
> >> >> >Quite a few new conflicts. Some of them non-trivial. I've fixed another
> >> >> >set of build failures, so 32-bit and 64-bit allmodconfigs build fine on
> >> >> >x86. ARM and x86 default configurations also build fine. PowerPC is in
> >> >> >pretty bad shape, mostly due to some OF header rework going on.
> >> >> >
> >> >>
> >> >> Hmm ... I see
> >> >>
> >> >> Building arm:defconfig ... failed
> >> >> --------------
> >> >> Error log:
> >> >> drivers/built-in.o: In function `mmc_gpio_request_cd':
> >> >> clkdev.c:(.text+0x74cf8): undefined reference to `devm_gpio_request_one'
> >> >> make: *** [vmlinux] Error 1
> >> >>
> >> >> Otherwise pretty much the same as yesterday, with a build log of
> >> >> total: 110 pass: 88 skipped: 4 fail: 18
> >> >>
> >> >> This is with "v3.12-rc5-7941-g765f88c".
> >> >
> >> > Yeah, I saw the devm_gpio_request_one() errors too. They happened for 3
> >> > boards on ARM I think. Must have forgotten to update the summary email.
> >> > I'll see if I can come up with a patch to fix the GPIO related build
> >> > failures, or at least report it to LinusW or Alexandre.
> >>
> >> Hmm.
> >>
> >> Please don't apply fixes like these directly to your tree, keep the
> >> broken parts (or drop the tree that introduced it). It makes the
> >> process of getting the fixes in where they really have to go much more
> >> error prone, since there's no way to track whether they have landed in
> >> the right place yet or not.
> >
> > I've found that fixing one build error often subsequent build failures,
> > which would go unnoticed if I dropped the trees or let the breakage
> > unfixed.
>
> Yeah, that's what happened with the GPIO subsystem on this release --
> there are two build errors but your fix resolves one of them such at
> the other one is exposed. It makes it confusing to bisect down to root
> cause. I'd almost rather have your tree just being broken, but patches
> submitted and sent in to the maintainer in question if you want to get
> it fixed ASAP.
I guess I could probably just push the final merge commit as a tree, but
it would require me to very strongly resist my compulsive urge not to
push something that doesn't even build.
I suppose if we could write that down into some kind of rule I could go
look at it until the compulsiveness wears down... =)
> In particular, the gpio fix in the tree right now has no description, etc.
Yes, I know. FWIW I fixed that up properly in today's tree, which I'm
almost ready to push out.
Thierry
On Fri, Oct 25, 2013 at 04:17:08PM +0200, Thierry Reding wrote:
> On Fri, Oct 25, 2013 at 06:43:53AM -0700, Olof Johansson wrote:
> > On Fri, Oct 25, 2013 at 6:35 AM, Thierry Reding
> > <[email protected]> wrote:
> > > On Fri, Oct 25, 2013 at 06:16:02AM -0700, Olof Johansson wrote:
> > >> On Fri, Oct 25, 2013 at 1:35 AM, Thierry Reding
> > >> <[email protected]> wrote:
> > >> > On Thu, Oct 24, 2013 at 10:02:22PM -0700, Guenter Roeck wrote:
> > >> >> On 10/24/2013 09:31 AM, Thierry Reding wrote:
> > >> >> >Hi all,
> > >> >> >
> > >> >> >I've uploaded today's linux-next tree to the master branch of the
> > >> >> >repository below:
> > >> >> >
> > >> >> > git://gitorious.org/thierryreding/linux-next.git
> > >> >> >
> > >> >> >A next-20131024 tag is also provided for convenience.
> > >> >> >
> > >> >> >Quite a few new conflicts. Some of them non-trivial. I've fixed another
> > >> >> >set of build failures, so 32-bit and 64-bit allmodconfigs build fine on
> > >> >> >x86. ARM and x86 default configurations also build fine. PowerPC is in
> > >> >> >pretty bad shape, mostly due to some OF header rework going on.
> > >> >> >
> > >> >>
> > >> >> Hmm ... I see
> > >> >>
> > >> >> Building arm:defconfig ... failed
> > >> >> --------------
> > >> >> Error log:
> > >> >> drivers/built-in.o: In function `mmc_gpio_request_cd':
> > >> >> clkdev.c:(.text+0x74cf8): undefined reference to `devm_gpio_request_one'
> > >> >> make: *** [vmlinux] Error 1
> > >> >>
> > >> >> Otherwise pretty much the same as yesterday, with a build log of
> > >> >> total: 110 pass: 88 skipped: 4 fail: 18
> > >> >>
> > >> >> This is with "v3.12-rc5-7941-g765f88c".
> > >> >
> > >> > Yeah, I saw the devm_gpio_request_one() errors too. They happened for 3
> > >> > boards on ARM I think. Must have forgotten to update the summary email.
> > >> > I'll see if I can come up with a patch to fix the GPIO related build
> > >> > failures, or at least report it to LinusW or Alexandre.
> > >>
> > >> Hmm.
> > >>
> > >> Please don't apply fixes like these directly to your tree, keep the
> > >> broken parts (or drop the tree that introduced it). It makes the
> > >> process of getting the fixes in where they really have to go much more
> > >> error prone, since there's no way to track whether they have landed in
> > >> the right place yet or not.
> > >
> > > I've found that fixing one build error often subsequent build failures,
> > > which would go unnoticed if I dropped the trees or let the breakage
> > > unfixed.
> >
> > Yeah, that's what happened with the GPIO subsystem on this release --
> > there are two build errors but your fix resolves one of them such at
> > the other one is exposed. It makes it confusing to bisect down to root
> > cause. I'd almost rather have your tree just being broken, but patches
> > submitted and sent in to the maintainer in question if you want to get
> > it fixed ASAP.
>
> I guess I could probably just push the final merge commit as a tree, but
> it would require me to very strongly resist my compulsive urge not to
> push something that doesn't even build.
>
"Doesn't even build" is relative, though. After all, there still _are_
18 build failures out of 106 in my test builds alone. Where do you draw
the line ? arm failures are bad, who cares about blackfin ?
Guenter
On Fri, Oct 25, 2013 at 03:03:40PM +0200, Thierry Reding wrote:
> Today's linux-next tree of the h8300-remove tree got a conflict in
>
> drivers/parport/Kconfig
>
> caused by commits e9783b0 (Revert "drivers: parport: Kconfig: exclude h8300
> for PARPORT_PC") and d90c3eb (Kconfig cleanup (PARPORT_PC dependencies)).
>
> I fixed it up (see below). Please verify that the resolution looks good.
>
> Thanks,
> Thierry
> ---
> diff --cc drivers/parport/Kconfig
> index f536685,dc82ef0..2225237
> --- a/drivers/parport/Kconfig
> +++ b/drivers/parport/Kconfig
> @@@ -41,8 -35,10 +41,7 @@@ if PARPOR
>
> config PARPORT_PC
> tristate "PC-style hardware"
> - depends on (!SPARC64 || PCI) && !SPARC32 && !M32R && !FRV && !S390 && \
> - (!M68K || ISA) && !MN10300 && !AVR32 && !BLACKFIN && \
> - !XTENSA && !CRIS
> -
> + depends on ARCH_MIGHT_HAVE_PC_PARPORT
> -
> ---help---
> You should say Y here if you have a PC-style parallel port. All
> IBM PC compatible computers and some Alphas have PC-style
>
I dropped the patch (revert) causing the conflict.
Guenter
On Fri, Oct 25, 2013 at 08:02:28AM -0700, Guenter Roeck wrote:
> On Fri, Oct 25, 2013 at 04:17:08PM +0200, Thierry Reding wrote:
> > On Fri, Oct 25, 2013 at 06:43:53AM -0700, Olof Johansson wrote:
> > > On Fri, Oct 25, 2013 at 6:35 AM, Thierry Reding
> > > <[email protected]> wrote:
> > > > On Fri, Oct 25, 2013 at 06:16:02AM -0700, Olof Johansson wrote:
> > > >> On Fri, Oct 25, 2013 at 1:35 AM, Thierry Reding
> > > >> <[email protected]> wrote:
> > > >> > On Thu, Oct 24, 2013 at 10:02:22PM -0700, Guenter Roeck wrote:
> > > >> >> On 10/24/2013 09:31 AM, Thierry Reding wrote:
> > > >> >> >Hi all,
> > > >> >> >
> > > >> >> >I've uploaded today's linux-next tree to the master branch of the
> > > >> >> >repository below:
> > > >> >> >
> > > >> >> > git://gitorious.org/thierryreding/linux-next.git
> > > >> >> >
> > > >> >> >A next-20131024 tag is also provided for convenience.
> > > >> >> >
> > > >> >> >Quite a few new conflicts. Some of them non-trivial. I've fixed another
> > > >> >> >set of build failures, so 32-bit and 64-bit allmodconfigs build fine on
> > > >> >> >x86. ARM and x86 default configurations also build fine. PowerPC is in
> > > >> >> >pretty bad shape, mostly due to some OF header rework going on.
> > > >> >> >
> > > >> >>
> > > >> >> Hmm ... I see
> > > >> >>
> > > >> >> Building arm:defconfig ... failed
> > > >> >> --------------
> > > >> >> Error log:
> > > >> >> drivers/built-in.o: In function `mmc_gpio_request_cd':
> > > >> >> clkdev.c:(.text+0x74cf8): undefined reference to `devm_gpio_request_one'
> > > >> >> make: *** [vmlinux] Error 1
> > > >> >>
> > > >> >> Otherwise pretty much the same as yesterday, with a build log of
> > > >> >> total: 110 pass: 88 skipped: 4 fail: 18
> > > >> >>
> > > >> >> This is with "v3.12-rc5-7941-g765f88c".
> > > >> >
> > > >> > Yeah, I saw the devm_gpio_request_one() errors too. They happened for 3
> > > >> > boards on ARM I think. Must have forgotten to update the summary email.
> > > >> > I'll see if I can come up with a patch to fix the GPIO related build
> > > >> > failures, or at least report it to LinusW or Alexandre.
> > > >>
> > > >> Hmm.
> > > >>
> > > >> Please don't apply fixes like these directly to your tree, keep the
> > > >> broken parts (or drop the tree that introduced it). It makes the
> > > >> process of getting the fixes in where they really have to go much more
> > > >> error prone, since there's no way to track whether they have landed in
> > > >> the right place yet or not.
> > > >
> > > > I've found that fixing one build error often subsequent build failures,
> > > > which would go unnoticed if I dropped the trees or let the breakage
> > > > unfixed.
> > >
> > > Yeah, that's what happened with the GPIO subsystem on this release --
> > > there are two build errors but your fix resolves one of them such at
> > > the other one is exposed. It makes it confusing to bisect down to root
> > > cause. I'd almost rather have your tree just being broken, but patches
> > > submitted and sent in to the maintainer in question if you want to get
> > > it fixed ASAP.
> >
> > I guess I could probably just push the final merge commit as a tree, but
> > it would require me to very strongly resist my compulsive urge not to
> > push something that doesn't even build.
> >
> "Doesn't even build" is relative, though. After all, there still _are_
> 18 build failures out of 106 in my test builds alone. Where do you draw
> the line ? arm failures are bad, who cares about blackfin ?
Well, I've been doing x86, ARM and PowerPC builds and of those only 3
are failing and I didn't fix them because I didn't really know how to.
But you're right, I guess one has to draw the line somewhere, and if
people prefer the tree to just be broken rather than with odd fixes on
top, then that's the way it going to be.
For now I've settled on pushing a branch which has only the fixes that
are required to make the trees work happily together and a separate tag
which has the patches that unbreak subsystem trees.
The reason I usually want linux-next to build is because I know that
various people rely on it for their daily work, so my reasoning was that
if I fix it before they even start using it, then they get to spend
their time with something more useful and only one person ends up fixing
the build issues instead of everyone.
Thierry
On Fri, Oct 25, 2013 at 06:33:43AM -0700, Olof Johansson wrote:
> On Fri, Oct 25, 2013 at 6:24 AM, Mark Brown <[email protected]> wrote:
> > The rule I was applying (which I think is the same as Stephen applies)
> > is that I'd fix anything that was definitely the result of a merge issue
> > (like the build failure in misc due to a sysfs API change in the sysfs
> > tree) but not anything that was just plain broken in the tree in
> > isolation.
> Some of those might still make sense, but as many as possible of them
> should be pushed down into the trees where they belong, even if
> they're strictly not needed there (as long as they don't break the
> standalone tree, of course).
Right, this is strictly for issues generated as a result of a change in
one tree that cause an issue when merged with another tree like adding a
user of an API in one tree that has had an incompatible change in
another.
On Fri, Oct 25, 2013 at 05:17:18PM +0200, Thierry Reding wrote:
> > >
> > "Doesn't even build" is relative, though. After all, there still _are_
> > 18 build failures out of 106 in my test builds alone. Where do you draw
> > the line ? arm failures are bad, who cares about blackfin ?
>
> Well, I've been doing x86, ARM and PowerPC builds and of those only 3
> are failing and I didn't fix them because I didn't really know how to.
> But you're right, I guess one has to draw the line somewhere, and if
> people prefer the tree to just be broken rather than with odd fixes on
> top, then that's the way it going to be.
>
> For now I've settled on pushing a branch which has only the fixes that
> are required to make the trees work happily together and a separate tag
> which has the patches that unbreak subsystem trees.
>
> The reason I usually want linux-next to build is because I know that
> various people rely on it for their daily work, so my reasoning was that
> if I fix it before they even start using it, then they get to spend
> their time with something more useful and only one person ends up fixing
> the build issues instead of everyone.
>
Frankly, I don't even know what the best approach would be.
Ultimately you are stuck between a rock and a hard place: You want the tree
to build so people can use it, but each patch you apply yourself might
result in it not getting fixed in the contributing repository.
I think one problem we have is how to report breakages. Any summary
mail or web page doesn't help if no one looks at it. It does help lot
to send specific e-mail along the line of "Commit 'bla' caused build 'x'
to fail as follows" to the respective mailing list and patch authors,
but that takes a lot of time which at least I don't have. And people
might get annoyed by automated e-mails, so that might not be a good
idea either.
Guenter
On Fri, Oct 25, 2013 at 7:17 PM, Guenter Roeck <[email protected]> wrote:
> I think one problem we have is how to report breakages. Any summary
> mail or web page doesn't help if no one looks at it. It does help lot
> to send specific e-mail along the line of "Commit 'bla' caused build 'x'
> to fail as follows" to the respective mailing list and patch authors,
> but that takes a lot of time which at least I don't have. And people
> might get annoyed by automated e-mails, so that might not be a good
> idea either.
In theory, these blame emails can be automated using some git bisect
scripting.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
* Will Deacon <[email protected]> wrote:
> On Fri, Oct 25, 2013 at 02:03:42PM +0100, Thierry Reding wrote:
> > Today's linux-next merge of the tip tree got conflicts in
> >
> > tools/perf/config/Makefile
> > tools/perf/config/feature-tests.mak
> >
> > caused by commits 405ffbd (perf tools: Check libunwind for availability of
> > dwarf parsing feature) and mostly 308e1e7 (tools/perf/build: Clean up the
> > libunwind logic in config/Makefile) as well as various follow-up patches.
> >
> > I fixed it up (see below). Please verify that the resolution looks good.
> > Also note that this isn't really a trivial resolution of a conflict, but
> > required modifying various other files. That causes rerere magic not to
> > work and needs part of conflict to be resolved manually. Perhaps a good
> > idea would be to rebase Jean's patch on top of the cleanups going on in
> > the tip tree? Perhaps even carry the patch in the tip tree?
>
> These came via my tree (arm perf) after discussion here:
>
> http://lists.infradead.org/pipermail/linux-arm-kernel/2013-October/203077.html
>
> Now that they've been pulled by rmk, we can't back them out with
> ugly reverts, so I'm not sure what we can do to resolve in the ARM
> tree; it looks like the perf Makefile has changed significantly in
> -tip.
I realize that it was acked by Arnaldo, but for workflow reasons I'd
really prefer it if non-trivial perf tooling patches went to Arnaldo
as a pull request so that he can resolve any such conflicts. perf is
in constant development so it's less work for you that way.
(Kernel side changes can go that route as well, as long as they are
perf related.)
Thanks,
Ingo
On Fri, Oct 25, 2013 at 03:03:39PM +0200, Thierry Reding wrote:
> diff --cc arch/arm/Kconfig
> index c06647d,7db8abe0..b6a708e
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@@ -5,7 -5,7 +5,8 @@@ config AR
> select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
> select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
> select ARCH_HAVE_CUSTOM_GPIO_H
> + select ARCH_USE_CMPXCHG_LOCKREF
> + select ARCH_MIGHT_HAVE_PC_PARPORT
> select ARCH_WANT_IPC_PARSE_VERSION
Thanks. Generally we want these things to be arranged alphabetically to
reduce the longer term chances of hitting merge conflicts, but in this
case it wouldn't make any difference.
Hi Ingo,
[adding rmk]
On Sat, Oct 26, 2013 at 09:40:33AM +0100, Ingo Molnar wrote:
> * Will Deacon <[email protected]> wrote:
> > On Fri, Oct 25, 2013 at 02:03:42PM +0100, Thierry Reding wrote:
> > > I fixed it up (see below). Please verify that the resolution looks good.
> > > Also note that this isn't really a trivial resolution of a conflict, but
> > > required modifying various other files. That causes rerere magic not to
> > > work and needs part of conflict to be resolved manually. Perhaps a good
> > > idea would be to rebase Jean's patch on top of the cleanups going on in
> > > the tip tree? Perhaps even carry the patch in the tip tree?
> >
> > These came via my tree (arm perf) after discussion here:
> >
> > http://lists.infradead.org/pipermail/linux-arm-kernel/2013-October/203077.html
> >
> > Now that they've been pulled by rmk, we can't back them out with
> > ugly reverts, so I'm not sure what we can do to resolve in the ARM
> > tree; it looks like the perf Makefile has changed significantly in
> > -tip.
>
> I realize that it was acked by Arnaldo, but for workflow reasons I'd
> really prefer it if non-trivial perf tooling patches went to Arnaldo
> as a pull request so that he can resolve any such conflicts. perf is
> in constant development so it's less work for you that way.
Sure. I wasn't aware quite how much you guys had planned for the perf
Makefile and I (wrongly) assumed that Arnaldo's ack was enough of an
indication that conflicts would be unlikely and/or trivial.
In future, I'll push back on any perf changes outside of arch/ in my tree,
but that doesn't help us get out of the current situation: the patches are
currently sitting in rmk's tree for 3.13, so that won't meet with -tip
(outside of next) until Linus pulls them both. What can we do about that?
Will
* Will Deacon <[email protected]> wrote:
> Hi Ingo,
>
> [adding rmk]
>
> On Sat, Oct 26, 2013 at 09:40:33AM +0100, Ingo Molnar wrote:
> > * Will Deacon <[email protected]> wrote:
> > > On Fri, Oct 25, 2013 at 02:03:42PM +0100, Thierry Reding wrote:
> > > > I fixed it up (see below). Please verify that the resolution looks good.
> > > > Also note that this isn't really a trivial resolution of a conflict, but
> > > > required modifying various other files. That causes rerere magic not to
> > > > work and needs part of conflict to be resolved manually. Perhaps a good
> > > > idea would be to rebase Jean's patch on top of the cleanups going on in
> > > > the tip tree? Perhaps even carry the patch in the tip tree?
> > >
> > > These came via my tree (arm perf) after discussion here:
> > >
> > > http://lists.infradead.org/pipermail/linux-arm-kernel/2013-October/203077.html
> > >
> > > Now that they've been pulled by rmk, we can't back them out with
> > > ugly reverts, so I'm not sure what we can do to resolve in the ARM
> > > tree; it looks like the perf Makefile has changed significantly in
> > > -tip.
> >
> > I realize that it was acked by Arnaldo, but for workflow reasons I'd
> > really prefer it if non-trivial perf tooling patches went to Arnaldo
> > as a pull request so that he can resolve any such conflicts. perf is
> > in constant development so it's less work for you that way.
>
> Sure. I wasn't aware quite how much you guys had planned for the perf
> Makefile and I (wrongly) assumed that Arnaldo's ack was enough of an
> indication that conflicts would be unlikely and/or trivial.
That was a bit of unlucky timing.
> In future, I'll push back on any perf changes outside of arch/ in my
> tree, but that doesn't help us get out of the current situation: the
> patches are currently sitting in rmk's tree for 3.13, so that won't meet
> with -tip (outside of next) until Linus pulls them both. What can we do
> about that?
Unless you guys want to do a revert I guess there's not much to do but to
warn Linus in the ARM pull request that a conflict is coming up.
Thanks,
Ingo
On Sun, Oct 27, 2013 at 08:12:37AM +0100, Ingo Molnar wrote:
>
> * Will Deacon <[email protected]> wrote:
> > In future, I'll push back on any perf changes outside of arch/ in my
> > tree, but that doesn't help us get out of the current situation: the
> > patches are currently sitting in rmk's tree for 3.13, so that won't meet
> > with -tip (outside of next) until Linus pulls them both. What can we do
> > about that?
>
> Unless you guys want to do a revert I guess there's not much to do but to
> warn Linus in the ARM pull request that a conflict is coming up.
>From Will's description, it sounded like this could be quite hairy to
fix up, so I'd like to include the conflict resolution in the pull
request so Linus has something to refer to if needed. Could someone
please forward me that?
Thanks.
On Sat, Oct 26, 2013 at 02:19:38PM +0100, Russell King - ARM Linux wrote:
> On Fri, Oct 25, 2013 at 03:03:39PM +0200, Thierry Reding wrote:
> > diff --cc arch/arm/Kconfig
> > index c06647d,7db8abe0..b6a708e
> > --- a/arch/arm/Kconfig
> > +++ b/arch/arm/Kconfig
> > @@@ -5,7 -5,7 +5,8 @@@ config AR
> > select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
> > select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
> > select ARCH_HAVE_CUSTOM_GPIO_H
> > + select ARCH_USE_CMPXCHG_LOCKREF
> > + select ARCH_MIGHT_HAVE_PC_PARPORT
> > select ARCH_WANT_IPC_PARSE_VERSION
>
> Thanks. Generally we want these things to be arranged alphabetically to
> reduce the longer term chances of hitting merge conflicts, but in this
> case it wouldn't make any difference.
I was aiming for alphabetical order... guess I need to revisit my ABCs.
Thierry
diff --cc tools/perf/config/Makefile
index 75b93d7,c516d6b..e4d06b2
--- a/tools/perf/config/Makefile
+++ b/tools/perf/config/Makefile
@@@ -29,13 -29,9 +29,13 @@@ ifeq ($(ARCH),x86_64
NO_PERF_REGS := 0
LIBUNWIND_LIBS = -lunwind -lunwind-x86_64
endif
+ifeq ($(ARCH),arm)
+ NO_PERF_REGS := 0
+ LIBUNWIND_LIBS = -lunwind -lunwind-arm
+endif
ifeq ($(NO_PERF_REGS),0)
- CFLAGS += -DHAVE_PERF_REGS
+ CFLAGS += -DHAVE_PERF_REGS_SUPPORT
endif
ifeq ($(src-perf),)
@@@ -93,20 -85,125 +89,126 @@@ CFLAGS += -std=gnu9
EXTLIBS = -lelf -lpthread -lrt -lm -ldl
- ifeq ($(call try-cc,$(SOURCE_HELLO),$(CFLAGS) -Werror -fstack-protector-all,-fstack-protector-all),y)
- CFLAGS += -fstack-protector-all
+ ifneq ($(OUTPUT),)
+ OUTPUT_FEATURES = $(OUTPUT)config/feature-checks/
+ $(shell mkdir -p $(OUTPUT_FEATURES))
endif
- ifeq ($(call try-cc,$(SOURCE_HELLO),$(CFLAGS) -Werror -Wstack-protector,-Wstack-protector),y)
- CFLAGS += -Wstack-protector
+ feature_check = $(eval $(feature_check_code))
+ define feature_check_code
+ feature-$(1) := $(shell $(MAKE) OUTPUT=$(OUTPUT_FEATURES) LDFLAGS=$(LDFLAGS) -C config/feature-checks test-$1 >/dev/null 2>/dev/null && echo 1 || echo 0)
+ endef
+
+ feature_set = $(eval $(feature_set_code))
+ define feature_set_code
+ feature-$(1) := 1
+ endef
+
+ #
+ # Build the feature check binaries in parallel, ignore errors, ignore return value and suppress output:
+ #
+
+ #
+ # Note that this is not a complete list of all feature tests, just
+ # those that are typically built on a fully configured system.
+ #
+ # [ Feature tests not mentioned here have to be built explicitly in
+ # the rule that uses them - an example for that is the 'bionic'
+ # feature check. ]
+ #
+ CORE_FEATURE_TESTS = \
+ backtrace \
+ dwarf \
+ fortify-source \
+ glibc \
+ gtk2 \
+ gtk2-infobar \
+ libaudit \
+ libbfd \
+ libelf \
+ libelf-getphdrnum \
+ libelf-mmap \
+ libnuma \
+ libperl \
+ libpython \
+ libpython-version \
+ libslang \
+ libunwind \
++ libunwind-debug-frame \
+ on-exit \
+ stackprotector \
+ stackprotector-all
+
+ #
+ # So here we detect whether test-all was rebuilt, to be able
+ # to skip the print-out of the long features list if the file
+ # existed before and after it was built:
+ #
+ ifeq ($(wildcard $(OUTPUT)config/feature-checks/test-all),)
+ test-all-failed := 1
+ else
+ test-all-failed := 0
+ endif
+
+ #
+ # Special fast-path for the 'all features are available' case:
+ #
+ $(call feature_check,all,$(MSG))
+
+ #
+ # Just in case the build freshly failed, make sure we print the
+ # feature matrix:
+ #
+ ifeq ($(feature-all), 0)
+ test-all-failed := 1
+ endif
+
+ ifeq ($(test-all-failed),1)
+ $(info )
+ $(info Auto-detecting system features:)
+ endif
+
+ ifeq ($(feature-all), 1)
+ #
+ # test-all.c passed - just set all the core feature flags to 1:
+ #
+ $(foreach feat,$(CORE_FEATURE_TESTS),$(call feature_set,$(feat)))
+ else
+ $(shell $(MAKE) OUTPUT=$(OUTPUT_FEATURES) LDFLAGS=$(LDFLAGS) -i -j -C config/feature-checks $(CORE_FEATURE_TESTS) >/dev/null 2>&1)
+ $(foreach feat,$(CORE_FEATURE_TESTS),$(call feature_check,$(feat)))
+ endif
+
+ #
+ # Print the result of the feature test:
+ #
+ feature_print = $(eval $(feature_print_code)) $(info $(MSG))
+
+ define feature_print_code
+ ifeq ($(feature-$(1)), 1)
+ MSG = $(shell printf '...%30s: [ \033[32mon\033[m ]' $(1))
+ else
+ MSG = $(shell printf '...%30s: [ \033[31mOFF\033[m ]' $(1))
+ endif
+ endef
+
+ #
+ # Only print out our features if we rebuilt the testcases or if a test failed:
+ #
+ ifeq ($(test-all-failed), 1)
+ $(foreach feat,$(CORE_FEATURE_TESTS),$(call feature_print,$(feat)))
+ $(info )
endif
- ifeq ($(call try-cc,$(SOURCE_HELLO),$(CFLAGS) -Werror -Wvolatile-register-var,-Wvolatile-register-var),y)
- CFLAGS += -Wvolatile-register-var
+ ifeq ($(feature-stackprotector-all), 1)
+ CFLAGS += -fstack-protector-all
+ endif
+
+ ifeq ($(feature-stackprotector), 1)
+ CFLAGS += -Wstack-protector
endif
- ifndef PERF_DEBUG
- ifeq ($(call try-cc,$(SOURCE_HELLO),$(CFLAGS) -D_FORTIFY_SOURCE=2,-D_FORTIFY_SOURCE=2),y)
+ ifeq ($(DEBUG),0)
+ ifeq ($(feature-fortify-source), 1)
CFLAGS += -D_FORTIFY_SOURCE=2
endif
endif
@@@ -179,64 -274,55 +279,59 @@@ els
endif # NO_LIBELF
ifndef NO_LIBELF
- CFLAGS += -DLIBELF_SUPPORT
- FLAGS_LIBELF=$(CFLAGS) $(LDFLAGS) $(EXTLIBS)
- ifeq ($(call try-cc,$(SOURCE_ELF_MMAP),$(FLAGS_LIBELF),-DLIBELF_MMAP),y)
- CFLAGS += -DLIBELF_MMAP
- endif
- ifeq ($(call try-cc,$(SOURCE_ELF_GETPHDRNUM),$(FLAGS_LIBELF),-DHAVE_ELF_GETPHDRNUM),y)
- CFLAGS += -DHAVE_ELF_GETPHDRNUM
- endif
+ CFLAGS += -DHAVE_LIBELF_SUPPORT
- # include ARCH specific config
- -include $(src-perf)/arch/$(ARCH)/Makefile
+ ifeq ($(feature-libelf-mmap), 1)
+ CFLAGS += -DHAVE_LIBELF_MMAP_SUPPORT
+ endif
- ifndef NO_DWARF
- ifeq ($(origin PERF_HAVE_DWARF_REGS), undefined)
- msg := $(warning DWARF register mappings have not been defined for architecture $(ARCH), DWARF support disabled);
- NO_DWARF := 1
- else
- CFLAGS += -DDWARF_SUPPORT $(LIBDW_CFLAGS)
- LDFLAGS += $(LIBDW_LDFLAGS)
- EXTLIBS += -lelf -ldw
- endif # PERF_HAVE_DWARF_REGS
- endif # NO_DWARF
+ ifeq ($(feature-libelf-getphdrnum), 1)
+ CFLAGS += -DHAVE_ELF_GETPHDRNUM_SUPPORT
+ endif
- endif # NO_LIBELF
+ # include ARCH specific config
+ -include $(src-perf)/arch/$(ARCH)/Makefile
- ifndef NO_LIBELF
- CFLAGS += -DLIBELF_SUPPORT
- FLAGS_LIBELF=$(CFLAGS) $(LDFLAGS) $(EXTLIBS)
- ifeq ($(call try-cc,$(SOURCE_ELF_MMAP),$(FLAGS_LIBELF),-DLIBELF_MMAP),y)
- CFLAGS += -DLIBELF_MMAP
- endif # try-cc
+ ifndef NO_DWARF
+ ifeq ($(origin PERF_HAVE_DWARF_REGS), undefined)
+ msg := $(warning DWARF register mappings have not been defined for architecture $(ARCH), DWARF support disabled);
+ NO_DWARF := 1
+ else
+ CFLAGS += -DHAVE_DWARF_SUPPORT $(LIBDW_CFLAGS)
+ LDFLAGS += $(LIBDW_LDFLAGS)
+ EXTLIBS += -lelf -ldw
+ endif # PERF_HAVE_DWARF_REGS
+ endif # NO_DWARF
endif # NO_LIBELF
-# There's only x86 (both 32 and 64) support for CFI unwind so far
-ifneq ($(ARCH),x86)
+ifeq ($(LIBUNWIND_LIBS),)
NO_LIBUNWIND := 1
endif
ifndef NO_LIBUNWIND
- # for linking with debug library, run like:
- # make DEBUG=1 LIBUNWIND_DIR=/opt/libunwind/
- ifdef LIBUNWIND_DIR
- LIBUNWIND_CFLAGS := -I$(LIBUNWIND_DIR)/include
- LIBUNWIND_LDFLAGS := -L$(LIBUNWIND_DIR)/lib
- endif
+ #
+ # For linking with debug library, run like:
+ #
+ # make DEBUG=1 LIBUNWIND_DIR=/opt/libunwind/
+ #
+ ifdef LIBUNWIND_DIR
+ LIBUNWIND_CFLAGS := -I$(LIBUNWIND_DIR)/include
+ LIBUNWIND_LDFLAGS := -L$(LIBUNWIND_DIR)/lib
+ endif
- FLAGS_UNWIND=$(LIBUNWIND_CFLAGS) $(CFLAGS) $(LIBUNWIND_LDFLAGS) $(LDFLAGS) $(EXTLIBS) $(LIBUNWIND_LIBS)
- ifneq ($(call try-cc,$(SOURCE_LIBUNWIND),$(FLAGS_UNWIND),libunwind),y)
- msg := $(warning No libunwind found, disabling post unwind support. Please install libunwind-dev[el] >= 1.1);
- NO_LIBUNWIND := 1
- endif # Libunwind support
- ifneq ($(call try-cc,$(SOURCE_LIBUNWIND_DEBUG_FRAME),$(FLAGS_UNWIND),libunwind debug_frame),y)
- msg := $(warning No debug_frame support found in libunwind);
- CFLAGS += -DNO_LIBUNWIND_DEBUG_FRAME
- endif # debug_frame support in libunwind
- endif # NO_LIBUNWIND
+ ifneq ($(feature-libunwind), 1)
- msg := $(warning No libunwind found, disabling post unwind support. Please install libunwind-dev[el] >= 0.99);
++ msg := $(warning No libunwind found, disabling post unwind support. Please install libunwind-dev[el] >= 1.1);
+ NO_LIBUNWIND := 1
++ else
++ ifneq ($(feature-libunwind-debug-frame), 1)
++ msg := $(warning No debug_frame support found in libunwind);
++ CFLAGS += -DNO_LIBUNWIND_DEBUG_FRAME
++ endif
+ endif
+ endif
ifndef NO_LIBUNWIND
- CFLAGS += -DLIBUNWIND_SUPPORT
+ CFLAGS += -DHAVE_LIBUNWIND_SUPPORT
EXTLIBS += $(LIBUNWIND_LIBS)
CFLAGS += $(LIBUNWIND_CFLAGS)
LDFLAGS += $(LIBUNWIND_LDFLAGS)
diff --cc tools/perf/config/feature-checks/Makefile
index 0000000,452b67c..abaf8f4
mode 000000,100644..100644
--- a/tools/perf/config/feature-checks/Makefile
+++ b/tools/perf/config/feature-checks/Makefile
@@@ -1,0 -1,144 +1,148 @@@
+
+ FILES= \
+ test-all \
+ test-backtrace \
+ test-bionic \
+ test-dwarf \
+ test-fortify-source \
+ test-glibc \
+ test-gtk2 \
+ test-gtk2-infobar \
+ test-hello \
+ test-libaudit \
+ test-libbfd \
+ test-liberty \
+ test-liberty-z \
+ test-cplus-demangle \
+ test-libelf \
+ test-libelf-getphdrnum \
+ test-libelf-mmap \
+ test-libnuma \
+ test-libperl \
+ test-libpython \
+ test-libpython-version \
+ test-libslang \
+ test-libunwind \
++ test-libunwind-debug-frame \
+ test-on-exit \
+ test-stackprotector-all \
+ test-stackprotector
+
+ CC := $(CC) -MD
+
+ all: $(FILES)
+
+ BUILD = $(CC) $(LDFLAGS) -o $(OUTPUT)$@ [email protected]
+
+ ###############################
+
+ test-all:
+ $(BUILD) -Werror -fstack-protector -fstack-protector-all -O2 -Werror -D_FORTIFY_SOURCE=2 -ldw -lelf -lnuma -lunwind -lunwind-x86_64 -lelf -laudit -I/usr/include/slang -lslang $(shell pkg-config --libs --cflags gtk+-2.0 2>/dev/null) $(FLAGS_PERL_EMBED) $(FLAGS_PYTHON_EMBED) -DPACKAGE='"perf"' -lbfd -ldl
+
+ test-hello:
+ $(BUILD)
+
+ test-stackprotector-all:
+ $(BUILD) -Werror -fstack-protector-all
+
+ test-stackprotector:
+ $(BUILD) -Werror -fstack-protector -Wstack-protector
+
+ test-fortify-source:
+ $(BUILD) -O2 -Werror -D_FORTIFY_SOURCE=2
+
+ test-bionic:
+ $(BUILD)
+
+ test-libelf:
+ $(BUILD) -lelf
+
+ test-glibc:
+ $(BUILD)
+
+ test-dwarf:
+ $(BUILD) -ldw
+
+ test-libelf-mmap:
+ $(BUILD) -lelf
+
+ test-libelf-getphdrnum:
+ $(BUILD) -lelf
+
+ test-libnuma:
+ $(BUILD) -lnuma
+
+ test-libunwind:
+ $(BUILD) -lunwind -lunwind-x86_64 -lelf
+
++test-libunwind-debug-frame:
++ $(BUILD) -lunwind -lunwind-x86_64 -lelf
++
+ test-libaudit:
+ $(BUILD) -laudit
+
+ test-libslang:
+ $(BUILD) -I/usr/include/slang -lslang
+
+ test-gtk2:
+ $(BUILD) $(shell pkg-config --libs --cflags gtk+-2.0 2>/dev/null)
+
+ test-gtk2-infobar:
+ $(BUILD) $(shell pkg-config --libs --cflags gtk+-2.0 2>/dev/null)
+
+ grep-libs = $(filter -l%,$(1))
+ strip-libs = $(filter-out -l%,$(1))
+
+ PERL_EMBED_LDOPTS = $(shell perl -MExtUtils::Embed -e ldopts 2>/dev/null)
+ PERL_EMBED_LDFLAGS = $(call strip-libs,$(PERL_EMBED_LDOPTS))
+ PERL_EMBED_LIBADD = $(call grep-libs,$(PERL_EMBED_LDOPTS))
+ PERL_EMBED_CCOPTS = `perl -MExtUtils::Embed -e ccopts 2>/dev/null`
+ FLAGS_PERL_EMBED=$(PERL_EMBED_CCOPTS) $(PERL_EMBED_LDOPTS)
+
+ test-libperl:
+ $(BUILD) $(FLAGS_PERL_EMBED)
+
+ override PYTHON := python
+ override PYTHON_CONFIG := python-config
+
+ escape-for-shell-sq = $(subst ','\'',$(1))
+ shell-sq = '$(escape-for-shell-sq)'
+
+ PYTHON_CONFIG_SQ = $(call shell-sq,$(PYTHON_CONFIG))
+
+ PYTHON_EMBED_LDOPTS = $(shell $(PYTHON_CONFIG_SQ) --ldflags 2>/dev/null)
+ PYTHON_EMBED_LDFLAGS = $(call strip-libs,$(PYTHON_EMBED_LDOPTS))
+ PYTHON_EMBED_LIBADD = $(call grep-libs,$(PYTHON_EMBED_LDOPTS))
+ PYTHON_EMBED_CCOPTS = $(shell $(PYTHON_CONFIG_SQ) --cflags 2>/dev/null)
+ FLAGS_PYTHON_EMBED = $(PYTHON_EMBED_CCOPTS) $(PYTHON_EMBED_LDOPTS)
+
+ test-libpython:
+ $(BUILD) $(FLAGS_PYTHON_EMBED)
+
+ test-libpython-version:
+ $(BUILD) $(FLAGS_PYTHON_EMBED)
+
+ test-libbfd:
+ $(BUILD) -DPACKAGE='"perf"' -lbfd -ldl
+
+ test-liberty:
+ $(CC) -o $(OUTPUT)$@ test-libbfd.c -DPACKAGE='"perf"' -lbfd -ldl -liberty
+
+ test-liberty-z:
+ $(CC) -o $(OUTPUT)$@ test-libbfd.c -DPACKAGE='"perf"' -lbfd -ldl -liberty -lz
+
+ test-cplus-demangle:
+ $(BUILD) -liberty
+
+ test-on-exit:
+ $(BUILD)
+
+ test-backtrace:
+ $(BUILD)
+
+ -include *.d
+
+ ###############################
+
+ clean:
+ rm -f $(FILES) *.d
diff --cc tools/perf/config/feature-checks/test-all.c
index 0000000,50d4318..726be48
mode 000000,100644..100644
--- a/tools/perf/config/feature-checks/test-all.c
+++ b/tools/perf/config/feature-checks/test-all.c
@@@ -1,0 -1,106 +1,110 @@@
+ /*
+ * test-all.c: Try to build all the main testcases at once.
+ *
+ * A well-configured system will have all the prereqs installed, so we can speed
+ * up auto-detection on such systems.
+ */
+
+ /*
+ * Quirk: Python and Perl headers cannot be in arbitrary places, so keep
+ * these 3 testcases at the top:
+ */
+ #define main main_test_libpython
+ # include "test-libpython.c"
+ #undef main
+
+ #define main main_test_libpython_version
+ # include "test-libpython-version.c"
+ #undef main
+
+ #define main main_test_libperl
+ # include "test-libperl.c"
+ #undef main
+
+ #define main main_test_hello
+ # include "test-hello.c"
+ #undef main
+
+ #define main main_test_libelf
+ # include "test-libelf.c"
+ #undef main
+
+ #define main main_test_libelf_mmap
+ # include "test-libelf-mmap.c"
+ #undef main
+
+ #define main main_test_glibc
+ # include "test-glibc.c"
+ #undef main
+
+ #define main main_test_dwarf
+ # include "test-dwarf.c"
+ #undef main
+
+ #define main main_test_libelf_getphdrnum
+ # include "test-libelf-getphdrnum.c"
+ #undef main
+
+ #define main main_test_libunwind
+ # include "test-libunwind.c"
+ #undef main
+
++#define main main_test_libunwind_debug_frame
++# include "test-libunwind-debug-frame.c"
++#undef main
++
+ #define main main_test_libaudit
+ # include "test-libaudit.c"
+ #undef main
+
+ #define main main_test_libslang
+ # include "test-libslang.c"
+ #undef main
+
+ #define main main_test_gtk2
+ # include "test-gtk2.c"
+ #undef main
+
+ #define main main_test_gtk2_infobar
+ # include "test-gtk2-infobar.c"
+ #undef main
+
+ #define main main_test_libbfd
+ # include "test-libbfd.c"
+ #undef main
+
+ #define main main_test_on_exit
+ # include "test-on-exit.c"
+ #undef main
+
+ #define main main_test_backtrace
+ # include "test-backtrace.c"
+ #undef main
+
+ #define main main_test_libnuma
+ # include "test-libnuma.c"
+ #undef main
+
+ int main(int argc, char *argv[])
+ {
+ main_test_libpython();
+ main_test_libpython_version();
+ main_test_libperl();
+ main_test_hello();
+ main_test_libelf();
+ main_test_libelf_mmap();
+ main_test_glibc();
+ main_test_dwarf();
+ main_test_libelf_getphdrnum();
+ main_test_libunwind();
+ main_test_libaudit();
+ main_test_libslang();
+ main_test_gtk2(argc, argv);
+ main_test_gtk2_infobar(argc, argv);
+ main_test_libbfd();
+ main_test_on_exit();
+ main_test_backtrace();
+ main_test_libnuma();
+
+ return 0;
+ }
diff --cc tools/perf/config/feature-checks/test-libunwind-debug-frame.c
index 0000000,0000000..0ef8087
new file mode 100644
--- /dev/null
+++ b/tools/perf/config/feature-checks/test-libunwind-debug-frame.c
@@@ -1,0 -1,0 +1,16 @@@
++#include <libunwind.h>
++#include <stdlib.h>
++
++extern int
++UNW_OBJ(dwarf_find_debug_frame) (int found, unw_dyn_info_t *di_debug,
++ unw_word_t ip, unw_word_t segbase,
++ const char *obj_name, unw_word_t start,
++ unw_word_t end);
++
++#define dwarf_find_debug_frame UNW_OBJ(dwarf_find_debug_frame)
++
++int main(void)
++{
++ dwarf_find_debug_frame(0, NULL, 0, 0, NULL, 0, 0);
++ return 0;
++}
On Mon, Oct 28, 2013 at 08:47:22AM +0100, Thierry Reding wrote:
> On Sun, Oct 27, 2013 at 10:00:48AM +0000, Russell King - ARM Linux wrote:
> > On Sun, Oct 27, 2013 at 08:12:37AM +0100, Ingo Molnar wrote:
> > >
> > > * Will Deacon <[email protected]> wrote:
> > > > In future, I'll push back on any perf changes outside of arch/ in my
> > > > tree, but that doesn't help us get out of the current situation: the
> > > > patches are currently sitting in rmk's tree for 3.13, so that won't meet
> > > > with -tip (outside of next) until Linus pulls them both. What can we do
> > > > about that?
> > >
> > > Unless you guys want to do a revert I guess there's not much to do but to
> > > warn Linus in the ARM pull request that a conflict is coming up.
> >
> > From Will's description, it sounded like this could be quite hairy to
> > fix up, so I'd like to include the conflict resolution in the pull
> > request so Linus has something to refer to if needed. Could someone
> > please forward me that?
>
> Hi Russell,
>
> I've attached the relevant parts of the resolution, although I'm not
> sure if anybody's actually confirmed that it's correct.
I'm not sure whether that can happen any time before -final - Will is
(storm dependent) flying out to Linaro Connect today, and I've no idea
who to turn to for this to be tested for ARM.
I guess we have some time given that Linus has released -rc7 and his
comments during the Kernel Summit/in the rc7 announcement.