2018-10-31 06:49:14

by Olof Johansson

[permalink] [raw]
Subject: [PATCH 0/3] RISC-V: A few build/warning fixes and cleanup

A couple of fixes for build breakage or warnings, and a small whitespace/asm
cleanup. The non-cleanups would be good to see in 4.20 to keep builds green.


Thanks!

-Olof



2018-10-31 06:48:08

by Olof Johansson

[permalink] [raw]
Subject: [PATCH 1/3] RISC-V: lib: Fix build error for 64-bit

Fixes the following build error from tinyconfig:

riscv64-unknown-linux-gnu-ld: kernel/sched/fair.o: in function `.L8':
fair.c:(.text+0x70): undefined reference to `__lshrti3'
riscv64-unknown-linux-gnu-ld: kernel/time/clocksource.o: in function `.L0 ':
clocksource.c:(.text+0x334): undefined reference to `__lshrti3'

Fixes: 7f47c73b355f ("RISC-V: Build tishift only on 64-bit")
Signed-off-by: Olof Johansson <[email protected]>
---
arch/riscv/lib/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/riscv/lib/Makefile b/arch/riscv/lib/Makefile
index 5739bd05d289..4e2e600f7d53 100644
--- a/arch/riscv/lib/Makefile
+++ b/arch/riscv/lib/Makefile
@@ -3,6 +3,6 @@ lib-y += memcpy.o
lib-y += memset.o
lib-y += uaccess.o

-lib-(CONFIG_64BIT) += tishift.o
+lib-$(CONFIG_64BIT) += tishift.o

lib-$(CONFIG_32BIT) += udivdi3.o
--
2.11.0


2018-10-31 06:48:10

by Olof Johansson

[permalink] [raw]
Subject: [PATCH 3/3] RISC-V: Silence some module warnings on 32-bit

Fixes:

arch/riscv/kernel/module.c: In function 'apply_r_riscv_32_rela':
./include/linux/kern_levels.h:5:18: warning: format '%llx' expects argument of type 'long long unsigned int', but argument 3 has type 'Elf32_Addr' {aka 'unsigned int'} [-Wformat=]
arch/riscv/kernel/module.c:23:27: note: format string is defined here
arch/riscv/kernel/module.c: In function 'apply_r_riscv_pcrel_hi20_rela':
./include/linux/kern_levels.h:5:18: warning: format '%llx' expects argument of type 'long long unsigned int', but argument 3 has type 'Elf32_Addr' {aka 'unsigned int'} [-Wformat=]
arch/riscv/kernel/module.c:104:23: note: format string is defined here
arch/riscv/kernel/module.c: In function 'apply_r_riscv_hi20_rela':
./include/linux/kern_levels.h:5:18: warning: format '%llx' expects argument of type 'long long unsigned int', but argument 3 has type 'Elf32_Addr' {aka 'unsigned int'} [-Wformat=]
arch/riscv/kernel/module.c:146:23: note: format string is defined here
arch/riscv/kernel/module.c: In function 'apply_r_riscv_got_hi20_rela':
./include/linux/kern_levels.h:5:18: warning: format '%llx' expects argument of type 'long long unsigned int', but argument 3 has type 'Elf32_Addr' {aka 'unsigned int'} [-Wformat=]
arch/riscv/kernel/module.c:190:60: note: format string is defined here
arch/riscv/kernel/module.c: In function 'apply_r_riscv_call_plt_rela':
./include/linux/kern_levels.h:5:18: warning: format '%llx' expects argument of type 'long long unsigned int', but argument 3 has type 'Elf32_Addr' {aka 'unsigned int'} [-Wformat=]
arch/riscv/kernel/module.c:214:24: note: format string is defined here
arch/riscv/kernel/module.c: In function 'apply_r_riscv_call_rela':
./include/linux/kern_levels.h:5:18: warning: format '%llx' expects argument of type 'long long unsigned int', but argument 3 has type 'Elf32_Addr' {aka 'unsigned int'} [-Wformat=]
arch/riscv/kernel/module.c:236:23: note: format string is defined here

Signed-off-by: Olof Johansson <[email protected]>
---
arch/riscv/kernel/module.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/riscv/kernel/module.c b/arch/riscv/kernel/module.c
index 3303ed2cd419..7dd308129b40 100644
--- a/arch/riscv/kernel/module.c
+++ b/arch/riscv/kernel/module.c
@@ -21,7 +21,7 @@ static int apply_r_riscv_32_rela(struct module *me, u32 *location, Elf_Addr v)
{
if (v != (u32)v) {
pr_err("%s: value %016llx out of range for 32-bit field\n",
- me->name, v);
+ me->name, (long long)v);
return -EINVAL;
}
*location = v;
@@ -102,7 +102,7 @@ static int apply_r_riscv_pcrel_hi20_rela(struct module *me, u32 *location,
if (offset != (s32)offset) {
pr_err(
"%s: target %016llx can not be addressed by the 32-bit offset from PC = %p\n",
- me->name, v, location);
+ me->name, (long long)v, location);
return -EINVAL;
}

@@ -144,7 +144,7 @@ static int apply_r_riscv_hi20_rela(struct module *me, u32 *location,
if (IS_ENABLED(CMODEL_MEDLOW)) {
pr_err(
"%s: target %016llx can not be addressed by the 32-bit offset from PC = %p\n",
- me->name, v, location);
+ me->name, (long long)v, location);
return -EINVAL;
}

@@ -188,7 +188,7 @@ static int apply_r_riscv_got_hi20_rela(struct module *me, u32 *location,
} else {
pr_err(
"%s: can not generate the GOT entry for symbol = %016llx from PC = %p\n",
- me->name, v, location);
+ me->name, (long long)v, location);
return -EINVAL;
}

@@ -212,7 +212,7 @@ static int apply_r_riscv_call_plt_rela(struct module *me, u32 *location,
} else {
pr_err(
"%s: target %016llx can not be addressed by the 32-bit offset from PC = %p\n",
- me->name, v, location);
+ me->name, (long long)v, location);
return -EINVAL;
}
}
@@ -234,7 +234,7 @@ static int apply_r_riscv_call_rela(struct module *me, u32 *location,
if (offset != fill_v) {
pr_err(
"%s: target %016llx can not be addressed by the 32-bit offset from PC = %p\n",
- me->name, v, location);
+ me->name, (long long)v, location);
return -EINVAL;
}

--
2.11.0


2018-10-31 06:50:09

by Olof Johansson

[permalink] [raw]
Subject: [PATCH 2/3] RISC-V: lib: minor asm cleanup

Fix tab/space conversion and use ENTRY/ENDPROC macros.

Signed-off-by: Olof Johansson <[email protected]>
---
arch/riscv/lib/tishift.S | 59 +++++++++++++++++++++++++-----------------------
arch/riscv/lib/udivdi3.S | 42 ++++++++++++++++++----------------
2 files changed, 53 insertions(+), 48 deletions(-)

diff --git a/arch/riscv/lib/tishift.S b/arch/riscv/lib/tishift.S
index 69abb1277234..237bc9fd0763 100644
--- a/arch/riscv/lib/tishift.S
+++ b/arch/riscv/lib/tishift.S
@@ -10,33 +10,36 @@
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*/
- .globl __lshrti3
-__lshrti3:
- beqz a2, .L1
- li a5,64
- sub a5,a5,a2
- addi sp,sp,-16
- sext.w a4,a5
- blez a5, .L2
- sext.w a2,a2
- sll a4,a1,a4
- srl a0,a0,a2
- srl a1,a1,a2
- or a0,a0,a4
- sd a1,8(sp)
- sd a0,0(sp)
- ld a0,0(sp)
- ld a1,8(sp)
- addi sp,sp,16
- ret
+
+#include <linux/linkage.h>
+
+ENTRY(__lshrti3)
+ beqz a2, .L1
+ li a5,64
+ sub a5,a5,a2
+ addi sp,sp,-16
+ sext.w a4,a5
+ blez a5, .L2
+ sext.w a2,a2
+ sll a4,a1,a4
+ srl a0,a0,a2
+ srl a1,a1,a2
+ or a0,a0,a4
+ sd a1,8(sp)
+ sd a0,0(sp)
+ ld a0,0(sp)
+ ld a1,8(sp)
+ addi sp,sp,16
+ ret
.L1:
- ret
+ ret
.L2:
- negw a4,a4
- srl a1,a1,a4
- sd a1,0(sp)
- sd zero,8(sp)
- ld a0,0(sp)
- ld a1,8(sp)
- addi sp,sp,16
- ret
+ negw a4,a4
+ srl a1,a1,a4
+ sd a1,0(sp)
+ sd zero,8(sp)
+ ld a0,0(sp)
+ ld a1,8(sp)
+ addi sp,sp,16
+ ret
+ENDPROC(__lshrti3)
diff --git a/arch/riscv/lib/udivdi3.S b/arch/riscv/lib/udivdi3.S
index cb01ae5b181a..7f1c0af182a3 100644
--- a/arch/riscv/lib/udivdi3.S
+++ b/arch/riscv/lib/udivdi3.S
@@ -11,28 +11,30 @@
* GNU General Public License for more details.
*/

- .globl __udivdi3
-__udivdi3:
- mv a2, a1
- mv a1, a0
- li a0, -1
- beqz a2, .L5
- li a3, 1
- bgeu a2, a1, .L2
+#include <linux/linkage.h>
+
+ENTRY(__udivdi3)
+ mv a2, a1
+ mv a1, a0
+ li a0, -1
+ beqz a2, .L5
+ li a3, 1
+ bgeu a2, a1, .L2
.L1:
- blez a2, .L2
- slli a2, a2, 1
- slli a3, a3, 1
- bgtu a1, a2, .L1
+ blez a2, .L2
+ slli a2, a2, 1
+ slli a3, a3, 1
+ bgtu a1, a2, .L1
.L2:
- li a0, 0
+ li a0, 0
.L3:
- bltu a1, a2, .L4
- sub a1, a1, a2
- or a0, a0, a3
+ bltu a1, a2, .L4
+ sub a1, a1, a2
+ or a0, a0, a3
.L4:
- srli a3, a3, 1
- srli a2, a2, 1
- bnez a3, .L3
+ srli a3, a3, 1
+ srli a2, a2, 1
+ bnez a3, .L3
.L5:
- ret
+ ret
+ENDPROC(__udivdi3)
--
2.11.0


2018-10-31 17:17:00

by Palmer Dabbelt

[permalink] [raw]
Subject: Re: [PATCH 0/3] RISC-V: A few build/warning fixes and cleanup

On Tue, 30 Oct 2018 23:47:06 PDT (-0700), Olof Johansson wrote:
> A couple of fixes for build breakage or warnings, and a small whitespace/asm
> cleanup. The non-cleanups would be good to see in 4.20 to keep builds green.

I'm happy to just keep them all together, since the cleanups are non-functional
changes. Patch 1/3 appears to have disappeared from my inbox and I can't get
to the infradead archives, do you mind re-sending it?

This also brings up a bigger issue: I need to stop breaking the build,
particularly as we now support a bunch of configurations. Is your CI stuff
still running? It'd be great to have it run against some of our integration
branches so I can catch these before they make it upstream. I haven't been
getting any emails.

2018-10-31 17:55:49

by Olof Johansson

[permalink] [raw]
Subject: Re: [PATCH 0/3] RISC-V: A few build/warning fixes and cleanup

Hi,

On Wed, Oct 31, 2018 at 10:09 AM Palmer Dabbelt <[email protected]> wrote:
>
> On Tue, 30 Oct 2018 23:47:06 PDT (-0700), Olof Johansson wrote:
> > A couple of fixes for build breakage or warnings, and a small whitespace/asm
> > cleanup. The non-cleanups would be good to see in 4.20 to keep builds green.
>
> I'm happy to just keep them all together, since the cleanups are non-functional
> changes. Patch 1/3 appears to have disappeared from my inbox and I can't get
> to the infradead archives, do you mind re-sending it?

Sure, check inbox in a few minutes.

> This also brings up a bigger issue: I need to stop breaking the build,
> particularly as we now support a bunch of configurations. Is your CI stuff
> still running? It'd be great to have it run against some of our integration
> branches so I can catch these before they make it upstream. I haven't been
> getting any emails.

I've migrated machines to a new system and that CI is up and running.
Right now the emails don't go anywhere but me, but let me know where
you want them sent and I'll be happy to do so (probably not
linux-riscv due to volume/noise). They're also uploaded to
http://arm-soc.lixom.net/buildlogs/riscv/.

Since you keep single-patch branches in your tree, and I compile
everything for every branch, I've restricted what branches I poll and
build. Right now it's "for*" and "riscv*".


-Olof

2018-10-31 18:13:09

by Logan Gunthorpe

[permalink] [raw]
Subject: Re: [PATCH 0/3] RISC-V: A few build/warning fixes and cleanup


On 2018-10-31 11:52 a.m., Olof Johansson wrote:
> I've migrated machines to a new system and that CI is up and running.
> Right now the emails don't go anywhere but me, but let me know where
> you want them sent and I'll be happy to do so (probably not
> linux-riscv due to volume/noise). They're also uploaded to
> http://arm-soc.lixom.net/buildlogs/riscv/.
>
> Since you keep single-patch branches in your tree, and I compile
> everything for every branch, I've restricted what branches I poll and
> build. Right now it's "for*" and "riscv*".

I think it would also be very nice to get the existing kbuild test robot
to start compile testing a few riscv configs. It already does most of
the other arches. This would help us catch these kinds of issues even
earlier seeing that test robot tests patches on mailing lists and many
other repos before Palmer would even pull them into his branch.
(Including a repo I routinely push branches to before sending out patches.)

I'm not sure who's currently responsible for the robot but I've copied
Fenguang who, I believe, set it up originally as well as the kbuild
lists. Hopefully he can point us in the right direction to help get this
set up.

Thanks,

Logan


2018-11-01 01:49:45

by Fengguang Wu

[permalink] [raw]
Subject: Re: [PATCH 0/3] RISC-V: A few build/warning fixes and cleanup

CC Philip, current kbuild test robot maintainer.

On Wed, Oct 31, 2018 at 12:12:21PM -0600, Logan Gunthorpe wrote:
>
>On 2018-10-31 11:52 a.m., Olof Johansson wrote:
>> I've migrated machines to a new system and that CI is up and running.
>> Right now the emails don't go anywhere but me, but let me know where
>> you want them sent and I'll be happy to do so (probably not
>> linux-riscv due to volume/noise). They're also uploaded to
>> http://arm-soc.lixom.net/buildlogs/riscv/.
>>
>> Since you keep single-patch branches in your tree, and I compile
>> everything for every branch, I've restricted what branches I poll and
>> build. Right now it's "for*" and "riscv*".
>
>I think it would also be very nice to get the existing kbuild test robot
>to start compile testing a few riscv configs. It already does most of
>the other arches. This would help us catch these kinds of issues even
>earlier seeing that test robot tests patches on mailing lists and many
>other repos before Palmer would even pull them into his branch.
>(Including a repo I routinely push branches to before sending out patches.)
>
>I'm not sure who's currently responsible for the robot but I've copied
>Fenguang who, I believe, set it up originally as well as the kbuild
>lists. Hopefully he can point us in the right direction to help get this
>set up.
>
>Thanks,
>
>Logan
>

2018-11-01 02:21:09

by Philip Li

[permalink] [raw]
Subject: RE: [PATCH 0/3] RISC-V: A few build/warning fixes and cleanup

> Subject: Re: [PATCH 0/3] RISC-V: A few build/warning fixes and cleanup
>
> CC Philip, current kbuild test robot maintainer.
>
> On Wed, Oct 31, 2018 at 12:12:21PM -0600, Logan Gunthorpe wrote:
> >
> >On 2018-10-31 11:52 a.m., Olof Johansson wrote:
> >> I've migrated machines to a new system and that CI is up and running.
> >> Right now the emails don't go anywhere but me, but let me know where
> >> you want them sent and I'll be happy to do so (probably not
> >> linux-riscv due to volume/noise). They're also uploaded to
> >> http://arm-soc.lixom.net/buildlogs/riscv/.
> >>
> >> Since you keep single-patch branches in your tree, and I compile
> >> everything for every branch, I've restricted what branches I poll and
> >> build. Right now it's "for*" and "riscv*".
> >
> >I think it would also be very nice to get the existing kbuild test robot
> >to start compile testing a few riscv configs. It already does most of
thanks Logan, the support to riscv and nds32 has been in our TODO list for
a while, but whole team is blocked by other effort. We will focus on this soon
to complete it within 2-3 weeks.

> >the other arches. This would help us catch these kinds of issues even
> >earlier seeing that test robot tests patches on mailing lists and many
> >other repos before Palmer would even pull them into his branch.
> >(Including a repo I routinely push branches to before sending out patches.)
> >
> >I'm not sure who's currently responsible for the robot but I've copied
> >Fenguang who, I believe, set it up originally as well as the kbuild
> >lists. Hopefully he can point us in the right direction to help get this
> >set up.
> >
> >Thanks,
> >
> >Logan
> >

2018-11-01 15:44:11

by Logan Gunthorpe

[permalink] [raw]
Subject: Re: [PATCH 0/3] RISC-V: A few build/warning fixes and cleanup



On 2018-10-31 8:19 p.m., Li, Philip wrote:
>>> I think it would also be very nice to get the existing kbuild test robot
>>> to start compile testing a few riscv configs. It already does most of
> thanks Logan, the support to riscv and nds32 has been in our TODO list for
> a while, but whole team is blocked by other effort. We will focus on this soon
> to complete it within 2-3 weeks.

Thanks! Glad to hear it.

Logan

2018-11-01 16:17:57

by Palmer Dabbelt

[permalink] [raw]
Subject: Re: [PATCH 0/3] RISC-V: A few build/warning fixes and cleanup

On Thu, 01 Nov 2018 08:43:15 PDT (-0700), [email protected] wrote:
>
>
> On 2018-10-31 8:19 p.m., Li, Philip wrote:
>>>> I think it would also be very nice to get the existing kbuild test robot
>>>> to start compile testing a few riscv configs. It already does most of
>> thanks Logan, the support to riscv and nds32 has been in our TODO list for
>> a while, but whole team is blocked by other effort. We will focus on this soon
>> to complete it within 2-3 weeks.
>
> Thanks! Glad to hear it.

We should probably at least have builds for rv32imac, rv32imafdc, rv64imac, and
rv64imafdc. It's probably also good to test SMP/non-SMP as well as
medlow/medany, as I doubt those get regularly tested. If you'd like I can
write up the configs, just point me to something that describes what I should
do.

2018-11-01 17:22:09

by Olof Johansson

[permalink] [raw]
Subject: Re: [PATCH 0/3] RISC-V: A few build/warning fixes and cleanup

On Thu, Nov 1, 2018 at 9:17 AM Palmer Dabbelt <[email protected]> wrote:
>
> On Thu, 01 Nov 2018 08:43:15 PDT (-0700), [email protected] wrote:
> >
> >
> > On 2018-10-31 8:19 p.m., Li, Philip wrote:
> >>>> I think it would also be very nice to get the existing kbuild test robot
> >>>> to start compile testing a few riscv configs. It already does most of
> >> thanks Logan, the support to riscv and nds32 has been in our TODO list for
> >> a while, but whole team is blocked by other effort. We will focus on this soon
> >> to complete it within 2-3 weeks.
> >
> > Thanks! Glad to hear it.
>
> We should probably at least have builds for rv32imac, rv32imafdc, rv64imac, and
> rv64imafdc. It's probably also good to test SMP/non-SMP as well as
> medlow/medany, as I doubt those get regularly tested. If you'd like I can
> write up the configs, just point me to something that describes what I should
> do.

It might make sense to either do a pseudo-arch for riscv32, or maybe a
config snippet to generate these arch-specific configs.

For the ISA options, it's a bit trickier. Ideally we want to build
just one kernel that can boot everywhere, and enable the rest
dynamically ('fd' in particular). Whether the kernel itself is built
with 'c' could be a config option to enable (like THUMB kernel on
32-bit ARM), but in general we probably want to watch out for
explosions of combinations here.

Embedded/low-end users will want a way to disable whatever they don't
need, so there's a balance to be found.

FWIW, the configs I build today are:

if [ -f arch/riscv/Makefile ] ; then
(grep -v "CONFIG_SMP=y" arch/riscv/configs/defconfig ; echo
"CONFIG_SMP=n") > arch/riscv/configs/nosmp_defconfig
(grep -v "CONFIG_ARCH_RV32I is not"
arch/riscv/configs/defconfig ; echo "CONFIG_ARCH_RV32I=y") >
arch/riscv/configs/rv32_defconfig
fi

+ tinyconfig, allmodconfig, allnoconfig and in some cases
allyesconfig. allmod and allyes take forever so I'm trying to figure
out what targets to build those for. Maybe linux-next only or
something. So doing allmod+ISA combinations would be quite a time
addition for build turnarounds for me.


-Olof