Re: [PATCH v8 5/5] xen/x86: switch x86 to use generic implemetation of bug.h

[Jan Beulich <jbeulich@xxxxxxxx>]

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