[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v4 0/9] add xenalyze to staging
On 06/03/2015 11:59 AM, Ian Campbell wrote: > On Wed, 2015-06-03 at 11:33 +0100, George Dunlap wrote: >> On 06/03/2015 11:10 AM, Ian Campbell wrote: >>> On Sat, 2015-05-23 at 08:24 +0000, Olaf Hering wrote: >>>> Having xenalyze in the source tree makes it much easier to keep private >>>> debug code in hypervisor and xenalyze in sync. It helped alot while >>>> debugging the root cause for commit >>>> 607e8494c42397fb249191904066cace6ac9a880. >>> >>> I'm afraid it doesn't build on arm64. >>> >>> Some of these actually look like non-arch specific failures (e.g. >>> conflicts with register_t from system headers) or issues which should >>> probably be addressed with xenalyze in tree (e.g. NR_CPUS ought to be >>> available directly now?) or with some trivial #ifdef modifications. >>> >>> That said, I don't know that xentrace actually works on ARM nor that >>> xenalyze could analyse such traces even with the build issues addressed, >>> so I'd be equally happy if this was just made x86 only. >>> >>> In file included from /usr/aarch64-linux-gnu/include/linux/types.h:4:0, >>> from /usr/aarch64-linux-gnu/include/asm/ptrace.h:22, >>> from /usr/aarch64-linux-gnu/include/sys/user.h:25, >>> from /usr/aarch64-linux-gnu/include/sys/procfs.h:34, >>> from /usr/aarch64-linux-gnu/include/sys/ucontext.h:26, >>> from /usr/aarch64-linux-gnu/include/signal.h:360, >>> from /usr/aarch64-linux-gnu/include/sys/wait.h:30, >>> from xenalyze.c:28: >>> /local/scratch/ianc/devel/committer-arm64.git/tools/xentrace/../../xen/include/asm/types.h:54:13: >>> error: conflicting types for 'register_t' >>> typedef u64 register_t; >>> ^ >>> In file included from /usr/aarch64-linux-gnu/include/stdlib.h:314:0, >>> from xenalyze.c:24: >>> /usr/aarch64-linux-gnu/include/sys/types.h:205:13: note: previous >>> declaration of 'register_t' was here >>> typedef int register_t __attribute__ ((__mode__ (__word__))); >>> ^ >> >> The weird thing about this one is that register_t isn't defined or used >> by xenalyze at all. >> >> The include pedigree is a bit confusing, but it looks like >> aarch64-linux-gnu/include/linux/types.h is including Xen files, and that >> there's a type mismatch between Xen's xen/include/asm/types.h and the >> system's include/sys/types.h. >> >> It looks like it will happen to any program which includes both #include >> both stdlib.h and sys/wait.h. If so, this is a general problem with Xen >> on ARM64, not a bug in xenalyze. >> >> (But as I said, the #include chain is a bit confusing, so I feel free to >> correct me if I got something wrong...) > > Has tools/xentrace/../../xen/include/asm/types.h ended up shadowing an > <asm/types.h> from one of these headers, which should have included > /usr/<arch>/include/asm/types.h? > > IOW the bug is in CFLAGS using some -I... or other, and/or in the fact > that our include directory somehow shadows the real ones? Aha -- looks like here's the culprit: xenalyze.o: CFLAGS += -I$(XEN_ROOT)/xen/include That's not in my original Makefile, and I didn't notice it when doing review. Olaf? -George _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |