Hi Jan, > On 23 Aug 2022, at 13:33, Jan Beulich <jbeul...@suse.com> wrote: > > On 23.08.2022 12:24, Bertrand Marquis wrote: >> --- a/tools/libacpi/mk_dsdt.c >> +++ b/tools/libacpi/mk_dsdt.c >> @@ -18,6 +18,16 @@ >> #include <stdlib.h> >> #include <stdbool.h> >> #if defined(CONFIG_X86) >> +/* >> + * When building on non x86 host, arch-x86/xen.h will include xen.h which >> will >> + * try to include the arch xen.h (for example if built on arm, x86/xen.h >> will >> + * include xen.h which will include arch-arm.h). >> + * To prevent this effect, define x86 to have the proper sub arch included >> when >> + * the compiler does not define it. >> + */ >> +#if !(defined(__i386__) || defined(__x86_64__)) >> +#define __x86_64__ >> +#endif > > Besides being confusing this depends on the order of checks in xen.h. > >> #include <xen/arch-x86/xen.h> >> #include <xen/hvm/hvm_info_table.h> >> #elif defined(CONFIG_ARM_64) > > At the very least you will want to #undef the auxiliary define as soon > as practically possible.
Ack > > But I think a different solution will want finding. Did you check what > the #include is needed for, really? I've glanced through the file > without being able to spot anything ... After all this is a build tool, > which generally can't correctly use many of the things declared in the > header. As stated in the comment after the commit message, this is not a good solution but an hack. Now I do not completely agree here, the tool is not really the problem but the headers are. There is not such an issue on arm. The tool needs at least: HVM_MAX_VCPUS XEN_ACPI_CPU_MAP XEN_ACPI_CPU_MAP_LEN XEN_ACPI_GPE0_CPUHP_BIT Which are defined in arch-x86/xen.h and hvm_info_table.h. I am not quite sure how to get those without the current include > >> diff --git a/xen/include/public/arch-x86/xen.h >> b/xen/include/public/arch-x86/xen.h >> index 58a1e87ee971..ea33a56eb6a0 100644 >> --- a/xen/include/public/arch-x86/xen.h >> +++ b/xen/include/public/arch-x86/xen.h >> @@ -24,6 +24,7 @@ >> * Copyright (c) 2004-2006, K A Fraser >> */ >> >> +/* TODO: when cross building, this will include the wrong arch header */ >> #include "../xen.h" > > I'm firmly against adding such a comment in a public header, the more > that it's misleading: Cross-building of Xen, for example, works quite > fine. The issue is limited to HOSTCC != CC (or yet more precisely the > target architecture of each), afaict. Point was the todo was more to show where the issue is coming from. I am really ok to remove this. Cheers Bertrand > > Jan
