On 11.02.2019 19:17, Nick Desaulniers wrote:
> On Sat, Feb 9, 2019 at 9:28 AM Stefan Agner <ste...@agner.ch> wrote:
>>
>> Thanks for the reviews so far.
>>
>> During some more testing I stumbled upon another issue:
>>
>> On 07.02.2019 10:48, Stefan Agner wrote:
>> > Use unified assembler syntax (UAL) in inline assembler. Divided
>> > syntax is considered depricated. This will also allow to build
>> > the kernel using LLVM's integrated assembler.
>> >
>> > Signed-off-by: Stefan Agner <ste...@agner.ch>
>> > ---
>> >  arch/arm/mm/copypage-v4mc.c | 2 +-
>> >  arch/arm/mm/copypage-v4wb.c | 2 +-
>> >  arch/arm/mm/copypage-v4wt.c | 2 +-
>> >  3 files changed, 3 insertions(+), 3 deletions(-)
>> >
>> > diff --git a/arch/arm/mm/copypage-v4mc.c b/arch/arm/mm/copypage-v4mc.c
>> > index b03202cddddb..b19c7ad1a6de 100644
>> > --- a/arch/arm/mm/copypage-v4mc.c
>> > +++ b/arch/arm/mm/copypage-v4mc.c
>> > @@ -56,7 +56,7 @@ static void mc_copy_user_page(void *from, void *to)
>> >       ldmia   %0!, {r2, r3, ip, lr}           @ 4\n\
>> >       subs    %2, %2, #1                      @ 1\n\
>> >       stmia   %1!, {r2, r3, ip, lr}           @ 4\n\
>> > -     ldmneia %0!, {r2, r3, ip, lr}           @ 4\n\
>> > +     ldmiane %0!, {r2, r3, ip, lr}           @ 4\n\
>> >       bne     1b                              @ "
>> >       : "+&r" (from), "+&r" (to), "=&r" (tmp)
>> >       : "2" (PAGE_SIZE / 64)
>> > diff --git a/arch/arm/mm/copypage-v4wb.c b/arch/arm/mm/copypage-v4wb.c
>> > index cd3e165afeed..6e3c9b69dd25 100644
>> > --- a/arch/arm/mm/copypage-v4wb.c
>> > +++ b/arch/arm/mm/copypage-v4wb.c
>> > @@ -38,7 +38,7 @@ static void v4wb_copy_user_page(void *kto, const void 
>> > *kfrom)
>> >       ldmia   %1!, {r3, r4, ip, lr}           @ 4\n\
>> >       subs    %2, %2, #1                      @ 1\n\
>> >       stmia   %0!, {r3, r4, ip, lr}           @ 4\n\
>> > -     ldmneia %1!, {r3, r4, ip, lr}           @ 4\n\
>> > +     ldmiane %1!, {r3, r4, ip, lr}           @ 4\n\
>> >       bne     1b                              @ 1\n\
>> >       mcr     p15, 0, %1, c7, c10, 4          @ 1   drain WB"
>> >       : "+&r" (kto), "+&r" (kfrom), "=&r" (tmp)
>> > diff --git a/arch/arm/mm/copypage-v4wt.c b/arch/arm/mm/copypage-v4wt.c
>> > index 8614572e1296..4a40fa1cbc2a 100644
>> > --- a/arch/arm/mm/copypage-v4wt.c
>> > +++ b/arch/arm/mm/copypage-v4wt.c
>> > @@ -34,7 +34,7 @@ static void v4wt_copy_user_page(void *kto, const void 
>> > *kfrom)
>> >       ldmia   %1!, {r3, r4, ip, lr}           @ 4\n\
>> >       subs    %2, %2, #1                      @ 1\n\
>> >       stmia   %0!, {r3, r4, ip, lr}           @ 4\n\
>> > -     ldmneia %1!, {r3, r4, ip, lr}           @ 4\n\
>> > +     ldmiane %1!, {r3, r4, ip, lr}           @ 4\n\
>> >       bne     1b                              @ 1\n\
>> >       mcr     p15, 0, %2, c7, c7, 0           @ flush ID cache"
>> >       : "+&r" (kto), "+&r" (kfrom), "=&r" (tmp)
>>
>> When compiling with gcc, this leads to:
>>
>> /tmp/ccrvA1wy.s: Assembler messages:
>> /tmp/ccrvA1wy.s:180: Error: bad instruction `ldmiane r0!,{r3,r4,ip,lr}'
>> make[1]: *** [scripts/Makefile.build:277: arch/arm/mm/copypage-v4wb.o]
>> Error 1
>> make: *** [Makefile:1042: arch/arm/mm] Error 2
>>
>> Unfortunately, the gcc option -masm-syntax-unified which allows unified
>> syntax in inline assembly is broken (see also
>> https://lkml.org/lkml/2019/1/7/1320).
>>
>> So this requires to sprinkle those inline assembly with ".syntax
>> unified" strings, similar to how I've done it in uaccess.h.
> 
> Not sure if this is purely a bug in GCC; Clang treats inline asm
> statements as unique, so asm directives do not carry over from one
> inline asm statement to another.  This has caused issues in other
> arch's inline assembly, where we need to repeat asm directives
> repeatedly for each inline asm statement.
> https://bugs.llvm.org/show_bug.cgi?id=19749

I don't think that this Clang bug is related.

GCC always emits a ".syntax xxx". The -masm-syntax-unified flag allows
to select unified syntax, but it is broken in current GCC releases. I
reported the bug and sent a fix to the GCC community, the upcoming GCC
9, as well as 7 and 8 bugfix releases, will have it fixed.

See:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88648

--
Stefan

Reply via email to