From patchwork Mon Oct 17 23:36:18 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Stefano Stabellini X-Patchwork-Id: 9380857 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 954016086B for ; Mon, 17 Oct 2016 23:39:23 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 8DF6128D15 for ; Mon, 17 Oct 2016 23:39:23 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 8218A28D35; Mon, 17 Oct 2016 23:39:23 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.2 required=2.0 tests=BAYES_00, RCVD_IN_DNSWL_MED autolearn=ham version=3.3.1 Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 8ED6A28D15 for ; Mon, 17 Oct 2016 23:39:22 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bwHSP-0001Mj-K7; Mon, 17 Oct 2016 23:36:37 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bwHSO-0001Md-Bb for xen-devel@lists.xenproject.org; Mon, 17 Oct 2016 23:36:36 +0000 Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id 4B/C3-21907-28065085; Mon, 17 Oct 2016 23:36:34 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHIsWRWlGSWpSXmKPExsVybKJsh25jAmu EweGP+hbft0xmcmD0OPzhCksAYxRrZl5SfkUCa8ble69ZC27ZVfzZeoO1gbHLtIuRi0NIYCqj xPd3T9ggnH4miYUfrrJ0MXJysAhoS2zZ8R3MZhMwlPj7ZBNQEQeHBJC95DMHSFhEQFHiwcubr CC9zAK/mST296xkAkkIC7hKHH/UwAxSzylgIHF/nQ9ImFfAW+JD61tGiF3PGSW2dEwDqxcV0J U49O8PG0SRoMTJmU9YQHqZBfwkpp0JhjC9JRZNkASpkBDIkJjXM4cVwvaSWHTjEpStJnH13Cb mCYxCs5AMmoUwaBbCIJAKZgEtibNHmxkhbHmJbddXsULY3hLfmq8xLmBkW8WoXpxaVJZapGuu l1SUmZ5RkpuYmaNraGCql5taXJyYnpqTmFSsl5yfu4kRGA8MQLCD8dhk50OMkhxMSqK8FlasE UJ8SfkplRmJxRnxRaU5qcWHGGU4OJQkeNPjgXKCRanpqRVpmTnAyIRJS3DwKInwfosDSvMWFy TmFmemQ6ROMSpKifOagPQJgCQySvPg2mDJ4BKjrJQwLyPQIUI8BalFuZklqPKvGMU5GJWEect BpvBk5pXATX8FtJgJaPG5PBaQxSWJCCmpBsaA5IkS016/MhR2qvumeFjBqKj5oEc966pfq8wD ih/HFgU2h65zF5q+bF2o+7dQsU49EzsTb5snSQu2vuBSjwo2MdVY80H4TMLfojf5PJxT/sZ+/ jzxi67o8jTeIiuZtUedjYW1hXk/JnBx1zrK5Ef6lK6ev9r1vemxsFS2CxcenPpu0P1BRomlOC PRUIu5qDgRAH8ol4sBAwAA X-Env-Sender: sstabellini@kernel.org X-Msg-Ref: server-6.tower-206.messagelabs.com!1476747392!65118247!1 X-Originating-IP: [198.145.29.136] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Received: X-StarScan-Version: 9.0.13; banners=-,-,- X-VirusChecked: Checked Received: (qmail 57594 invoked from network); 17 Oct 2016 23:36:33 -0000 Received: from mail.kernel.org (HELO mail.kernel.org) (198.145.29.136) by server-6.tower-206.messagelabs.com with DHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 17 Oct 2016 23:36:33 -0000 Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 668E9202EC; Mon, 17 Oct 2016 23:36:30 +0000 (UTC) Received: from [10.0.0.56] (c-50-131-44-19.hsd1.ca.comcast.net [50.131.44.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id AA3C420270; Mon, 17 Oct 2016 23:36:28 +0000 (UTC) Date: Mon, 17 Oct 2016 16:36:18 -0700 (PDT) From: Stefano Stabellini X-X-Sender: sstabellini@sstabellini-ThinkPad-X260 To: Wei Liu In-Reply-To: <20161017165507.GA24550@citrix.com> Message-ID: References: <1476464552-12969-1-git-send-email-wei.liu2@citrix.com> <1476464552-12969-2-git-send-email-wei.liu2@citrix.com> <20161017104700.GE23219@citrix.com> <20161017145646.GA16605@linaro.org> <20161017165507.GA24550@citrix.com> User-Agent: Alpine 2.10 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-ID: X-Virus-Scanned: ClamAV using ClamSMTP Cc: Stefano Stebellini , Steve Capper , Wei Chen , Steve Capper , Julien Grall , Jan Beulich , Shannon Zhao , Xen-devel , Boris Ostrovsky Subject: Re: [Xen-devel] [PATCH for-4.8 1/3] libacpi: fix arm64 build X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" X-Virus-Scanned: ClamAV using ClamSMTP 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 > > > > Signed-off-by: Wei Liu > > > > --- > > > > Cc: Julien Grall > > > > Cc: Wei Chen > > > > Cc: Steve Capper > > > > Cc: Jan Beulich > > > > Cc: Boris Ostrovsky > > > > Cc: Shannon Zhao > > > > Cc: Stefano Stebellini > > > > > > > > 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 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. Acked-by: Wei Liu --- 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 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