On 05.09.2023 04:08, Henry Wang wrote: >> On Sep 1, 2023, at 15:26, Jan Beulich <[email protected]> wrote: >> --- a/xen/include/public/arch-arm.h >> +++ b/xen/include/public/arch-arm.h >> @@ -152,8 +152,10 @@ >> >> #define XEN_HYPERCALL_TAG 0XEA1 >> >> -#define int64_aligned_t int64_t __attribute__((aligned(8))) >> -#define uint64_aligned_t uint64_t __attribute__((aligned(8))) >> +#if defined(__XEN__) || defined(__XEN_TOOLS__) >> +#define int64_aligned_t int64_t __attribute__((__aligned__(8))) >> +#define uint64_aligned_t uint64_t __attribute__((__aligned__(8))) >> +#endif > > Today I tested this patch by our CI (on top of today’s staging), and it looks > like below error will happen for both arm32 and arm64 Yocto build: > > The arm32 failure: > https://pastebin.com/raw/S7ZqmG6z > > The arm64 failure: > https://pastebin.com/raw/HMFh5tuS
Thanks for pointing this out. Turns out that not even all libraries get __XEN_TOOLS__ defined (see tools/Rules.mk). In the case of toolcore, the public xen.h is included solely to get a definition of domid_t. None of the handles are actually needed. I wonder if such a dependency couldn't be avoided. Yet doing so would help only a little: Other libraries (evtchn or gnttab for example) likely need more, yet don't depend on libxc either. For the time being I'll extend the #if to also check for __GNUC__, but I'm not convinced this is a good way of dealing with the issue. Jan
