* [PATCH for-4.8 0/3] libacpi fixes
@ 2016-10-14 17:02 Wei Liu
2016-10-14 17:02 ` [PATCH for-4.8 1/3] libacpi: fix arm64 build Wei Liu
` (3 more replies)
0 siblings, 4 replies; 14+ messages in thread
From: Wei Liu @ 2016-10-14 17:02 UTC (permalink / raw)
To: Xen-devel; +Cc: Wei Liu
Wei Liu (3):
libacpi: fix arm64 build
libacpi: require ACPI_BUILD_DIR to be set
libacpi: add back the "G" in "GNU" in licence header
tools/libacpi/Makefile | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
--
2.1.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 14+ messages in thread* [PATCH for-4.8 1/3] libacpi: fix arm64 build 2016-10-14 17:02 [PATCH for-4.8 0/3] libacpi fixes Wei Liu @ 2016-10-14 17:02 ` Wei Liu 2016-10-17 10:47 ` Wei Liu 2016-10-14 17:02 ` [PATCH for-4.8 2/3] libacpi: require ACPI_BUILD_DIR to be set Wei Liu ` (2 subsequent siblings) 3 siblings, 1 reply; 14+ messages in thread From: Wei Liu @ 2016-10-14 17:02 UTC (permalink / raw) To: Xen-devel Cc: Stefano Stebellini, Wei Liu, Wei Chen, Steve Capper, Julien Grall, Jan Beulich, Shannon Zhao, Boris Ostrovsky The arm64 build for libacpi was broken due to two reasons: 1. ACPI_BUILD_DIR was appended twice to dsdt_anycpu_arm.c. 2. The inclusion of firmware/Rules.mk overrided XEN_TARGET_ARCH, which made CONFIG_ARM disappear. Fix those by: 1. Correctly generate full path for dsdt_anaycpu_arm.c. 2. Include tools/Rules.mk instead, because libacpi/Makefile doesn't rely on settings in firmware/Rules.mk. While at it, use CONFIG_ARM_64 instead of CONFIG_ARM as it is more accurate. Reported-by: Julien Grall <julien.grall@arm.com> Signed-off-by: Wei Liu <wei.liu2@citrix.com> --- Cc: Julien Grall <julien.grall@arm.com> Cc: Wei Chen <wei.chen@arm.com> Cc: Steve Capper <steve.capper@arm.com> Cc: Jan Beulich <JBeulich@suse.com> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com> Cc: Shannon Zhao <zhaoshenglong@huawei.com> Cc: Stefano Stebellini <sstabellini@kernel.org> Please check if CONFIG_ARM_64 is correct -- IIRC ACPI is only relevant on arm64. Would appreciate any build test report from ARM people. --- tools/libacpi/Makefile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tools/libacpi/Makefile b/tools/libacpi/Makefile index db7a3a9..24eb0c2 100644 --- a/tools/libacpi/Makefile +++ b/tools/libacpi/Makefile @@ -13,12 +13,12 @@ # XEN_ROOT = $(CURDIR)/../.. -include $(XEN_ROOT)/tools/firmware/Rules.mk +include $(XEN_ROOT)/tools/Rules.mk MK_DSDT = $(ACPI_BUILD_DIR)/mk_dsdt C_SRC-$(GPL) = dsdt_anycpu.c dsdt_15cpu.c dsdt_anycpu_qemu_xen.c -C_SRC-$(CONFIG_ARM) = $(ACPI_BUILD_DIR)/dsdt_anycpu_arm.c +C_SRC-$(CONFIG_ARM_64) = dsdt_anycpu_arm.c C_SRC = $(addprefix $(ACPI_BUILD_DIR)/, dsdt_pvh.c $(C_SRC-y)) H_SRC = $(addprefix $(ACPI_BUILD_DIR)/, ssdt_s3.h ssdt_s4.h ssdt_pm.h ssdt_tpm.h) -- 2.1.4 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel ^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: [PATCH for-4.8 1/3] libacpi: fix arm64 build 2016-10-14 17:02 ` [PATCH for-4.8 1/3] libacpi: fix arm64 build Wei Liu @ 2016-10-17 10:47 ` Wei Liu 2016-10-17 14:57 ` Steve Capper 0 siblings, 1 reply; 14+ messages in thread From: Wei Liu @ 2016-10-17 10:47 UTC (permalink / raw) To: Xen-devel Cc: Stefano Stebellini, Wei Liu, Wei Chen, Steve Capper, Julien Grall, Jan Beulich, Shannon Zhao, Boris Ostrovsky On Fri, Oct 14, 2016 at 06:02:30PM +0100, Wei Liu wrote: > The arm64 build for libacpi was broken due to two reasons: > > 1. ACPI_BUILD_DIR was appended twice to dsdt_anycpu_arm.c. > 2. The inclusion of firmware/Rules.mk overrided XEN_TARGET_ARCH, which > made CONFIG_ARM disappear. > > Fix those by: > > 1. Correctly generate full path for dsdt_anaycpu_arm.c. > 2. Include tools/Rules.mk instead, because libacpi/Makefile doesn't rely > on settings in firmware/Rules.mk. > > While at it, use CONFIG_ARM_64 instead of CONFIG_ARM as it is more > accurate. > > Reported-by: Julien Grall <julien.grall@arm.com> > Signed-off-by: Wei Liu <wei.liu2@citrix.com> > --- > Cc: Julien Grall <julien.grall@arm.com> > Cc: Wei Chen <wei.chen@arm.com> > Cc: Steve Capper <steve.capper@arm.com> > Cc: Jan Beulich <JBeulich@suse.com> > Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com> > Cc: Shannon Zhao <zhaoshenglong@huawei.com> > Cc: Stefano Stebellini <sstabellini@kernel.org> > > Please check if CONFIG_ARM_64 is correct -- IIRC ACPI is only relevant > on arm64. > > Would appreciate any build test report from ARM people. I set up a chroot environment this morning and built arm64 Xen. It worked. Since Jan and Julien are both away, I've taken the liberty of applying this patch with both my RM hat and tools maintainer hat on. I have also applied patch #3 since it is rather trivial. I will let Jan decide whether patch #2 is necessary. Wei. > --- > tools/libacpi/Makefile | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/tools/libacpi/Makefile b/tools/libacpi/Makefile > index db7a3a9..24eb0c2 100644 > --- a/tools/libacpi/Makefile > +++ b/tools/libacpi/Makefile > @@ -13,12 +13,12 @@ > # > > XEN_ROOT = $(CURDIR)/../.. > -include $(XEN_ROOT)/tools/firmware/Rules.mk > +include $(XEN_ROOT)/tools/Rules.mk > > MK_DSDT = $(ACPI_BUILD_DIR)/mk_dsdt > > C_SRC-$(GPL) = dsdt_anycpu.c dsdt_15cpu.c dsdt_anycpu_qemu_xen.c > -C_SRC-$(CONFIG_ARM) = $(ACPI_BUILD_DIR)/dsdt_anycpu_arm.c > +C_SRC-$(CONFIG_ARM_64) = dsdt_anycpu_arm.c > C_SRC = $(addprefix $(ACPI_BUILD_DIR)/, dsdt_pvh.c $(C_SRC-y)) > H_SRC = $(addprefix $(ACPI_BUILD_DIR)/, ssdt_s3.h ssdt_s4.h ssdt_pm.h ssdt_tpm.h) > > -- > 2.1.4 > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH for-4.8 1/3] libacpi: fix arm64 build 2016-10-17 10:47 ` Wei Liu @ 2016-10-17 14:57 ` Steve Capper 2016-10-17 16:55 ` Wei Liu 0 siblings, 1 reply; 14+ messages in thread From: Steve Capper @ 2016-10-17 14:57 UTC (permalink / raw) To: Wei Liu Cc: Stefano Stebellini, Wei Chen, Steve Capper, Julien Grall, Jan Beulich, Shannon Zhao, Xen-devel, Boris Ostrovsky On Mon, Oct 17, 2016 at 11:47:00AM +0100, Wei Liu wrote: > On Fri, Oct 14, 2016 at 06:02:30PM +0100, Wei Liu wrote: > > The arm64 build for libacpi was broken due to two reasons: > > > > 1. ACPI_BUILD_DIR was appended twice to dsdt_anycpu_arm.c. > > 2. The inclusion of firmware/Rules.mk overrided XEN_TARGET_ARCH, which > > made CONFIG_ARM disappear. > > > > Fix those by: > > > > 1. Correctly generate full path for dsdt_anaycpu_arm.c. > > 2. Include tools/Rules.mk instead, because libacpi/Makefile doesn't rely > > on settings in firmware/Rules.mk. > > > > While at it, use CONFIG_ARM_64 instead of CONFIG_ARM as it is more > > accurate. > > > > Reported-by: Julien Grall <julien.grall@arm.com> > > Signed-off-by: Wei Liu <wei.liu2@citrix.com> > > --- > > Cc: Julien Grall <julien.grall@arm.com> > > Cc: Wei Chen <wei.chen@arm.com> > > Cc: Steve Capper <steve.capper@arm.com> > > Cc: Jan Beulich <JBeulich@suse.com> > > Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com> > > Cc: Shannon Zhao <zhaoshenglong@huawei.com> > > Cc: Stefano Stebellini <sstabellini@kernel.org> > > > > Please check if CONFIG_ARM_64 is correct -- IIRC ACPI is only relevant > > on arm64. > > > > Would appreciate any build test report from ARM people. > > I set up a chroot environment this morning and built arm64 Xen. It > worked. > > Since Jan and Julien are both away, I've taken the liberty of applying > this patch with both my RM hat and tools maintainer hat on. > > I have also applied patch #3 since it is rather trivial. > > I will let Jan decide whether patch #2 is necessary. > Thanks Wei, I am trying to verify this patch, but I think I am running into another issue with the libxl acpi support patches. Essentially I'm getting namespace clashes with the following: * nonnull * noreturn * register_t I think this is due to the following logic in the libxl/Makefile: libxl_arm_acpi.o: libxl_arm_acpi.c $(CC) -c $(CFLAGS) -I../../xen/include/ -o $@ libxl_arm_acpi.c When compiling libxl_arm_acpi.c, /usr/include/linux/types.h tries to pull in xen/include/xen/types.h (instead of /usr/include/asm/types.h), which then eventually pulls in xen/include/xen/compiler.h which redefines key information. Which rootfs are you chrooting into for the testing? (I've experienced build issues on Debian Jessie and Ubuntu Xenial running in a Docker container). Cheers, -- Steve I build Xen via: $ git clean -f -d -x $ ./configure --with-xenstored=xenstored --with-system-qemu=/usr/local/bin/qemu-system-aarch64 $ make My builds finish like this: gcc -c -O1 -fno-omit-frame-pointer -DBUILD_ID -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs -O0 -g3 -D__XEN_INTERFACE_VERSION__=__XEN_LATEST_INTERFACE_VERSION__ -MMD -MF .libxl_arm_acpi.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls -Werror -Wno-format-zero-length -Wmissing-declarations -Wno-declaration-after-statement -Wformat-nonliteral -I. -fPIC -pthread -I/home/steven/xen/tools/libxl/../../tools/libs/toollog/include -I/home/steven/xen/tools/libxl/../../tools/include -I/home/steven/xen/tools/libxl/../../tools/libs/evtchn/include -I/home/steven/xen/tools/libxl/../../tools/include -I/home/steven/xen/tools/libxl/../../tools/libxc/include -I/home/steven/xen/tools/libxl/../../tools/libs/toollog/include -I/home/steven/xen/tools/libxl/../../tools/include -I/home/steven/xen/tools/libxl/../../tools/libs/foreignmemory/include -I/home/steven/xen/tools/libxl/../../tools/include -I/home/steven/xen/tools/libxl/../../tools/include -D__XEN_TOOLS__ -I/home/steven/xen/tools/libxl/../../tools/libxc/include -I/home/steven/xen/tools/libxl/../../tools/libs/evtchn/include -I/home/steven/xen/tools/libxl/../../tools/include -I/home/steven/xen/tools/libxl/../../tools/libs/foreignmemory/include -I/home/steven/xen/tools/libxl/../../tools/include -I/home/steven/xen/tools/libxl/../../tools/include -I/home/steven/xen/tools/libxl/../../tools/xenstore/include -I/home/steven/xen/tools/libxl/../../tools/include -I/home/steven/xen/tools/libxl/../../tools/blktap2/control -I/home/steven/xen/tools/libxl/../../tools/blktap2/include -I/home/steven/xen/tools/libxl/../../tools/include -Wshadow -include /home/steven/xen/tools/libxl/../../tools/config.h -I../../xen/include/ -o libxl_arm_acpi.o libxl_arm_acpi.c In file included from /usr/include/linux/types.h:4:0, from /usr/include/aarch64-linux-gnu/asm/sigcontext.h:19, from /usr/include/aarch64-linux-gnu/bits/sigcontext.h:27, from /usr/include/signal.h:332, from libxl_internal.h:30, from libxl_arm.h:17, from libxl_arm_acpi.c:19: ../../xen/include/asm/types.h:54:13: error: conflicting types for 'register_t' typedef u64 register_t; ^ In file included from /usr/include/uuid/uuid.h:38:0, from libxl_osdeps.h:43, from libxl_internal.h:20, from libxl_arm.h:17, from libxl_arm_acpi.c:19: /usr/include/aarch64-linux-gnu/sys/types.h:205:13: note: previous declaration of 'register_t' was here typedef int register_t __attribute__ ((__mode__ (__word__))); ^ In file included from libxl_internal.h:35:0, from libxl_arm.h:17, from libxl_arm_acpi.c:19: /usr/include/stdlib.h:241:6: error: nonnull argument has invalid operand number (argument 1) __locale_t __loc) __THROW __nonnull ((1, 4)); ^ /usr/include/stdlib.h:246:6: error: nonnull argument has invalid operand number (argument 1) __THROW __nonnull ((1, 4)); ^ /usr/include/stdlib.h:252:6: error: nonnull argument has invalid operand number (argument 1) __THROW __nonnull ((1, 4)); ^ /usr/include/stdlib.h:258:6: error: nonnull argument has invalid operand number (argument 1) __THROW __nonnull ((1, 4)); ^ /usr/include/stdlib.h:262:6: error: nonnull argument has invalid operand number (argument 1) __THROW __nonnull ((1, 3)); ^ /usr/include/stdlib.h:266:6: error: nonnull argument has invalid operand number (argument 1) __THROW __nonnull ((1, 3)); ^ /usr/include/stdlib.h:271:6: error: nonnull argument has invalid operand number (argument 1) __THROW __nonnull ((1, 3)); ^ /usr/include/stdlib.h:355:8: error: nonnull argument has invalid operand number (argument 1) int32_t *__restrict __result) __THROW __nonnull ((1, 2)); ^ /usr/include/stdlib.h:363:6: error: nonnull argument has invalid operand number (argument 1) __THROW __nonnull ((2, 4)); ^ /usr/include/stdlib.h:367:6: error: nonnull argument has invalid operand number (argument 1) __THROW __nonnull ((1, 2)); ^ /usr/include/stdlib.h:424:9: error: nonnull argument has invalid operand number (argument 1) double *__restrict __result) __THROW __nonnull ((1, 2)); ^ /usr/include/stdlib.h:427:9: error: nonnull argument has invalid operand number (argument 1) double *__restrict __result) __THROW __nonnull ((1, 2)); ^ /usr/include/stdlib.h:432:6: error: nonnull argument has invalid operand number (argument 1) __THROW __nonnull ((1, 2)); ^ /usr/include/stdlib.h:436:6: error: nonnull argument has invalid operand number (argument 1) __THROW __nonnull ((1, 2)); ^ /usr/include/stdlib.h:441:6: error: nonnull argument has invalid operand number (argument 1) __THROW __nonnull ((1, 2)); ^ /usr/include/stdlib.h:445:6: error: nonnull argument has invalid operand number (argument 1) __THROW __nonnull ((1, 2)); ^ /usr/include/stdlib.h:452:15: error: nonnull argument has invalid operand number (argument 1) struct drand48_data *__buffer) __THROW __nonnull ((1, 2)); ^ /usr/include/stdlib.h:456:6: error: nonnull argument has invalid operand number (argument 1) __THROW __nonnull ((1, 2)); ^ In file included from libxl_internal.h:35:0, from libxl_arm.h:17, from libxl_arm_acpi.c:19: /usr/include/stdlib.h:757:6: error: nonnull argument has invalid operand number (argument 1) __nonnull ((1, 2, 5)) __wur; ^ /usr/include/stdlib.h:766:6: error: nonnull argument has invalid operand number (argument 1) __compar_fn_t __compar) __nonnull ((1, 4)); ^ /usr/include/stdlib.h:770:3: error: nonnull argument has invalid operand number (argument 1) __nonnull ((1, 4)); ^ /usr/include/stdlib.h:813:6: error: nonnull argument has invalid operand number (argument 1) int *__restrict __sign) __THROW __nonnull ((3, 4)) __wur; ^ /usr/include/stdlib.h:819:6: error: nonnull argument has invalid operand number (argument 1) int *__restrict __sign) __THROW __nonnull ((3, 4)) __wur; ^ /usr/include/stdlib.h:832:6: error: nonnull argument has invalid operand number (argument 1) __THROW __nonnull ((3, 4)) __wur; ^ /usr/include/stdlib.h:835:6: error: nonnull argument has invalid operand number (argument 1) __THROW __nonnull ((3, 4)) __wur; ^ /usr/include/stdlib.h:844:6: error: nonnull argument has invalid operand number (argument 1) size_t __len) __THROW __nonnull ((3, 4, 5)); ^ /usr/include/stdlib.h:847:6: error: nonnull argument has invalid operand number (argument 1) size_t __len) __THROW __nonnull ((3, 4, 5)); ^ /usr/include/stdlib.h:852:6: error: nonnull argument has invalid operand number (argument 1) __THROW __nonnull ((3, 4, 5)); ^ /usr/include/stdlib.h:856:6: error: nonnull argument has invalid operand number (argument 1) __THROW __nonnull ((3, 4, 5)); ^ /usr/include/stdlib.h:902:6: error: nonnull argument has invalid operand number (argument 1) __THROW __nonnull ((1, 2, 3)) __wur; ^ In file included from libxl_internal.h:36:0, from libxl_arm.h:17, from libxl_arm_acpi.c:19: /usr/include/string.h:47:8: error: nonnull argument has invalid operand number (argument 1) size_t __n) __THROW __nonnull ((1, 2)); ^ /usr/include/string.h:51:6: error: nonnull argument has invalid operand number (argument 1) __THROW __nonnull ((1, 2)); ^ /usr/include/string.h:60:6: error: nonnull argument has invalid operand number (argument 1) __THROW __nonnull ((1, 2)); ^ /usr/include/string.h:70:6: error: nonnull argument has invalid operand number (argument 1) __THROW __attribute_pure__ __nonnull ((1, 2)); ^ /usr/include/string.h:130:6: error: nonnull argument has invalid operand number (argument 1) __THROW __nonnull ((1, 2)); ^ /usr/include/string.h:134:6: error: nonnull argument has invalid operand number (argument 1) __THROW __nonnull ((1, 2)); ^ /usr/include/string.h:138:6: error: nonnull argument has invalid operand number (argument 1) __THROW __nonnull ((1, 2)); ^ /usr/include/string.h:141:9: error: nonnull argument has invalid operand number (argument 1) size_t __n) __THROW __nonnull ((1, 2)); ^ /usr/include/string.h:145:6: error: nonnull argument has invalid operand number (argument 1) __THROW __attribute_pure__ __nonnull ((1, 2)); ^ /usr/include/string.h:148:6: error: nonnull argument has invalid operand number (argument 1) __THROW __attribute_pure__ __nonnull ((1, 2)); ^ /usr/include/string.h:152:6: error: nonnull argument has invalid operand number (argument 1) __THROW __attribute_pure__ __nonnull ((1, 2)); ^ /usr/include/string.h:167:6: error: nonnull argument has invalid operand number (argument 1) __THROW __attribute_pure__ __nonnull ((1, 2, 3)); ^ /usr/include/string.h:170:5: error: nonnull argument has invalid operand number (argument 1) __locale_t __l) __THROW __nonnull ((2, 4)); ^ /usr/include/string.h:286:6: error: nonnull argument has invalid operand number (argument 1) __THROW __attribute_pure__ __nonnull ((1, 2)); ^ /usr/include/string.h:290:6: error: nonnull argument has invalid operand number (argument 1) __THROW __attribute_pure__ __nonnull ((1, 2)); ^ /usr/include/string.h:316:6: error: nonnull argument has invalid operand number (argument 1) __THROW __attribute_pure__ __nonnull ((1, 2)); ^ /usr/include/string.h:343:6: error: nonnull argument has invalid operand number (argument 1) __THROW __attribute_pure__ __nonnull ((1, 2)); ^ /usr/include/string.h:357:6: error: nonnull argument has invalid operand number (argument 1) __THROW __nonnull ((2, 3)); ^ /usr/include/string.h:361:6: error: nonnull argument has invalid operand number (argument 1) __THROW __nonnull ((2, 3)); ^ /usr/include/string.h:374:6: error: nonnull argument has invalid operand number (argument 1) __THROW __attribute_pure__ __nonnull ((1, 2)); ^ /usr/include/string.h:384:6: error: nonnull argument has invalid operand number (argument 1) __THROW __attribute_pure__ __nonnull ((1, 3)); ^ /usr/include/string.h:390:6: error: nonnull argument has invalid operand number (argument 1) __THROW __nonnull ((1, 2)); ^ /usr/include/string.h:393:6: error: nonnull argument has invalid operand number (argument 1) __THROW __nonnull ((1, 2)); ^ /usr/include/string.h:456:6: error: nonnull argument has invalid operand number (argument 1) __THROW __nonnull ((1, 2)); ^ /usr/include/string.h:463:6: error: nonnull argument has invalid operand number (argument 1) __THROW __attribute_pure__ __nonnull ((1, 2)); ^ /usr/include/string.h:535:6: error: nonnull argument has invalid operand number (argument 1) __THROW __attribute_pure__ __nonnull ((1, 2)); ^ /usr/include/string.h:539:6: error: nonnull argument has invalid operand number (argument 1) __THROW __attribute_pure__ __nonnull ((1, 2)); ^ /usr/include/string.h:547:6: error: nonnull argument has invalid operand number (argument 1) __THROW __attribute_pure__ __nonnull ((1, 2, 3)); ^ /usr/include/string.h:551:6: error: nonnull argument has invalid operand number (argument 1) __THROW __attribute_pure__ __nonnull ((1, 2, 4)); ^ /usr/include/string.h:559:6: error: nonnull argument has invalid operand number (argument 1) __THROW __nonnull ((1, 2)); ^ /usr/include/string.h:568:6: error: nonnull argument has invalid operand number (argument 1) __THROW __nonnull ((1, 2)); ^ /usr/include/string.h:570:6: error: nonnull argument has invalid operand number (argument 1) __THROW __nonnull ((1, 2)); ^ /usr/include/string.h:576:6: error: nonnull argument has invalid operand number (argument 1) __THROW __nonnull ((1, 2)); ^ /usr/include/string.h:579:6: error: nonnull argument has invalid operand number (argument 1) __THROW __nonnull ((1, 2)); ^ /usr/include/string.h:585:6: error: nonnull argument has invalid operand number (argument 1) __THROW __attribute_pure__ __nonnull ((1, 2)); ^ In file included from libxl_internal.h:37:0, from libxl_arm.h:17, from libxl_arm_acpi.c:19: /usr/include/unistd.h:552:6: error: nonnull argument has invalid operand number (argument 1) char *const __envp[]) __THROW __nonnull ((1, 2)); ^ /usr/include/unistd.h:564:6: error: nonnull argument has invalid operand number (argument 1) __THROW __nonnull ((1, 2)); ^ /usr/include/unistd.h:569:6: error: nonnull argument has invalid operand number (argument 1) __THROW __nonnull ((1, 2)); ^ /usr/include/unistd.h:574:6: error: nonnull argument has invalid operand number (argument 1) __THROW __nonnull ((1, 2)); ^ /usr/include/unistd.h:579:6: error: nonnull argument has invalid operand number (argument 1) __THROW __nonnull ((1, 2)); ^ /usr/include/unistd.h:585:6: error: nonnull argument has invalid operand number (argument 1) __THROW __nonnull ((1, 2)); ^ /usr/include/unistd.h:592:6: error: nonnull argument has invalid operand number (argument 1) __THROW __nonnull ((1, 2)); ^ In file included from libxl_internal.h:37:0, from libxl_arm.h:17, from libxl_arm_acpi.c:19: /usr/include/unistd.h:791:6: error: nonnull argument has invalid operand number (argument 1) __THROW __nonnull ((1, 2)) __wur; ^ /usr/include/unistd.h:798:6: error: nonnull argument has invalid operand number (argument 1) __THROW __nonnull ((2, 4)) __wur; ^ /usr/include/unistd.h:804:6: error: nonnull argument has invalid operand number (argument 1) __THROW __nonnull ((1, 2)) __wur; ^ /usr/include/unistd.h:811:6: error: nonnull argument has invalid operand number (argument 1) __THROW __nonnull ((1, 2)) __wur; ^ /usr/include/unistd.h:817:9: error: nonnull argument has invalid operand number (argument 1) const char *__to) __THROW __nonnull ((1, 3)) __wur; ^ /usr/include/unistd.h:822:6: error: nonnull argument has invalid operand number (argument 1) __THROW __nonnull ((2, 3)) __wur; ^ In file included from libxl_internal.h:37:0, from libxl_arm.h:17, from libxl_arm_acpi.c:19: /usr/include/unistd.h:1121:6: error: nonnull argument has invalid operand number (argument 1) __THROW __nonnull ((1, 2)); ^ /usr/include/unistd.h:1134:5: error: nonnull argument has invalid operand number (argument 1) ssize_t __n) __THROW __nonnull ((1, 2)); ^ In file included from libxl_internal.h:43:0, from libxl_arm.h:17, from libxl_arm_acpi.c:19: /usr/include/aarch64-linux-gnu/sys/stat.h:210:11: error: nonnull argument has invalid operand number (argument 1) struct stat *__restrict __buf) __THROW __nonnull ((1, 2)); ^ /usr/include/aarch64-linux-gnu/sys/stat.h:229:13: error: nonnull argument has invalid operand number (argument 1) struct stat64 *__restrict __buf) __THROW __nonnull ((1, 2)); ^ /usr/include/aarch64-linux-gnu/sys/stat.h:240:6: error: nonnull argument has invalid operand number (argument 1) __THROW __nonnull ((2, 3)); ^ /usr/include/aarch64-linux-gnu/sys/stat.h:255:6: error: nonnull argument has invalid operand number (argument 1) __THROW __nonnull ((2, 3)); ^ /usr/include/aarch64-linux-gnu/sys/stat.h:264:12: error: nonnull argument has invalid operand number (argument 1) struct stat *__restrict __buf) __THROW __nonnull ((1, 2)); ^ /usr/include/aarch64-linux-gnu/sys/stat.h:278:6: error: nonnull argument has invalid operand number (argument 1) __THROW __nonnull ((1, 2)); ^ /usr/include/aarch64-linux-gnu/sys/stat.h:402:14: error: nonnull argument has invalid operand number (argument 1) struct stat *__stat_buf) __THROW __nonnull ((2, 3)); ^ /usr/include/aarch64-linux-gnu/sys/stat.h:404:15: error: nonnull argument has invalid operand number (argument 1) struct stat *__stat_buf) __THROW __nonnull ((2, 3)); ^ /usr/include/aarch64-linux-gnu/sys/stat.h:407:6: error: nonnull argument has invalid operand number (argument 1) __THROW __nonnull ((3, 4)); ^ /usr/include/aarch64-linux-gnu/sys/stat.h:435:16: error: nonnull argument has invalid operand number (argument 1) struct stat64 *__stat_buf) __THROW __nonnull ((2, 3)); ^ /usr/include/aarch64-linux-gnu/sys/stat.h:437:17: error: nonnull argument has invalid operand number (argument 1) struct stat64 *__stat_buf) __THROW __nonnull ((2, 3)); ^ /usr/include/aarch64-linux-gnu/sys/stat.h:440:6: error: nonnull argument has invalid operand number (argument 1) __THROW __nonnull ((3, 4)); ^ /usr/include/aarch64-linux-gnu/sys/stat.h:443:8: error: nonnull argument has invalid operand number (argument 1) __dev_t *__dev) __THROW __nonnull ((2, 4)); ^ /usr/include/aarch64-linux-gnu/sys/stat.h:447:6: error: nonnull argument has invalid operand number (argument 1) __THROW __nonnull ((3, 5)); ^ In file included from ../../xen/include/xen/config.h:13:0, from ../../xen/include/asm/types.h:6, from /usr/include/linux/types.h:4, from /usr/include/aarch64-linux-gnu/asm/sigcontext.h:19, from /usr/include/aarch64-linux-gnu/bits/sigcontext.h:27, from /usr/include/signal.h:332, from libxl_internal.h:30, from libxl_arm.h:17, from libxl_arm_acpi.c:19: libxl_internal.h:202:68: error: expected ')' before '__attribute__' size_t nmemb, size_t size) __attribute__((noreturn)); ^ In file included from libxl_arm.h:17:0, from libxl_arm_acpi.c:19: libxl_internal.h:202:77: error: expected ',' or ';' before ')' token size_t nmemb, size_t size) __attribute__((noreturn)); ^ In file included from ../../xen/include/xen/config.h:13:0, from ../../xen/include/asm/types.h:6, from /usr/include/linux/types.h:4, from /usr/include/aarch64-linux-gnu/asm/sigcontext.h:19, from /usr/include/aarch64-linux-gnu/bits/sigcontext.h:27, from /usr/include/signal.h:332, from libxl_internal.h:30, from libxl_arm.h:17, from libxl_arm_acpi.c:19: libxl_internal.h:1618:61: error: expected ')' before '__attribute__' char *const env[]) __attribute__((noreturn)); ^ In file included from libxl_arm.h:17:0, from libxl_arm_acpi.c:19: libxl_internal.h:1618:70: error: expected ',' or ';' before ')' token char *const env[]) __attribute__((noreturn)); ^ Makefile:99: recipe for target 'libxl_arm_acpi.o' failed make[3]: *** [libxl_arm_acpi.o] Error 1 make[3]: Leaving directory '/home/steven/xen/tools/libxl' /home/steven/xen/tools/../tools/Rules.mk:216: recipe for target 'subdir-install-libxl' failed make[2]: *** [subdir-install-libxl] Error 2 make[2]: Leaving directory '/home/steven/xen/tools' /home/steven/xen/tools/../tools/Rules.mk:211: recipe for target 'subdirs-install' failed make[1]: *** [subdirs-install] Error 2 make[1]: Leaving directory '/home/steven/xen/tools' Makefile:101: recipe for target 'install-tools' failed make: *** [install-tools] Error 2 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH for-4.8 1/3] libacpi: fix arm64 build 2016-10-17 14:57 ` Steve Capper @ 2016-10-17 16:55 ` Wei Liu 2016-10-17 23:36 ` Stefano Stabellini 0 siblings, 1 reply; 14+ messages in thread From: Wei Liu @ 2016-10-17 16:55 UTC (permalink / raw) To: Steve Capper Cc: Stefano Stebellini, Wei Liu, Wei Chen, Steve Capper, Julien Grall, Jan Beulich, Shannon Zhao, Xen-devel, Boris Ostrovsky On Mon, Oct 17, 2016 at 03:57:06PM +0100, Steve Capper wrote: > On Mon, Oct 17, 2016 at 11:47:00AM +0100, Wei Liu wrote: > > On Fri, Oct 14, 2016 at 06:02:30PM +0100, Wei Liu wrote: > > > The arm64 build for libacpi was broken due to two reasons: > > > > > > 1. ACPI_BUILD_DIR was appended twice to dsdt_anycpu_arm.c. > > > 2. The inclusion of firmware/Rules.mk overrided XEN_TARGET_ARCH, which > > > made CONFIG_ARM disappear. > > > > > > Fix those by: > > > > > > 1. Correctly generate full path for dsdt_anaycpu_arm.c. > > > 2. Include tools/Rules.mk instead, because libacpi/Makefile doesn't rely > > > on settings in firmware/Rules.mk. > > > > > > While at it, use CONFIG_ARM_64 instead of CONFIG_ARM as it is more > > > accurate. > > > > > > Reported-by: Julien Grall <julien.grall@arm.com> > > > Signed-off-by: Wei Liu <wei.liu2@citrix.com> > > > --- > > > Cc: Julien Grall <julien.grall@arm.com> > > > Cc: Wei Chen <wei.chen@arm.com> > > > Cc: Steve Capper <steve.capper@arm.com> > > > Cc: Jan Beulich <JBeulich@suse.com> > > > Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com> > > > Cc: Shannon Zhao <zhaoshenglong@huawei.com> > > > Cc: Stefano Stebellini <sstabellini@kernel.org> > > > > > > Please check if CONFIG_ARM_64 is correct -- IIRC ACPI is only relevant > > > on arm64. > > > > > > Would appreciate any build test report from ARM people. > > > > I set up a chroot environment this morning and built arm64 Xen. It > > worked. > > > > Since Jan and Julien are both away, I've taken the liberty of applying > > this patch with both my RM hat and tools maintainer hat on. > > > > I have also applied patch #3 since it is rather trivial. > > > > I will let Jan decide whether patch #2 is necessary. > > > > Thanks Wei, > I am trying to verify this patch, but I think I am running into another > issue with the libxl acpi support patches. > > Essentially I'm getting namespace clashes with the following: > * nonnull > * noreturn > * register_t > > I think this is due to the following logic in the libxl/Makefile: > libxl_arm_acpi.o: libxl_arm_acpi.c > $(CC) -c $(CFLAGS) -I../../xen/include/ -o $@ libxl_arm_acpi.c > > When compiling libxl_arm_acpi.c, /usr/include/linux/types.h tries to pull > in xen/include/xen/types.h (instead of /usr/include/asm/types.h), which > then eventually pulls in xen/include/xen/compiler.h which redefines key > information. > > Which rootfs are you chrooting into for the testing? > (I've experienced build issues on Debian Jessie and Ubuntu Xenial running > in a Docker container). > qemu-debootstrap, sid, arm64. I saw similar errors. But they went away after I `git clean -fffddddxx` the tree. The fact that they went away somehow and Julien succeeded in building on variant of this patch made me think it was due to some issues in my environment. > Cheers, > -- > Steve > > I build Xen via: > $ git clean -f -d -x > $ ./configure --with-xenstored=xenstored --with-system-qemu=/usr/local/bin/qemu-system-aarch64 > $ make > > My builds finish like this: > > gcc -c -O1 -fno-omit-frame-pointer -DBUILD_ID -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs -O0 -g3 -D__XEN_INTERFACE_VERSION__=__XEN_LATEST_INTERFACE_VERSION__ -MMD -MF .libxl_arm_acpi.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls -Werror -Wno-format-zero-length -Wmissing-declarations -Wno-declaration-after-statement -Wformat-nonliteral -I. -fPIC -pthread -I/home/steven/xen/tools/libxl/../../tools/libs/toollog/include -I/home/steven/xen/tools/libxl/../../tools/include -I/home/steven/xen/tools/libxl/../../tools/libs/evtchn/include -I/home/steven/xen/tools/libxl/../../tools/include -I/home/steven/xen/tools/libxl/../../tools/libxc/include -I/home/steven/xen/tools/libxl/../../tools/libs/toollog/include -I/home/steven/xen/tools/libxl/../../tools/include -I/home/steven/xen/tools/libxl/../../tools/libs/foreignmemory/include -I/home/steven/xen/tools/libxl/../../tools/include -I/home/steven/xen/tools/libxl/../../tools/include -D__XEN_TOOLS__ -I/home/steven/xen/tools/libxl/../../tools/libxc/include -I/home/steven/xen/tools/libxl/../../tools/libs/evtchn/include -I/home/steven/xen/tools/libxl/../../tools/include -I/home/steven/xen/tools/libxl/../../tools/libs/foreignmemory/include -I/home/steven/xen/tools/libxl/../../tools/include -I/home/steven/xen/tools/libxl/../../tools/include -I/home/steven/xen/tools/libxl/../../tools/xenstore/include -I/home/steven/xen/tools/libxl/../../tools/include -I/home/steven/xen/tools/libxl/../../tools/blktap2/control -I/home/steven/xen/tools/libxl/../../tools/blktap2/include -I/home/steven/xen/tools/libxl/../../tools/include -Wshadow -include /home/steven/xen/tools/libxl/../../tools/config.h -I../../xen/include/ -o libxl_arm_acpi.o libxl_arm_acpi.c > In file included from /usr/include/linux/types.h:4:0, > from /usr/include/aarch64-linux-gnu/asm/sigcontext.h:19, > from /usr/include/aarch64-linux-gnu/bits/sigcontext.h:27, > from /usr/include/signal.h:332, > from libxl_internal.h:30, > from libxl_arm.h:17, > from libxl_arm_acpi.c:19: > ../../xen/include/asm/types.h:54:13: error: conflicting types for 'register_t' > typedef u64 register_t; > ^ Now that I think about this, we indeed had similar error in the past. But I'm curious why I succeeded. ┌─[wei@zion] - [/local/work/xen-arm64.git/tools/libxl] - [Mon Oct 17, 17:53] └─[$]> ls -l libxl_arm_acpi.o -rw-rw-r-- 1 wei wei 535160 Oct 17 11:37 libxl_arm_acpi.o ┌─[wei@zion] - [/local/work/xen-arm64.git/tools/libxl] - [Mon Oct 17, 17:53] └─[$]> file libxl_arm_acpi.o libxl_arm_acpi.o: ELF 64-bit LSB relocatable, ARM aarch64, version 1 (SYSV), not stripped > In file included from /usr/include/uuid/uuid.h:38:0, > from libxl_osdeps.h:43, > from libxl_internal.h:20, > from libxl_arm.h:17, > from libxl_arm_acpi.c:19: > /usr/include/aarch64-linux-gnu/sys/types.h:205:13: note: previous declaration of 'register_t' was here > typedef int register_t __attribute__ ((__mode__ (__word__))); > ^ > In file included from libxl_internal.h:35:0, > from libxl_arm.h:17, > from libxl_arm_acpi.c:19: > /usr/include/stdlib.h:241:6: error: nonnull argument has invalid operand number (argument 1) > __locale_t __loc) __THROW __nonnull ((1, 4)); > ^ > /usr/include/stdlib.h:246:6: error: nonnull argument has invalid operand number (argument 1) > __THROW __nonnull ((1, 4)); > ^ > /usr/include/stdlib.h:252:6: error: nonnull argument has invalid operand number (argument 1) > __THROW __nonnull ((1, 4)); > ^ > /usr/include/stdlib.h:258:6: error: nonnull argument has invalid operand number (argument 1) > __THROW __nonnull ((1, 4)); > ^ > /usr/include/stdlib.h:262:6: error: nonnull argument has invalid operand number (argument 1) > __THROW __nonnull ((1, 3)); > ^ > /usr/include/stdlib.h:266:6: error: nonnull argument has invalid operand number (argument 1) > __THROW __nonnull ((1, 3)); > ^ > /usr/include/stdlib.h:271:6: error: nonnull argument has invalid operand number (argument 1) > __THROW __nonnull ((1, 3)); > ^ > /usr/include/stdlib.h:355:8: error: nonnull argument has invalid operand number (argument 1) > int32_t *__restrict __result) __THROW __nonnull ((1, 2)); > ^ > /usr/include/stdlib.h:363:6: error: nonnull argument has invalid operand number (argument 1) > __THROW __nonnull ((2, 4)); > ^ > /usr/include/stdlib.h:367:6: error: nonnull argument has invalid operand number (argument 1) > __THROW __nonnull ((1, 2)); > ^ > /usr/include/stdlib.h:424:9: error: nonnull argument has invalid operand number (argument 1) > double *__restrict __result) __THROW __nonnull ((1, 2)); > ^ > /usr/include/stdlib.h:427:9: error: nonnull argument has invalid operand number (argument 1) > double *__restrict __result) __THROW __nonnull ((1, 2)); > ^ > /usr/include/stdlib.h:432:6: error: nonnull argument has invalid operand number (argument 1) > __THROW __nonnull ((1, 2)); > ^ > /usr/include/stdlib.h:436:6: error: nonnull argument has invalid operand number (argument 1) > __THROW __nonnull ((1, 2)); > ^ > /usr/include/stdlib.h:441:6: error: nonnull argument has invalid operand number (argument 1) > __THROW __nonnull ((1, 2)); > ^ > /usr/include/stdlib.h:445:6: error: nonnull argument has invalid operand number (argument 1) > __THROW __nonnull ((1, 2)); > ^ > /usr/include/stdlib.h:452:15: error: nonnull argument has invalid operand number (argument 1) > struct drand48_data *__buffer) __THROW __nonnull ((1, 2)); > ^ > /usr/include/stdlib.h:456:6: error: nonnull argument has invalid operand number (argument 1) > __THROW __nonnull ((1, 2)); > ^ > In file included from libxl_internal.h:35:0, > from libxl_arm.h:17, > from libxl_arm_acpi.c:19: > /usr/include/stdlib.h:757:6: error: nonnull argument has invalid operand number (argument 1) > __nonnull ((1, 2, 5)) __wur; > ^ > /usr/include/stdlib.h:766:6: error: nonnull argument has invalid operand number (argument 1) > __compar_fn_t __compar) __nonnull ((1, 4)); > ^ > /usr/include/stdlib.h:770:3: error: nonnull argument has invalid operand number (argument 1) > __nonnull ((1, 4)); > ^ > /usr/include/stdlib.h:813:6: error: nonnull argument has invalid operand number (argument 1) > int *__restrict __sign) __THROW __nonnull ((3, 4)) __wur; > ^ > /usr/include/stdlib.h:819:6: error: nonnull argument has invalid operand number (argument 1) > int *__restrict __sign) __THROW __nonnull ((3, 4)) __wur; > ^ > /usr/include/stdlib.h:832:6: error: nonnull argument has invalid operand number (argument 1) > __THROW __nonnull ((3, 4)) __wur; > ^ > /usr/include/stdlib.h:835:6: error: nonnull argument has invalid operand number (argument 1) > __THROW __nonnull ((3, 4)) __wur; > ^ > /usr/include/stdlib.h:844:6: error: nonnull argument has invalid operand number (argument 1) > size_t __len) __THROW __nonnull ((3, 4, 5)); > ^ > /usr/include/stdlib.h:847:6: error: nonnull argument has invalid operand number (argument 1) > size_t __len) __THROW __nonnull ((3, 4, 5)); > ^ > /usr/include/stdlib.h:852:6: error: nonnull argument has invalid operand number (argument 1) > __THROW __nonnull ((3, 4, 5)); > ^ > /usr/include/stdlib.h:856:6: error: nonnull argument has invalid operand number (argument 1) > __THROW __nonnull ((3, 4, 5)); > ^ > /usr/include/stdlib.h:902:6: error: nonnull argument has invalid operand number (argument 1) > __THROW __nonnull ((1, 2, 3)) __wur; > ^ > In file included from libxl_internal.h:36:0, > from libxl_arm.h:17, > from libxl_arm_acpi.c:19: > /usr/include/string.h:47:8: error: nonnull argument has invalid operand number (argument 1) > size_t __n) __THROW __nonnull ((1, 2)); > ^ > /usr/include/string.h:51:6: error: nonnull argument has invalid operand number (argument 1) > __THROW __nonnull ((1, 2)); > ^ > /usr/include/string.h:60:6: error: nonnull argument has invalid operand number (argument 1) > __THROW __nonnull ((1, 2)); > ^ > /usr/include/string.h:70:6: error: nonnull argument has invalid operand number (argument 1) > __THROW __attribute_pure__ __nonnull ((1, 2)); > ^ > /usr/include/string.h:130:6: error: nonnull argument has invalid operand number (argument 1) > __THROW __nonnull ((1, 2)); > ^ > /usr/include/string.h:134:6: error: nonnull argument has invalid operand number (argument 1) > __THROW __nonnull ((1, 2)); > ^ > /usr/include/string.h:138:6: error: nonnull argument has invalid operand number (argument 1) > __THROW __nonnull ((1, 2)); > ^ > /usr/include/string.h:141:9: error: nonnull argument has invalid operand number (argument 1) > size_t __n) __THROW __nonnull ((1, 2)); > ^ > /usr/include/string.h:145:6: error: nonnull argument has invalid operand number (argument 1) > __THROW __attribute_pure__ __nonnull ((1, 2)); > ^ > /usr/include/string.h:148:6: error: nonnull argument has invalid operand number (argument 1) > __THROW __attribute_pure__ __nonnull ((1, 2)); > ^ > /usr/include/string.h:152:6: error: nonnull argument has invalid operand number (argument 1) > __THROW __attribute_pure__ __nonnull ((1, 2)); > ^ > /usr/include/string.h:167:6: error: nonnull argument has invalid operand number (argument 1) > __THROW __attribute_pure__ __nonnull ((1, 2, 3)); > ^ > /usr/include/string.h:170:5: error: nonnull argument has invalid operand number (argument 1) > __locale_t __l) __THROW __nonnull ((2, 4)); > ^ > /usr/include/string.h:286:6: error: nonnull argument has invalid operand number (argument 1) > __THROW __attribute_pure__ __nonnull ((1, 2)); > ^ > /usr/include/string.h:290:6: error: nonnull argument has invalid operand number (argument 1) > __THROW __attribute_pure__ __nonnull ((1, 2)); > ^ > /usr/include/string.h:316:6: error: nonnull argument has invalid operand number (argument 1) > __THROW __attribute_pure__ __nonnull ((1, 2)); > ^ > /usr/include/string.h:343:6: error: nonnull argument has invalid operand number (argument 1) > __THROW __attribute_pure__ __nonnull ((1, 2)); > ^ > /usr/include/string.h:357:6: error: nonnull argument has invalid operand number (argument 1) > __THROW __nonnull ((2, 3)); > ^ > /usr/include/string.h:361:6: error: nonnull argument has invalid operand number (argument 1) > __THROW __nonnull ((2, 3)); > ^ > /usr/include/string.h:374:6: error: nonnull argument has invalid operand number (argument 1) > __THROW __attribute_pure__ __nonnull ((1, 2)); > ^ > /usr/include/string.h:384:6: error: nonnull argument has invalid operand number (argument 1) > __THROW __attribute_pure__ __nonnull ((1, 3)); > ^ > /usr/include/string.h:390:6: error: nonnull argument has invalid operand number (argument 1) > __THROW __nonnull ((1, 2)); > ^ > /usr/include/string.h:393:6: error: nonnull argument has invalid operand number (argument 1) > __THROW __nonnull ((1, 2)); > ^ > /usr/include/string.h:456:6: error: nonnull argument has invalid operand number (argument 1) > __THROW __nonnull ((1, 2)); > ^ > /usr/include/string.h:463:6: error: nonnull argument has invalid operand number (argument 1) > __THROW __attribute_pure__ __nonnull ((1, 2)); > ^ > /usr/include/string.h:535:6: error: nonnull argument has invalid operand number (argument 1) > __THROW __attribute_pure__ __nonnull ((1, 2)); > ^ > /usr/include/string.h:539:6: error: nonnull argument has invalid operand number (argument 1) > __THROW __attribute_pure__ __nonnull ((1, 2)); > ^ > /usr/include/string.h:547:6: error: nonnull argument has invalid operand number (argument 1) > __THROW __attribute_pure__ __nonnull ((1, 2, 3)); > ^ > /usr/include/string.h:551:6: error: nonnull argument has invalid operand number (argument 1) > __THROW __attribute_pure__ __nonnull ((1, 2, 4)); > ^ > /usr/include/string.h:559:6: error: nonnull argument has invalid operand number (argument 1) > __THROW __nonnull ((1, 2)); > ^ > /usr/include/string.h:568:6: error: nonnull argument has invalid operand number (argument 1) > __THROW __nonnull ((1, 2)); > ^ > /usr/include/string.h:570:6: error: nonnull argument has invalid operand number (argument 1) > __THROW __nonnull ((1, 2)); > ^ > /usr/include/string.h:576:6: error: nonnull argument has invalid operand number (argument 1) > __THROW __nonnull ((1, 2)); > ^ > /usr/include/string.h:579:6: error: nonnull argument has invalid operand number (argument 1) > __THROW __nonnull ((1, 2)); > ^ > /usr/include/string.h:585:6: error: nonnull argument has invalid operand number (argument 1) > __THROW __attribute_pure__ __nonnull ((1, 2)); > ^ > In file included from libxl_internal.h:37:0, > from libxl_arm.h:17, > from libxl_arm_acpi.c:19: > /usr/include/unistd.h:552:6: error: nonnull argument has invalid operand number (argument 1) > char *const __envp[]) __THROW __nonnull ((1, 2)); > ^ > /usr/include/unistd.h:564:6: error: nonnull argument has invalid operand number (argument 1) > __THROW __nonnull ((1, 2)); > ^ > /usr/include/unistd.h:569:6: error: nonnull argument has invalid operand number (argument 1) > __THROW __nonnull ((1, 2)); > ^ > /usr/include/unistd.h:574:6: error: nonnull argument has invalid operand number (argument 1) > __THROW __nonnull ((1, 2)); > ^ > /usr/include/unistd.h:579:6: error: nonnull argument has invalid operand number (argument 1) > __THROW __nonnull ((1, 2)); > ^ > /usr/include/unistd.h:585:6: error: nonnull argument has invalid operand number (argument 1) > __THROW __nonnull ((1, 2)); > ^ > /usr/include/unistd.h:592:6: error: nonnull argument has invalid operand number (argument 1) > __THROW __nonnull ((1, 2)); > ^ > In file included from libxl_internal.h:37:0, > from libxl_arm.h:17, > from libxl_arm_acpi.c:19: > /usr/include/unistd.h:791:6: error: nonnull argument has invalid operand number (argument 1) > __THROW __nonnull ((1, 2)) __wur; > ^ > /usr/include/unistd.h:798:6: error: nonnull argument has invalid operand number (argument 1) > __THROW __nonnull ((2, 4)) __wur; > ^ > /usr/include/unistd.h:804:6: error: nonnull argument has invalid operand number (argument 1) > __THROW __nonnull ((1, 2)) __wur; > ^ > /usr/include/unistd.h:811:6: error: nonnull argument has invalid operand number (argument 1) > __THROW __nonnull ((1, 2)) __wur; > ^ > /usr/include/unistd.h:817:9: error: nonnull argument has invalid operand number (argument 1) > const char *__to) __THROW __nonnull ((1, 3)) __wur; > ^ > /usr/include/unistd.h:822:6: error: nonnull argument has invalid operand number (argument 1) > __THROW __nonnull ((2, 3)) __wur; > ^ > In file included from libxl_internal.h:37:0, > from libxl_arm.h:17, > from libxl_arm_acpi.c:19: > /usr/include/unistd.h:1121:6: error: nonnull argument has invalid operand number (argument 1) > __THROW __nonnull ((1, 2)); > ^ > /usr/include/unistd.h:1134:5: error: nonnull argument has invalid operand number (argument 1) > ssize_t __n) __THROW __nonnull ((1, 2)); > ^ > In file included from libxl_internal.h:43:0, > from libxl_arm.h:17, > from libxl_arm_acpi.c:19: > /usr/include/aarch64-linux-gnu/sys/stat.h:210:11: error: nonnull argument has invalid operand number (argument 1) > struct stat *__restrict __buf) __THROW __nonnull ((1, 2)); > ^ > /usr/include/aarch64-linux-gnu/sys/stat.h:229:13: error: nonnull argument has invalid operand number (argument 1) > struct stat64 *__restrict __buf) __THROW __nonnull ((1, 2)); > ^ > /usr/include/aarch64-linux-gnu/sys/stat.h:240:6: error: nonnull argument has invalid operand number (argument 1) > __THROW __nonnull ((2, 3)); > ^ > /usr/include/aarch64-linux-gnu/sys/stat.h:255:6: error: nonnull argument has invalid operand number (argument 1) > __THROW __nonnull ((2, 3)); > ^ > /usr/include/aarch64-linux-gnu/sys/stat.h:264:12: error: nonnull argument has invalid operand number (argument 1) > struct stat *__restrict __buf) __THROW __nonnull ((1, 2)); > ^ > /usr/include/aarch64-linux-gnu/sys/stat.h:278:6: error: nonnull argument has invalid operand number (argument 1) > __THROW __nonnull ((1, 2)); > ^ > /usr/include/aarch64-linux-gnu/sys/stat.h:402:14: error: nonnull argument has invalid operand number (argument 1) > struct stat *__stat_buf) __THROW __nonnull ((2, 3)); > ^ > /usr/include/aarch64-linux-gnu/sys/stat.h:404:15: error: nonnull argument has invalid operand number (argument 1) > struct stat *__stat_buf) __THROW __nonnull ((2, 3)); > ^ > /usr/include/aarch64-linux-gnu/sys/stat.h:407:6: error: nonnull argument has invalid operand number (argument 1) > __THROW __nonnull ((3, 4)); > ^ > /usr/include/aarch64-linux-gnu/sys/stat.h:435:16: error: nonnull argument has invalid operand number (argument 1) > struct stat64 *__stat_buf) __THROW __nonnull ((2, 3)); > ^ > /usr/include/aarch64-linux-gnu/sys/stat.h:437:17: error: nonnull argument has invalid operand number (argument 1) > struct stat64 *__stat_buf) __THROW __nonnull ((2, 3)); > ^ > /usr/include/aarch64-linux-gnu/sys/stat.h:440:6: error: nonnull argument has invalid operand number (argument 1) > __THROW __nonnull ((3, 4)); > ^ > /usr/include/aarch64-linux-gnu/sys/stat.h:443:8: error: nonnull argument has invalid operand number (argument 1) > __dev_t *__dev) __THROW __nonnull ((2, 4)); > ^ > /usr/include/aarch64-linux-gnu/sys/stat.h:447:6: error: nonnull argument has invalid operand number (argument 1) > __THROW __nonnull ((3, 5)); > ^ > In file included from ../../xen/include/xen/config.h:13:0, > from ../../xen/include/asm/types.h:6, > from /usr/include/linux/types.h:4, > from /usr/include/aarch64-linux-gnu/asm/sigcontext.h:19, > from /usr/include/aarch64-linux-gnu/bits/sigcontext.h:27, > from /usr/include/signal.h:332, > from libxl_internal.h:30, > from libxl_arm.h:17, > from libxl_arm_acpi.c:19: > libxl_internal.h:202:68: error: expected ')' before '__attribute__' > size_t nmemb, size_t size) __attribute__((noreturn)); > ^ > In file included from libxl_arm.h:17:0, > from libxl_arm_acpi.c:19: > libxl_internal.h:202:77: error: expected ',' or ';' before ')' token > size_t nmemb, size_t size) __attribute__((noreturn)); > ^ > In file included from ../../xen/include/xen/config.h:13:0, > from ../../xen/include/asm/types.h:6, > from /usr/include/linux/types.h:4, > from /usr/include/aarch64-linux-gnu/asm/sigcontext.h:19, > from /usr/include/aarch64-linux-gnu/bits/sigcontext.h:27, > from /usr/include/signal.h:332, > from libxl_internal.h:30, > from libxl_arm.h:17, > from libxl_arm_acpi.c:19: > libxl_internal.h:1618:61: error: expected ')' before '__attribute__' > char *const env[]) __attribute__((noreturn)); > ^ > In file included from libxl_arm.h:17:0, > from libxl_arm_acpi.c:19: > libxl_internal.h:1618:70: error: expected ',' or ';' before ')' token > char *const env[]) __attribute__((noreturn)); > ^ > Makefile:99: recipe for target 'libxl_arm_acpi.o' failed > make[3]: *** [libxl_arm_acpi.o] Error 1 > make[3]: Leaving directory '/home/steven/xen/tools/libxl' > /home/steven/xen/tools/../tools/Rules.mk:216: recipe for target 'subdir-install-libxl' failed > make[2]: *** [subdir-install-libxl] Error 2 > make[2]: Leaving directory '/home/steven/xen/tools' > /home/steven/xen/tools/../tools/Rules.mk:211: recipe for target 'subdirs-install' failed > make[1]: *** [subdirs-install] Error 2 > make[1]: Leaving directory '/home/steven/xen/tools' > Makefile:101: recipe for target 'install-tools' failed > make: *** [install-tools] Error 2 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH for-4.8 1/3] libacpi: fix arm64 build 2016-10-17 16:55 ` Wei Liu @ 2016-10-17 23:36 ` Stefano Stabellini 2016-10-18 7:52 ` Steve Capper 2016-10-18 11:17 ` Wei Liu 0 siblings, 2 replies; 14+ messages in thread From: Stefano Stabellini @ 2016-10-17 23:36 UTC (permalink / raw) To: Wei Liu Cc: Stefano Stebellini, Steve Capper, Wei Chen, Steve Capper, Julien Grall, Jan Beulich, Shannon Zhao, Xen-devel, Boris Ostrovsky [-- Attachment #1: Type: TEXT/PLAIN, Size: 7647 bytes --] On Mon, 17 Oct 2016, Wei Liu wrote: > On Mon, Oct 17, 2016 at 03:57:06PM +0100, Steve Capper wrote: > > On Mon, Oct 17, 2016 at 11:47:00AM +0100, Wei Liu wrote: > > > On Fri, Oct 14, 2016 at 06:02:30PM +0100, Wei Liu wrote: > > > > The arm64 build for libacpi was broken due to two reasons: > > > > > > > > 1. ACPI_BUILD_DIR was appended twice to dsdt_anycpu_arm.c. > > > > 2. The inclusion of firmware/Rules.mk overrided XEN_TARGET_ARCH, which > > > > made CONFIG_ARM disappear. > > > > > > > > Fix those by: > > > > > > > > 1. Correctly generate full path for dsdt_anaycpu_arm.c. > > > > 2. Include tools/Rules.mk instead, because libacpi/Makefile doesn't rely > > > > on settings in firmware/Rules.mk. > > > > > > > > While at it, use CONFIG_ARM_64 instead of CONFIG_ARM as it is more > > > > accurate. > > > > > > > > Reported-by: Julien Grall <julien.grall@arm.com> > > > > Signed-off-by: Wei Liu <wei.liu2@citrix.com> > > > > --- > > > > Cc: Julien Grall <julien.grall@arm.com> > > > > Cc: Wei Chen <wei.chen@arm.com> > > > > Cc: Steve Capper <steve.capper@arm.com> > > > > Cc: Jan Beulich <JBeulich@suse.com> > > > > Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com> > > > > Cc: Shannon Zhao <zhaoshenglong@huawei.com> > > > > Cc: Stefano Stebellini <sstabellini@kernel.org> > > > > > > > > Please check if CONFIG_ARM_64 is correct -- IIRC ACPI is only relevant > > > > on arm64. > > > > > > > > Would appreciate any build test report from ARM people. > > > > > > I set up a chroot environment this morning and built arm64 Xen. It > > > worked. > > > > > > Since Jan and Julien are both away, I've taken the liberty of applying > > > this patch with both my RM hat and tools maintainer hat on. > > > > > > I have also applied patch #3 since it is rather trivial. > > > > > > I will let Jan decide whether patch #2 is necessary. > > > > > > > Thanks Wei, > > I am trying to verify this patch, but I think I am running into another > > issue with the libxl acpi support patches. > > > > Essentially I'm getting namespace clashes with the following: > > * nonnull > > * noreturn > > * register_t > > > > I think this is due to the following logic in the libxl/Makefile: > > libxl_arm_acpi.o: libxl_arm_acpi.c > > $(CC) -c $(CFLAGS) -I../../xen/include/ -o $@ libxl_arm_acpi.c > > > > When compiling libxl_arm_acpi.c, /usr/include/linux/types.h tries to pull > > in xen/include/xen/types.h (instead of /usr/include/asm/types.h), which > > then eventually pulls in xen/include/xen/compiler.h which redefines key > > information. > > > > Which rootfs are you chrooting into for the testing? > > (I've experienced build issues on Debian Jessie and Ubuntu Xenial running > > in a Docker container). > > > > qemu-debootstrap, sid, arm64. > > I saw similar errors. But they went away after I `git clean -fffddddxx` > the tree. > > The fact that they went away somehow and Julien succeeded in building on > variant of this patch made me think it was due to some issues in my > environment. > > > Cheers, > > -- > > Steve > > > > I build Xen via: > > $ git clean -f -d -x > > $ ./configure --with-xenstored=xenstored --with-system-qemu=/usr/local/bin/qemu-system-aarch64 > > $ make > > > > My builds finish like this: > > > > gcc -c -O1 -fno-omit-frame-pointer -DBUILD_ID -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs -O0 -g3 -D__XEN_INTERFACE_VERSION__=__XEN_LATEST_INTERFACE_VERSION__ -MMD -MF .libxl_arm_acpi.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls -Werror -Wno-format-zero-length -Wmissing-declarations -Wno-declaration-after-statement -Wformat-nonliteral -I. -fPIC -pthread -I/home/steven/xen/tools/libxl/../../tools/libs/toollog/include -I/home/steven/xen/tools/libxl/../../tools/include -I/home/steven/xen/tools/libxl/../../tools/libs/evtchn/include -I/home/steven/xen/tools/libxl/../../tools/include -I/home/steven/xen/tools/libxl/../../tools/libxc/include -I/home/steven/xen /tools/libxl/../../tools/libs/toollog/include -I/home/steven/xen/tools/libxl/../../tools/include -I/home/steven/xen/tools/libxl/../../tools/libs/foreignmemory/include -I/home/steven/xen/tool s/libxl/../../tools/include -I/home/steven/xen/tools/libxl/../../tools/include -D__XEN_TOOLS__ -I/home/steven/xen/tools/libxl/../../tools/libxc/include -I/home/steven/xen/tools/libxl/../../tools/libs/evtchn/include -I/home/steven/xen/tools/libxl/../../tools/include -I/home/steven/xen/tools/libxl/../../tools/libs/foreignmemory/include -I/home/steven/xen/tools/libxl/../../tools/include -I/home/steven/xen/tools/libxl/../../tools/include -I/home/steven/xen/tools/libxl/../../tools/xenstore/include -I/home/steven/xen/tools/libxl/../../tools/include -I/home/steven/xen/tools/libxl/../../tools/blktap2/control -I/home/steven/xen/tools/libxl/../../tools/blktap2/include -I/home/steven/xen/tools/libxl/../../tools/include -Wshadow -include /home/steven/xen/tools/libxl/../../tools/config.h -I../../xen/ include/ -o libxl_arm_acpi.o libxl_arm_acpi.c > > In file included from /usr/include/linux/types.h:4:0, > > from /usr/include/aarch64-linux-gnu/asm/sigcontext.h:19, > > from /usr/include/aarch64-linux-gnu/bits/sigcontext.h:27, > > from /usr/include/signal.h:332, > > from libxl_internal.h:30, > > from libxl_arm.h:17, > > from libxl_arm_acpi.c:19: > > ../../xen/include/asm/types.h:54:13: error: conflicting types for 'register_t' > > typedef u64 register_t; > > ^ > > Now that I think about this, we indeed had similar error in the past. > > But I'm curious why I succeeded. I confirm that your patch (344da4f3ad6c4f76ef4efd530f4b1cc6901d6ff9) fixes the dsdt_anycpu_arm.c build issue. This error is due to the libxl build picking up "../../xen/include/asm/types.h" for #include <asm/types.h> which is wrong (it should be /usr/include/asm/types.h). I did some digging and it depends on the build order: * build tools/ before xen/ --> works * build xen/ before tools/ --> does not work The reason for this is that building Xen creates the xen/include/arm link, which causes ../../xen/include/asm/types.h from being chosen first, because of -I../../xen/include/ in libxl/Makefile. This is dangerous and wrong. --- ARM64: fix libxl build, do not include ../../xen/include Do not include ../../xen/include/ to build libxl_arm_acpi.c: header files clashing against default headers under /usr/include are present in that directory. Link only $(XEN_ROOT)/xen/include/acpi under tools/include instead. Build tested on ARM64 and x86_64. Signed-off-by: Stefano Stabellini <sstabellini@kernel.org> diff --git a/tools/include/Makefile b/tools/include/Makefile index dec8b3d..d95d837 100644 --- a/tools/include/Makefile +++ b/tools/include/Makefile @@ -20,6 +20,7 @@ xen/.dir: ln -sf ../xen-sys/$(XEN_OS) xen/sys ln -sf $(addprefix $(XEN_ROOT)/xen/include/xen/,libelf.h elfstructs.h) xen/libelf/ ln -s ../xen-foreign xen/foreign + ln -s $(XEN_ROOT)/xen/include/acpi acpi touch $@ # Not xen/xsm as that clashes with link to diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile index c4e4117..dac19ac 100644 --- a/tools/libxl/Makefile +++ b/tools/libxl/Makefile @@ -96,7 +96,7 @@ dsdt_anycpu_arm.c: $(MAKE) -C $(ACPI_PATH) ACPI_BUILD_DIR=$(CURDIR) libxl_arm_acpi.o: libxl_arm_acpi.c - $(CC) -c $(CFLAGS) -I../../xen/include/ -o $@ libxl_arm_acpi.c + $(CC) -c $(CFLAGS) -o $@ libxl_arm_acpi.c else LIBXL_OBJS-$(CONFIG_ARM) += libxl_arm_no_acpi.o endif [-- Attachment #2: Type: text/plain, Size: 127 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel ^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: [PATCH for-4.8 1/3] libacpi: fix arm64 build 2016-10-17 23:36 ` Stefano Stabellini @ 2016-10-18 7:52 ` Steve Capper 2016-10-18 11:21 ` Wei Liu 2016-10-18 11:17 ` Wei Liu 1 sibling, 1 reply; 14+ messages in thread From: Steve Capper @ 2016-10-18 7:52 UTC (permalink / raw) To: Stefano Stabellini Cc: Wei Liu, Wei Chen, Steve Capper, Julien Grall, Jan Beulich, Shannon Zhao, Xen-devel, Boris Ostrovsky On Mon, Oct 17, 2016 at 04:36:18PM -0700, Stefano Stabellini wrote: > On Mon, 17 Oct 2016, Wei Liu wrote: > > On Mon, Oct 17, 2016 at 03:57:06PM +0100, Steve Capper wrote: > > > On Mon, Oct 17, 2016 at 11:47:00AM +0100, Wei Liu wrote: > > > > On Fri, Oct 14, 2016 at 06:02:30PM +0100, Wei Liu wrote: > > > > > The arm64 build for libacpi was broken due to two reasons: > > > > > [ ... ] > > > In file included from /usr/include/linux/types.h:4:0, > > > from /usr/include/aarch64-linux-gnu/asm/sigcontext.h:19, > > > from /usr/include/aarch64-linux-gnu/bits/sigcontext.h:27, > > > from /usr/include/signal.h:332, > > > from libxl_internal.h:30, > > > from libxl_arm.h:17, > > > from libxl_arm_acpi.c:19: > > > ../../xen/include/asm/types.h:54:13: error: conflicting types for 'register_t' > > > typedef u64 register_t; > > > ^ > > > > Now that I think about this, we indeed had similar error in the past. > > > > But I'm curious why I succeeded. > > I confirm that your patch (344da4f3ad6c4f76ef4efd530f4b1cc6901d6ff9) > fixes the dsdt_anycpu_arm.c build issue. > > This error is due to the libxl build picking up > "../../xen/include/asm/types.h" for > > #include <asm/types.h> > > which is wrong (it should be /usr/include/asm/types.h). > I did some digging and it depends on the build order: > > * build tools/ before xen/ --> works > * build xen/ before tools/ --> does not work > > The reason for this is that building Xen creates the xen/include/arm > link, which causes ../../xen/include/asm/types.h from being chosen > first, because of -I../../xen/include/ in libxl/Makefile. > > This is dangerous and wrong. > > --- > ARM64: fix libxl build, do not include ../../xen/include > > Do not include ../../xen/include/ to build libxl_arm_acpi.c: header > files clashing against default headers under /usr/include are present in > that directory. > > Link only $(XEN_ROOT)/xen/include/acpi under tools/include instead. > > Build tested on ARM64 and x86_64. > > Signed-off-by: Stefano Stabellini <sstabellini@kernel.org> > > diff --git a/tools/include/Makefile b/tools/include/Makefile > index dec8b3d..d95d837 100644 > --- a/tools/include/Makefile > +++ b/tools/include/Makefile > @@ -20,6 +20,7 @@ xen/.dir: > ln -sf ../xen-sys/$(XEN_OS) xen/sys > ln -sf $(addprefix $(XEN_ROOT)/xen/include/xen/,libelf.h elfstructs.h) xen/libelf/ > ln -s ../xen-foreign xen/foreign > + ln -s $(XEN_ROOT)/xen/include/acpi acpi > touch $@ > > # Not xen/xsm as that clashes with link to > diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile > index c4e4117..dac19ac 100644 > --- a/tools/libxl/Makefile > +++ b/tools/libxl/Makefile > @@ -96,7 +96,7 @@ dsdt_anycpu_arm.c: > $(MAKE) -C $(ACPI_PATH) ACPI_BUILD_DIR=$(CURDIR) > > libxl_arm_acpi.o: libxl_arm_acpi.c > - $(CC) -c $(CFLAGS) -I../../xen/include/ -o $@ libxl_arm_acpi.c > + $(CC) -c $(CFLAGS) -o $@ libxl_arm_acpi.c > else > LIBXL_OBJS-$(CONFIG_ARM) += libxl_arm_no_acpi.o > endif Thanks Stefano, It hadn't occurred to me to add the acpi symlink :-). I can confirm that this fix works for me. ( I think we just delete the libxl_arm_acpi.o build rule and rely on implicit make? ) Cheers, -- Steve _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH for-4.8 1/3] libacpi: fix arm64 build 2016-10-18 7:52 ` Steve Capper @ 2016-10-18 11:21 ` Wei Liu 2016-10-18 11:43 ` Wei Liu 0 siblings, 1 reply; 14+ messages in thread From: Wei Liu @ 2016-10-18 11:21 UTC (permalink / raw) To: Steve Capper Cc: Stefano Stabellini, Wei Liu, Wei Chen, Steve Capper, Julien Grall, Jan Beulich, Shannon Zhao, Xen-devel, Boris Ostrovsky On Tue, Oct 18, 2016 at 08:52:24AM +0100, Steve Capper wrote: > On Mon, Oct 17, 2016 at 04:36:18PM -0700, Stefano Stabellini wrote: > > On Mon, 17 Oct 2016, Wei Liu wrote: > > > On Mon, Oct 17, 2016 at 03:57:06PM +0100, Steve Capper wrote: > > > > On Mon, Oct 17, 2016 at 11:47:00AM +0100, Wei Liu wrote: > > > > > On Fri, Oct 14, 2016 at 06:02:30PM +0100, Wei Liu wrote: > > > > > > The arm64 build for libacpi was broken due to two reasons: > > > > > > > > [ ... ] > > > > > In file included from /usr/include/linux/types.h:4:0, > > > > from /usr/include/aarch64-linux-gnu/asm/sigcontext.h:19, > > > > from /usr/include/aarch64-linux-gnu/bits/sigcontext.h:27, > > > > from /usr/include/signal.h:332, > > > > from libxl_internal.h:30, > > > > from libxl_arm.h:17, > > > > from libxl_arm_acpi.c:19: > > > > ../../xen/include/asm/types.h:54:13: error: conflicting types for 'register_t' > > > > typedef u64 register_t; > > > > ^ > > > > > > Now that I think about this, we indeed had similar error in the past. > > > > > > But I'm curious why I succeeded. > > > > I confirm that your patch (344da4f3ad6c4f76ef4efd530f4b1cc6901d6ff9) > > fixes the dsdt_anycpu_arm.c build issue. > > > > This error is due to the libxl build picking up > > "../../xen/include/asm/types.h" for > > > > #include <asm/types.h> > > > > which is wrong (it should be /usr/include/asm/types.h). > > I did some digging and it depends on the build order: > > > > * build tools/ before xen/ --> works > > * build xen/ before tools/ --> does not work > > > > The reason for this is that building Xen creates the xen/include/arm > > link, which causes ../../xen/include/asm/types.h from being chosen > > first, because of -I../../xen/include/ in libxl/Makefile. > > > > This is dangerous and wrong. > > > > --- > > ARM64: fix libxl build, do not include ../../xen/include > > > > Do not include ../../xen/include/ to build libxl_arm_acpi.c: header > > files clashing against default headers under /usr/include are present in > > that directory. > > > > Link only $(XEN_ROOT)/xen/include/acpi under tools/include instead. > > > > Build tested on ARM64 and x86_64. > > > > Signed-off-by: Stefano Stabellini <sstabellini@kernel.org> > > > > diff --git a/tools/include/Makefile b/tools/include/Makefile > > index dec8b3d..d95d837 100644 > > --- a/tools/include/Makefile > > +++ b/tools/include/Makefile > > @@ -20,6 +20,7 @@ xen/.dir: > > ln -sf ../xen-sys/$(XEN_OS) xen/sys > > ln -sf $(addprefix $(XEN_ROOT)/xen/include/xen/,libelf.h elfstructs.h) xen/libelf/ > > ln -s ../xen-foreign xen/foreign > > + ln -s $(XEN_ROOT)/xen/include/acpi acpi > > touch $@ > > > > # Not xen/xsm as that clashes with link to > > diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile > > index c4e4117..dac19ac 100644 > > --- a/tools/libxl/Makefile > > +++ b/tools/libxl/Makefile > > @@ -96,7 +96,7 @@ dsdt_anycpu_arm.c: > > $(MAKE) -C $(ACPI_PATH) ACPI_BUILD_DIR=$(CURDIR) > > > > libxl_arm_acpi.o: libxl_arm_acpi.c > > - $(CC) -c $(CFLAGS) -I../../xen/include/ -o $@ libxl_arm_acpi.c > > + $(CC) -c $(CFLAGS) -o $@ libxl_arm_acpi.c > > else > > LIBXL_OBJS-$(CONFIG_ARM) += libxl_arm_no_acpi.o > > endif > > Thanks Stefano, > It hadn't occurred to me to add the acpi symlink :-). > > I can confirm that this fix works for me. > Right. I will turn this into a Tested-by tag. Thanks for testing. > ( I think we just delete the libxl_arm_acpi.o build rule and rely on > implicit make? ) > Yes, that can be done. Patch is welcome. :-) Wei. > Cheers, > -- > Steve _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH for-4.8 1/3] libacpi: fix arm64 build 2016-10-18 11:21 ` Wei Liu @ 2016-10-18 11:43 ` Wei Liu 0 siblings, 0 replies; 14+ messages in thread From: Wei Liu @ 2016-10-18 11:43 UTC (permalink / raw) To: Steve Capper Cc: Stefano Stabellini, Wei Liu, Wei Chen, Steve Capper, Julien Grall, Jan Beulich, Shannon Zhao, Xen-devel, Boris Ostrovsky On Tue, Oct 18, 2016 at 12:21:02PM +0100, Wei Liu wrote: [...] > > > --- > > > ARM64: fix libxl build, do not include ../../xen/include > > > > > > Do not include ../../xen/include/ to build libxl_arm_acpi.c: header > > > files clashing against default headers under /usr/include are present in > > > that directory. > > > > > > Link only $(XEN_ROOT)/xen/include/acpi under tools/include instead. > > > > > > Build tested on ARM64 and x86_64. > > > > > > Signed-off-by: Stefano Stabellini <sstabellini@kernel.org> > > > > > > diff --git a/tools/include/Makefile b/tools/include/Makefile > > > index dec8b3d..d95d837 100644 > > > --- a/tools/include/Makefile > > > +++ b/tools/include/Makefile > > > @@ -20,6 +20,7 @@ xen/.dir: > > > ln -sf ../xen-sys/$(XEN_OS) xen/sys > > > ln -sf $(addprefix $(XEN_ROOT)/xen/include/xen/,libelf.h elfstructs.h) xen/libelf/ > > > ln -s ../xen-foreign xen/foreign > > > + ln -s $(XEN_ROOT)/xen/include/acpi acpi > > > touch $@ > > > > > > # Not xen/xsm as that clashes with link to > > > diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile > > > index c4e4117..dac19ac 100644 > > > --- a/tools/libxl/Makefile > > > +++ b/tools/libxl/Makefile > > > @@ -96,7 +96,7 @@ dsdt_anycpu_arm.c: > > > $(MAKE) -C $(ACPI_PATH) ACPI_BUILD_DIR=$(CURDIR) > > > > > > libxl_arm_acpi.o: libxl_arm_acpi.c > > > - $(CC) -c $(CFLAGS) -I../../xen/include/ -o $@ libxl_arm_acpi.c > > > + $(CC) -c $(CFLAGS) -o $@ libxl_arm_acpi.c > > > else > > > LIBXL_OBJS-$(CONFIG_ARM) += libxl_arm_no_acpi.o > > > endif > > > > Thanks Stefano, > > It hadn't occurred to me to add the acpi symlink :-). > > > > I can confirm that this fix works for me. > > > > Right. I will turn this into a Tested-by tag. Thanks for testing. > > > ( I think we just delete the libxl_arm_acpi.o build rule and rely on > > implicit make? ) > > > > Yes, that can be done. Patch is welcome. :-) > I don't know why, but my arm64 chroot is broken at the moment (hangs from time to time, got TCG fatal error). I might submit a patch to change that if I manage to fix my arm64 chroot. Feel free to submit a patch to delete the explicit rule. In the mean time, I've applied this patch as-is so that it passes push-gate sooner. Wei. > Wei. > > > Cheers, > > -- > > Steve _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH for-4.8 1/3] libacpi: fix arm64 build 2016-10-17 23:36 ` Stefano Stabellini 2016-10-18 7:52 ` Steve Capper @ 2016-10-18 11:17 ` Wei Liu 1 sibling, 0 replies; 14+ messages in thread From: Wei Liu @ 2016-10-18 11:17 UTC (permalink / raw) To: Stefano Stabellini Cc: Steve Capper, Wei Chen, Steve Capper, Shannon Zhao, Julien Grall, Jan Beulich, Xen-devel, Wei Liu, Boris Ostrovsky On Mon, Oct 17, 2016 at 04:36:18PM -0700, Stefano Stabellini wrote: > On Mon, 17 Oct 2016, Wei Liu wrote: > > On Mon, Oct 17, 2016 at 03:57:06PM +0100, Steve Capper wrote: > > > On Mon, Oct 17, 2016 at 11:47:00AM +0100, Wei Liu wrote: > > > > On Fri, Oct 14, 2016 at 06:02:30PM +0100, Wei Liu wrote: > > > > > The arm64 build for libacpi was broken due to two reasons: > > > > > > > > > > 1. ACPI_BUILD_DIR was appended twice to dsdt_anycpu_arm.c. > > > > > 2. The inclusion of firmware/Rules.mk overrided XEN_TARGET_ARCH, which > > > > > made CONFIG_ARM disappear. > > > > > > > > > > Fix those by: > > > > > > > > > > 1. Correctly generate full path for dsdt_anaycpu_arm.c. > > > > > 2. Include tools/Rules.mk instead, because libacpi/Makefile doesn't rely > > > > > on settings in firmware/Rules.mk. > > > > > > > > > > While at it, use CONFIG_ARM_64 instead of CONFIG_ARM as it is more > > > > > accurate. > > > > > > > > > > Reported-by: Julien Grall <julien.grall@arm.com> > > > > > Signed-off-by: Wei Liu <wei.liu2@citrix.com> > > > > > --- > > > > > Cc: Julien Grall <julien.grall@arm.com> > > > > > Cc: Wei Chen <wei.chen@arm.com> > > > > > Cc: Steve Capper <steve.capper@arm.com> > > > > > Cc: Jan Beulich <JBeulich@suse.com> > > > > > Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com> > > > > > Cc: Shannon Zhao <zhaoshenglong@huawei.com> > > > > > Cc: Stefano Stebellini <sstabellini@kernel.org> > > > > > > > > > > Please check if CONFIG_ARM_64 is correct -- IIRC ACPI is only relevant > > > > > on arm64. > > > > > > > > > > Would appreciate any build test report from ARM people. > > > > > > > > I set up a chroot environment this morning and built arm64 Xen. It > > > > worked. > > > > > > > > Since Jan and Julien are both away, I've taken the liberty of applying > > > > this patch with both my RM hat and tools maintainer hat on. > > > > > > > > I have also applied patch #3 since it is rather trivial. > > > > > > > > I will let Jan decide whether patch #2 is necessary. > > > > > > > > > > Thanks Wei, > > > I am trying to verify this patch, but I think I am running into another > > > issue with the libxl acpi support patches. > > > > > > Essentially I'm getting namespace clashes with the following: > > > * nonnull > > > * noreturn > > > * register_t > > > > > > I think this is due to the following logic in the libxl/Makefile: > > > libxl_arm_acpi.o: libxl_arm_acpi.c > > > $(CC) -c $(CFLAGS) -I../../xen/include/ -o $@ libxl_arm_acpi.c > > > > > > When compiling libxl_arm_acpi.c, /usr/include/linux/types.h tries to pull > > > in xen/include/xen/types.h (instead of /usr/include/asm/types.h), which > > > then eventually pulls in xen/include/xen/compiler.h which redefines key > > > information. > > > > > > Which rootfs are you chrooting into for the testing? > > > (I've experienced build issues on Debian Jessie and Ubuntu Xenial running > > > in a Docker container). > > > > > > > qemu-debootstrap, sid, arm64. > > > > I saw similar errors. But they went away after I `git clean -fffddddxx` > > the tree. > > > > The fact that they went away somehow and Julien succeeded in building on > > variant of this patch made me think it was due to some issues in my > > environment. > > > > > Cheers, > > > -- > > > Steve > > > > > > I build Xen via: > > > $ git clean -f -d -x > > > $ ./configure --with-xenstored=xenstored --with-system-qemu=/usr/local/bin/qemu-system-aarch64 > > > $ make > > > > > > My builds finish like this: > > > > > > gcc -c -O1 -fno-omit-frame-pointer -DBUILD_ID -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs -O0 -g3 -D__XEN_INTERFACE_VERSION__=__XEN_LATEST_INTERFACE_VERSION__ -MMD -MF .libxl_arm_acpi.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls -Werror -Wno-format-zero-length -Wmissing-declarations -Wno-declaration-after-statement -Wformat-nonliteral -I. -fPIC -pthread -I/home/steven/xen/tools/libxl/../../tools/libs/toollog/include -I/home/steven/xen/tools/libxl/../../tools/include -I/home/steven/xen/tools/libxl/../../tools/libs/evtchn/include -I/home/steven/xen/tools/libxl/../../tools/include -I/home/steven/xen/tools/libxl/../../tools/libxc/include -I/home/steven/xen/tools/libxl/../../tools/libs/toollog/include -I/home/steven/xen/tools/libxl/../../tools/include -I/home/steven/xen/tools/libxl/../../tools/libs/foreignmemory/include -I/home/steven/xen/tool > s/libxl/../../tools/include -I/home/steven/xen/tools/libxl/../../tools/include -D__XEN_TOOLS__ -I/home/steven/xen/tools/libxl/../../tools/libxc/include -I/home/steven/xen/tools/libxl/../../tools/libs/evtchn/include -I/home/steven/xen/tools/libxl/../../tools/include -I/home/steven/xen/tools/libxl/../../tools/libs/foreignmemory/include -I/home/steven/xen/tools/libxl/../../tools/include -I/home/steven/xen/tools/libxl/../../tools/include -I/home/steven/xen/tools/libxl/../../tools/xenstore/include -I/home/steven/xen/tools/libxl/../../tools/include -I/home/steven/xen/tools/libxl/../../tools/blktap2/control -I/home/steven/xen/tools/libxl/../../tools/blktap2/include -I/home/steven/xen/tools/libxl/../../tools/include -Wshadow -include /home/steven/xen/tools/libxl/../../tools/config.h -I../../xen/include/ -o libxl_arm_acpi.o libxl_arm_acpi.c > > > In file included from /usr/include/linux/types.h:4:0, > > > from /usr/include/aarch64-linux-gnu/asm/sigcontext.h:19, > > > from /usr/include/aarch64-linux-gnu/bits/sigcontext.h:27, > > > from /usr/include/signal.h:332, > > > from libxl_internal.h:30, > > > from libxl_arm.h:17, > > > from libxl_arm_acpi.c:19: > > > ../../xen/include/asm/types.h:54:13: error: conflicting types for 'register_t' > > > typedef u64 register_t; > > > ^ > > > > Now that I think about this, we indeed had similar error in the past. > > > > But I'm curious why I succeeded. > > I confirm that your patch (344da4f3ad6c4f76ef4efd530f4b1cc6901d6ff9) > fixes the dsdt_anycpu_arm.c build issue. > > This error is due to the libxl build picking up > "../../xen/include/asm/types.h" for > > #include <asm/types.h> > > which is wrong (it should be /usr/include/asm/types.h). > I did some digging and it depends on the build order: > > * build tools/ before xen/ --> works > * build xen/ before tools/ --> does not work > > The reason for this is that building Xen creates the xen/include/arm > link, which causes ../../xen/include/asm/types.h from being chosen > first, because of -I../../xen/include/ in libxl/Makefile. > Ah, thanks for digging into this. > This is dangerous and wrong. Yes, I agree. This should be fixed. > > --- > ARM64: fix libxl build, do not include ../../xen/include > > Do not include ../../xen/include/ to build libxl_arm_acpi.c: header > files clashing against default headers under /usr/include are present in > that directory. > > Link only $(XEN_ROOT)/xen/include/acpi under tools/include instead. > > Build tested on ARM64 and x86_64. > > Signed-off-by: Stefano Stabellini <sstabellini@kernel.org> > Acked-by: Wei Liu <wei.liu2@citrix.com> Thanks for the patch. This is indeed how it should have been done in the first place. Sorry for not paying enough attention to this while reviewing. > diff --git a/tools/include/Makefile b/tools/include/Makefile > index dec8b3d..d95d837 100644 > --- a/tools/include/Makefile > +++ b/tools/include/Makefile > @@ -20,6 +20,7 @@ xen/.dir: > ln -sf ../xen-sys/$(XEN_OS) xen/sys > ln -sf $(addprefix $(XEN_ROOT)/xen/include/xen/,libelf.h elfstructs.h) xen/libelf/ > ln -s ../xen-foreign xen/foreign > + ln -s $(XEN_ROOT)/xen/include/acpi acpi > touch $@ > > # Not xen/xsm as that clashes with link to > diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile > index c4e4117..dac19ac 100644 > --- a/tools/libxl/Makefile > +++ b/tools/libxl/Makefile > @@ -96,7 +96,7 @@ dsdt_anycpu_arm.c: > $(MAKE) -C $(ACPI_PATH) ACPI_BUILD_DIR=$(CURDIR) > > libxl_arm_acpi.o: libxl_arm_acpi.c > - $(CC) -c $(CFLAGS) -I../../xen/include/ -o $@ libxl_arm_acpi.c > + $(CC) -c $(CFLAGS) -o $@ libxl_arm_acpi.c > else > LIBXL_OBJS-$(CONFIG_ARM) += libxl_arm_no_acpi.o > endif _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 14+ messages in thread
* [PATCH for-4.8 2/3] libacpi: require ACPI_BUILD_DIR to be set 2016-10-14 17:02 [PATCH for-4.8 0/3] libacpi fixes Wei Liu 2016-10-14 17:02 ` [PATCH for-4.8 1/3] libacpi: fix arm64 build Wei Liu @ 2016-10-14 17:02 ` Wei Liu 2016-10-24 12:48 ` Jan Beulich 2016-10-14 17:02 ` [PATCH for-4.8 3/3] libacpi: add back the "G" in "GNU" in licence header Wei Liu 2016-10-14 17:19 ` [PATCH for-4.8 0/3] libacpi fixes Andrew Cooper 3 siblings, 1 reply; 14+ messages in thread From: Wei Liu @ 2016-10-14 17:02 UTC (permalink / raw) To: Xen-devel; +Cc: Wei Liu, Jan Beulich It's better to have a explicit error than a build failure returned by gcc. Signed-off-by: Wei Liu <wei.liu2@citrix.com> --- Cc: Jan Beulich <JBeulich@suse.com> --- tools/libacpi/Makefile | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/tools/libacpi/Makefile b/tools/libacpi/Makefile index 24eb0c2..c1f0af8 100644 --- a/tools/libacpi/Makefile +++ b/tools/libacpi/Makefile @@ -15,6 +15,10 @@ XEN_ROOT = $(CURDIR)/../.. include $(XEN_ROOT)/tools/Rules.mk +ifeq ($(ACPI_BUILD_DIR),) +$(error ACPI_BUILD_DIR not set) +endif + MK_DSDT = $(ACPI_BUILD_DIR)/mk_dsdt C_SRC-$(GPL) = dsdt_anycpu.c dsdt_15cpu.c dsdt_anycpu_qemu_xen.c -- 2.1.4 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel ^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: [PATCH for-4.8 2/3] libacpi: require ACPI_BUILD_DIR to be set 2016-10-14 17:02 ` [PATCH for-4.8 2/3] libacpi: require ACPI_BUILD_DIR to be set Wei Liu @ 2016-10-24 12:48 ` Jan Beulich 0 siblings, 0 replies; 14+ messages in thread From: Jan Beulich @ 2016-10-24 12:48 UTC (permalink / raw) To: Wei Liu; +Cc: Xen-devel >>> On 14.10.16 at 19:02, <wei.liu2@citrix.com> wrote: > It's better to have a explicit error than a build failure returned by > gcc. > > Signed-off-by: Wei Liu <wei.liu2@citrix.com> Acked-by: Jan Beulich <jbeulich@suse.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 14+ messages in thread
* [PATCH for-4.8 3/3] libacpi: add back the "G" in "GNU" in licence header 2016-10-14 17:02 [PATCH for-4.8 0/3] libacpi fixes Wei Liu 2016-10-14 17:02 ` [PATCH for-4.8 1/3] libacpi: fix arm64 build Wei Liu 2016-10-14 17:02 ` [PATCH for-4.8 2/3] libacpi: require ACPI_BUILD_DIR to be set Wei Liu @ 2016-10-14 17:02 ` Wei Liu 2016-10-14 17:19 ` [PATCH for-4.8 0/3] libacpi fixes Andrew Cooper 3 siblings, 0 replies; 14+ messages in thread From: Wei Liu @ 2016-10-14 17:02 UTC (permalink / raw) To: Xen-devel; +Cc: Wei Liu, Jan Beulich Signed-off-by: Wei Liu <wei.liu2@citrix.com> --- Cc: Jan Beulich <JBeulich@suse.com> --- tools/libacpi/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/libacpi/Makefile b/tools/libacpi/Makefile index c1f0af8..18a5cd4 100644 --- a/tools/libacpi/Makefile +++ b/tools/libacpi/Makefile @@ -9,7 +9,7 @@ # This program is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the -# NU Lesser General Public License for more details. +# GNU Lesser General Public License for more details. # XEN_ROOT = $(CURDIR)/../.. -- 2.1.4 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel ^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: [PATCH for-4.8 0/3] libacpi fixes 2016-10-14 17:02 [PATCH for-4.8 0/3] libacpi fixes Wei Liu ` (2 preceding siblings ...) 2016-10-14 17:02 ` [PATCH for-4.8 3/3] libacpi: add back the "G" in "GNU" in licence header Wei Liu @ 2016-10-14 17:19 ` Andrew Cooper 3 siblings, 0 replies; 14+ messages in thread From: Andrew Cooper @ 2016-10-14 17:19 UTC (permalink / raw) To: Wei Liu, Xen-devel On 14/10/16 18:02, Wei Liu wrote: > Wei Liu (3): > libacpi: fix arm64 build > libacpi: require ACPI_BUILD_DIR to be set > libacpi: add back the "G" in "GNU" in licence header All Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2016-10-24 12:48 UTC | newest] Thread overview: 14+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2016-10-14 17:02 [PATCH for-4.8 0/3] libacpi fixes Wei Liu 2016-10-14 17:02 ` [PATCH for-4.8 1/3] libacpi: fix arm64 build Wei Liu 2016-10-17 10:47 ` Wei Liu 2016-10-17 14:57 ` Steve Capper 2016-10-17 16:55 ` Wei Liu 2016-10-17 23:36 ` Stefano Stabellini 2016-10-18 7:52 ` Steve Capper 2016-10-18 11:21 ` Wei Liu 2016-10-18 11:43 ` Wei Liu 2016-10-18 11:17 ` Wei Liu 2016-10-14 17:02 ` [PATCH for-4.8 2/3] libacpi: require ACPI_BUILD_DIR to be set Wei Liu 2016-10-24 12:48 ` Jan Beulich 2016-10-14 17:02 ` [PATCH for-4.8 3/3] libacpi: add back the "G" in "GNU" in licence header Wei Liu 2016-10-14 17:19 ` [PATCH for-4.8 0/3] libacpi fixes Andrew Cooper
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).