style question: breaking inline assembly lines

[Chris Johns]

On 14/6/2023 5:47 am, Joel Sherrill wrote:
> 
> 
> On Tue, Jun 13, 2023 at 9:51 AM Sebastian Huber
> <sebastian.huber at embedded-brains.de <mailto:sebastian.huber at embedded-brains.de>>
> wrote:
> 
>     On 13.06.23 00:04, Gedare Bloom wrote:
>     >       "b _ARM_Exception_default\n"
>     >       :
>     > -    : [cpufsz] "i" (sizeof(CPU_Exception_frame)),
>     > -      [cpuspoff] "i" (offsetof(CPU_Exception_frame, register_sp)),
>     > -      [v7mlroff] "i" (offsetof(ARMV7M_Exception_frame, register_lr)),
>     > -      [cpuvecoff] "J" (offsetof(CPU_Exception_frame, vector)),
>     > -      [cpuvfpoff] "i" (ARM_EXCEPTION_FRAME_VFP_CONTEXT_OFFSET),
>     > -      [cpacr] "i" (ARMV7M_CPACR),
>     > -      [vfpsz] "i" (ARM_VFP_CONTEXT_SIZE)
>     > +    : [cpufsz] "i"( sizeof( CPU_Exception_frame ) ),
> 
>     If we place operators (e.g. &&, ||, ...) at the end of a broken line,
>     then we should do this for the : as well.
> 
> 
> OK.
>  
> 
> 
>     My current preference would be to format all non-third-party sources
>     with a standard clang-format selection. I guess in the long run, this
>     will be the easiest approach to maintain. If we use exotic options, then
>     we may up ending as clang-format maintainers.
> 
> 
> I think this is the thing we have to keep in mind and I even said I would
> go along with compromises when we started. Get as close as you can
> and we will have to accept that -- for now. We should definitely file tickets 
> with clang-format and ourselves to track things we don't like. If we get an 
> option in the future whether we or someone else implements it, we can 
> use it and reformat again. Those hopefully are not that invasive.

Sounds like a plan.

I am a little concerned about the version of clang-format I need as some
machines I work on are no at current OS versions.

Chris