On 28.03.2023 18:55, Oleksii wrote: > On Tue, 2023-03-28 at 19:38 +0300, Oleksii wrote: >> On Tue, 2023-03-28 at 18:38 +0300, Oleksii wrote: >>> offsets.s arch/x86/x86_64/asm-offsets.c >>> In file included from ./include/public/domctl.h:21, >>> from ./include/public/sysctl.h:18, >>> from ./arch/x86/include/asm/cpuid.h:14, >>> from ./arch/x86/include/asm/cpufeature.h:10, >>> from ./arch/x86/include/asm/system.h:7, >>> from ./arch/x86/include/asm/atomic.h:5, >>> from ./include/xen/gdbstub.h:24, >>> from ./arch/x86/include/asm/debugger.h:10, >>> from ./include/xen/debugger.h:24, >>> from ./arch/x86/include/asm/bug.h:6, >>> from ./include/xen/bug.h:15, >>> from ./arch/x86/include/asm/alternative.h:7, >>> from ./arch/x86/include/asm/bitops.h:8, >>> from ./include/xen/bitops.h:106, >>> from ./arch/x86/include/asm/smp.h:8, >>> from ./include/xen/smp.h:4, >>> from ./include/xen/perfc.h:7, >>> from arch/x86/x86_64/asm-offsets.c:9: >> And again the problem is that x86's <asm/bug.h> includes >> <xen/debugger.h> which somewhere inside uses BUG() which will be >> defined after we will back for x86's <asm/bug.h> to <xen/bug.h> where >> BUG() is defined. >> >> So it looks like we can't include to <asm/bug.h> something that will >> use functionality defined in <xen/bug.h>... >> >> Thereby I don't see better option that include <xen/debugger.h> in >> <common/bug.c> instead of <asm/bug.h>
Well, to deal with this specific issue we could re-arrange xen/perfc.h a little (to skip part of it when COMPILE_OFFSETS is defined), but it seems quite likely that then the same issue would surface yet again elsewhere. So yes, for the time being I guess we need to go with what you have. Until we can sort the xen/lib.h vs xen/bug.h aspect. > Or as an option we can include <xen/bug.h> in <asm/bug.h> instead of > include <asm/bug.h> in <xen/bug.h> it will allow us to resolve an > issue... > > Do you think this option will be better? No, imo that arrangement should remain as is. Jan
