All of lore.kernel.org
 help / color / mirror / Atom feed
* Re: [linux-next:master 7032/8629] arch/powerpc/kernel/vdso32/gettimeofday.S:40: Error: syntax error; found `@', expected `,'
       [not found] <20200922232956.GO28786@gate.crashing.org>
@ 2020-09-23 19:26 ` Fāng-ruì Sòng
  2020-09-23 20:43   ` Nick Desaulniers
  0 siblings, 1 reply; 7+ messages in thread
From: Fāng-ruì Sòng @ 2020-09-23 19:26 UTC (permalink / raw)
  To: kbuild-all

[-- Attachment #1: Type: text/plain, Size: 2750 bytes --]

On Tue, Sep 22, 2020 at 4:32 PM Segher Boessenkool
<segher@kernel.crashing.org> wrote:
>
> Hi!
>
> On Tue, Sep 22, 2020 at 03:51:12PM -0700, Fāng-ruì Sòng wrote:
> > On Tue, Sep 22, 2020 at 2:55 PM Segher Boessenkool
> > <segher@kernel.crashing.org> wrote:
> > > This is the 32-bit @local relocation; its history predates binutils CVS
> > > (so older than 1999).  It is the same as @local24pc (which is documented
> > > in even the oldest ABI documents).  It *uses* the GOT (or PLT).
> > >
> > > If you do have @local24pc, just add an alias @local for it?
> >
> > R_PPC_LOCAL24PC is a legacy thing.
>
> I have no idea what you call "legacy".  It is very much an active
> feature.

R_PPC_LOCAL24PC and R_PPC_PLTREL24 are not inherited by ppc64. That is
a pretty good sign that they are "legacy" :)

> > GCC appears to emit it when
> > referencing hidden/internal/local symbols.
>
> GCC uses it for PIC (and other things).
>
> > It was invented probably
> > because a couple of decades ago people think having relocation types
> > to encode symbol properties was a good idea.
>
> It *had* to be invented.  The ABIs clearly say what it does, and no
> other mechanism provide for that.  It has nothing to do with symbol
> properties.

They may have overloaded edge-case semantics in binutils but their
general purpose use cases aren't any different from _REL24.

> > This is not useful
> > because symbol information can change when merging information from
> > other translation units (a default visibility can become hidden). Such
> > properties are really the symbols', and not the relocation types'.
> > ppc64 has unified R_PPC_LOCAL24PC/R_PPC_REL24/R_PPC_PLTREL24.
>
> It is not clear to me what you are saying here.
>
> > When I implemented R_PPC_LOCAL24PC for LLD
> > (https://reviews.llvm.org/D62464 ) I simply treated it as an alias for
> > R_PPC_REL24.
>
> But it very obviously is *not*.  It might not matter for the one use
> case you wanted to support, of course.
>
> In any case, you should implement @local as well?  That is used as an
> alias to @local24pc for over twenty years now.
>
> > It is clear that LLVM integrated assembler needs to support @local24pc
> > .... There isn't even a test case in binutils-gdb.
> >
> > If there is a @local24pc use case, just change it to @local. The
> > suffix can probably be deleted as well.
>
> If you want to claim to support the older ABIs, you need to implement
> support for them.
>
>
> Segher

clang ppc32 supports @local and LLD supports R_PPC_LOCAL24PC, which
are sufficient. Even GNU as does not have a test for @local24pc and I
cannot find usage in the wild, so clang probably does not need to
support @local24pc.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [linux-next:master 7032/8629] arch/powerpc/kernel/vdso32/gettimeofday.S:40: Error: syntax error; found `@', expected `,'
  2020-09-23 19:26 ` [linux-next:master 7032/8629] arch/powerpc/kernel/vdso32/gettimeofday.S:40: Error: syntax error; found `@', expected `,' Fāng-ruì Sòng
@ 2020-09-23 20:43   ` Nick Desaulniers
  2020-09-23 23:54     ` Nick Desaulniers
  0 siblings, 1 reply; 7+ messages in thread
From: Nick Desaulniers @ 2020-09-23 20:43 UTC (permalink / raw)
  To: kbuild-all

[-- Attachment #1: Type: text/plain, Size: 6732 bytes --]

On Wed, Sep 23, 2020 at 12:26 PM Fāng-ruì Sòng <maskray@google.com> wrote:
>
> On Tue, Sep 22, 2020 at 4:32 PM Segher Boessenkool
> <segher@kernel.crashing.org> wrote:
> >
> > Hi!
> >
> > On Tue, Sep 22, 2020 at 03:51:12PM -0700, Fāng-ruì Sòng wrote:
> > > On Tue, Sep 22, 2020 at 2:55 PM Segher Boessenkool
> > > <segher@kernel.crashing.org> wrote:
> > > > This is the 32-bit @local relocation; its history predates binutils CVS
> > > > (so older than 1999).  It is the same as @local24pc (which is documented
> > > > in even the oldest ABI documents).  It *uses* the GOT (or PLT).
> > > >
> > > > If you do have @local24pc, just add an alias @local for it?
> > >
> > > R_PPC_LOCAL24PC is a legacy thing.
> >
> > I have no idea what you call "legacy".  It is very much an active
> > feature.
>
> R_PPC_LOCAL24PC and R_PPC_PLTREL24 are not inherited by ppc64. That is
> a pretty good sign that they are "legacy" :)
>
> > > GCC appears to emit it when
> > > referencing hidden/internal/local symbols.
> >
> > GCC uses it for PIC (and other things).
> >
> > > It was invented probably
> > > because a couple of decades ago people think having relocation types
> > > to encode symbol properties was a good idea.
> >
> > It *had* to be invented.  The ABIs clearly say what it does, and no
> > other mechanism provide for that.  It has nothing to do with symbol
> > properties.
>
> They may have overloaded edge-case semantics in binutils but their
> general purpose use cases aren't any different from _REL24.
>
> > > This is not useful
> > > because symbol information can change when merging information from
> > > other translation units (a default visibility can become hidden). Such
> > > properties are really the symbols', and not the relocation types'.
> > > ppc64 has unified R_PPC_LOCAL24PC/R_PPC_REL24/R_PPC_PLTREL24.
> >
> > It is not clear to me what you are saying here.
> >
> > > When I implemented R_PPC_LOCAL24PC for LLD
> > > (https://reviews.llvm.org/D62464 ) I simply treated it as an alias for
> > > R_PPC_REL24.
> >
> > But it very obviously is *not*.  It might not matter for the one use
> > case you wanted to support, of course.
> >
> > In any case, you should implement @local as well?  That is used as an
> > alias to @local24pc for over twenty years now.
> >
> > > It is clear that LLVM integrated assembler needs to support @local24pc
> > > .... There isn't even a test case in binutils-gdb.
> > >
> > > If there is a @local24pc use case, just change it to @local. The
> > > suffix can probably be deleted as well.
> >
> > If you want to claim to support the older ABIs, you need to implement
> > support for them.
> >
> >
> > Segher
>
> clang ppc32 supports @local and LLD supports R_PPC_LOCAL24PC, which
> are sufficient. Even GNU as does not have a test for @local24pc and I
> cannot find usage in the wild, so clang probably does not need to
> support @local24pc.

I just fetched the config and can reproduce via:
$ ARCH=powerpc CROSS_COMPILE=powerpc64le-linux-gnu- make CC=clang -j71
arch/powerpc/kernel/vdso32/gettimeofday.o

Adding `V=1` to the above, I see:

clang -Wp,-MMD,arch/powerpc/kernel/vdso32/.gettimeofday.o.d  -nostdinc
-isystem /android0/llvm-project/llvm/build/lib/clang/12.0.0/include
-I./arch/powerpc/include -I./arch/powerpc/include/generated
-I./include -I./arch/powerpc/include/uapi
-I./arch/powerpc/include/generated/uapi -I./include/uapi
-I./include/generated/uapi -include ./include/linux/kconfig.h
-D__KERNEL__ -I ./arch/powerpc -DHAVE_AS_ATHIGH=1 -Qunused-arguments
-D__ASSEMBLY__ -fno-PIE --target=powerpc64le-linux-gnu
--prefix=/usr/bin/powerpc64le-linux-gnu- --gcc-toolchain=/usr
-no-integrated-as -Werror=unknown-warning-option -m64 -Wl,-a64
-Wa,-maltivec -Wa,-mpower4 -Wa,-many -mlittle-endian -Wa,-gdwarf-2
-D__VDSO32__ -s     -m32 -c -o
arch/powerpc/kernel/vdso32/gettimeofday.o
arch/powerpc/kernel/vdso32/gettimeofday.S

(so I was wrong about -no-integrated-as)

I wonder if we need to be setting --target=powerpc-linux-gnu instead?
Maybe the -m32 isn't being forwarded to the assembler?  Or is there an
assembler directive we can use to tell the assembler that this should
be assembled in 32b mode? (looks like no:
https://sourceware.org/binutils/docs/as/PowerPC_002dPseudo.html#PowerPC_002dPseudo)

```
foo:
  bl bar(a)local

bar:
```
assembles with powerpc-linux-gnu-as but fails with the error message
we observe for powerpc64le-linux-gnu-as. (I'm pretty sure we had
similar issues with the compat vdso on arm64).

ah, `-a32` will put the assembler in 32b mode.  I'm guessing gcc maybe
adds this implicitly for `-m32`?

```
diff --git a/arch/powerpc/kernel/vdso32/Makefile
b/arch/powerpc/kernel/vdso32/Makefile
index 73eada6bc8cd..c29d948f45e3 100644
--- a/arch/powerpc/kernel/vdso32/Makefile
+++ b/arch/powerpc/kernel/vdso32/Makefile
@@ -26,7 +26,7 @@ UBSAN_SANITIZE := n

 ccflags-y := -shared -fno-common -fno-builtin -nostdlib \
        -Wl,-soname=linux-vdso32.so.1 -Wl,--hash-style=both
-asflags-y := -D__VDSO32__ -s
+asflags-y := -D__VDSO32__ -s -Wa,-a32

 obj-y += vdso32_wrapper.o
 targets += vdso32.lds
```
gets us a little further, but then I observe additional failures:
```
  VDSO32A arch/powerpc/kernel/vdso32/gettimeofday.o
arch/powerpc/kernel/vdso32/gettimeofday.S: Assembler messages:
arch/powerpc/kernel/vdso32/gettimeofday.S:39: Error: operand out of
range (0x00000000000f4240 is not between 0xffffffffffff8000 and
0x000000000000ffff)
arch/powerpc/kernel/vdso32/gettimeofday.S:39: Error: syntax error;
found `@', expected `,'
arch/powerpc/kernel/vdso32/gettimeofday.S:39: Error: junk at end of
line: `@high'
arch/powerpc/kernel/vdso32/gettimeofday.S:83: Error: operand out of
range (0x000000003b9aca00 is not between 0xffffffffffff8000 and
0x000000000000ffff)
arch/powerpc/kernel/vdso32/gettimeofday.S:83: Error: syntax error;
found `@', expected `,'
arch/powerpc/kernel/vdso32/gettimeofday.S:83: Error: junk at end of
line: `@high'
arch/powerpc/kernel/vdso32/gettimeofday.S:203: Error: operand out of
range (0x00000000003d0900 is not between 0xffffffffffff8000 and
0x000000000000ffff)
arch/powerpc/kernel/vdso32/gettimeofday.S:203: Error: syntax error;
found `@', expected `,'
arch/powerpc/kernel/vdso32/gettimeofday.S:203: Error: junk at end of
line: `@high'
clang-12: error: assembler command failed with exit code 1 (use -v to
see invocation)
make[3]: *** [arch/powerpc/kernel/vdso32/Makefile:49:
arch/powerpc/kernel/vdso32/gettimeofday.o] Error 1
```
That's preprocessed in, but looks like support for @high is missing
from clang as well.
-- 
Thanks,
~Nick Desaulniers

^ permalink raw reply related	[flat|nested] 7+ messages in thread

* Re: [linux-next:master 7032/8629] arch/powerpc/kernel/vdso32/gettimeofday.S:40: Error: syntax error; found `@', expected `,'
  2020-09-23 20:43   ` Nick Desaulniers
@ 2020-09-23 23:54     ` Nick Desaulniers
  0 siblings, 0 replies; 7+ messages in thread
From: Nick Desaulniers @ 2020-09-23 23:54 UTC (permalink / raw)
  To: kbuild-all

[-- Attachment #1: Type: text/plain, Size: 4512 bytes --]

On Wed, Sep 23, 2020 at 1:43 PM Nick Desaulniers
<ndesaulniers@google.com> wrote:
>
> I just fetched the config and can reproduce via:
> $ ARCH=powerpc CROSS_COMPILE=powerpc64le-linux-gnu- make CC=clang -j71
> arch/powerpc/kernel/vdso32/gettimeofday.o
>
> Adding `V=1` to the above, I see:
>
> clang -Wp,-MMD,arch/powerpc/kernel/vdso32/.gettimeofday.o.d  -nostdinc
> -isystem /android0/llvm-project/llvm/build/lib/clang/12.0.0/include
> -I./arch/powerpc/include -I./arch/powerpc/include/generated
> -I./include -I./arch/powerpc/include/uapi
> -I./arch/powerpc/include/generated/uapi -I./include/uapi
> -I./include/generated/uapi -include ./include/linux/kconfig.h
> -D__KERNEL__ -I ./arch/powerpc -DHAVE_AS_ATHIGH=1 -Qunused-arguments
> -D__ASSEMBLY__ -fno-PIE --target=powerpc64le-linux-gnu
> --prefix=/usr/bin/powerpc64le-linux-gnu- --gcc-toolchain=/usr
> -no-integrated-as -Werror=unknown-warning-option -m64 -Wl,-a64
> -Wa,-maltivec -Wa,-mpower4 -Wa,-many -mlittle-endian -Wa,-gdwarf-2
> -D__VDSO32__ -s     -m32 -c -o
> arch/powerpc/kernel/vdso32/gettimeofday.o
> arch/powerpc/kernel/vdso32/gettimeofday.S
>
> (so I was wrong about -no-integrated-as)
>
> I wonder if we need to be setting --target=powerpc-linux-gnu instead?
> Maybe the -m32 isn't being forwarded to the assembler?  Or is there an
> assembler directive we can use to tell the assembler that this should
> be assembled in 32b mode? (looks like no:
> https://sourceware.org/binutils/docs/as/PowerPC_002dPseudo.html#PowerPC_002dPseudo)
>
> ```
> foo:
>   bl bar(a)local
>
> bar:
> ```
> assembles with powerpc-linux-gnu-as but fails with the error message
> we observe for powerpc64le-linux-gnu-as. (I'm pretty sure we had
> similar issues with the compat vdso on arm64).
>
> ah, `-a32` will put the assembler in 32b mode.  I'm guessing gcc maybe
> adds this implicitly for `-m32`?
>
> ```
> diff --git a/arch/powerpc/kernel/vdso32/Makefile
> b/arch/powerpc/kernel/vdso32/Makefile
> index 73eada6bc8cd..c29d948f45e3 100644
> --- a/arch/powerpc/kernel/vdso32/Makefile
> +++ b/arch/powerpc/kernel/vdso32/Makefile
> @@ -26,7 +26,7 @@ UBSAN_SANITIZE := n
>
>  ccflags-y := -shared -fno-common -fno-builtin -nostdlib \
>         -Wl,-soname=linux-vdso32.so.1 -Wl,--hash-style=both
> -asflags-y := -D__VDSO32__ -s
> +asflags-y := -D__VDSO32__ -s -Wa,-a32
>
>  obj-y += vdso32_wrapper.o
>  targets += vdso32.lds
> ```
> gets us a little further, but then I observe additional failures:
> ```
>   VDSO32A arch/powerpc/kernel/vdso32/gettimeofday.o
> arch/powerpc/kernel/vdso32/gettimeofday.S: Assembler messages:
> arch/powerpc/kernel/vdso32/gettimeofday.S:39: Error: operand out of
> range (0x00000000000f4240 is not between 0xffffffffffff8000 and
> 0x000000000000ffff)
> arch/powerpc/kernel/vdso32/gettimeofday.S:39: Error: syntax error;
> found `@', expected `,'
> arch/powerpc/kernel/vdso32/gettimeofday.S:39: Error: junk at end of
> line: `@high'
> arch/powerpc/kernel/vdso32/gettimeofday.S:83: Error: operand out of
> range (0x000000003b9aca00 is not between 0xffffffffffff8000 and
> 0x000000000000ffff)
> arch/powerpc/kernel/vdso32/gettimeofday.S:83: Error: syntax error;
> found `@', expected `,'
> arch/powerpc/kernel/vdso32/gettimeofday.S:83: Error: junk at end of
> line: `@high'
> arch/powerpc/kernel/vdso32/gettimeofday.S:203: Error: operand out of
> range (0x00000000003d0900 is not between 0xffffffffffff8000 and
> 0x000000000000ffff)
> arch/powerpc/kernel/vdso32/gettimeofday.S:203: Error: syntax error;
> found `@', expected `,'
> arch/powerpc/kernel/vdso32/gettimeofday.S:203: Error: junk at end of
> line: `@high'
> clang-12: error: assembler command failed with exit code 1 (use -v to
> see invocation)
> make[3]: *** [arch/powerpc/kernel/vdso32/Makefile:49:
> arch/powerpc/kernel/vdso32/gettimeofday.o] Error 1
> ```
> That's preprocessed in, but looks like support for @high is missing
> from clang as well.

Hmmm...so the @high is coming from arch/powerpc/include/asm/ppc_asm.h:320

314 #if defined(__powerpc64__) && defined(HAVE_AS_ATHIGH)
315 #define __AS_ATHIGH high
316 #else
317 #define __AS_ATHIGH h
318 #endif
319
320 .macro __LOAD_REG_IMMEDIATE_32 r, x
321   .if (\x) >= 0x8000 || (\x) < -0x8000
322     lis \r, (\x)@__AS_ATHIGH

So we're #defining __powerpc64__ because of the
--target=powerpc64le-linux-gnu, but then trying to assemble this in
32b mode since it's a compat vdso?
-- 
Thanks,
~Nick Desaulniers

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [linux-next:master 7032/8629] arch/powerpc/kernel/vdso32/gettimeofday.S:40: Error: syntax error; found `@', expected `,'
       [not found] <20200924003055.GZ28786@gate.crashing.org>
@ 2020-09-24 20:40 ` Nick Desaulniers
  0 siblings, 0 replies; 7+ messages in thread
From: Nick Desaulniers @ 2020-09-24 20:40 UTC (permalink / raw)
  To: kbuild-all

[-- Attachment #1: Type: text/plain, Size: 898 bytes --]

On Wed, Sep 23, 2020 at 5:33 PM Segher Boessenkool
<segher@kernel.crashing.org> wrote:
>
> On Wed, Sep 23, 2020 at 01:43:18PM -0700, Nick Desaulniers wrote:
> > I wonder if we need to be setting --target=powerpc-linux-gnu instead?
>
> Yes, probably.
>
> > ah, `-a32` will put the assembler in 32b mode.  I'm guessing gcc maybe
> > adds this implicitly for `-m32`?
>
> For Linux and many other systems, yes (if it isn't the default, etc).

Now I'm curious if this behavior works in Clang for x86...does the
target triple used internally change when -m32 is specified?  If so, I
wonder if Clang doesn't do the same thing for PPC maybe.

For now, I'll just send a patch marking the relevant config as broken
or "un-selectable" when CC_IS_CLANG with a TODO until we have more
time to sort this out; that way the CI will stop harassing folks over
it.
-- 
Thanks,
~Nick Desaulniers

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [linux-next:master 7032/8629] arch/powerpc/kernel/vdso32/gettimeofday.S:40: Error: syntax error; found `@', expected `,'
       [not found] <20200922215325.GM28786@gate.crashing.org>
@ 2020-09-22 22:51 ` Fāng-ruì Sòng
  0 siblings, 0 replies; 7+ messages in thread
From: Fāng-ruì Sòng @ 2020-09-22 22:51 UTC (permalink / raw)
  To: kbuild-all

[-- Attachment #1: Type: text/plain, Size: 2218 bytes --]

On Tue, Sep 22, 2020 at 2:55 PM Segher Boessenkool
<segher@kernel.crashing.org> wrote:
>
> On Tue, Sep 22, 2020 at 11:24:28AM -0700, Nick Desaulniers wrote:
> > On Tue, Sep 22, 2020 at 9:37 AM Segher Boessenkool
> > <segher@kernel.crashing.org> wrote:
> > > Yes, and @local isn't new either.
> >
> > The first issue is that arch/powerpc/kernel/vdso32/Makefile resets the
> > cflags that we very carefully constructed in the top level Makefile.
>
> Or, it could be said you are relying on no one else daring to touch a
> generic variable ;-)
>
> > > > A new clang issue ? This code has been there for years and been building
> > > > with success with GNU tools.
> > >
> > > Does the clang integrated assembler handle embedded relocations at all?
> >
> > I believe so, but each ISA may have different levels of support for
> > all of the different possible relocation types.  TBH, I have not yet
> > tested Clang's integrated assembler with PPC.  These are to avoid GOT
> > indirection?
>
> This is the 32-bit @local relocation; its history predates binutils CVS
> (so older than 1999).  It is the same as @local24pc (which is documented
> in even the oldest ABI documents).  It *uses* the GOT (or PLT).
>
> If you do have @local24pc, just add an alias @local for it?
>
>
> Segher

R_PPC_LOCAL24PC is a legacy thing. GCC appears to emit it when
referencing hidden/internal/local symbols. It was invented probably
because a couple of decades ago people think having relocation types
to encode symbol properties was a good idea. This is not useful
because symbol information can change when merging information from
other translation units (a default visibility can become hidden). Such
properties are really the symbols', and not the relocation types'.
ppc64 has unified R_PPC_LOCAL24PC/R_PPC_REL24/R_PPC_PLTREL24.

When I implemented R_PPC_LOCAL24PC for LLD
(https://reviews.llvm.org/D62464 ) I simply treated it as an alias for
R_PPC_REL24.

It is clear that LLVM integrated assembler needs to support @local24pc
.... There isn't even a test case in binutils-gdb.

If there is a @local24pc use case, just change it to @local. The
suffix can probably be deleted as well.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [linux-next:master 7032/8629] arch/powerpc/kernel/vdso32/gettimeofday.S:40: Error: syntax error; found `@', expected `,'
       [not found] <20200922163519.GL28786@gate.crashing.org>
@ 2020-09-22 18:24 ` Nick Desaulniers
  0 siblings, 0 replies; 7+ messages in thread
From: Nick Desaulniers @ 2020-09-22 18:24 UTC (permalink / raw)
  To: kbuild-all

[-- Attachment #1: Type: text/plain, Size: 2296 bytes --]

On Tue, Sep 22, 2020 at 9:37 AM Segher Boessenkool
<segher@kernel.crashing.org> wrote:
>
> On Tue, Sep 22, 2020 at 06:46:04AM +0200, Christophe Leroy wrote:
> > Hi Nick,
> >
> > Le 17/09/2020 à 21:56, kernel test robot a écrit :
> > >Hi Michael,
> > >
> > >First bad commit (maybe != root cause):
> > >
> > >tree:
> > >https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
> > >head:   860461e4fcaa76200d2d1a53523e0ff7be92e6e8
> > >commit: 231b232df8f67e7d37af01259c21f2a131c3911e [7032/8629] powerpc/64:
> > >Make VDSO32 track COMPAT on 64-bit
> >
> > Definitely not the root cause. That code has been there for years.
>
> Yes, and @local isn't new either.

The first issue is that arch/powerpc/kernel/vdso32/Makefile resets the
cflags that we very carefully constructed in the top level Makefile.
This is a common issue faced by building the kernel with clang.  As
such, the flag `-no-integrated-as` gets dropped, which would have told
Clang not to use its integrated assembler and to instead fork out to
GNU as.  Something like this (but for the 64b VDSO, too) would fix it:

diff --git a/arch/powerpc/kernel/vdso32/Makefile
b/arch/powerpc/kernel/vdso32/Makefile
index 73eada6bc8cd..9aabcbce19cd 100644
--- a/arch/powerpc/kernel/vdso32/Makefile
+++ b/arch/powerpc/kernel/vdso32/Makefile
@@ -28,6 +28,10 @@ ccflags-y := -shared -fno-common -fno-builtin -nostdlib \
        -Wl,-soname=linux-vdso32.so.1 -Wl,--hash-style=both
 asflags-y := -D__VDSO32__ -s

+ifdef CC_IS_CLANG
+ccflags-y += -no-integrated-as
+endif
+

Would probably want to gate that on !LLVM_IAS, too, though.

>
> > >config: powerpc64-randconfig-r035-20200917 (attached as .config)
> > >compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project
> > >1321160a26e7e489baf9b10d6de90a342f898960)
> >
> > A new clang issue ? This code has been there for years and been building
> > with success with GNU tools.
>
> Does the clang integrated assembler handle embedded relocations at all?

I believe so, but each ISA may have different levels of support for
all of the different possible relocation types.  TBH, I have not yet
tested Clang's integrated assembler with PPC.  These are to avoid GOT
indirection?
-- 
Thanks,
~Nick Desaulniers

^ permalink raw reply related	[flat|nested] 7+ messages in thread

* [linux-next:master 7032/8629] arch/powerpc/kernel/vdso32/gettimeofday.S:40: Error: syntax error; found `@', expected `,'
@ 2020-09-17 19:56 kernel test robot
  0 siblings, 0 replies; 7+ messages in thread
From: kernel test robot @ 2020-09-17 19:56 UTC (permalink / raw)
  To: kbuild-all

[-- Attachment #1: Type: text/plain, Size: 16066 bytes --]

Hi Michael,

First bad commit (maybe != root cause):

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
head:   860461e4fcaa76200d2d1a53523e0ff7be92e6e8
commit: 231b232df8f67e7d37af01259c21f2a131c3911e [7032/8629] powerpc/64: Make VDSO32 track COMPAT on 64-bit
config: powerpc64-randconfig-r035-20200917 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project 1321160a26e7e489baf9b10d6de90a342f898960)
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # install powerpc64 cross compiling tool for clang build
        # apt-get install binutils-powerpc64-linux-gnu
        git checkout 231b232df8f67e7d37af01259c21f2a131c3911e
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=powerpc64 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>

All error/warnings (new ones prefixed by >>):

   arch/powerpc/kernel/vdso32/gettimeofday.S: Assembler messages:
>> arch/powerpc/kernel/vdso32/gettimeofday.S:40: Error: syntax error; found `@', expected `,'
>> arch/powerpc/kernel/vdso32/gettimeofday.S:40: Error: junk at end of line: `@local'
>> arch/powerpc/kernel/vdso32/gettimeofday.S:68: Warning: invalid register expression
>> arch/powerpc/kernel/vdso32/gettimeofday.S:68: Error: operand out of range (3 is not between 0 and 1)
   arch/powerpc/kernel/vdso32/gettimeofday.S:68: Error: missing operand
   arch/powerpc/kernel/vdso32/gettimeofday.S:69: Warning: invalid register expression
   arch/powerpc/kernel/vdso32/gettimeofday.S:69: Error: operand out of range (3 is not between 0 and 1)
   arch/powerpc/kernel/vdso32/gettimeofday.S:69: Error: missing operand
   arch/powerpc/kernel/vdso32/gettimeofday.S:72: Warning: invalid register expression
   arch/powerpc/kernel/vdso32/gettimeofday.S:72: Error: operand out of range (3 is not between 0 and 1)
   arch/powerpc/kernel/vdso32/gettimeofday.S:72: Error: missing operand
   arch/powerpc/kernel/vdso32/gettimeofday.S:73: Warning: invalid register expression
   arch/powerpc/kernel/vdso32/gettimeofday.S:73: Error: operand out of range (3 is not between 0 and 1)
   arch/powerpc/kernel/vdso32/gettimeofday.S:73: Error: missing operand
   arch/powerpc/kernel/vdso32/gettimeofday.S:86: Error: syntax error; found `@', expected `,'
   arch/powerpc/kernel/vdso32/gettimeofday.S:86: Error: junk at end of line: `@local'
   arch/powerpc/kernel/vdso32/gettimeofday.S:110: Warning: invalid register expression
   arch/powerpc/kernel/vdso32/gettimeofday.S:110: Error: operand out of range (8 is not between 0 and 1)
   arch/powerpc/kernel/vdso32/gettimeofday.S:110: Error: missing operand
   arch/powerpc/kernel/vdso32/gettimeofday.S:144: Warning: invalid register expression
   arch/powerpc/kernel/vdso32/gettimeofday.S:144: Error: missing operand
   arch/powerpc/kernel/vdso32/gettimeofday.S:213: Warning: invalid register expression
   arch/powerpc/kernel/vdso32/gettimeofday.S:213: Error: operand out of range (4 is not between 0 and 1)
   arch/powerpc/kernel/vdso32/gettimeofday.S:213: Error: missing operand
   clang-12: error: assembler command failed with exit code 1 (use -v to see invocation)

# https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=231b232df8f67e7d37af01259c21f2a131c3911e
git remote add linux-next https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
git fetch --no-tags linux-next master
git checkout 231b232df8f67e7d37af01259c21f2a131c3911e
vim +40 arch/powerpc/kernel/vdso32/gettimeofday.S

597bc5c00b666f Paul Mackerras         2008-10-27   22  
a7f290dad32ee3 Benjamin Herrenschmidt 2005-11-11   23  	.text
a7f290dad32ee3 Benjamin Herrenschmidt 2005-11-11   24  /*
a7f290dad32ee3 Benjamin Herrenschmidt 2005-11-11   25   * Exact prototype of gettimeofday
a7f290dad32ee3 Benjamin Herrenschmidt 2005-11-11   26   *
a7f290dad32ee3 Benjamin Herrenschmidt 2005-11-11   27   * int __kernel_gettimeofday(struct timeval *tv, struct timezone *tz);
a7f290dad32ee3 Benjamin Herrenschmidt 2005-11-11   28   *
a7f290dad32ee3 Benjamin Herrenschmidt 2005-11-11   29   */
a7f290dad32ee3 Benjamin Herrenschmidt 2005-11-11   30  V_FUNCTION_BEGIN(__kernel_gettimeofday)
a7f290dad32ee3 Benjamin Herrenschmidt 2005-11-11   31    .cfi_startproc
a7f290dad32ee3 Benjamin Herrenschmidt 2005-11-11   32  	mflr	r12
a7f290dad32ee3 Benjamin Herrenschmidt 2005-11-11   33    .cfi_register lr,r12
a7f290dad32ee3 Benjamin Herrenschmidt 2005-11-11   34  
bfc2eae0ad72a4 Christophe Leroy       2019-12-02   35  	mr.	r10,r3			/* r10 saves tv */
a7f290dad32ee3 Benjamin Herrenschmidt 2005-11-11   36  	mr	r11,r4			/* r11 saves tz */
ec0895f08f9951 Christophe Leroy       2019-12-02   37  	get_datapage	r9, r0
74609f4536f2b8 Tony Breeds            2007-06-26   38  	beq	3f
6e2f9e9cfd560f Christophe Leroy       2019-12-02   39  	LOAD_REG_IMMEDIATE(r7, 1000000)	/* load up USEC_PER_SEC */
8fd63a9ea75284 Paul Mackerras         2010-06-20  @40  	bl	__do_get_tspec(a)local	/* get sec/usec from tb & kernel */
8fd63a9ea75284 Paul Mackerras         2010-06-20   41  	stw	r3,TVAL32_TV_SEC(r10)
8fd63a9ea75284 Paul Mackerras         2010-06-20   42  	stw	r4,TVAL32_TV_USEC(r10)
a7f290dad32ee3 Benjamin Herrenschmidt 2005-11-11   43  
74609f4536f2b8 Tony Breeds            2007-06-26   44  3:	cmplwi	r11,0			/* check if tz is NULL */
bfc2eae0ad72a4 Christophe Leroy       2019-12-02   45  	mtlr	r12
bfc2eae0ad72a4 Christophe Leroy       2019-12-02   46  	crclr	cr0*4+so
bfc2eae0ad72a4 Christophe Leroy       2019-12-02   47  	li	r3,0
bfc2eae0ad72a4 Christophe Leroy       2019-12-02   48  	beqlr
bfc2eae0ad72a4 Christophe Leroy       2019-12-02   49  
a7f290dad32ee3 Benjamin Herrenschmidt 2005-11-11   50  	lwz	r4,CFG_TZ_MINUTEWEST(r9)/* fill tz */
a7f290dad32ee3 Benjamin Herrenschmidt 2005-11-11   51  	lwz	r5,CFG_TZ_DSTTIME(r9)
a7f290dad32ee3 Benjamin Herrenschmidt 2005-11-11   52  	stw	r4,TZONE_TZ_MINWEST(r11)
a7f290dad32ee3 Benjamin Herrenschmidt 2005-11-11   53  	stw	r5,TZONE_TZ_DSTTIME(r11)
a7f290dad32ee3 Benjamin Herrenschmidt 2005-11-11   54  
a7f290dad32ee3 Benjamin Herrenschmidt 2005-11-11   55  	blr
a7f290dad32ee3 Benjamin Herrenschmidt 2005-11-11   56    .cfi_endproc
a7f290dad32ee3 Benjamin Herrenschmidt 2005-11-11   57  V_FUNCTION_END(__kernel_gettimeofday)
a7f290dad32ee3 Benjamin Herrenschmidt 2005-11-11   58  
a7f290dad32ee3 Benjamin Herrenschmidt 2005-11-11   59  /*
a7f290dad32ee3 Benjamin Herrenschmidt 2005-11-11   60   * Exact prototype of clock_gettime()
a7f290dad32ee3 Benjamin Herrenschmidt 2005-11-11   61   *
a7f290dad32ee3 Benjamin Herrenschmidt 2005-11-11   62   * int __kernel_clock_gettime(clockid_t clock_id, struct timespec *tp);
a7f290dad32ee3 Benjamin Herrenschmidt 2005-11-11   63   *
a7f290dad32ee3 Benjamin Herrenschmidt 2005-11-11   64   */
a7f290dad32ee3 Benjamin Herrenschmidt 2005-11-11   65  V_FUNCTION_BEGIN(__kernel_clock_gettime)
a7f290dad32ee3 Benjamin Herrenschmidt 2005-11-11   66    .cfi_startproc
a7f290dad32ee3 Benjamin Herrenschmidt 2005-11-11   67  	/* Check for supported clock IDs */
a7f290dad32ee3 Benjamin Herrenschmidt 2005-11-11  @68  	cmpli	cr0,r3,CLOCK_REALTIME
a7f290dad32ee3 Benjamin Herrenschmidt 2005-11-11   69  	cmpli	cr1,r3,CLOCK_MONOTONIC
0c37ec2aa88bd8 Benjamin Herrenschmidt 2005-11-14   70  	cror	cr0*4+eq,cr0*4+eq,cr1*4+eq
654abc69ef2e69 Christophe Leroy       2019-12-02   71  
654abc69ef2e69 Christophe Leroy       2019-12-02   72  	cmpli	cr5,r3,CLOCK_REALTIME_COARSE
654abc69ef2e69 Christophe Leroy       2019-12-02   73  	cmpli	cr6,r3,CLOCK_MONOTONIC_COARSE
654abc69ef2e69 Christophe Leroy       2019-12-02   74  	cror	cr5*4+eq,cr5*4+eq,cr6*4+eq
654abc69ef2e69 Christophe Leroy       2019-12-02   75  
654abc69ef2e69 Christophe Leroy       2019-12-02   76  	cror	cr0*4+eq,cr0*4+eq,cr5*4+eq
654abc69ef2e69 Christophe Leroy       2019-12-02   77  	bne	cr0, .Lgettime_fallback
a7f290dad32ee3 Benjamin Herrenschmidt 2005-11-11   78  
a7f290dad32ee3 Benjamin Herrenschmidt 2005-11-11   79  	mflr	r12			/* r12 saves lr */
a7f290dad32ee3 Benjamin Herrenschmidt 2005-11-11   80    .cfi_register lr,r12
a7f290dad32ee3 Benjamin Herrenschmidt 2005-11-11   81  	mr	r11,r4			/* r11 saves tp */
ec0895f08f9951 Christophe Leroy       2019-12-02   82  	get_datapage	r9, r0
6e2f9e9cfd560f Christophe Leroy       2019-12-02   83  	LOAD_REG_IMMEDIATE(r7, NSEC_PER_SEC)	/* load up NSEC_PER_SEC */
654abc69ef2e69 Christophe Leroy       2019-12-02   84  	beq	cr5, .Lcoarse_clocks
654abc69ef2e69 Christophe Leroy       2019-12-02   85  .Lprecise_clocks:
654abc69ef2e69 Christophe Leroy       2019-12-02   86  	bl	__do_get_tspec(a)local	/* get sec/nsec from tb & kernel */
654abc69ef2e69 Christophe Leroy       2019-12-02   87  	bne	cr1, .Lfinish		/* not monotonic -> all done */
a7f290dad32ee3 Benjamin Herrenschmidt 2005-11-11   88  
a7f290dad32ee3 Benjamin Herrenschmidt 2005-11-11   89  	/*
a7f290dad32ee3 Benjamin Herrenschmidt 2005-11-11   90  	 * CLOCK_MONOTONIC
a7f290dad32ee3 Benjamin Herrenschmidt 2005-11-11   91  	 */
a7f290dad32ee3 Benjamin Herrenschmidt 2005-11-11   92  
a7f290dad32ee3 Benjamin Herrenschmidt 2005-11-11   93  	/* now we must fixup using wall to monotonic. We need to snapshot
a7f290dad32ee3 Benjamin Herrenschmidt 2005-11-11   94  	 * that value and do the counter trick again. Fortunately, we still
a7f290dad32ee3 Benjamin Herrenschmidt 2005-11-11   95  	 * have the counter value in r8 that was returned by __do_get_xsec.
597bc5c00b666f Paul Mackerras         2008-10-27   96  	 * At this point, r3,r4 contain our sec/nsec values, r5 and r6
597bc5c00b666f Paul Mackerras         2008-10-27   97  	 * can be used, r7 contains NSEC_PER_SEC.
a7f290dad32ee3 Benjamin Herrenschmidt 2005-11-11   98  	 */
a7f290dad32ee3 Benjamin Herrenschmidt 2005-11-11   99  
dd9a994fc68d19 Christophe Leroy       2019-04-04  100  	lwz	r5,(WTOM_CLOCK_SEC+LOPART)(r9)
597bc5c00b666f Paul Mackerras         2008-10-27  101  	lwz	r6,WTOM_CLOCK_NSEC(r9)
a7f290dad32ee3 Benjamin Herrenschmidt 2005-11-11  102  
597bc5c00b666f Paul Mackerras         2008-10-27  103  	/* We now have our offset in r5,r6. We create a fake dependency
597bc5c00b666f Paul Mackerras         2008-10-27  104  	 * on that value and re-check the counter
a7f290dad32ee3 Benjamin Herrenschmidt 2005-11-11  105  	 */
597bc5c00b666f Paul Mackerras         2008-10-27  106  	or	r0,r6,r5
597bc5c00b666f Paul Mackerras         2008-10-27  107  	xor	r0,r0,r0
a7f290dad32ee3 Benjamin Herrenschmidt 2005-11-11  108  	add	r9,r9,r0
597bc5c00b666f Paul Mackerras         2008-10-27  109  	lwz	r0,(CFG_TB_UPDATE_COUNT+LOPART)(r9)
a7f290dad32ee3 Benjamin Herrenschmidt 2005-11-11  110          cmpl    cr0,r8,r0		/* check if updated */
654abc69ef2e69 Christophe Leroy       2019-12-02  111  	bne-	.Lprecise_clocks
654abc69ef2e69 Christophe Leroy       2019-12-02  112  	b	.Lfinish_monotonic
654abc69ef2e69 Christophe Leroy       2019-12-02  113  
654abc69ef2e69 Christophe Leroy       2019-12-02  114  	/*
654abc69ef2e69 Christophe Leroy       2019-12-02  115  	 * For coarse clocks we get data directly from the vdso data page, so
654abc69ef2e69 Christophe Leroy       2019-12-02  116  	 * we don't need to call __do_get_tspec, but we still need to do the
654abc69ef2e69 Christophe Leroy       2019-12-02  117  	 * counter trick.
654abc69ef2e69 Christophe Leroy       2019-12-02  118  	 */
654abc69ef2e69 Christophe Leroy       2019-12-02  119  .Lcoarse_clocks:
654abc69ef2e69 Christophe Leroy       2019-12-02  120  	lwz	r8,(CFG_TB_UPDATE_COUNT+LOPART)(r9)
654abc69ef2e69 Christophe Leroy       2019-12-02  121  	andi.	r0,r8,1                 /* pending update ? loop */
654abc69ef2e69 Christophe Leroy       2019-12-02  122  	bne-	.Lcoarse_clocks
654abc69ef2e69 Christophe Leroy       2019-12-02  123  	add	r9,r9,r0		/* r0 is already 0 */
654abc69ef2e69 Christophe Leroy       2019-12-02  124  
654abc69ef2e69 Christophe Leroy       2019-12-02  125  	/*
654abc69ef2e69 Christophe Leroy       2019-12-02  126  	 * CLOCK_REALTIME_COARSE, below values are needed for MONOTONIC_COARSE
654abc69ef2e69 Christophe Leroy       2019-12-02  127  	 * too
654abc69ef2e69 Christophe Leroy       2019-12-02  128  	 */
654abc69ef2e69 Christophe Leroy       2019-12-02  129  	lwz	r3,STAMP_XTIME_SEC+LOPART(r9)
654abc69ef2e69 Christophe Leroy       2019-12-02  130  	lwz	r4,STAMP_XTIME_NSEC+LOPART(r9)
654abc69ef2e69 Christophe Leroy       2019-12-02  131  	bne	cr6,1f
654abc69ef2e69 Christophe Leroy       2019-12-02  132  
654abc69ef2e69 Christophe Leroy       2019-12-02  133  	/* CLOCK_MONOTONIC_COARSE */
654abc69ef2e69 Christophe Leroy       2019-12-02  134  	lwz	r5,(WTOM_CLOCK_SEC+LOPART)(r9)
654abc69ef2e69 Christophe Leroy       2019-12-02  135  	lwz	r6,WTOM_CLOCK_NSEC(r9)
654abc69ef2e69 Christophe Leroy       2019-12-02  136  
654abc69ef2e69 Christophe Leroy       2019-12-02  137  	/* check if counter has updated */
654abc69ef2e69 Christophe Leroy       2019-12-02  138  	or	r0,r6,r5
654abc69ef2e69 Christophe Leroy       2019-12-02  139  1:	or	r0,r0,r3
654abc69ef2e69 Christophe Leroy       2019-12-02  140  	or	r0,r0,r4
654abc69ef2e69 Christophe Leroy       2019-12-02  141  	xor	r0,r0,r0
654abc69ef2e69 Christophe Leroy       2019-12-02  142  	add	r3,r3,r0
654abc69ef2e69 Christophe Leroy       2019-12-02  143  	lwz	r0,CFG_TB_UPDATE_COUNT+LOPART(r9)
654abc69ef2e69 Christophe Leroy       2019-12-02  144  	cmpl	cr0,r0,r8               /* check if updated */
654abc69ef2e69 Christophe Leroy       2019-12-02  145  	bne-	.Lcoarse_clocks
654abc69ef2e69 Christophe Leroy       2019-12-02  146  
654abc69ef2e69 Christophe Leroy       2019-12-02  147  	/* Counter has not updated, so continue calculating proper values for
654abc69ef2e69 Christophe Leroy       2019-12-02  148  	 * sec and nsec if monotonic coarse, or just return with the proper
654abc69ef2e69 Christophe Leroy       2019-12-02  149  	 * values for realtime.
654abc69ef2e69 Christophe Leroy       2019-12-02  150  	 */
654abc69ef2e69 Christophe Leroy       2019-12-02  151  	bne	cr6, .Lfinish
a7f290dad32ee3 Benjamin Herrenschmidt 2005-11-11  152  
597bc5c00b666f Paul Mackerras         2008-10-27  153  	/* Calculate and store result. Note that this mimics the C code,
a7f290dad32ee3 Benjamin Herrenschmidt 2005-11-11  154  	 * which may cause funny results if nsec goes negative... is that
a7f290dad32ee3 Benjamin Herrenschmidt 2005-11-11  155  	 * possible at all ?
a7f290dad32ee3 Benjamin Herrenschmidt 2005-11-11  156  	 */
654abc69ef2e69 Christophe Leroy       2019-12-02  157  .Lfinish_monotonic:
597bc5c00b666f Paul Mackerras         2008-10-27  158  	add	r3,r3,r5
597bc5c00b666f Paul Mackerras         2008-10-27  159  	add	r4,r4,r6
597bc5c00b666f Paul Mackerras         2008-10-27  160  	cmpw	cr0,r4,r7
597bc5c00b666f Paul Mackerras         2008-10-27  161  	cmpwi	cr1,r4,0
a7f290dad32ee3 Benjamin Herrenschmidt 2005-11-11  162  	blt	1f
597bc5c00b666f Paul Mackerras         2008-10-27  163  	subf	r4,r7,r4
a7f290dad32ee3 Benjamin Herrenschmidt 2005-11-11  164  	addi	r3,r3,1
654abc69ef2e69 Christophe Leroy       2019-12-02  165  1:	bge	cr1, .Lfinish
0c37ec2aa88bd8 Benjamin Herrenschmidt 2005-11-14  166  	addi	r3,r3,-1
597bc5c00b666f Paul Mackerras         2008-10-27  167  	add	r4,r4,r7
597bc5c00b666f Paul Mackerras         2008-10-27  168  

:::::: The code at line 40 was first introduced by commit
:::::: 8fd63a9ea7528463211a6c88d500c51851d960c8 powerpc: Rework VDSO gettimeofday to prevent time going backwards

:::::: TO: Paul Mackerras <paulus@samba.org>
:::::: CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org

[-- Attachment #2: config.gz --]
[-- Type: application/gzip, Size: 24662 bytes --]

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2020-09-24 20:40 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <20200922232956.GO28786@gate.crashing.org>
2020-09-23 19:26 ` [linux-next:master 7032/8629] arch/powerpc/kernel/vdso32/gettimeofday.S:40: Error: syntax error; found `@', expected `,' Fāng-ruì Sòng
2020-09-23 20:43   ` Nick Desaulniers
2020-09-23 23:54     ` Nick Desaulniers
     [not found] <20200924003055.GZ28786@gate.crashing.org>
2020-09-24 20:40 ` Nick Desaulniers
     [not found] <20200922215325.GM28786@gate.crashing.org>
2020-09-22 22:51 ` Fāng-ruì Sòng
     [not found] <20200922163519.GL28786@gate.crashing.org>
2020-09-22 18:24 ` Nick Desaulniers
2020-09-17 19:56 kernel test robot

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.