Re: [Xen-devel] [PATCH v4 0/9] add xenalyze to staging

[George Dunlap <george.dunlap@xxxxxxxxxxxxx>]

On 06/03/2015 12:16 PM, George Dunlap wrote:
> 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

Looks like the purpose of that was to be able to include trace.h directly:

#include <public/trace.h>

But the right way to do this is to do what xentrace.c does:

#include <xen/trace.h>

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel