[linux-next:master 7032/8629] arch/powerpc/kernel/vdso32/gettimeofday.S:40: Error: syntax error; found `@', expected `,'

[kernel test robot]

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 <l...@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@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@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 <pau...@samba.org>
:::::: CC: Benjamin Herrenschmidt <be...@kernel.crashing.org>

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuil...@lists.01.org

[Christophe Leroy]

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.

> 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.

Christophe

[Segher Boessenkool]

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.

> >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?


Segher

[Nick Desaulniers]

On Tue, Sep 22, 2020 at 9:37 AM Segher Boessenkool
<seg...@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

[Segher Boessenkool]

On Tue, Sep 22, 2020 at 11:24:28AM -0700, Nick Desaulniers wrote:
> On Tue, Sep 22, 2020 at 9:37 AM Segher Boessenkool
> <seg...@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

[Fāng-ruì Sòng]

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.

[Segher Boessenkool]

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
> <seg...@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.

> 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.

> 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

[Fāng-ruì Sòng]

On Tue, Sep 22, 2020 at 4:32 PM Segher Boessenkool

<seg...@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
> > <seg...@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.

[Nick Desaulniers]

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@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

[Nick Desaulniers]

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

[Segher Boessenkool]

On Wed, Sep 23, 2020 at 12:26:27PM -0700, Fāng-ruì Sòng wrote:
> On Tue, Sep 22, 2020 at 4:32 PM Segher Boessenkool

> > 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
> > > <seg...@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" :)

powerpc64 (and powerpc64le) are completely separate ABIs! *Nothing* is
inherited.

(Not replying to the rest; if you do not want to implement correct
32-bit support, that is fine with me.)


Segher

[Segher Boessenkool]

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).


Segher

[Nick Desaulniers]

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