> On 31 Jul 2023, at 16:20, Jan Beulich <jbeul...@suse.com> wrote:
>
> On 31.07.2023 17:11, Luca Fancellu wrote:
>>>> + {
>>>> + "rel_path": "arch/x86/include/asm/bug.h",
>>>> + "comment": "Includes mostly assembly macro"
>>>> + },
>>>
>>> Mind me asking why assembly macros wouldn't want maintaining in proper
>>> style?
>>
>> From what I know (experts on CF correct me if I am wrong) clang-format is
>> meant to format only some languages
>> (C/C++/...) and assembly is not one of them, so what is happening is that
>> most of the time clang-format breaks
>> it, in fact we are formatting only .c and .h, but since we have some headers
>> with assembly macros, I’ve seen some issues
>> that ranges from really ugly formatting to build break.
>>
>> One thing we could do, is to export the headers that contain only assembly
>> stuffs in dedicate headers (<header>_asm.h ?)
>> so that we could easily use a name regex to exclude "*_asm.h” from
>> clang-format? And also these headers could #error if
>> included when __ASSEMBLY__ is not defined?
>
> In principle this may be a route to go (naming aside), but first of all
> I wonder what "assembler macros" are to you: We use both C macros and
> true assembler macros in assembly code. The former I would hope formatting
> tools don't have an issue with.
Yes, C macros are clearly not an issue, true assembler macros are, like the
example below:
.macro BUG_FRAME type, line, file_str, second_frame, msg
.if \type >= BUGFRAME_NR
.error "Invalid BUGFRAME index"
.endif
.L\@ud: ud2a
.pushsection .rodata.str1, "aMS", @progbits, 1
.L\@s1: .asciz "\file_str"
.popsection
.pushsection .bug_frames.\type, "a", @progbits
.p2align 2
.L\@bf:
.long (.L\@ud - .L\@bf) + \
((\line >> BUG_LINE_LO_WIDTH) << BUG_DISP_WIDTH)
.long (.L\@s1 - .L\@bf) + \
((\line & ((1 << BUG_LINE_LO_WIDTH) - 1)) << BUG_DISP_WIDTH)
.if \second_frame
.pushsection .rodata.str1, "aMS", @progbits, 1
.L\@s2: .asciz "\msg"
.popsection
.long 0, (.L\@s2 - .L\@bf)
.endif
.popsection
.endm
I don’t think CF has knowledge of the token .macro/.endm/.if/[...] and so it
formats them
in weird ways
>
> Jan
