* [PATCH] riscv: Fix build against binutils 2.38
@ 2022-01-28 13:47 Alexandre Ghiti
2022-01-28 14:15 ` Bin Meng
` (3 more replies)
0 siblings, 4 replies; 24+ messages in thread
From: Alexandre Ghiti @ 2022-01-28 13:47 UTC (permalink / raw)
To: Rick Chen, Leo, Aurelien Jarno, Heinrich Schuchardt, u-boot
Cc: Alexandre Ghiti
The following description is copied from the equivalent patch for the
Linux Kernel proposed by Aurelien Jarno:
From version 2.38, binutils default to ISA spec version 20191213. This
means that the csr read/write (csrr*/csrw*) instructions and fence.i
instruction has separated from the `I` extension, become two standalone
extensions: Zicsr and Zifencei. As the kernel uses those instruction,
this causes the following build failure:
arch/riscv/cpu/mtrap.S: Assembler messages:
arch/riscv/cpu/mtrap.S:65: Error: unrecognized opcode `csrr a0,scause'
arch/riscv/cpu/mtrap.S:66: Error: unrecognized opcode `csrr a1,sepc'
arch/riscv/cpu/mtrap.S:67: Error: unrecognized opcode `csrr a2,stval'
arch/riscv/cpu/mtrap.S:70: Error: unrecognized opcode `csrw sepc,a0'
Signed-off-by: Alexandre Ghiti <alexandre.ghiti@canonical.com>
---
arch/riscv/Makefile | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/arch/riscv/Makefile b/arch/riscv/Makefile
index 0b80eb8d86..53d1194ffb 100644
--- a/arch/riscv/Makefile
+++ b/arch/riscv/Makefile
@@ -24,7 +24,16 @@ ifeq ($(CONFIG_CMODEL_MEDANY),y)
CMODEL = medany
endif
-ARCH_FLAGS = -march=$(ARCH_BASE)$(ARCH_A)$(ARCH_C) -mabi=$(ABI) \
+RISCV_MARCH = $(ARCH_BASE)$(ARCH_A)$(ARCH_C)
+
+# Newer binutils versions default to ISA spec version 20191213 which moves some
+# instructions from the I extension to the Zicsr and Zifencei extensions.
+toolchain-need-zicsr-zifencei := $(call cc-option-yn, -mabi=$(ABI) -march=$(RISCV_MARCH)_zicsr_zifencei)
+ifeq ($(toolchain-need-zicsr-zifencei),y)
+ RISCV_MARCH := $(RISCV_MARCH)_zicsr_zifencei
+endif
+
+ARCH_FLAGS = -march=$(RISCV_MARCH) -mabi=$(ABI) \
-mcmodel=$(CMODEL)
PLATFORM_CPPFLAGS += $(ARCH_FLAGS)
--
2.32.0
^ permalink raw reply related [flat|nested] 24+ messages in thread
* Re: [PATCH] riscv: Fix build against binutils 2.38
2022-01-28 13:47 [PATCH] riscv: Fix build against binutils 2.38 Alexandre Ghiti
@ 2022-01-28 14:15 ` Bin Meng
2022-01-28 18:03 ` Heinrich Schuchardt
` (2 subsequent siblings)
3 siblings, 0 replies; 24+ messages in thread
From: Bin Meng @ 2022-01-28 14:15 UTC (permalink / raw)
To: Alexandre Ghiti
Cc: Rick Chen, Leo, Aurelien Jarno, Heinrich Schuchardt, U-Boot Mailing List
On Fri, Jan 28, 2022 at 9:47 PM Alexandre Ghiti
<alexandre.ghiti@canonical.com> wrote:
>
> The following description is copied from the equivalent patch for the
> Linux Kernel proposed by Aurelien Jarno:
>
> From version 2.38, binutils default to ISA spec version 20191213. This
> means that the csr read/write (csrr*/csrw*) instructions and fence.i
> instruction has separated from the `I` extension, become two standalone
> extensions: Zicsr and Zifencei. As the kernel uses those instruction,
> this causes the following build failure:
>
> arch/riscv/cpu/mtrap.S: Assembler messages:
> arch/riscv/cpu/mtrap.S:65: Error: unrecognized opcode `csrr a0,scause'
> arch/riscv/cpu/mtrap.S:66: Error: unrecognized opcode `csrr a1,sepc'
> arch/riscv/cpu/mtrap.S:67: Error: unrecognized opcode `csrr a2,stval'
> arch/riscv/cpu/mtrap.S:70: Error: unrecognized opcode `csrw sepc,a0'
>
> Signed-off-by: Alexandre Ghiti <alexandre.ghiti@canonical.com>
> ---
> arch/riscv/Makefile | 11 ++++++++++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] riscv: Fix build against binutils 2.38
2022-01-28 13:47 [PATCH] riscv: Fix build against binutils 2.38 Alexandre Ghiti
2022-01-28 14:15 ` Bin Meng
@ 2022-01-28 18:03 ` Heinrich Schuchardt
2022-01-28 18:19 ` Aurelien Jarno
2022-01-28 18:22 ` Heinrich Schuchardt
2022-02-17 9:24 ` Leo Liang
2022-06-23 13:40 ` Heiko Stübner
3 siblings, 2 replies; 24+ messages in thread
From: Heinrich Schuchardt @ 2022-01-28 18:03 UTC (permalink / raw)
To: Alexandre Ghiti; +Cc: Rick Chen, Leo, Aurelien Jarno, u-boot, matthias.klose
On 1/28/22 14:47, Alexandre Ghiti wrote:
> The following description is copied from the equivalent patch for the
> Linux Kernel proposed by Aurelien Jarno:
>
> From version 2.38, binutils default to ISA spec version 20191213. This
> means that the csr read/write (csrr*/csrw*) instructions and fence.i
> instruction has separated from the `I` extension, become two standalone
> extensions: Zicsr and Zifencei. As the kernel uses those instruction,
> this causes the following build failure:
>
> arch/riscv/cpu/mtrap.S: Assembler messages:
> arch/riscv/cpu/mtrap.S:65: Error: unrecognized opcode `csrr a0,scause'
> arch/riscv/cpu/mtrap.S:66: Error: unrecognized opcode `csrr a1,sepc'
> arch/riscv/cpu/mtrap.S:67: Error: unrecognized opcode `csrr a2,stval'
> arch/riscv/cpu/mtrap.S:70: Error: unrecognized opcode `csrw sepc,a0'
I tried to build qemu-riscv64_smode_defconfig. With your patch I get
arch/riscv/cpu/cpu.c: Assembler messages:
arch/riscv/cpu/cpu.c:94: Error: unrecognized opcode `csrs sstatus,a5'
arch/riscv/cpu/cpu.c:95: Error: unrecognized opcode `csrw 0x003,0'
The build flag used is -march=rv64imac.
My toolchain is:
binutils 2.37.90.20220126-0ubuntu1
riscv64-linux-gnu-gcc (Ubuntu 10.3.0-8ubuntu1) 10.3.0
This GCC does not support _zicsr_zifencei:
cc1: error: ‘-march=rv64imac_zicsr_zifencei’: unsupported ISA subset ‘z
Could it be that the GCC is too old for the new binutils?
When was the z subset added to GCC?
What about the device trees:
arch/riscv/dts/fu540-c000.dtsi:32:
riscv,isa = "rv64imac";
arch/riscv/dts/fu740-c000.dtsi:34:
riscv,isa = "rv64imac";
arch/riscv/dts/microchip-mpfs.dtsi:28:
riscv,isa = "rv64imac";
Best regards
Heinrich
>
> Signed-off-by: Alexandre Ghiti <alexandre.ghiti@canonical.com>
> ---
> arch/riscv/Makefile | 11 ++++++++++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/arch/riscv/Makefile b/arch/riscv/Makefile
> index 0b80eb8d86..53d1194ffb 100644
> --- a/arch/riscv/Makefile
> +++ b/arch/riscv/Makefile
> @@ -24,7 +24,16 @@ ifeq ($(CONFIG_CMODEL_MEDANY),y)
> CMODEL = medany
> endif
>
> -ARCH_FLAGS = -march=$(ARCH_BASE)$(ARCH_A)$(ARCH_C) -mabi=$(ABI) \
> +RISCV_MARCH = $(ARCH_BASE)$(ARCH_A)$(ARCH_C)
> +
> +# Newer binutils versions default to ISA spec version 20191213 which moves some
> +# instructions from the I extension to the Zicsr and Zifencei extensions.
> +toolchain-need-zicsr-zifencei := $(call cc-option-yn, -mabi=$(ABI) -march=$(RISCV_MARCH)_zicsr_zifencei)
> +ifeq ($(toolchain-need-zicsr-zifencei),y)
> + RISCV_MARCH := $(RISCV_MARCH)_zicsr_zifencei
> +endif
> +
> +ARCH_FLAGS = -march=$(RISCV_MARCH) -mabi=$(ABI) \
> -mcmodel=$(CMODEL)
>
> PLATFORM_CPPFLAGS += $(ARCH_FLAGS)
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] riscv: Fix build against binutils 2.38
2022-01-28 18:03 ` Heinrich Schuchardt
@ 2022-01-28 18:19 ` Aurelien Jarno
2022-01-28 18:28 ` Aurelien Jarno
2022-01-28 18:22 ` Heinrich Schuchardt
1 sibling, 1 reply; 24+ messages in thread
From: Aurelien Jarno @ 2022-01-28 18:19 UTC (permalink / raw)
To: Heinrich Schuchardt
Cc: Alexandre Ghiti, Rick Chen, Leo, u-boot, matthias.klose
On 2022-01-28 19:03, Heinrich Schuchardt wrote:
> On 1/28/22 14:47, Alexandre Ghiti wrote:
> > The following description is copied from the equivalent patch for the
> > Linux Kernel proposed by Aurelien Jarno:
> >
> > From version 2.38, binutils default to ISA spec version 20191213. This
> > means that the csr read/write (csrr*/csrw*) instructions and fence.i
> > instruction has separated from the `I` extension, become two standalone
> > extensions: Zicsr and Zifencei. As the kernel uses those instruction,
> > this causes the following build failure:
> >
> > arch/riscv/cpu/mtrap.S: Assembler messages:
> > arch/riscv/cpu/mtrap.S:65: Error: unrecognized opcode `csrr a0,scause'
> > arch/riscv/cpu/mtrap.S:66: Error: unrecognized opcode `csrr a1,sepc'
> > arch/riscv/cpu/mtrap.S:67: Error: unrecognized opcode `csrr a2,stval'
> > arch/riscv/cpu/mtrap.S:70: Error: unrecognized opcode `csrw sepc,a0'
>
> I tried to build qemu-riscv64_smode_defconfig. With your patch I get
>
> arch/riscv/cpu/cpu.c: Assembler messages:
> arch/riscv/cpu/cpu.c:94: Error: unrecognized opcode `csrs sstatus,a5'
> arch/riscv/cpu/cpu.c:95: Error: unrecognized opcode `csrw 0x003,0'
>
> The build flag used is -march=rv64imac.
>
> My toolchain is:
> binutils 2.37.90.20220126-0ubuntu1
> riscv64-linux-gnu-gcc (Ubuntu 10.3.0-8ubuntu1) 10.3.0
>
> This GCC does not support _zicsr_zifencei:
> cc1: error: ‘-march=rv64imac_zicsr_zifencei’: unsupported ISA subset ‘z
>
> Could it be that the GCC is too old for the new binutils?
> When was the z subset added to GCC?
Yes, GCC 11 is the minimum version that understand those extensions.
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurelien@aurel32.net http://www.aurel32.net
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] riscv: Fix build against binutils 2.38
2022-01-28 18:03 ` Heinrich Schuchardt
2022-01-28 18:19 ` Aurelien Jarno
@ 2022-01-28 18:22 ` Heinrich Schuchardt
1 sibling, 0 replies; 24+ messages in thread
From: Heinrich Schuchardt @ 2022-01-28 18:22 UTC (permalink / raw)
To: Alexandre Ghiti; +Cc: Rick Chen, Leo, Aurelien Jarno, u-boot, matthias.klose
On 1/28/22 19:03, Heinrich Schuchardt wrote:
> On 1/28/22 14:47, Alexandre Ghiti wrote:
>> The following description is copied from the equivalent patch for the
>> Linux Kernel proposed by Aurelien Jarno:
>>
>> From version 2.38, binutils default to ISA spec version 20191213. This
>> means that the csr read/write (csrr*/csrw*) instructions and fence.i
>> instruction has separated from the `I` extension, become two standalone
>> extensions: Zicsr and Zifencei. As the kernel uses those instruction,
>> this causes the following build failure:
>>
>> arch/riscv/cpu/mtrap.S: Assembler messages:
>> arch/riscv/cpu/mtrap.S:65: Error: unrecognized opcode `csrr a0,scause'
>> arch/riscv/cpu/mtrap.S:66: Error: unrecognized opcode `csrr a1,sepc'
>> arch/riscv/cpu/mtrap.S:67: Error: unrecognized opcode `csrr a2,stval'
>> arch/riscv/cpu/mtrap.S:70: Error: unrecognized opcode `csrw sepc,a0'
>
> I tried to build qemu-riscv64_smode_defconfig. With your patch I get
>
> arch/riscv/cpu/cpu.c: Assembler messages:
> arch/riscv/cpu/cpu.c:94: Error: unrecognized opcode `csrs sstatus,a5'
> arch/riscv/cpu/cpu.c:95: Error: unrecognized opcode `csrw 0x003,0'
>
> The build flag used is -march=rv64imac.
>
> My toolchain is:
> binutils 2.37.90.20220126-0ubuntu1
> riscv64-linux-gnu-gcc (Ubuntu 10.3.0-8ubuntu1) 10.3.0
>
> This GCC does not support _zicsr_zifencei:
> cc1: error: ‘-march=rv64imac_zicsr_zifencei’: unsupported ISA subset ‘z
>
> Could it be that the GCC is too old for the new binutils?
> When was the z subset added to GCC?
>
> What about the device trees:
>
> arch/riscv/dts/fu540-c000.dtsi:32:
> riscv,isa = "rv64imac";
>
> arch/riscv/dts/fu740-c000.dtsi:34:
> riscv,isa = "rv64imac";
>
> arch/riscv/dts/microchip-mpfs.dtsi:28:
> riscv,isa = "rv64imac";
>
> Best regards
>
> Heinrich
riscv64-linux-gnu-gcc (Ubuntu 11.2.0-3ubuntu1) 11.2.0
bintutils 2.37.90.20220126-0ubuntu1
plus your patch works fine and uses -march=rv64imac_zicsr_zifencei.
Unfortunately this is not yet the standard cross-compiler in Ubuntu 22.04.
Tested-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
>
>>
>> Signed-off-by: Alexandre Ghiti <alexandre.ghiti@canonical.com>
>> ---
>> arch/riscv/Makefile | 11 ++++++++++-
>> 1 file changed, 10 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/riscv/Makefile b/arch/riscv/Makefile
>> index 0b80eb8d86..53d1194ffb 100644
>> --- a/arch/riscv/Makefile
>> +++ b/arch/riscv/Makefile
>> @@ -24,7 +24,16 @@ ifeq ($(CONFIG_CMODEL_MEDANY),y)
>> CMODEL = medany
>> endif
>> -ARCH_FLAGS = -march=$(ARCH_BASE)$(ARCH_A)$(ARCH_C) -mabi=$(ABI) \
>> +RISCV_MARCH = $(ARCH_BASE)$(ARCH_A)$(ARCH_C)
>> +
>> +# Newer binutils versions default to ISA spec version 20191213 which
>> moves some
>> +# instructions from the I extension to the Zicsr and Zifencei
>> extensions.
>> +toolchain-need-zicsr-zifencei := $(call cc-option-yn, -mabi=$(ABI)
>> -march=$(RISCV_MARCH)_zicsr_zifencei)
>> +ifeq ($(toolchain-need-zicsr-zifencei),y)
>> + RISCV_MARCH := $(RISCV_MARCH)_zicsr_zifencei
>> +endif
>> +
>> +ARCH_FLAGS = -march=$(RISCV_MARCH) -mabi=$(ABI) \
>> -mcmodel=$(CMODEL)
>> PLATFORM_CPPFLAGS += $(ARCH_FLAGS)
>
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] riscv: Fix build against binutils 2.38
2022-01-28 18:19 ` Aurelien Jarno
@ 2022-01-28 18:28 ` Aurelien Jarno
0 siblings, 0 replies; 24+ messages in thread
From: Aurelien Jarno @ 2022-01-28 18:28 UTC (permalink / raw)
To: Heinrich Schuchardt
Cc: Alexandre Ghiti, Rick Chen, Leo, u-boot, matthias.klose
On 2022-01-28 19:19, Aurelien Jarno wrote:
> On 2022-01-28 19:03, Heinrich Schuchardt wrote:
> > On 1/28/22 14:47, Alexandre Ghiti wrote:
> > > The following description is copied from the equivalent patch for the
> > > Linux Kernel proposed by Aurelien Jarno:
> > >
> > > From version 2.38, binutils default to ISA spec version 20191213. This
> > > means that the csr read/write (csrr*/csrw*) instructions and fence.i
> > > instruction has separated from the `I` extension, become two standalone
> > > extensions: Zicsr and Zifencei. As the kernel uses those instruction,
> > > this causes the following build failure:
> > >
> > > arch/riscv/cpu/mtrap.S: Assembler messages:
> > > arch/riscv/cpu/mtrap.S:65: Error: unrecognized opcode `csrr a0,scause'
> > > arch/riscv/cpu/mtrap.S:66: Error: unrecognized opcode `csrr a1,sepc'
> > > arch/riscv/cpu/mtrap.S:67: Error: unrecognized opcode `csrr a2,stval'
> > > arch/riscv/cpu/mtrap.S:70: Error: unrecognized opcode `csrw sepc,a0'
> >
> > I tried to build qemu-riscv64_smode_defconfig. With your patch I get
> >
> > arch/riscv/cpu/cpu.c: Assembler messages:
> > arch/riscv/cpu/cpu.c:94: Error: unrecognized opcode `csrs sstatus,a5'
> > arch/riscv/cpu/cpu.c:95: Error: unrecognized opcode `csrw 0x003,0'
> >
> > The build flag used is -march=rv64imac.
> >
> > My toolchain is:
> > binutils 2.37.90.20220126-0ubuntu1
> > riscv64-linux-gnu-gcc (Ubuntu 10.3.0-8ubuntu1) 10.3.0
> >
> > This GCC does not support _zicsr_zifencei:
> > cc1: error: ‘-march=rv64imac_zicsr_zifencei’: unsupported ISA subset ‘z
> >
> > Could it be that the GCC is too old for the new binutils?
> > When was the z subset added to GCC?
>
> Yes, GCC 11 is the minimum version that understand those extensions.
GCC 11 is also required to support the not recommended alternative fix
-misa-spec=2.2.
If you need to support GCC 10, it seems that the only option is to build
binutils with --with-isa-spec=2.2.
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurelien@aurel32.net http://www.aurel32.net
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] riscv: Fix build against binutils 2.38
2022-01-28 13:47 [PATCH] riscv: Fix build against binutils 2.38 Alexandre Ghiti
2022-01-28 14:15 ` Bin Meng
2022-01-28 18:03 ` Heinrich Schuchardt
@ 2022-02-17 9:24 ` Leo Liang
2022-02-17 10:28 ` Alexandre Ghiti
2022-06-23 13:40 ` Heiko Stübner
3 siblings, 1 reply; 24+ messages in thread
From: Leo Liang @ 2022-02-17 9:24 UTC (permalink / raw)
To: Alexandre Ghiti
Cc: Rick Chen, Aurelien Jarno, Heinrich Schuchardt, u-boot, bmeng.cn
Hi Alexandre,
On Fri, Jan 28, 2022 at 02:47:13PM +0100, Alexandre Ghiti wrote:
> The following description is copied from the equivalent patch for the
> Linux Kernel proposed by Aurelien Jarno:
>
> From version 2.38, binutils default to ISA spec version 20191213. This
> means that the csr read/write (csrr*/csrw*) instructions and fence.i
> instruction has separated from the `I` extension, become two standalone
> extensions: Zicsr and Zifencei. As the kernel uses those instruction,
> this causes the following build failure:
>
> arch/riscv/cpu/mtrap.S: Assembler messages:
> arch/riscv/cpu/mtrap.S:65: Error: unrecognized opcode `csrr a0,scause'
> arch/riscv/cpu/mtrap.S:66: Error: unrecognized opcode `csrr a1,sepc'
> arch/riscv/cpu/mtrap.S:67: Error: unrecognized opcode `csrr a2,stval'
> arch/riscv/cpu/mtrap.S:70: Error: unrecognized opcode `csrw sepc,a0'
>
> Signed-off-by: Alexandre Ghiti <alexandre.ghiti@canonical.com>
> ---
> arch/riscv/Makefile | 11 ++++++++++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
This patch seems to fail CI somehow.
(https://source.denx.de/u-boot/custodians/u-boot-riscv/-/pipelines/11004)
Could you take a look at it ?
Best regards,
Leo
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] riscv: Fix build against binutils 2.38
2022-02-17 9:24 ` Leo Liang
@ 2022-02-17 10:28 ` Alexandre Ghiti
2022-02-19 8:51 ` Leo Liang
0 siblings, 1 reply; 24+ messages in thread
From: Alexandre Ghiti @ 2022-02-17 10:28 UTC (permalink / raw)
To: Leo Liang
Cc: Rick Chen, Aurelien Jarno, Heinrich Schuchardt, u-boot, bmeng.cn
Hi Leo,
On Thu, Feb 17, 2022 at 10:25 AM Leo Liang <ycliang@andestech.com> wrote:
>
> Hi Alexandre,
> On Fri, Jan 28, 2022 at 02:47:13PM +0100, Alexandre Ghiti wrote:
> > The following description is copied from the equivalent patch for the
> > Linux Kernel proposed by Aurelien Jarno:
> >
> > From version 2.38, binutils default to ISA spec version 20191213. This
> > means that the csr read/write (csrr*/csrw*) instructions and fence.i
> > instruction has separated from the `I` extension, become two standalone
> > extensions: Zicsr and Zifencei. As the kernel uses those instruction,
> > this causes the following build failure:
> >
> > arch/riscv/cpu/mtrap.S: Assembler messages:
> > arch/riscv/cpu/mtrap.S:65: Error: unrecognized opcode `csrr a0,scause'
> > arch/riscv/cpu/mtrap.S:66: Error: unrecognized opcode `csrr a1,sepc'
> > arch/riscv/cpu/mtrap.S:67: Error: unrecognized opcode `csrr a2,stval'
> > arch/riscv/cpu/mtrap.S:70: Error: unrecognized opcode `csrw sepc,a0'
> >
> > Signed-off-by: Alexandre Ghiti <alexandre.ghiti@canonical.com>
> > ---
> > arch/riscv/Makefile | 11 ++++++++++-
> > 1 file changed, 10 insertions(+), 1 deletion(-)
>
> This patch seems to fail CI somehow.
> (https://source.denx.de/u-boot/custodians/u-boot-riscv/-/pipelines/11004)
>
> Could you take a look at it ?
I have just tried on master (commit ab8903a24db1) and it failed for
the same reason, so this is not related to this patch. Nevertheless,
I'll try to bisect the problem :)
Thanks,
Alex
>
> Best regards,
> Leo
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] riscv: Fix build against binutils 2.38
2022-02-17 10:28 ` Alexandre Ghiti
@ 2022-02-19 8:51 ` Leo Liang
2022-02-21 16:42 ` Alexandre Ghiti
0 siblings, 1 reply; 24+ messages in thread
From: Leo Liang @ 2022-02-19 8:51 UTC (permalink / raw)
To: Alexandre Ghiti
Cc: Rick Chen, Aurelien Jarno, Heinrich Schuchardt, u-boot, bmeng.cn
Hi Alex,
On Thu, Feb 17, 2022 at 11:28:46AM +0100, Alexandre Ghiti wrote:
> Hi Leo,
>
> On Thu, Feb 17, 2022 at 10:25 AM Leo Liang <ycliang@andestech.com> wrote:
> >
> > Hi Alexandre,
> > On Fri, Jan 28, 2022 at 02:47:13PM +0100, Alexandre Ghiti wrote:
> > > The following description is copied from the equivalent patch for the
> > > Linux Kernel proposed by Aurelien Jarno:
> > >
> > > From version 2.38, binutils default to ISA spec version 20191213. This
> > > means that the csr read/write (csrr*/csrw*) instructions and fence.i
> > > instruction has separated from the `I` extension, become two standalone
> > > extensions: Zicsr and Zifencei. As the kernel uses those instruction,
> > > this causes the following build failure:
> > >
> > > arch/riscv/cpu/mtrap.S: Assembler messages:
> > > arch/riscv/cpu/mtrap.S:65: Error: unrecognized opcode `csrr a0,scause'
> > > arch/riscv/cpu/mtrap.S:66: Error: unrecognized opcode `csrr a1,sepc'
> > > arch/riscv/cpu/mtrap.S:67: Error: unrecognized opcode `csrr a2,stval'
> > > arch/riscv/cpu/mtrap.S:70: Error: unrecognized opcode `csrw sepc,a0'
> > >
> > > Signed-off-by: Alexandre Ghiti <alexandre.ghiti@canonical.com>
> > > ---
> > > arch/riscv/Makefile | 11 ++++++++++-
> > > 1 file changed, 10 insertions(+), 1 deletion(-)
> >
> > This patch seems to fail CI somehow.
> > (https://source.denx.de/u-boot/custodians/u-boot-riscv/-/pipelines/11004)
> >
> > Could you take a look at it ?
>
> I have just tried on master (commit ab8903a24db1) and it failed for
> the same reason, so this is not related to this patch. Nevertheless,
> I'll try to bisect the problem :)
>
> Thanks,
>
> Alex
>
Thanks for putting the effort into it!
AFAIK, this patch does nothing related to the error message "undefined reference to `__ashldi3'" from the failed CI.
Nonetheless, I have tried a few times myself,
and found that CI could pass with ab8903a24db1 but cannot pass with this patch on my side.
https://source.denx.de/u-boot/custodians/u-boot-riscv/-/commits/staging
https://source.denx.de/u-boot/custodians/u-boot-riscv/-/pipelines
Best regards,
Leo
> >
> > Best regards,
> > Leo
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] riscv: Fix build against binutils 2.38
2022-02-19 8:51 ` Leo Liang
@ 2022-02-21 16:42 ` Alexandre Ghiti
2022-03-01 3:21 ` Leo Liang
0 siblings, 1 reply; 24+ messages in thread
From: Alexandre Ghiti @ 2022-02-21 16:42 UTC (permalink / raw)
To: Leo Liang
Cc: Rick Chen, Aurelien Jarno, Heinrich Schuchardt, u-boot, bmeng.cn
On Sat, Feb 19, 2022 at 9:52 AM Leo Liang <ycliang@andestech.com> wrote:
>
> Hi Alex,
> On Thu, Feb 17, 2022 at 11:28:46AM +0100, Alexandre Ghiti wrote:
> > Hi Leo,
> >
> > On Thu, Feb 17, 2022 at 10:25 AM Leo Liang <ycliang@andestech.com> wrote:
> > >
> > > Hi Alexandre,
> > > On Fri, Jan 28, 2022 at 02:47:13PM +0100, Alexandre Ghiti wrote:
> > > > The following description is copied from the equivalent patch for the
> > > > Linux Kernel proposed by Aurelien Jarno:
> > > >
> > > > From version 2.38, binutils default to ISA spec version 20191213. This
> > > > means that the csr read/write (csrr*/csrw*) instructions and fence.i
> > > > instruction has separated from the `I` extension, become two standalone
> > > > extensions: Zicsr and Zifencei. As the kernel uses those instruction,
> > > > this causes the following build failure:
> > > >
> > > > arch/riscv/cpu/mtrap.S: Assembler messages:
> > > > arch/riscv/cpu/mtrap.S:65: Error: unrecognized opcode `csrr a0,scause'
> > > > arch/riscv/cpu/mtrap.S:66: Error: unrecognized opcode `csrr a1,sepc'
> > > > arch/riscv/cpu/mtrap.S:67: Error: unrecognized opcode `csrr a2,stval'
> > > > arch/riscv/cpu/mtrap.S:70: Error: unrecognized opcode `csrw sepc,a0'
> > > >
> > > > Signed-off-by: Alexandre Ghiti <alexandre.ghiti@canonical.com>
> > > > ---
> > > > arch/riscv/Makefile | 11 ++++++++++-
> > > > 1 file changed, 10 insertions(+), 1 deletion(-)
> > >
> > > This patch seems to fail CI somehow.
> > > (https://source.denx.de/u-boot/custodians/u-boot-riscv/-/pipelines/11004)
> > >
> > > Could you take a look at it ?
> >
> > I have just tried on master (commit ab8903a24db1) and it failed for
> > the same reason, so this is not related to this patch. Nevertheless,
> > I'll try to bisect the problem :)
> >
> > Thanks,
> >
> > Alex
> >
>
> Thanks for putting the effort into it!
>
> AFAIK, this patch does nothing related to the error message "undefined reference to `__ashldi3'" from the failed CI.
>
> Nonetheless, I have tried a few times myself,
> and found that CI could pass with ab8903a24db1 but cannot pass with this patch on my side.
> https://source.denx.de/u-boot/custodians/u-boot-riscv/-/commits/staging
> https://source.denx.de/u-boot/custodians/u-boot-riscv/-/pipelines
>
To me it is an issue with the toolchain: libgcc is missing those
symbols. If I use an Ubuntu toolchain, it fails no matter which commit
I am on (I tested as far as v2021.10). But if I use a toolchain from
https://mirrors.edge.kernel.org/pub/tools/crosstool/files/bin/x86_64/,
it works fine.
What I don't understand is how you manage to have different build
results with the same docker image: can you confirm that you use the
same toolchains in the following builds?
https://source.denx.de/u-boot/custodians/u-boot-riscv/-/jobs/393701
https://source.denx.de/u-boot/custodians/u-boot-riscv/-/jobs/393783
The only difference I see here is the gitlab-runner version (line 1).
Thanks,
Alex
> Best regards,
> Leo
>
> > >
> > > Best regards,
> > > Leo
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] riscv: Fix build against binutils 2.38
2022-02-21 16:42 ` Alexandre Ghiti
@ 2022-03-01 3:21 ` Leo Liang
2022-03-03 11:06 ` Leo Liang
0 siblings, 1 reply; 24+ messages in thread
From: Leo Liang @ 2022-03-01 3:21 UTC (permalink / raw)
To: Alexandre Ghiti
Cc: Rick Chen, Aurelien Jarno, Heinrich Schuchardt, u-boot, bmeng.cn
Hi Alex,
On Mon, Feb 21, 2022 at 05:42:41PM +0100, Alexandre Ghiti wrote:
> On Sat, Feb 19, 2022 at 9:52 AM Leo Liang <ycliang@andestech.com> wrote:
> >
> > Hi Alex,
> > On Thu, Feb 17, 2022 at 11:28:46AM +0100, Alexandre Ghiti wrote:
> > > Hi Leo,
> > >
> > > On Thu, Feb 17, 2022 at 10:25 AM Leo Liang <ycliang@andestech.com> wrote:
> > > >
> > > > Hi Alexandre,
> > > > On Fri, Jan 28, 2022 at 02:47:13PM +0100, Alexandre Ghiti wrote:
> > > > > The following description is copied from the equivalent patch for the
> > > > > Linux Kernel proposed by Aurelien Jarno:
> > > > >
> > > > > From version 2.38, binutils default to ISA spec version 20191213. This
> > > > > means that the csr read/write (csrr*/csrw*) instructions and fence.i
> > > > > instruction has separated from the `I` extension, become two standalone
> > > > > extensions: Zicsr and Zifencei. As the kernel uses those instruction,
> > > > > this causes the following build failure:
> > > > >
> > > > > arch/riscv/cpu/mtrap.S: Assembler messages:
> > > > > arch/riscv/cpu/mtrap.S:65: Error: unrecognized opcode `csrr a0,scause'
> > > > > arch/riscv/cpu/mtrap.S:66: Error: unrecognized opcode `csrr a1,sepc'
> > > > > arch/riscv/cpu/mtrap.S:67: Error: unrecognized opcode `csrr a2,stval'
> > > > > arch/riscv/cpu/mtrap.S:70: Error: unrecognized opcode `csrw sepc,a0'
> > > > >
> > > > > Signed-off-by: Alexandre Ghiti <alexandre.ghiti@canonical.com>
> > > > > ---
> > > > > arch/riscv/Makefile | 11 ++++++++++-
> > > > > 1 file changed, 10 insertions(+), 1 deletion(-)
> > > >
> > > > This patch seems to fail CI somehow.
> > > > (https://source.denx.de/u-boot/custodians/u-boot-riscv/-/pipelines/11004)
> > > >
> > > > Could you take a look at it ?
> > >
> > > I have just tried on master (commit ab8903a24db1) and it failed for
> > > the same reason, so this is not related to this patch. Nevertheless,
> > > I'll try to bisect the problem :)
> > >
> > > Thanks,
> > >
> > > Alex
> > >
> >
> > Thanks for putting the effort into it!
> >
> > AFAIK, this patch does nothing related to the error message "undefined reference to `__ashldi3'" from the failed CI.
> >
> > Nonetheless, I have tried a few times myself,
> > and found that CI could pass with ab8903a24db1 but cannot pass with this patch on my side.
> > https://source.denx.de/u-boot/custodians/u-boot-riscv/-/commits/staging
> > https://source.denx.de/u-boot/custodians/u-boot-riscv/-/pipelines
> >
>
> To me it is an issue with the toolchain: libgcc is missing those
> symbols. If I use an Ubuntu toolchain, it fails no matter which commit
> I am on (I tested as far as v2021.10). But if I use a toolchain from
> https://mirrors.edge.kernel.org/pub/tools/crosstool/files/bin/x86_64/,
> it works fine.
>
> What I don't understand is how you manage to have different build
> results with the same docker image: can you confirm that you use the
> same toolchains in the following builds?
>
> https://source.denx.de/u-boot/custodians/u-boot-riscv/-/jobs/393701
> https://source.denx.de/u-boot/custodians/u-boot-riscv/-/jobs/393783
>
Sorry for the late reply.
I have checked the toolchain version of these two builds,
they are using the same toolchain[1] from Tom's docker image on docker hub[2].
Also the fail is reproducible using this docker image with the following commands:
leo@host sudo docker run -it --name leo-test trini/u-boot-gitlab-ci-runner:focal-20220113-03Feb2022 /bin/bash
uboot@356268d27bf0:~$ git clone https://source.denx.de/u-boot/custodians/u-boot-riscv.git && cd u-boot-riscv
uboot@356268d27bf0:~/u-boot-riscv$ git checkout staging
uboot@356268d27bf0:~/u-boot-riscv$ export PATH=/opt/gcc-11.1.0-nolibc/riscv64-linux/bin:$PATH
uboot@356268d27bf0:~/u-boot-riscv$ export CROSS_COMPILE=riscv64-linux-
uboot@356268d27bf0:~/u-boot-riscv$ make qemu-riscv32_spl_defconfig
uboot@356268d27bf0:~/u-boot-riscv$ make -j`nproc` V=1
...
riscv64-linux-ld.bfd -m elf32lriscv --gc-sections -static -pie -Bstatic --no-dynamic-linker -z notext --build-id=none -Ttext 0x81200000 -o u-boot -T u-boot.lds arch/riscv/cpu/start.o --whole-archive arch/riscv/cpu/built-in.o arch/riscv/cpu/generic/built-in.o arch/riscv/lib/built-in.o board/emulation/common/built-in.o board/emulation/qemu-riscv/built-in.o boot/built-in.o cmd/built-in.o common/built-in.o disk/built-in.o drivers/built-in.o drivers/usb/cdns3/built-in.o drivers/usb/common/built-in.o drivers/usb/dwc3/built-in.o drivers/usb/emul/built-in.o drivers/usb/eth/built-in.o drivers/usb/host/built-in.o drivers/usb/mtu3/built-in.o drivers/usb/musb-new/built-in.o drivers/usb/musb/built-in.o drivers/usb/phy/built-in.o drivers/usb/ulpi/built-in.o env/built-in.o fs/built-in.o lib/built-in.o net/built-in.o --no-whole-archive -L /opt/gcc-11.1.0-nolibc/riscv64-linux/bin/../lib/gcc/riscv64-linux/11.1.0 -lgcc -Map u-boot.map; true
riscv64-linux-ld.bfd: drivers/virtio/virtio-uclass.o: in function `virtio_uclass_child_pre_probe':
/home/uboot/u-boot-riscv/drivers/virtio/virtio-uclass.c:339: undefined reference to `__lshrdi3'
riscv64-linux-ld.bfd: /home/uboot/u-boot-riscv/drivers/virtio/virtio-uclass.c:311: undefined reference to `__ashldi3'
riscv64-linux-ld.bfd: /home/uboot/u-boot-riscv/drivers/virtio/virtio-uclass.c:310: undefined reference to `__ashldi3'
riscv64-linux-ld.bfd: drivers/nvme/nvme.o: in function `nvme_blk_rw':
/home/uboot/u-boot-riscv/drivers/nvme/nvme.c:776: undefined reference to `__lshrdi3'
riscv64-linux-ld.bfd: fs/ext4/ext4_common.o: in function `ext4fs_get_extent_block':
/home/uboot/u-boot-riscv/fs/ext4/ext4_common.c:1560: undefined reference to `__ashldi3'
riscv64-linux-ld.bfd: fs/ext4/dev.o: in function `ext4fs_set_blk_dev':
/home/uboot/u-boot-riscv/fs/ext4/dev.c:46: undefined reference to `__lshrdi3'
riscv64-linux-ld.bfd: lib/display_options.o: in function `print_size':
/home/uboot/u-boot-riscv/lib/display_options.c:103: undefined reference to `__lshrdi3'
riscv64-linux-ld.bfd: /home/uboot/u-boot-riscv/lib/display_options.c:102: undefined reference to `__ashldi3'
riscv64-linux-ld.bfd: /home/uboot/u-boot-riscv/lib/display_options.c:95: undefined reference to `__ashldi3'
riscv64-linux-ld.bfd: /home/uboot/u-boot-riscv/lib/display_options.c:124: undefined reference to `__lshrdi3'
riscv64-linux-ld.bfd: lib/vsprintf.o: in function `number':
/home/uboot/u-boot-riscv/lib/vsprintf.c:213: undefined reference to `__lshrdi3'
make: *** [Makefile:1800: u-boot] Error 1
Furthermore, Using the same container and perform the identical build commands listed above on master branch produce no error.
What seems a bit odd is that when testing qemu-riscv32_spl,
buildman still uses 64 bit toolchain for the build.
I am not sure what the effect of "riscv64-linux-ld.bfd -m elf32lriscv" is.
Do you have any thoughts ?
[1] https://mirrors.edge.kernel.org/pub/tools/crosstool/files/bin/x86_64/11.1.0/x86_64-gcc-11.1.0-nolibc-riscv64-linux.tar.xz
[2] https://hub.docker.com/layers/trini/u-boot-gitlab-ci-runner/focal-20220113-03Feb2022/images/sha256-b1cddec69526015c550ac8e528114c976ccd1a0e75676328c4f81b834e06b2b3?context=explore
Best regards,
Leo
> The only difference I see here is the gitlab-runner version (line 1).
>
> Thanks,
>
> Alex
>
> > Best regards,
> > Leo
> >
> > > >
> > > > Best regards,
> > > > Leo
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] riscv: Fix build against binutils 2.38
2022-03-01 3:21 ` Leo Liang
@ 2022-03-03 11:06 ` Leo Liang
2022-03-09 6:31 ` Leo Liang
0 siblings, 1 reply; 24+ messages in thread
From: Leo Liang @ 2022-03-03 11:06 UTC (permalink / raw)
To: Alexandre Ghiti
Cc: Rick Chen, Aurelien Jarno, Heinrich Schuchardt, u-boot, bmeng.cn
Hi Alex,
On Tue, Mar 01, 2022 at 03:21:56AM +0000, Leo Liang wrote:
> Hi Alex,
> On Mon, Feb 21, 2022 at 05:42:41PM +0100, Alexandre Ghiti wrote:
> > On Sat, Feb 19, 2022 at 9:52 AM Leo Liang <ycliang@andestech.com> wrote:
> > >
> > > Hi Alex,
> > > On Thu, Feb 17, 2022 at 11:28:46AM +0100, Alexandre Ghiti wrote:
> > > > Hi Leo,
> > > >
> > > > On Thu, Feb 17, 2022 at 10:25 AM Leo Liang <ycliang@andestech.com> wrote:
> > > > >
> > > > > Hi Alexandre,
> > > > > On Fri, Jan 28, 2022 at 02:47:13PM +0100, Alexandre Ghiti wrote:
> > > > > > The following description is copied from the equivalent patch for the
> > > > > > Linux Kernel proposed by Aurelien Jarno:
> > > > > >
> > > > > > From version 2.38, binutils default to ISA spec version 20191213. This
> > > > > > means that the csr read/write (csrr*/csrw*) instructions and fence.i
> > > > > > instruction has separated from the `I` extension, become two standalone
> > > > > > extensions: Zicsr and Zifencei. As the kernel uses those instruction,
> > > > > > this causes the following build failure:
> > > > > >
> > > > > > arch/riscv/cpu/mtrap.S: Assembler messages:
> > > > > > arch/riscv/cpu/mtrap.S:65: Error: unrecognized opcode `csrr a0,scause'
> > > > > > arch/riscv/cpu/mtrap.S:66: Error: unrecognized opcode `csrr a1,sepc'
> > > > > > arch/riscv/cpu/mtrap.S:67: Error: unrecognized opcode `csrr a2,stval'
> > > > > > arch/riscv/cpu/mtrap.S:70: Error: unrecognized opcode `csrw sepc,a0'
> > > > > >
> > > > > > Signed-off-by: Alexandre Ghiti <alexandre.ghiti@canonical.com>
> > > > > > ---
> > > > > > arch/riscv/Makefile | 11 ++++++++++-
> > > > > > 1 file changed, 10 insertions(+), 1 deletion(-)
> > > > >
> > > > > This patch seems to fail CI somehow.
> > > > > (https://source.denx.de/u-boot/custodians/u-boot-riscv/-/pipelines/11004)
> > > > >
> > > > > Could you take a look at it ?
> > > >
> > > > I have just tried on master (commit ab8903a24db1) and it failed for
> > > > the same reason, so this is not related to this patch. Nevertheless,
> > > > I'll try to bisect the problem :)
> > > >
> > > > Thanks,
> > > >
> > > > Alex
> > > >
> > >
> > > Thanks for putting the effort into it!
> > >
> > > AFAIK, this patch does nothing related to the error message "undefined reference to `__ashldi3'" from the failed CI.
> > >
> > > Nonetheless, I have tried a few times myself,
> > > and found that CI could pass with ab8903a24db1 but cannot pass with this patch on my side.
> > > https://source.denx.de/u-boot/custodians/u-boot-riscv/-/commits/staging
> > > https://source.denx.de/u-boot/custodians/u-boot-riscv/-/pipelines
> > >
> >
> > To me it is an issue with the toolchain: libgcc is missing those
> > symbols. If I use an Ubuntu toolchain, it fails no matter which commit
> > I am on (I tested as far as v2021.10). But if I use a toolchain from
> > https://mirrors.edge.kernel.org/pub/tools/crosstool/files/bin/x86_64/,
> > it works fine.
> >
> > What I don't understand is how you manage to have different build
> > results with the same docker image: can you confirm that you use the
> > same toolchains in the following builds?
> >
> > https://source.denx.de/u-boot/custodians/u-boot-riscv/-/jobs/393701
> > https://source.denx.de/u-boot/custodians/u-boot-riscv/-/jobs/393783
> >
>
> Sorry for the late reply.
> I have checked the toolchain version of these two builds,
> they are using the same toolchain[1] from Tom's docker image on docker hub[2].
>
> Also the fail is reproducible using this docker image with the following commands:
>
> leo@host sudo docker run -it --name leo-test trini/u-boot-gitlab-ci-runner:focal-20220113-03Feb2022 /bin/bash
> uboot@356268d27bf0:~$ git clone https://source.denx.de/u-boot/custodians/u-boot-riscv.git && cd u-boot-riscv
> uboot@356268d27bf0:~/u-boot-riscv$ git checkout staging
> uboot@356268d27bf0:~/u-boot-riscv$ export PATH=/opt/gcc-11.1.0-nolibc/riscv64-linux/bin:$PATH
> uboot@356268d27bf0:~/u-boot-riscv$ export CROSS_COMPILE=riscv64-linux-
> uboot@356268d27bf0:~/u-boot-riscv$ make qemu-riscv32_spl_defconfig
> uboot@356268d27bf0:~/u-boot-riscv$ make -j`nproc` V=1
>
> ...
>
> riscv64-linux-ld.bfd -m elf32lriscv --gc-sections -static -pie -Bstatic --no-dynamic-linker -z notext --build-id=none -Ttext 0x81200000 -o u-boot -T u-boot.lds arch/riscv/cpu/start.o --whole-archive arch/riscv/cpu/built-in.o arch/riscv/cpu/generic/built-in.o arch/riscv/lib/built-in.o board/emulation/common/built-in.o board/emulation/qemu-riscv/built-in.o boot/built-in.o cmd/built-in.o common/built-in.o disk/built-in.o drivers/built-in.o drivers/usb/cdns3/built-in.o drivers/usb/common/built-in.o drivers/usb/dwc3/built-in.o drivers/usb/emul/built-in.o drivers/usb/eth/built-in.o drivers/usb/host/built-in.o drivers/usb/mtu3/built-in.o drivers/usb/musb-new/built-in.o drivers/usb/musb/built-in.o drivers/usb/phy/built-in.o drivers/usb/ulpi/built-in.o env/built-in.o fs/built-in.o lib/built-in.o net/built-in.o --no-whole-archive -L /opt/gcc-11.1.0-nolibc/riscv64-linux/bin/../lib/gcc/riscv64-linux/11.1.0 -lgcc -Map u-boot.map; true
> riscv64-linux-ld.bfd: drivers/virtio/virtio-uclass.o: in function `virtio_uclass_child_pre_probe':
> /home/uboot/u-boot-riscv/drivers/virtio/virtio-uclass.c:339: undefined reference to `__lshrdi3'
> riscv64-linux-ld.bfd: /home/uboot/u-boot-riscv/drivers/virtio/virtio-uclass.c:311: undefined reference to `__ashldi3'
> riscv64-linux-ld.bfd: /home/uboot/u-boot-riscv/drivers/virtio/virtio-uclass.c:310: undefined reference to `__ashldi3'
> riscv64-linux-ld.bfd: drivers/nvme/nvme.o: in function `nvme_blk_rw':
> /home/uboot/u-boot-riscv/drivers/nvme/nvme.c:776: undefined reference to `__lshrdi3'
> riscv64-linux-ld.bfd: fs/ext4/ext4_common.o: in function `ext4fs_get_extent_block':
> /home/uboot/u-boot-riscv/fs/ext4/ext4_common.c:1560: undefined reference to `__ashldi3'
> riscv64-linux-ld.bfd: fs/ext4/dev.o: in function `ext4fs_set_blk_dev':
> /home/uboot/u-boot-riscv/fs/ext4/dev.c:46: undefined reference to `__lshrdi3'
> riscv64-linux-ld.bfd: lib/display_options.o: in function `print_size':
> /home/uboot/u-boot-riscv/lib/display_options.c:103: undefined reference to `__lshrdi3'
> riscv64-linux-ld.bfd: /home/uboot/u-boot-riscv/lib/display_options.c:102: undefined reference to `__ashldi3'
> riscv64-linux-ld.bfd: /home/uboot/u-boot-riscv/lib/display_options.c:95: undefined reference to `__ashldi3'
> riscv64-linux-ld.bfd: /home/uboot/u-boot-riscv/lib/display_options.c:124: undefined reference to `__lshrdi3'
> riscv64-linux-ld.bfd: lib/vsprintf.o: in function `number':
> /home/uboot/u-boot-riscv/lib/vsprintf.c:213: undefined reference to `__lshrdi3'
> make: *** [Makefile:1800: u-boot] Error 1
>
> Furthermore, Using the same container and perform the identical build commands listed above on master branch produce no error.
>
> What seems a bit odd is that when testing qemu-riscv32_spl,
> buildman still uses 64 bit toolchain for the build.
> I am not sure what the effect of "riscv64-linux-ld.bfd -m elf32lriscv" is.
>
> Do you have any thoughts ?
>
> [1] https://mirrors.edge.kernel.org/pub/tools/crosstool/files/bin/x86_64/11.1.0/x86_64-gcc-11.1.0-nolibc-riscv64-linux.tar.xz
> [2] https://hub.docker.com/layers/trini/u-boot-gitlab-ci-runner/focal-20220113-03Feb2022/images/sha256-b1cddec69526015c550ac8e528114c976ccd1a0e75676328c4f81b834e06b2b3?context=explore
>
> Best regards,
> Leo
>
I re-ran again with buildman's verbose option (./tools/buildman/buildman -o /tmp/qemu-riscv32_spl/ -w -E -W -e -V -v --board qemu-riscv32_spl)
and found that the failed command is as below:
riscv64-linux-ld.bfd -m elf32lriscv --gc-sections -static -pie -Bstatic --no-dynamic-linker -z notext --build-id=none -Ttext 0x81200000 -o u-boot -T u-boot.lds arch/riscv/cpu/start.o --whole-archive arch/riscv/cpu/built-in.o arch/riscv/cpu/generic/built-in.o arch/riscv/lib/built-in.o board/emulation/common/built-in.o board/emulation/qemu-riscv/built-in.o boot/built-in.o cmd/built-in.o common/built-in.o disk/built-in.o drivers/built-in.o drivers/usb/cdns3/built-in.o drivers/usb/common/built-in.o drivers/usb/dwc3/built-in.o drivers/usb/emul/built-in.o drivers/usb/eth/built-in.o drivers/usb/host/built-in.o drivers/usb/mtu3/built-in.o drivers/usb/musb-new/built-in.o drivers/usb/musb/built-in.o drivers/usb/phy/built-in.o drivers/usb/ulpi/built-in.o env/built-in.o fs/built-in.o lib/built-in.o net/built-in.o --no-whole-archive -L /opt/gcc-11.1.0-nolibc/riscv64-linux/bin/../lib/gcc/riscv64-linux/11.1.0 -lgcc -Map u-boot.map; true
^^^^^^^^^^^^^^^^^^^^^^
The reason for this to fail is due to the wrong search path for libgcc.
The above command uses "-L /opt/gcc-11.1.0-nolibc/riscv64-linux/bin/../lib/gcc/riscv64-linux/11.1.0",
where it should be "-L /opt/gcc-11.1.0-nolibc/riscv64-linux/bin/../lib/gcc/riscv64-linux/11.1.0/lib32/ilp32[d]".
This search path is generated from Makefile:865 `PLATFORM_LIBGCC := -L $(shell dirname `$(CC) $(c_flags) -print-libgcc-file-name`) -lgcc`.
I'll try to find out how buildman executes the make process.
```
$ ./tools/buildman/buildman -o /tmp/qemu-riscv32_spl/ -w -E -W -e -V -v --board qemu-riscv32_spl
$ cat /tmp/qemu-riscv32_spl/log | grep u-boot.map
riscv64-linux-ld.bfd -m elf32lriscv --gc-sections -static -pie -Bstatic --no-dynamic-linker -z notext --build-id=none -Ttext 0x81200000 -o u-boot -T u-boot.lds arch/riscv/cpu/start.o --whole-archive arch/riscv/cpu/built-in.o arch/riscv/cpu/generic/built-in.o arch/riscv/lib/built-in.o board/emulation/common/built-in.o board/emulation/qemu-riscv/built-in.o boot/built-in.o cmd/built-in.o common/built-in.o disk/built-in.o drivers/built-in.o drivers/usb/cdns3/built-in.o drivers/usb/common/built-in.o drivers/usb/dwc3/built-in.o drivers/usb/emul/built-in.o drivers/usb/eth/built-in.o drivers/usb/host/built-in.o drivers/usb/mtu3/built-in.o drivers/usb/musb-new/built-in.o drivers/usb/musb/built-in.o drivers/usb/phy/built-in.o drivers/usb/ulpi/built-in.o env/built-in.o fs/built-in.o lib/built-in.o net/built-in.o --no-whole-archive -L /opt/gcc-11.1.0-nolibc/riscv64-linux/bin/../lib/gcc/riscv64-linux/11.1.0 -lgcc -Map u-boot.map; true
```
Best regards,
Leo
>
> > The only difference I see here is the gitlab-runner version (line 1).
> >
> > Thanks,
> >
> > Alex
> >
> > > Best regards,
> > > Leo
> > >
> > > > >
> > > > > Best regards,
> > > > > Leo
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] riscv: Fix build against binutils 2.38
2022-03-03 11:06 ` Leo Liang
@ 2022-03-09 6:31 ` Leo Liang
2022-03-10 8:03 ` Alexandre Ghiti
2022-10-01 23:24 ` Heinrich Schuchardt
0 siblings, 2 replies; 24+ messages in thread
From: Leo Liang @ 2022-03-09 6:31 UTC (permalink / raw)
To: Alexandre Ghiti
Cc: Rick Chen, Aurelien Jarno, Heinrich Schuchardt, u-boot, bmeng.cn,
sjg, trini
Hi Alex,
On Thu, Mar 03, 2022 at 11:06:18AM +0000, Leo Liang wrote:
> Hi Alex,
> On Tue, Mar 01, 2022 at 03:21:56AM +0000, Leo Liang wrote:
> > Hi Alex,
> > On Mon, Feb 21, 2022 at 05:42:41PM +0100, Alexandre Ghiti wrote:
> > > On Sat, Feb 19, 2022 at 9:52 AM Leo Liang <ycliang@andestech.com> wrote:
> > > >
> > > > Hi Alex,
> > > > On Thu, Feb 17, 2022 at 11:28:46AM +0100, Alexandre Ghiti wrote:
> > > > > Hi Leo,
> > > > >
> > > > > On Thu, Feb 17, 2022 at 10:25 AM Leo Liang <ycliang@andestech.com> wrote:
> > > > > >
> > > > > > Hi Alexandre,
> > > > > > On Fri, Jan 28, 2022 at 02:47:13PM +0100, Alexandre Ghiti wrote:
> > > > > > > The following description is copied from the equivalent patch for the
> > > > > > > Linux Kernel proposed by Aurelien Jarno:
> > > > > > >
> > > > > > > From version 2.38, binutils default to ISA spec version 20191213. This
> > > > > > > means that the csr read/write (csrr*/csrw*) instructions and fence.i
> > > > > > > instruction has separated from the `I` extension, become two standalone
> > > > > > > extensions: Zicsr and Zifencei. As the kernel uses those instruction,
> > > > > > > this causes the following build failure:
> > > > > > >
> > > > > > > arch/riscv/cpu/mtrap.S: Assembler messages:
> > > > > > > arch/riscv/cpu/mtrap.S:65: Error: unrecognized opcode `csrr a0,scause'
> > > > > > > arch/riscv/cpu/mtrap.S:66: Error: unrecognized opcode `csrr a1,sepc'
> > > > > > > arch/riscv/cpu/mtrap.S:67: Error: unrecognized opcode `csrr a2,stval'
> > > > > > > arch/riscv/cpu/mtrap.S:70: Error: unrecognized opcode `csrw sepc,a0'
> > > > > > >
> > > > > > > Signed-off-by: Alexandre Ghiti <alexandre.ghiti@canonical.com>
> > > > > > > ---
> > > > > > > arch/riscv/Makefile | 11 ++++++++++-
> > > > > > > 1 file changed, 10 insertions(+), 1 deletion(-)
> > > > > >
> > > > > > This patch seems to fail CI somehow.
> > > > > > (https://source.denx.de/u-boot/custodians/u-boot-riscv/-/pipelines/11004)
> > > > > >
> > > > > > Could you take a look at it ?
> > > > >
> > > > > I have just tried on master (commit ab8903a24db1) and it failed for
> > > > > the same reason, so this is not related to this patch. Nevertheless,
> > > > > I'll try to bisect the problem :)
> > > > >
> > > > > Thanks,
> > > > >
> > > > > Alex
> > > > >
> > > >
> > > > Thanks for putting the effort into it!
> > > >
> > > > AFAIK, this patch does nothing related to the error message "undefined reference to `__ashldi3'" from the failed CI.
> > > >
> > > > Nonetheless, I have tried a few times myself,
> > > > and found that CI could pass with ab8903a24db1 but cannot pass with this patch on my side.
> > > > https://source.denx.de/u-boot/custodians/u-boot-riscv/-/commits/staging
> > > > https://source.denx.de/u-boot/custodians/u-boot-riscv/-/pipelines
> > > >
> > >
> > > To me it is an issue with the toolchain: libgcc is missing those
> > > symbols. If I use an Ubuntu toolchain, it fails no matter which commit
> > > I am on (I tested as far as v2021.10). But if I use a toolchain from
> > > https://mirrors.edge.kernel.org/pub/tools/crosstool/files/bin/x86_64/,
> > > it works fine.
> > >
> > > What I don't understand is how you manage to have different build
> > > results with the same docker image: can you confirm that you use the
> > > same toolchains in the following builds?
> > >
> > > https://source.denx.de/u-boot/custodians/u-boot-riscv/-/jobs/393701
> > > https://source.denx.de/u-boot/custodians/u-boot-riscv/-/jobs/393783
> > >
> >
> > Sorry for the late reply.
> > I have checked the toolchain version of these two builds,
> > they are using the same toolchain[1] from Tom's docker image on docker hub[2].
> >
> > Also the fail is reproducible using this docker image with the following commands:
> >
> > leo@host sudo docker run -it --name leo-test trini/u-boot-gitlab-ci-runner:focal-20220113-03Feb2022 /bin/bash
> > uboot@356268d27bf0:~$ git clone https://source.denx.de/u-boot/custodians/u-boot-riscv.git && cd u-boot-riscv
> > uboot@356268d27bf0:~/u-boot-riscv$ git checkout staging
> > uboot@356268d27bf0:~/u-boot-riscv$ export PATH=/opt/gcc-11.1.0-nolibc/riscv64-linux/bin:$PATH
> > uboot@356268d27bf0:~/u-boot-riscv$ export CROSS_COMPILE=riscv64-linux-
> > uboot@356268d27bf0:~/u-boot-riscv$ make qemu-riscv32_spl_defconfig
> > uboot@356268d27bf0:~/u-boot-riscv$ make -j`nproc` V=1
> >
> > ...
> >
> > riscv64-linux-ld.bfd -m elf32lriscv --gc-sections -static -pie -Bstatic --no-dynamic-linker -z notext --build-id=none -Ttext 0x81200000 -o u-boot -T u-boot.lds arch/riscv/cpu/start.o --whole-archive arch/riscv/cpu/built-in.o arch/riscv/cpu/generic/built-in.o arch/riscv/lib/built-in.o board/emulation/common/built-in.o board/emulation/qemu-riscv/built-in.o boot/built-in.o cmd/built-in.o common/built-in.o disk/built-in.o drivers/built-in.o drivers/usb/cdns3/built-in.o drivers/usb/common/built-in.o drivers/usb/dwc3/built-in.o drivers/usb/emul/built-in.o drivers/usb/eth/built-in.o drivers/usb/host/built-in.o drivers/usb/mtu3/built-in.o drivers/usb/musb-new/built-in.o drivers/usb/musb/built-in.o drivers/usb/phy/built-in.o drivers/usb/ulpi/built-in.o env/built-in.o fs/built-in.o lib/built-in.o net/built-in.o --no-whole-archive -L /opt/gcc-11.1.0-nolibc/riscv64-linux/bin/../lib/gcc/riscv64-linux/11.1.0 -lgcc -Map u-boot.map; true
> > riscv64-linux-ld.bfd: drivers/virtio/virtio-uclass.o: in function `virtio_uclass_child_pre_probe':
> > /home/uboot/u-boot-riscv/drivers/virtio/virtio-uclass.c:339: undefined reference to `__lshrdi3'
> > riscv64-linux-ld.bfd: /home/uboot/u-boot-riscv/drivers/virtio/virtio-uclass.c:311: undefined reference to `__ashldi3'
> > riscv64-linux-ld.bfd: /home/uboot/u-boot-riscv/drivers/virtio/virtio-uclass.c:310: undefined reference to `__ashldi3'
> > riscv64-linux-ld.bfd: drivers/nvme/nvme.o: in function `nvme_blk_rw':
> > /home/uboot/u-boot-riscv/drivers/nvme/nvme.c:776: undefined reference to `__lshrdi3'
> > riscv64-linux-ld.bfd: fs/ext4/ext4_common.o: in function `ext4fs_get_extent_block':
> > /home/uboot/u-boot-riscv/fs/ext4/ext4_common.c:1560: undefined reference to `__ashldi3'
> > riscv64-linux-ld.bfd: fs/ext4/dev.o: in function `ext4fs_set_blk_dev':
> > /home/uboot/u-boot-riscv/fs/ext4/dev.c:46: undefined reference to `__lshrdi3'
> > riscv64-linux-ld.bfd: lib/display_options.o: in function `print_size':
> > /home/uboot/u-boot-riscv/lib/display_options.c:103: undefined reference to `__lshrdi3'
> > riscv64-linux-ld.bfd: /home/uboot/u-boot-riscv/lib/display_options.c:102: undefined reference to `__ashldi3'
> > riscv64-linux-ld.bfd: /home/uboot/u-boot-riscv/lib/display_options.c:95: undefined reference to `__ashldi3'
> > riscv64-linux-ld.bfd: /home/uboot/u-boot-riscv/lib/display_options.c:124: undefined reference to `__lshrdi3'
> > riscv64-linux-ld.bfd: lib/vsprintf.o: in function `number':
> > /home/uboot/u-boot-riscv/lib/vsprintf.c:213: undefined reference to `__lshrdi3'
> > make: *** [Makefile:1800: u-boot] Error 1
> >
> > Furthermore, Using the same container and perform the identical build commands listed above on master branch produce no error.
> >
> > What seems a bit odd is that when testing qemu-riscv32_spl,
> > buildman still uses 64 bit toolchain for the build.
> > I am not sure what the effect of "riscv64-linux-ld.bfd -m elf32lriscv" is.
> >
> > Do you have any thoughts ?
> >
> > [1] https://mirrors.edge.kernel.org/pub/tools/crosstool/files/bin/x86_64/11.1.0/x86_64-gcc-11.1.0-nolibc-riscv64-linux.tar.xz
> > [2] https://hub.docker.com/layers/trini/u-boot-gitlab-ci-runner/focal-20220113-03Feb2022/images/sha256-b1cddec69526015c550ac8e528114c976ccd1a0e75676328c4f81b834e06b2b3?context=explore
> >
> > Best regards,
> > Leo
> >
>
> I re-ran again with buildman's verbose option (./tools/buildman/buildman -o /tmp/qemu-riscv32_spl/ -w -E -W -e -V -v --board qemu-riscv32_spl)
> and found that the failed command is as below:
>
> riscv64-linux-ld.bfd -m elf32lriscv --gc-sections -static -pie -Bstatic --no-dynamic-linker -z notext --build-id=none -Ttext 0x81200000 -o u-boot -T u-boot.lds arch/riscv/cpu/start.o --whole-archive arch/riscv/cpu/built-in.o arch/riscv/cpu/generic/built-in.o arch/riscv/lib/built-in.o board/emulation/common/built-in.o board/emulation/qemu-riscv/built-in.o boot/built-in.o cmd/built-in.o common/built-in.o disk/built-in.o drivers/built-in.o drivers/usb/cdns3/built-in.o drivers/usb/common/built-in.o drivers/usb/dwc3/built-in.o drivers/usb/emul/built-in.o drivers/usb/eth/built-in.o drivers/usb/host/built-in.o drivers/usb/mtu3/built-in.o drivers/usb/musb-new/built-in.o drivers/usb/musb/built-in.o drivers/usb/phy/built-in.o drivers/usb/ulpi/built-in.o env/built-in.o fs/built-in.o lib/built-in.o net/built-in.o --no-whole-archive -L /opt/gcc-11.1.0-nolibc/riscv64-linux/bin/../lib/gcc/riscv64-linux/11.1.0 -lgcc -Map u-boot.map; true
> ^^^^^^^^^^^^^^^^^^^^^^
>
> The reason for this to fail is due to the wrong search path for libgcc.
> The above command uses "-L /opt/gcc-11.1.0-nolibc/riscv64-linux/bin/../lib/gcc/riscv64-linux/11.1.0",
> where it should be "-L /opt/gcc-11.1.0-nolibc/riscv64-linux/bin/../lib/gcc/riscv64-linux/11.1.0/lib32/ilp32[d]".
>
> This search path is generated from Makefile:865 `PLATFORM_LIBGCC := -L $(shell dirname `$(CC) $(c_flags) -print-libgcc-file-name`) -lgcc`.
>
> I'll try to find out how buildman executes the make process.
>
> ```
> $ ./tools/buildman/buildman -o /tmp/qemu-riscv32_spl/ -w -E -W -e -V -v --board qemu-riscv32_spl
> $ cat /tmp/qemu-riscv32_spl/log | grep u-boot.map
> riscv64-linux-ld.bfd -m elf32lriscv --gc-sections -static -pie -Bstatic --no-dynamic-linker -z notext --build-id=none -Ttext 0x81200000 -o u-boot -T u-boot.lds arch/riscv/cpu/start.o --whole-archive arch/riscv/cpu/built-in.o arch/riscv/cpu/generic/built-in.o arch/riscv/lib/built-in.o board/emulation/common/built-in.o board/emulation/qemu-riscv/built-in.o boot/built-in.o cmd/built-in.o common/built-in.o disk/built-in.o drivers/built-in.o drivers/usb/cdns3/built-in.o drivers/usb/common/built-in.o drivers/usb/dwc3/built-in.o drivers/usb/emul/built-in.o drivers/usb/eth/built-in.o drivers/usb/host/built-in.o drivers/usb/mtu3/built-in.o drivers/usb/musb-new/built-in.o drivers/usb/musb/built-in.o drivers/usb/phy/built-in.o drivers/usb/ulpi/built-in.o env/built-in.o fs/built-in.o lib/built-in.o net/built-in.o --no-whole-archive -L /opt/gcc-11.1.0-nolibc/riscv64-linux/bin/../lib/gcc/riscv64-linux/11.1.0 -lgcc -Map u-boot.map; true
> ```
>
This patch looks valid, it's the CI process which causes the error to occur.
The command "dirname $(riscv64-linux-gcc -march=rv32imac -mabi=ilp32 -print-libgcc-filename)" gives
different result from "dirname $(riscv64-linux-gcc -march=rv32imac_zicsr_zifencei -mabi=ilp32 -print-libgcc-filename)".
The former gives "/opt/gcc-11.1.0-nolibc/riscv64-linux/bin/../lib/gcc/riscv64-linux/11.1.0/lib32/ilp32"
while the latter gives "/opt/gcc-11.1.0-nolibc/riscv64-linux/bin/../lib/gcc/riscv64-linux/11.1.0".
The symbol __ashldi3 and __lshrdi3 only exist in libgcc.a under /opt/gcc-11.1.0-nolibc/riscv64-linux/bin/../lib/gcc/riscv64-linux/11.1.0/lib32/ilp32,
so linker search path have to be set to it to link successfully.
The multilib setting does not cover zifencei and zicsr, so we get a default multilib path from -print-libgcc-file-name, and thus run into error like this.
We should be able to fix this by using 32 bit toolchain in the CI process for 32 bit platform/configuration.
Any thoughts or comments ?
Best regards,
Leo
> Best regards,
> Leo
>
> >
> > > The only difference I see here is the gitlab-runner version (line 1).
> > >
> > > Thanks,
> > >
> > > Alex
> > >
> > > > Best regards,
> > > > Leo
> > > >
> > > > > >
> > > > > > Best regards,
> > > > > > Leo
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] riscv: Fix build against binutils 2.38
2022-03-09 6:31 ` Leo Liang
@ 2022-03-10 8:03 ` Alexandre Ghiti
2022-04-07 9:12 ` Leo Liang
2022-10-01 23:24 ` Heinrich Schuchardt
1 sibling, 1 reply; 24+ messages in thread
From: Alexandre Ghiti @ 2022-03-10 8:03 UTC (permalink / raw)
To: Leo Liang
Cc: Rick Chen, Aurelien Jarno, Heinrich Schuchardt, u-boot, bmeng.cn,
sjg, trini
Hi Leo,
On Wed, Mar 9, 2022 at 7:31 AM Leo Liang <ycliang@andestech.com> wrote:
>
> Hi Alex,
> On Thu, Mar 03, 2022 at 11:06:18AM +0000, Leo Liang wrote:
> > Hi Alex,
> > On Tue, Mar 01, 2022 at 03:21:56AM +0000, Leo Liang wrote:
> > > Hi Alex,
> > > On Mon, Feb 21, 2022 at 05:42:41PM +0100, Alexandre Ghiti wrote:
> > > > On Sat, Feb 19, 2022 at 9:52 AM Leo Liang <ycliang@andestech.com> wrote:
> > > > >
> > > > > Hi Alex,
> > > > > On Thu, Feb 17, 2022 at 11:28:46AM +0100, Alexandre Ghiti wrote:
> > > > > > Hi Leo,
> > > > > >
> > > > > > On Thu, Feb 17, 2022 at 10:25 AM Leo Liang <ycliang@andestech.com> wrote:
> > > > > > >
> > > > > > > Hi Alexandre,
> > > > > > > On Fri, Jan 28, 2022 at 02:47:13PM +0100, Alexandre Ghiti wrote:
> > > > > > > > The following description is copied from the equivalent patch for the
> > > > > > > > Linux Kernel proposed by Aurelien Jarno:
> > > > > > > >
> > > > > > > > From version 2.38, binutils default to ISA spec version 20191213. This
> > > > > > > > means that the csr read/write (csrr*/csrw*) instructions and fence.i
> > > > > > > > instruction has separated from the `I` extension, become two standalone
> > > > > > > > extensions: Zicsr and Zifencei. As the kernel uses those instruction,
> > > > > > > > this causes the following build failure:
> > > > > > > >
> > > > > > > > arch/riscv/cpu/mtrap.S: Assembler messages:
> > > > > > > > arch/riscv/cpu/mtrap.S:65: Error: unrecognized opcode `csrr a0,scause'
> > > > > > > > arch/riscv/cpu/mtrap.S:66: Error: unrecognized opcode `csrr a1,sepc'
> > > > > > > > arch/riscv/cpu/mtrap.S:67: Error: unrecognized opcode `csrr a2,stval'
> > > > > > > > arch/riscv/cpu/mtrap.S:70: Error: unrecognized opcode `csrw sepc,a0'
> > > > > > > >
> > > > > > > > Signed-off-by: Alexandre Ghiti <alexandre.ghiti@canonical.com>
> > > > > > > > ---
> > > > > > > > arch/riscv/Makefile | 11 ++++++++++-
> > > > > > > > 1 file changed, 10 insertions(+), 1 deletion(-)
> > > > > > >
> > > > > > > This patch seems to fail CI somehow.
> > > > > > > (https://source.denx.de/u-boot/custodians/u-boot-riscv/-/pipelines/11004)
> > > > > > >
> > > > > > > Could you take a look at it ?
> > > > > >
> > > > > > I have just tried on master (commit ab8903a24db1) and it failed for
> > > > > > the same reason, so this is not related to this patch. Nevertheless,
> > > > > > I'll try to bisect the problem :)
> > > > > >
> > > > > > Thanks,
> > > > > >
> > > > > > Alex
> > > > > >
> > > > >
> > > > > Thanks for putting the effort into it!
> > > > >
> > > > > AFAIK, this patch does nothing related to the error message "undefined reference to `__ashldi3'" from the failed CI.
> > > > >
> > > > > Nonetheless, I have tried a few times myself,
> > > > > and found that CI could pass with ab8903a24db1 but cannot pass with this patch on my side.
> > > > > https://source.denx.de/u-boot/custodians/u-boot-riscv/-/commits/staging
> > > > > https://source.denx.de/u-boot/custodians/u-boot-riscv/-/pipelines
> > > > >
> > > >
> > > > To me it is an issue with the toolchain: libgcc is missing those
> > > > symbols. If I use an Ubuntu toolchain, it fails no matter which commit
> > > > I am on (I tested as far as v2021.10). But if I use a toolchain from
> > > > https://mirrors.edge.kernel.org/pub/tools/crosstool/files/bin/x86_64/,
> > > > it works fine.
> > > >
> > > > What I don't understand is how you manage to have different build
> > > > results with the same docker image: can you confirm that you use the
> > > > same toolchains in the following builds?
> > > >
> > > > https://source.denx.de/u-boot/custodians/u-boot-riscv/-/jobs/393701
> > > > https://source.denx.de/u-boot/custodians/u-boot-riscv/-/jobs/393783
> > > >
> > >
> > > Sorry for the late reply.
> > > I have checked the toolchain version of these two builds,
> > > they are using the same toolchain[1] from Tom's docker image on docker hub[2].
> > >
> > > Also the fail is reproducible using this docker image with the following commands:
> > >
> > > leo@host sudo docker run -it --name leo-test trini/u-boot-gitlab-ci-runner:focal-20220113-03Feb2022 /bin/bash
> > > uboot@356268d27bf0:~$ git clone https://source.denx.de/u-boot/custodians/u-boot-riscv.git && cd u-boot-riscv
> > > uboot@356268d27bf0:~/u-boot-riscv$ git checkout staging
> > > uboot@356268d27bf0:~/u-boot-riscv$ export PATH=/opt/gcc-11.1.0-nolibc/riscv64-linux/bin:$PATH
> > > uboot@356268d27bf0:~/u-boot-riscv$ export CROSS_COMPILE=riscv64-linux-
> > > uboot@356268d27bf0:~/u-boot-riscv$ make qemu-riscv32_spl_defconfig
> > > uboot@356268d27bf0:~/u-boot-riscv$ make -j`nproc` V=1
> > >
> > > ...
> > >
> > > riscv64-linux-ld.bfd -m elf32lriscv --gc-sections -static -pie -Bstatic --no-dynamic-linker -z notext --build-id=none -Ttext 0x81200000 -o u-boot -T u-boot.lds arch/riscv/cpu/start.o --whole-archive arch/riscv/cpu/built-in.o arch/riscv/cpu/generic/built-in.o arch/riscv/lib/built-in.o board/emulation/common/built-in.o board/emulation/qemu-riscv/built-in.o boot/built-in.o cmd/built-in.o common/built-in.o disk/built-in.o drivers/built-in.o drivers/usb/cdns3/built-in.o drivers/usb/common/built-in.o drivers/usb/dwc3/built-in.o drivers/usb/emul/built-in.o drivers/usb/eth/built-in.o drivers/usb/host/built-in.o drivers/usb/mtu3/built-in.o drivers/usb/musb-new/built-in.o drivers/usb/musb/built-in.o drivers/usb/phy/built-in.o drivers/usb/ulpi/built-in.o env/built-in.o fs/built-in.o lib/built-in.o net/built-in.o --no-whole-archive -L /opt/gcc-11.1.0-nolibc/riscv64-linux/bin/../lib/gcc/riscv64-linux/11.1.0 -lgcc -Map u-boot.map; true
> > > riscv64-linux-ld.bfd: drivers/virtio/virtio-uclass.o: in function `virtio_uclass_child_pre_probe':
> > > /home/uboot/u-boot-riscv/drivers/virtio/virtio-uclass.c:339: undefined reference to `__lshrdi3'
> > > riscv64-linux-ld.bfd: /home/uboot/u-boot-riscv/drivers/virtio/virtio-uclass.c:311: undefined reference to `__ashldi3'
> > > riscv64-linux-ld.bfd: /home/uboot/u-boot-riscv/drivers/virtio/virtio-uclass.c:310: undefined reference to `__ashldi3'
> > > riscv64-linux-ld.bfd: drivers/nvme/nvme.o: in function `nvme_blk_rw':
> > > /home/uboot/u-boot-riscv/drivers/nvme/nvme.c:776: undefined reference to `__lshrdi3'
> > > riscv64-linux-ld.bfd: fs/ext4/ext4_common.o: in function `ext4fs_get_extent_block':
> > > /home/uboot/u-boot-riscv/fs/ext4/ext4_common.c:1560: undefined reference to `__ashldi3'
> > > riscv64-linux-ld.bfd: fs/ext4/dev.o: in function `ext4fs_set_blk_dev':
> > > /home/uboot/u-boot-riscv/fs/ext4/dev.c:46: undefined reference to `__lshrdi3'
> > > riscv64-linux-ld.bfd: lib/display_options.o: in function `print_size':
> > > /home/uboot/u-boot-riscv/lib/display_options.c:103: undefined reference to `__lshrdi3'
> > > riscv64-linux-ld.bfd: /home/uboot/u-boot-riscv/lib/display_options.c:102: undefined reference to `__ashldi3'
> > > riscv64-linux-ld.bfd: /home/uboot/u-boot-riscv/lib/display_options.c:95: undefined reference to `__ashldi3'
> > > riscv64-linux-ld.bfd: /home/uboot/u-boot-riscv/lib/display_options.c:124: undefined reference to `__lshrdi3'
> > > riscv64-linux-ld.bfd: lib/vsprintf.o: in function `number':
> > > /home/uboot/u-boot-riscv/lib/vsprintf.c:213: undefined reference to `__lshrdi3'
> > > make: *** [Makefile:1800: u-boot] Error 1
> > >
> > > Furthermore, Using the same container and perform the identical build commands listed above on master branch produce no error.
> > >
> > > What seems a bit odd is that when testing qemu-riscv32_spl,
> > > buildman still uses 64 bit toolchain for the build.
> > > I am not sure what the effect of "riscv64-linux-ld.bfd -m elf32lriscv" is.
> > >
> > > Do you have any thoughts ?
> > >
> > > [1] https://mirrors.edge.kernel.org/pub/tools/crosstool/files/bin/x86_64/11.1.0/x86_64-gcc-11.1.0-nolibc-riscv64-linux.tar.xz
> > > [2] https://hub.docker.com/layers/trini/u-boot-gitlab-ci-runner/focal-20220113-03Feb2022/images/sha256-b1cddec69526015c550ac8e528114c976ccd1a0e75676328c4f81b834e06b2b3?context=explore
> > >
> > > Best regards,
> > > Leo
> > >
> >
> > I re-ran again with buildman's verbose option (./tools/buildman/buildman -o /tmp/qemu-riscv32_spl/ -w -E -W -e -V -v --board qemu-riscv32_spl)
> > and found that the failed command is as below:
> >
> > riscv64-linux-ld.bfd -m elf32lriscv --gc-sections -static -pie -Bstatic --no-dynamic-linker -z notext --build-id=none -Ttext 0x81200000 -o u-boot -T u-boot.lds arch/riscv/cpu/start.o --whole-archive arch/riscv/cpu/built-in.o arch/riscv/cpu/generic/built-in.o arch/riscv/lib/built-in.o board/emulation/common/built-in.o board/emulation/qemu-riscv/built-in.o boot/built-in.o cmd/built-in.o common/built-in.o disk/built-in.o drivers/built-in.o drivers/usb/cdns3/built-in.o drivers/usb/common/built-in.o drivers/usb/dwc3/built-in.o drivers/usb/emul/built-in.o drivers/usb/eth/built-in.o drivers/usb/host/built-in.o drivers/usb/mtu3/built-in.o drivers/usb/musb-new/built-in.o drivers/usb/musb/built-in.o drivers/usb/phy/built-in.o drivers/usb/ulpi/built-in.o env/built-in.o fs/built-in.o lib/built-in.o net/built-in.o --no-whole-archive -L /opt/gcc-11.1.0-nolibc/riscv64-linux/bin/../lib/gcc/riscv64-linux/11.1.0 -lgcc -Map u-boot.map; true
> > ^^^^^^^^^^^^^^^^^^^^^^
> >
> > The reason for this to fail is due to the wrong search path for libgcc.
> > The above command uses "-L /opt/gcc-11.1.0-nolibc/riscv64-linux/bin/../lib/gcc/riscv64-linux/11.1.0",
> > where it should be "-L /opt/gcc-11.1.0-nolibc/riscv64-linux/bin/../lib/gcc/riscv64-linux/11.1.0/lib32/ilp32[d]".
> >
> > This search path is generated from Makefile:865 `PLATFORM_LIBGCC := -L $(shell dirname `$(CC) $(c_flags) -print-libgcc-file-name`) -lgcc`.
> >
> > I'll try to find out how buildman executes the make process.
> >
> > ```
> > $ ./tools/buildman/buildman -o /tmp/qemu-riscv32_spl/ -w -E -W -e -V -v --board qemu-riscv32_spl
> > $ cat /tmp/qemu-riscv32_spl/log | grep u-boot.map
> > riscv64-linux-ld.bfd -m elf32lriscv --gc-sections -static -pie -Bstatic --no-dynamic-linker -z notext --build-id=none -Ttext 0x81200000 -o u-boot -T u-boot.lds arch/riscv/cpu/start.o --whole-archive arch/riscv/cpu/built-in.o arch/riscv/cpu/generic/built-in.o arch/riscv/lib/built-in.o board/emulation/common/built-in.o board/emulation/qemu-riscv/built-in.o boot/built-in.o cmd/built-in.o common/built-in.o disk/built-in.o drivers/built-in.o drivers/usb/cdns3/built-in.o drivers/usb/common/built-in.o drivers/usb/dwc3/built-in.o drivers/usb/emul/built-in.o drivers/usb/eth/built-in.o drivers/usb/host/built-in.o drivers/usb/mtu3/built-in.o drivers/usb/musb-new/built-in.o drivers/usb/musb/built-in.o drivers/usb/phy/built-in.o drivers/usb/ulpi/built-in.o env/built-in.o fs/built-in.o lib/built-in.o net/built-in.o --no-whole-archive -L /opt/gcc-11.1.0-nolibc/riscv64-linux/bin/../lib/gcc/riscv64-linux/11.1.0 -lgcc -Map u-boot.map; true
> > ```
> >
>
> This patch looks valid, it's the CI process which causes the error to occur.
>
> The command "dirname $(riscv64-linux-gcc -march=rv32imac -mabi=ilp32 -print-libgcc-filename)" gives
> different result from "dirname $(riscv64-linux-gcc -march=rv32imac_zicsr_zifencei -mabi=ilp32 -print-libgcc-filename)".
>
> The former gives "/opt/gcc-11.1.0-nolibc/riscv64-linux/bin/../lib/gcc/riscv64-linux/11.1.0/lib32/ilp32"
> while the latter gives "/opt/gcc-11.1.0-nolibc/riscv64-linux/bin/../lib/gcc/riscv64-linux/11.1.0".
>
> The symbol __ashldi3 and __lshrdi3 only exist in libgcc.a under /opt/gcc-11.1.0-nolibc/riscv64-linux/bin/../lib/gcc/riscv64-linux/11.1.0/lib32/ilp32,
> so linker search path have to be set to it to link successfully.
>
> The multilib setting does not cover zifencei and zicsr, so we get a default multilib path from -print-libgcc-file-name, and thus run into error like this.
>
> We should be able to fix this by using 32 bit toolchain in the CI process for 32 bit platform/configuration.
>
> Any thoughts or comments ?
Let me ask internally to the guy who handles the toolchains, he may
have an idea.
Thanks for looking into that,
Alex
>
> Best regards,
> Leo
>
> > Best regards,
> > Leo
> >
> > >
> > > > The only difference I see here is the gitlab-runner version (line 1).
> > > >
> > > > Thanks,
> > > >
> > > > Alex
> > > >
> > > > > Best regards,
> > > > > Leo
> > > > >
> > > > > > >
> > > > > > > Best regards,
> > > > > > > Leo
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] riscv: Fix build against binutils 2.38
2022-03-10 8:03 ` Alexandre Ghiti
@ 2022-04-07 9:12 ` Leo Liang
2022-04-12 9:14 ` Alexandre Ghiti
0 siblings, 1 reply; 24+ messages in thread
From: Leo Liang @ 2022-04-07 9:12 UTC (permalink / raw)
To: Alexandre Ghiti
Cc: Rick Chen, Aurelien Jarno, Heinrich Schuchardt, u-boot, bmeng.cn,
sjg, trini
Hi Alex,
On Thu, Mar 10, 2022 at 09:03:08AM +0100, Alexandre Ghiti wrote:
> Hi Leo,
>
> On Wed, Mar 9, 2022 at 7:31 AM Leo Liang <ycliang@andestech.com> wrote:
> >
> > Hi Alex,
> > On Thu, Mar 03, 2022 at 11:06:18AM +0000, Leo Liang wrote:
> > > Hi Alex,
> > > On Tue, Mar 01, 2022 at 03:21:56AM +0000, Leo Liang wrote:
> > > > Hi Alex,
> > > > On Mon, Feb 21, 2022 at 05:42:41PM +0100, Alexandre Ghiti wrote:
> > > > > On Sat, Feb 19, 2022 at 9:52 AM Leo Liang <ycliang@andestech.com> wrote:
> > > > > >
> > > > > > Hi Alex,
> > > > > > On Thu, Feb 17, 2022 at 11:28:46AM +0100, Alexandre Ghiti wrote:
> > > > > > > Hi Leo,
> > > > > > >
> > > > > > > On Thu, Feb 17, 2022 at 10:25 AM Leo Liang <ycliang@andestech.com> wrote:
> > > > > > > >
> > > > > > > > Hi Alexandre,
> > > > > > > > On Fri, Jan 28, 2022 at 02:47:13PM +0100, Alexandre Ghiti wrote:
> > > > > > > > > The following description is copied from the equivalent patch for the
> > > > > > > > > Linux Kernel proposed by Aurelien Jarno:
> > > > > > > > >
> > > > > > > > > From version 2.38, binutils default to ISA spec version 20191213. This
> > > > > > > > > means that the csr read/write (csrr*/csrw*) instructions and fence.i
> > > > > > > > > instruction has separated from the `I` extension, become two standalone
> > > > > > > > > extensions: Zicsr and Zifencei. As the kernel uses those instruction,
> > > > > > > > > this causes the following build failure:
> > > > > > > > >
> > > > > > > > > arch/riscv/cpu/mtrap.S: Assembler messages:
> > > > > > > > > arch/riscv/cpu/mtrap.S:65: Error: unrecognized opcode `csrr a0,scause'
> > > > > > > > > arch/riscv/cpu/mtrap.S:66: Error: unrecognized opcode `csrr a1,sepc'
> > > > > > > > > arch/riscv/cpu/mtrap.S:67: Error: unrecognized opcode `csrr a2,stval'
> > > > > > > > > arch/riscv/cpu/mtrap.S:70: Error: unrecognized opcode `csrw sepc,a0'
> > > > > > > > >
> > > > > > > > > Signed-off-by: Alexandre Ghiti <alexandre.ghiti@canonical.com>
> > > > > > > > > ---
> > > > > > > > > arch/riscv/Makefile | 11 ++++++++++-
> > > > > > > > > 1 file changed, 10 insertions(+), 1 deletion(-)
> > > > > > > >
> > > > > > > > This patch seems to fail CI somehow.
> > > > > > > > (https://source.denx.de/u-boot/custodians/u-boot-riscv/-/pipelines/11004)
> > > > > > > >
> > > > > > > > Could you take a look at it ?
> > > > > > >
> > > > > > > I have just tried on master (commit ab8903a24db1) and it failed for
> > > > > > > the same reason, so this is not related to this patch. Nevertheless,
> > > > > > > I'll try to bisect the problem :)
> > > > > > >
> > > > > > > Thanks,
> > > > > > >
> > > > > > > Alex
> > > > > > >
> > > > > >
> > > > > > Thanks for putting the effort into it!
> > > > > >
> > > > > > AFAIK, this patch does nothing related to the error message "undefined reference to `__ashldi3'" from the failed CI.
> > > > > >
> > > > > > Nonetheless, I have tried a few times myself,
> > > > > > and found that CI could pass with ab8903a24db1 but cannot pass with this patch on my side.
> > > > > > https://source.denx.de/u-boot/custodians/u-boot-riscv/-/commits/staging
> > > > > > https://source.denx.de/u-boot/custodians/u-boot-riscv/-/pipelines
> > > > > >
> > > > >
> > > > > To me it is an issue with the toolchain: libgcc is missing those
> > > > > symbols. If I use an Ubuntu toolchain, it fails no matter which commit
> > > > > I am on (I tested as far as v2021.10). But if I use a toolchain from
> > > > > https://mirrors.edge.kernel.org/pub/tools/crosstool/files/bin/x86_64/,
> > > > > it works fine.
> > > > >
> > > > > What I don't understand is how you manage to have different build
> > > > > results with the same docker image: can you confirm that you use the
> > > > > same toolchains in the following builds?
> > > > >
> > > > > https://source.denx.de/u-boot/custodians/u-boot-riscv/-/jobs/393701
> > > > > https://source.denx.de/u-boot/custodians/u-boot-riscv/-/jobs/393783
> > > > >
> > > >
> > > > Sorry for the late reply.
> > > > I have checked the toolchain version of these two builds,
> > > > they are using the same toolchain[1] from Tom's docker image on docker hub[2].
> > > >
> > > > Also the fail is reproducible using this docker image with the following commands:
> > > >
> > > > leo@host sudo docker run -it --name leo-test trini/u-boot-gitlab-ci-runner:focal-20220113-03Feb2022 /bin/bash
> > > > uboot@356268d27bf0:~$ git clone https://source.denx.de/u-boot/custodians/u-boot-riscv.git && cd u-boot-riscv
> > > > uboot@356268d27bf0:~/u-boot-riscv$ git checkout staging
> > > > uboot@356268d27bf0:~/u-boot-riscv$ export PATH=/opt/gcc-11.1.0-nolibc/riscv64-linux/bin:$PATH
> > > > uboot@356268d27bf0:~/u-boot-riscv$ export CROSS_COMPILE=riscv64-linux-
> > > > uboot@356268d27bf0:~/u-boot-riscv$ make qemu-riscv32_spl_defconfig
> > > > uboot@356268d27bf0:~/u-boot-riscv$ make -j`nproc` V=1
> > > >
> > > > ...
> > > >
> > > > riscv64-linux-ld.bfd -m elf32lriscv --gc-sections -static -pie -Bstatic --no-dynamic-linker -z notext --build-id=none -Ttext 0x81200000 -o u-boot -T u-boot.lds arch/riscv/cpu/start.o --whole-archive arch/riscv/cpu/built-in.o arch/riscv/cpu/generic/built-in.o arch/riscv/lib/built-in.o board/emulation/common/built-in.o board/emulation/qemu-riscv/built-in.o boot/built-in.o cmd/built-in.o common/built-in.o disk/built-in.o drivers/built-in.o drivers/usb/cdns3/built-in.o drivers/usb/common/built-in.o drivers/usb/dwc3/built-in.o drivers/usb/emul/built-in.o drivers/usb/eth/built-in.o drivers/usb/host/built-in.o drivers/usb/mtu3/built-in.o drivers/usb/musb-new/built-in.o drivers/usb/musb/built-in.o drivers/usb/phy/built-in.o drivers/usb/ulpi/built-in.o env/built-in.o fs/built-in.o lib/built-in.o net/built-in.o --no-whole-archive -L /opt/gcc-11.1.0-nolibc/riscv64-linux/bin/../lib/gcc/riscv64-linux/11.1.0 -lgcc -Map u-boot.map; true
> > > > riscv64-linux-ld.bfd: drivers/virtio/virtio-uclass.o: in function `virtio_uclass_child_pre_probe':
> > > > /home/uboot/u-boot-riscv/drivers/virtio/virtio-uclass.c:339: undefined reference to `__lshrdi3'
> > > > riscv64-linux-ld.bfd: /home/uboot/u-boot-riscv/drivers/virtio/virtio-uclass.c:311: undefined reference to `__ashldi3'
> > > > riscv64-linux-ld.bfd: /home/uboot/u-boot-riscv/drivers/virtio/virtio-uclass.c:310: undefined reference to `__ashldi3'
> > > > riscv64-linux-ld.bfd: drivers/nvme/nvme.o: in function `nvme_blk_rw':
> > > > /home/uboot/u-boot-riscv/drivers/nvme/nvme.c:776: undefined reference to `__lshrdi3'
> > > > riscv64-linux-ld.bfd: fs/ext4/ext4_common.o: in function `ext4fs_get_extent_block':
> > > > /home/uboot/u-boot-riscv/fs/ext4/ext4_common.c:1560: undefined reference to `__ashldi3'
> > > > riscv64-linux-ld.bfd: fs/ext4/dev.o: in function `ext4fs_set_blk_dev':
> > > > /home/uboot/u-boot-riscv/fs/ext4/dev.c:46: undefined reference to `__lshrdi3'
> > > > riscv64-linux-ld.bfd: lib/display_options.o: in function `print_size':
> > > > /home/uboot/u-boot-riscv/lib/display_options.c:103: undefined reference to `__lshrdi3'
> > > > riscv64-linux-ld.bfd: /home/uboot/u-boot-riscv/lib/display_options.c:102: undefined reference to `__ashldi3'
> > > > riscv64-linux-ld.bfd: /home/uboot/u-boot-riscv/lib/display_options.c:95: undefined reference to `__ashldi3'
> > > > riscv64-linux-ld.bfd: /home/uboot/u-boot-riscv/lib/display_options.c:124: undefined reference to `__lshrdi3'
> > > > riscv64-linux-ld.bfd: lib/vsprintf.o: in function `number':
> > > > /home/uboot/u-boot-riscv/lib/vsprintf.c:213: undefined reference to `__lshrdi3'
> > > > make: *** [Makefile:1800: u-boot] Error 1
> > > >
> > > > Furthermore, Using the same container and perform the identical build commands listed above on master branch produce no error.
> > > >
> > > > What seems a bit odd is that when testing qemu-riscv32_spl,
> > > > buildman still uses 64 bit toolchain for the build.
> > > > I am not sure what the effect of "riscv64-linux-ld.bfd -m elf32lriscv" is.
> > > >
> > > > Do you have any thoughts ?
> > > >
> > > > [1] https://mirrors.edge.kernel.org/pub/tools/crosstool/files/bin/x86_64/11.1.0/x86_64-gcc-11.1.0-nolibc-riscv64-linux.tar.xz
> > > > [2] https://hub.docker.com/layers/trini/u-boot-gitlab-ci-runner/focal-20220113-03Feb2022/images/sha256-b1cddec69526015c550ac8e528114c976ccd1a0e75676328c4f81b834e06b2b3?context=explore
> > > >
> > > > Best regards,
> > > > Leo
> > > >
> > >
> > > I re-ran again with buildman's verbose option (./tools/buildman/buildman -o /tmp/qemu-riscv32_spl/ -w -E -W -e -V -v --board qemu-riscv32_spl)
> > > and found that the failed command is as below:
> > >
> > > riscv64-linux-ld.bfd -m elf32lriscv --gc-sections -static -pie -Bstatic --no-dynamic-linker -z notext --build-id=none -Ttext 0x81200000 -o u-boot -T u-boot.lds arch/riscv/cpu/start.o --whole-archive arch/riscv/cpu/built-in.o arch/riscv/cpu/generic/built-in.o arch/riscv/lib/built-in.o board/emulation/common/built-in.o board/emulation/qemu-riscv/built-in.o boot/built-in.o cmd/built-in.o common/built-in.o disk/built-in.o drivers/built-in.o drivers/usb/cdns3/built-in.o drivers/usb/common/built-in.o drivers/usb/dwc3/built-in.o drivers/usb/emul/built-in.o drivers/usb/eth/built-in.o drivers/usb/host/built-in.o drivers/usb/mtu3/built-in.o drivers/usb/musb-new/built-in.o drivers/usb/musb/built-in.o drivers/usb/phy/built-in.o drivers/usb/ulpi/built-in.o env/built-in.o fs/built-in.o lib/built-in.o net/built-in.o --no-whole-archive -L /opt/gcc-11.1.0-nolibc/riscv64-linux/bin/../lib/gcc/riscv64-linux/11.1.0 -lgcc -Map u-boot.map; true
> > > ^^^^^^^^^^^^^^^^^^^^^^
> > >
> > > The reason for this to fail is due to the wrong search path for libgcc.
> > > The above command uses "-L /opt/gcc-11.1.0-nolibc/riscv64-linux/bin/../lib/gcc/riscv64-linux/11.1.0",
> > > where it should be "-L /opt/gcc-11.1.0-nolibc/riscv64-linux/bin/../lib/gcc/riscv64-linux/11.1.0/lib32/ilp32[d]".
> > >
> > > This search path is generated from Makefile:865 `PLATFORM_LIBGCC := -L $(shell dirname `$(CC) $(c_flags) -print-libgcc-file-name`) -lgcc`.
> > >
> > > I'll try to find out how buildman executes the make process.
> > >
> > > ```
> > > $ ./tools/buildman/buildman -o /tmp/qemu-riscv32_spl/ -w -E -W -e -V -v --board qemu-riscv32_spl
> > > $ cat /tmp/qemu-riscv32_spl/log | grep u-boot.map
> > > riscv64-linux-ld.bfd -m elf32lriscv --gc-sections -static -pie -Bstatic --no-dynamic-linker -z notext --build-id=none -Ttext 0x81200000 -o u-boot -T u-boot.lds arch/riscv/cpu/start.o --whole-archive arch/riscv/cpu/built-in.o arch/riscv/cpu/generic/built-in.o arch/riscv/lib/built-in.o board/emulation/common/built-in.o board/emulation/qemu-riscv/built-in.o boot/built-in.o cmd/built-in.o common/built-in.o disk/built-in.o drivers/built-in.o drivers/usb/cdns3/built-in.o drivers/usb/common/built-in.o drivers/usb/dwc3/built-in.o drivers/usb/emul/built-in.o drivers/usb/eth/built-in.o drivers/usb/host/built-in.o drivers/usb/mtu3/built-in.o drivers/usb/musb-new/built-in.o drivers/usb/musb/built-in.o drivers/usb/phy/built-in.o drivers/usb/ulpi/built-in.o env/built-in.o fs/built-in.o lib/built-in.o net/built-in.o --no-whole-archive -L /opt/gcc-11.1.0-nolibc/riscv64-linux/bin/../lib/gcc/riscv64-linux/11.1.0 -lgcc -Map u-boot.map; true
> > > ```
> > >
> >
> > This patch looks valid, it's the CI process which causes the error to occur.
> >
> > The command "dirname $(riscv64-linux-gcc -march=rv32imac -mabi=ilp32 -print-libgcc-filename)" gives
> > different result from "dirname $(riscv64-linux-gcc -march=rv32imac_zicsr_zifencei -mabi=ilp32 -print-libgcc-filename)".
> >
> > The former gives "/opt/gcc-11.1.0-nolibc/riscv64-linux/bin/../lib/gcc/riscv64-linux/11.1.0/lib32/ilp32"
> > while the latter gives "/opt/gcc-11.1.0-nolibc/riscv64-linux/bin/../lib/gcc/riscv64-linux/11.1.0".
> >
> > The symbol __ashldi3 and __lshrdi3 only exist in libgcc.a under /opt/gcc-11.1.0-nolibc/riscv64-linux/bin/../lib/gcc/riscv64-linux/11.1.0/lib32/ilp32,
> > so linker search path have to be set to it to link successfully.
> >
> > The multilib setting does not cover zifencei and zicsr, so we get a default multilib path from -print-libgcc-file-name, and thus run into error like this.
> >
> > We should be able to fix this by using 32 bit toolchain in the CI process for 32 bit platform/configuration.
> >
> > Any thoughts or comments ?
>
> Let me ask internally to the guy who handles the toolchains, he may
> have an idea.
>
> Thanks for looking into that,
>
A gentle ping.
Any comments?
Or should we spin a patch for updating the toolchain used for 32 bit build?
Best regards,
Leo
> Alex
>
> >
> > Best regards,
> > Leo
> >
> > > Best regards,
> > > Leo
> > >
> > > >
> > > > > The only difference I see here is the gitlab-runner version (line 1).
> > > > >
> > > > > Thanks,
> > > > >
> > > > > Alex
> > > > >
> > > > > > Best regards,
> > > > > > Leo
> > > > > >
> > > > > > > >
> > > > > > > > Best regards,
> > > > > > > > Leo
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] riscv: Fix build against binutils 2.38
2022-04-07 9:12 ` Leo Liang
@ 2022-04-12 9:14 ` Alexandre Ghiti
2022-04-13 1:49 ` Leo Liang
0 siblings, 1 reply; 24+ messages in thread
From: Alexandre Ghiti @ 2022-04-12 9:14 UTC (permalink / raw)
To: Leo Liang
Cc: Rick Chen, Aurelien Jarno, Heinrich Schuchardt, u-boot, bmeng.cn,
sjg, trini
Hi Leo,
On Thu, Apr 7, 2022 at 11:13 AM Leo Liang <ycliang@andestech.com> wrote:
>
> Hi Alex,
> On Thu, Mar 10, 2022 at 09:03:08AM +0100, Alexandre Ghiti wrote:
> > Hi Leo,
> >
> > On Wed, Mar 9, 2022 at 7:31 AM Leo Liang <ycliang@andestech.com> wrote:
> > >
> > > Hi Alex,
> > > On Thu, Mar 03, 2022 at 11:06:18AM +0000, Leo Liang wrote:
> > > > Hi Alex,
> > > > On Tue, Mar 01, 2022 at 03:21:56AM +0000, Leo Liang wrote:
> > > > > Hi Alex,
> > > > > On Mon, Feb 21, 2022 at 05:42:41PM +0100, Alexandre Ghiti wrote:
> > > > > > On Sat, Feb 19, 2022 at 9:52 AM Leo Liang <ycliang@andestech.com> wrote:
> > > > > > >
> > > > > > > Hi Alex,
> > > > > > > On Thu, Feb 17, 2022 at 11:28:46AM +0100, Alexandre Ghiti wrote:
> > > > > > > > Hi Leo,
> > > > > > > >
> > > > > > > > On Thu, Feb 17, 2022 at 10:25 AM Leo Liang <ycliang@andestech.com> wrote:
> > > > > > > > >
> > > > > > > > > Hi Alexandre,
> > > > > > > > > On Fri, Jan 28, 2022 at 02:47:13PM +0100, Alexandre Ghiti wrote:
> > > > > > > > > > The following description is copied from the equivalent patch for the
> > > > > > > > > > Linux Kernel proposed by Aurelien Jarno:
> > > > > > > > > >
> > > > > > > > > > From version 2.38, binutils default to ISA spec version 20191213. This
> > > > > > > > > > means that the csr read/write (csrr*/csrw*) instructions and fence.i
> > > > > > > > > > instruction has separated from the `I` extension, become two standalone
> > > > > > > > > > extensions: Zicsr and Zifencei. As the kernel uses those instruction,
> > > > > > > > > > this causes the following build failure:
> > > > > > > > > >
> > > > > > > > > > arch/riscv/cpu/mtrap.S: Assembler messages:
> > > > > > > > > > arch/riscv/cpu/mtrap.S:65: Error: unrecognized opcode `csrr a0,scause'
> > > > > > > > > > arch/riscv/cpu/mtrap.S:66: Error: unrecognized opcode `csrr a1,sepc'
> > > > > > > > > > arch/riscv/cpu/mtrap.S:67: Error: unrecognized opcode `csrr a2,stval'
> > > > > > > > > > arch/riscv/cpu/mtrap.S:70: Error: unrecognized opcode `csrw sepc,a0'
> > > > > > > > > >
> > > > > > > > > > Signed-off-by: Alexandre Ghiti <alexandre.ghiti@canonical.com>
> > > > > > > > > > ---
> > > > > > > > > > arch/riscv/Makefile | 11 ++++++++++-
> > > > > > > > > > 1 file changed, 10 insertions(+), 1 deletion(-)
> > > > > > > > >
> > > > > > > > > This patch seems to fail CI somehow.
> > > > > > > > > (https://source.denx.de/u-boot/custodians/u-boot-riscv/-/pipelines/11004)
> > > > > > > > >
> > > > > > > > > Could you take a look at it ?
> > > > > > > >
> > > > > > > > I have just tried on master (commit ab8903a24db1) and it failed for
> > > > > > > > the same reason, so this is not related to this patch. Nevertheless,
> > > > > > > > I'll try to bisect the problem :)
> > > > > > > >
> > > > > > > > Thanks,
> > > > > > > >
> > > > > > > > Alex
> > > > > > > >
> > > > > > >
> > > > > > > Thanks for putting the effort into it!
> > > > > > >
> > > > > > > AFAIK, this patch does nothing related to the error message "undefined reference to `__ashldi3'" from the failed CI.
> > > > > > >
> > > > > > > Nonetheless, I have tried a few times myself,
> > > > > > > and found that CI could pass with ab8903a24db1 but cannot pass with this patch on my side.
> > > > > > > https://source.denx.de/u-boot/custodians/u-boot-riscv/-/commits/staging
> > > > > > > https://source.denx.de/u-boot/custodians/u-boot-riscv/-/pipelines
> > > > > > >
> > > > > >
> > > > > > To me it is an issue with the toolchain: libgcc is missing those
> > > > > > symbols. If I use an Ubuntu toolchain, it fails no matter which commit
> > > > > > I am on (I tested as far as v2021.10). But if I use a toolchain from
> > > > > > https://mirrors.edge.kernel.org/pub/tools/crosstool/files/bin/x86_64/,
> > > > > > it works fine.
> > > > > >
> > > > > > What I don't understand is how you manage to have different build
> > > > > > results with the same docker image: can you confirm that you use the
> > > > > > same toolchains in the following builds?
> > > > > >
> > > > > > https://source.denx.de/u-boot/custodians/u-boot-riscv/-/jobs/393701
> > > > > > https://source.denx.de/u-boot/custodians/u-boot-riscv/-/jobs/393783
> > > > > >
> > > > >
> > > > > Sorry for the late reply.
> > > > > I have checked the toolchain version of these two builds,
> > > > > they are using the same toolchain[1] from Tom's docker image on docker hub[2].
> > > > >
> > > > > Also the fail is reproducible using this docker image with the following commands:
> > > > >
> > > > > leo@host sudo docker run -it --name leo-test trini/u-boot-gitlab-ci-runner:focal-20220113-03Feb2022 /bin/bash
> > > > > uboot@356268d27bf0:~$ git clone https://source.denx.de/u-boot/custodians/u-boot-riscv.git && cd u-boot-riscv
> > > > > uboot@356268d27bf0:~/u-boot-riscv$ git checkout staging
> > > > > uboot@356268d27bf0:~/u-boot-riscv$ export PATH=/opt/gcc-11.1.0-nolibc/riscv64-linux/bin:$PATH
> > > > > uboot@356268d27bf0:~/u-boot-riscv$ export CROSS_COMPILE=riscv64-linux-
> > > > > uboot@356268d27bf0:~/u-boot-riscv$ make qemu-riscv32_spl_defconfig
> > > > > uboot@356268d27bf0:~/u-boot-riscv$ make -j`nproc` V=1
> > > > >
> > > > > ...
> > > > >
> > > > > riscv64-linux-ld.bfd -m elf32lriscv --gc-sections -static -pie -Bstatic --no-dynamic-linker -z notext --build-id=none -Ttext 0x81200000 -o u-boot -T u-boot.lds arch/riscv/cpu/start.o --whole-archive arch/riscv/cpu/built-in.o arch/riscv/cpu/generic/built-in.o arch/riscv/lib/built-in.o board/emulation/common/built-in.o board/emulation/qemu-riscv/built-in.o boot/built-in.o cmd/built-in.o common/built-in.o disk/built-in.o drivers/built-in.o drivers/usb/cdns3/built-in.o drivers/usb/common/built-in.o drivers/usb/dwc3/built-in.o drivers/usb/emul/built-in.o drivers/usb/eth/built-in.o drivers/usb/host/built-in.o drivers/usb/mtu3/built-in.o drivers/usb/musb-new/built-in.o drivers/usb/musb/built-in.o drivers/usb/phy/built-in.o drivers/usb/ulpi/built-in.o env/built-in.o fs/built-in.o lib/built-in.o net/built-in.o --no-whole-archive -L /opt/gcc-11.1.0-nolibc/riscv64-linux/bin/../lib/gcc/riscv64-linux/11.1.0 -lgcc -Map u-boot.map; true
> > > > > riscv64-linux-ld.bfd: drivers/virtio/virtio-uclass.o: in function `virtio_uclass_child_pre_probe':
> > > > > /home/uboot/u-boot-riscv/drivers/virtio/virtio-uclass.c:339: undefined reference to `__lshrdi3'
> > > > > riscv64-linux-ld.bfd: /home/uboot/u-boot-riscv/drivers/virtio/virtio-uclass.c:311: undefined reference to `__ashldi3'
> > > > > riscv64-linux-ld.bfd: /home/uboot/u-boot-riscv/drivers/virtio/virtio-uclass.c:310: undefined reference to `__ashldi3'
> > > > > riscv64-linux-ld.bfd: drivers/nvme/nvme.o: in function `nvme_blk_rw':
> > > > > /home/uboot/u-boot-riscv/drivers/nvme/nvme.c:776: undefined reference to `__lshrdi3'
> > > > > riscv64-linux-ld.bfd: fs/ext4/ext4_common.o: in function `ext4fs_get_extent_block':
> > > > > /home/uboot/u-boot-riscv/fs/ext4/ext4_common.c:1560: undefined reference to `__ashldi3'
> > > > > riscv64-linux-ld.bfd: fs/ext4/dev.o: in function `ext4fs_set_blk_dev':
> > > > > /home/uboot/u-boot-riscv/fs/ext4/dev.c:46: undefined reference to `__lshrdi3'
> > > > > riscv64-linux-ld.bfd: lib/display_options.o: in function `print_size':
> > > > > /home/uboot/u-boot-riscv/lib/display_options.c:103: undefined reference to `__lshrdi3'
> > > > > riscv64-linux-ld.bfd: /home/uboot/u-boot-riscv/lib/display_options.c:102: undefined reference to `__ashldi3'
> > > > > riscv64-linux-ld.bfd: /home/uboot/u-boot-riscv/lib/display_options.c:95: undefined reference to `__ashldi3'
> > > > > riscv64-linux-ld.bfd: /home/uboot/u-boot-riscv/lib/display_options.c:124: undefined reference to `__lshrdi3'
> > > > > riscv64-linux-ld.bfd: lib/vsprintf.o: in function `number':
> > > > > /home/uboot/u-boot-riscv/lib/vsprintf.c:213: undefined reference to `__lshrdi3'
> > > > > make: *** [Makefile:1800: u-boot] Error 1
> > > > >
> > > > > Furthermore, Using the same container and perform the identical build commands listed above on master branch produce no error.
> > > > >
> > > > > What seems a bit odd is that when testing qemu-riscv32_spl,
> > > > > buildman still uses 64 bit toolchain for the build.
> > > > > I am not sure what the effect of "riscv64-linux-ld.bfd -m elf32lriscv" is.
> > > > >
> > > > > Do you have any thoughts ?
> > > > >
> > > > > [1] https://mirrors.edge.kernel.org/pub/tools/crosstool/files/bin/x86_64/11.1.0/x86_64-gcc-11.1.0-nolibc-riscv64-linux.tar.xz
> > > > > [2] https://hub.docker.com/layers/trini/u-boot-gitlab-ci-runner/focal-20220113-03Feb2022/images/sha256-b1cddec69526015c550ac8e528114c976ccd1a0e75676328c4f81b834e06b2b3?context=explore
> > > > >
> > > > > Best regards,
> > > > > Leo
> > > > >
> > > >
> > > > I re-ran again with buildman's verbose option (./tools/buildman/buildman -o /tmp/qemu-riscv32_spl/ -w -E -W -e -V -v --board qemu-riscv32_spl)
> > > > and found that the failed command is as below:
> > > >
> > > > riscv64-linux-ld.bfd -m elf32lriscv --gc-sections -static -pie -Bstatic --no-dynamic-linker -z notext --build-id=none -Ttext 0x81200000 -o u-boot -T u-boot.lds arch/riscv/cpu/start.o --whole-archive arch/riscv/cpu/built-in.o arch/riscv/cpu/generic/built-in.o arch/riscv/lib/built-in.o board/emulation/common/built-in.o board/emulation/qemu-riscv/built-in.o boot/built-in.o cmd/built-in.o common/built-in.o disk/built-in.o drivers/built-in.o drivers/usb/cdns3/built-in.o drivers/usb/common/built-in.o drivers/usb/dwc3/built-in.o drivers/usb/emul/built-in.o drivers/usb/eth/built-in.o drivers/usb/host/built-in.o drivers/usb/mtu3/built-in.o drivers/usb/musb-new/built-in.o drivers/usb/musb/built-in.o drivers/usb/phy/built-in.o drivers/usb/ulpi/built-in.o env/built-in.o fs/built-in.o lib/built-in.o net/built-in.o --no-whole-archive -L /opt/gcc-11.1.0-nolibc/riscv64-linux/bin/../lib/gcc/riscv64-linux/11.1.0 -lgcc -Map u-boot.map; true
> > > > ^^^^^^^^^^^^^^^^^^^^^^
> > > >
> > > > The reason for this to fail is due to the wrong search path for libgcc.
> > > > The above command uses "-L /opt/gcc-11.1.0-nolibc/riscv64-linux/bin/../lib/gcc/riscv64-linux/11.1.0",
> > > > where it should be "-L /opt/gcc-11.1.0-nolibc/riscv64-linux/bin/../lib/gcc/riscv64-linux/11.1.0/lib32/ilp32[d]".
> > > >
> > > > This search path is generated from Makefile:865 `PLATFORM_LIBGCC := -L $(shell dirname `$(CC) $(c_flags) -print-libgcc-file-name`) -lgcc`.
> > > >
> > > > I'll try to find out how buildman executes the make process.
> > > >
> > > > ```
> > > > $ ./tools/buildman/buildman -o /tmp/qemu-riscv32_spl/ -w -E -W -e -V -v --board qemu-riscv32_spl
> > > > $ cat /tmp/qemu-riscv32_spl/log | grep u-boot.map
> > > > riscv64-linux-ld.bfd -m elf32lriscv --gc-sections -static -pie -Bstatic --no-dynamic-linker -z notext --build-id=none -Ttext 0x81200000 -o u-boot -T u-boot.lds arch/riscv/cpu/start.o --whole-archive arch/riscv/cpu/built-in.o arch/riscv/cpu/generic/built-in.o arch/riscv/lib/built-in.o board/emulation/common/built-in.o board/emulation/qemu-riscv/built-in.o boot/built-in.o cmd/built-in.o common/built-in.o disk/built-in.o drivers/built-in.o drivers/usb/cdns3/built-in.o drivers/usb/common/built-in.o drivers/usb/dwc3/built-in.o drivers/usb/emul/built-in.o drivers/usb/eth/built-in.o drivers/usb/host/built-in.o drivers/usb/mtu3/built-in.o drivers/usb/musb-new/built-in.o drivers/usb/musb/built-in.o drivers/usb/phy/built-in.o drivers/usb/ulpi/built-in.o env/built-in.o fs/built-in.o lib/built-in.o net/built-in.o --no-whole-archive -L /opt/gcc-11.1.0-nolibc/riscv64-linux/bin/../lib/gcc/riscv64-linux/11.1.0 -lgcc -Map u-boot.map; true
> > > > ```
> > > >
> > >
> > > This patch looks valid, it's the CI process which causes the error to occur.
> > >
> > > The command "dirname $(riscv64-linux-gcc -march=rv32imac -mabi=ilp32 -print-libgcc-filename)" gives
> > > different result from "dirname $(riscv64-linux-gcc -march=rv32imac_zicsr_zifencei -mabi=ilp32 -print-libgcc-filename)".
> > >
> > > The former gives "/opt/gcc-11.1.0-nolibc/riscv64-linux/bin/../lib/gcc/riscv64-linux/11.1.0/lib32/ilp32"
> > > while the latter gives "/opt/gcc-11.1.0-nolibc/riscv64-linux/bin/../lib/gcc/riscv64-linux/11.1.0".
> > >
> > > The symbol __ashldi3 and __lshrdi3 only exist in libgcc.a under /opt/gcc-11.1.0-nolibc/riscv64-linux/bin/../lib/gcc/riscv64-linux/11.1.0/lib32/ilp32,
> > > so linker search path have to be set to it to link successfully.
> > >
> > > The multilib setting does not cover zifencei and zicsr, so we get a default multilib path from -print-libgcc-file-name, and thus run into error like this.
> > >
> > > We should be able to fix this by using 32 bit toolchain in the CI process for 32 bit platform/configuration.
> > >
> > > Any thoughts or comments ?
> >
> > Let me ask internally to the guy who handles the toolchains, he may
> > have an idea.
> >
> > Thanks for looking into that,
> >
>
> A gentle ping.
>
> Any comments?
> Or should we spin a patch for updating the toolchain used for 32 bit build?
Sorry for being very slow here, if the patch is too much of a burden,
maybe you should drop it for now, I will have more time to work on
this in 2 weeks, sorry again.
Alex
>
> Best regards,
> Leo
>
> > Alex
> >
> > >
> > > Best regards,
> > > Leo
> > >
> > > > Best regards,
> > > > Leo
> > > >
> > > > >
> > > > > > The only difference I see here is the gitlab-runner version (line 1).
> > > > > >
> > > > > > Thanks,
> > > > > >
> > > > > > Alex
> > > > > >
> > > > > > > Best regards,
> > > > > > > Leo
> > > > > > >
> > > > > > > > >
> > > > > > > > > Best regards,
> > > > > > > > > Leo
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] riscv: Fix build against binutils 2.38
2022-04-12 9:14 ` Alexandre Ghiti
@ 2022-04-13 1:49 ` Leo Liang
0 siblings, 0 replies; 24+ messages in thread
From: Leo Liang @ 2022-04-13 1:49 UTC (permalink / raw)
To: Alexandre Ghiti; +Cc: Rick Chen, u-boot
Hi Alex,
On Tue, Apr 12, 2022 at 11:14:32AM +0200, Alexandre Ghiti wrote:
> Hi Leo,
> > A gentle ping.
> >
> > Any comments?
> > Or should we spin a patch for updating the toolchain used for 32 bit build?
>
> Sorry for being very slow here, if the patch is too much of a burden,
> maybe you should drop it for now, I will have more time to work on
> this in 2 weeks, sorry again.
>
> Alex
>
Understood! No worries! Take your time to it.
Best regards,
Leo
> >
> > Best regards,
> > Leo
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] riscv: Fix build against binutils 2.38
2022-01-28 13:47 [PATCH] riscv: Fix build against binutils 2.38 Alexandre Ghiti
` (2 preceding siblings ...)
2022-02-17 9:24 ` Leo Liang
@ 2022-06-23 13:40 ` Heiko Stübner
2022-08-30 20:28 ` Christian Stewart
3 siblings, 1 reply; 24+ messages in thread
From: Heiko Stübner @ 2022-06-23 13:40 UTC (permalink / raw)
To: Rick Chen, Leo, Aurelien Jarno, Heinrich Schuchardt, u-boot
Cc: Alexandre Ghiti, Alexandre Ghiti, Coelacanthus
Am Freitag, 28. Januar 2022, 14:47:13 CEST schrieb Alexandre Ghiti:
> The following description is copied from the equivalent patch for the
> Linux Kernel proposed by Aurelien Jarno:
>
> From version 2.38, binutils default to ISA spec version 20191213. This
> means that the csr read/write (csrr*/csrw*) instructions and fence.i
> instruction has separated from the `I` extension, become two standalone
> extensions: Zicsr and Zifencei. As the kernel uses those instruction,
> this causes the following build failure:
>
> arch/riscv/cpu/mtrap.S: Assembler messages:
> arch/riscv/cpu/mtrap.S:65: Error: unrecognized opcode `csrr a0,scause'
> arch/riscv/cpu/mtrap.S:66: Error: unrecognized opcode `csrr a1,sepc'
> arch/riscv/cpu/mtrap.S:67: Error: unrecognized opcode `csrr a2,stval'
> arch/riscv/cpu/mtrap.S:70: Error: unrecognized opcode `csrw sepc,a0'
>
> Signed-off-by: Alexandre Ghiti <alexandre.ghiti@canonical.com>
After upgrading my binutils to the recent snapshot package
in Debian-unstable (2.38.50.20220622-1), I've also run into that issue:
/home/devel/hstuebner/04_riscv/sun20i_d1_u-boot/drivers/timer/riscv_timer.c: Assembler messages:
/home/devel/hstuebner/04_riscv/sun20i_d1_u-boot/drivers/timer/riscv_timer.c:24: Error: unrecognized opcode `csrr a0,0xc01', extension `zicsr' required
make[3]: *** [/home/devel/hstuebner/04_riscv/sun20i_d1_u-boot/scripts/Makefile.build:254: drivers/timer/riscv_timer.o] Fehler 1
Is there progress in getting this patch applied to u-boot in some way?
Also it looks like there was another patch with similar content submitted
recently [0].
In any case:
On a D1-Nezha it fixes the build (and boot)
Tested-by: Heiko Stuebner <heiko@sntech.de>
Thanks
Heiko
[0] https://lore.kernel.org/all/PH7PR14MB5594FD11D1BE74284F554BEBCED49@PH7PR14MB5594.namprd14.prod.outlook.com/
> ---
> arch/riscv/Makefile | 11 ++++++++++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/arch/riscv/Makefile b/arch/riscv/Makefile
> index 0b80eb8d86..53d1194ffb 100644
> --- a/arch/riscv/Makefile
> +++ b/arch/riscv/Makefile
> @@ -24,7 +24,16 @@ ifeq ($(CONFIG_CMODEL_MEDANY),y)
> CMODEL = medany
> endif
>
> -ARCH_FLAGS = -march=$(ARCH_BASE)$(ARCH_A)$(ARCH_C) -mabi=$(ABI) \
> +RISCV_MARCH = $(ARCH_BASE)$(ARCH_A)$(ARCH_C)
> +
> +# Newer binutils versions default to ISA spec version 20191213 which moves some
> +# instructions from the I extension to the Zicsr and Zifencei extensions.
> +toolchain-need-zicsr-zifencei := $(call cc-option-yn, -mabi=$(ABI) -march=$(RISCV_MARCH)_zicsr_zifencei)
> +ifeq ($(toolchain-need-zicsr-zifencei),y)
> + RISCV_MARCH := $(RISCV_MARCH)_zicsr_zifencei
> +endif
> +
> +ARCH_FLAGS = -march=$(RISCV_MARCH) -mabi=$(ABI) \
> -mcmodel=$(CMODEL)
>
> PLATFORM_CPPFLAGS += $(ARCH_FLAGS)
>
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] riscv: Fix build against binutils 2.38
2022-06-23 13:40 ` Heiko Stübner
@ 2022-08-30 20:28 ` Christian Stewart
0 siblings, 0 replies; 24+ messages in thread
From: Christian Stewart @ 2022-08-30 20:28 UTC (permalink / raw)
To: Heiko
Cc: Rick Chen, Leo, Aurelien Jarno, Heinrich Schuchardt, u-boot,
Alexandre Ghiti, Coelacanthus
Hi all,
Am Freitag, 28. Januar 2022, 14:47:13 CEST schrieb Alexandre Ghiti:
> The following description is copied from the equivalent patch for the
> Linux Kernel proposed by Aurelien Jarno:
>
> From version 2.38, binutils default to ISA spec version 20191213. This
> means that the csr read/write (csrr*/csrw*) instructions and fence.i
> instruction has separated from the `I` extension, become two standalone
> extensions: Zicsr and Zifencei. As the kernel uses those instruction,
> this causes the following build failure:
>
> arch/riscv/cpu/mtrap.S: Assembler messages:
> arch/riscv/cpu/mtrap.S:65: Error: unrecognized opcode `csrr a0,scause'
> arch/riscv/cpu/mtrap.S:66: Error: unrecognized opcode `csrr a1,sepc'
> arch/riscv/cpu/mtrap.S:67: Error: unrecognized opcode `csrr a2,stval'
> arch/riscv/cpu/mtrap.S:70: Error: unrecognized opcode `csrw sepc,a0'
>
> Signed-off-by: Alexandre Ghiti <alexandre.ghiti@canonical.com>
Heiko wrote:
> Is there progress in getting this patch applied to u-boot in some way?
> Also it looks like there was another patch with similar content submitted
> recently [0].
>
> In any case:
>
> On a D1-Nezha it fixes the build (and boot)
> Tested-by: Heiko Stuebner <heiko@sntech.de>
Fixes the boot with u-boot in Buildroot:
[0] https://lore.kernel.org/all/PH7PR14MB5594FD11D1BE74284F554BEBCED49@PH7PR14MB5594.namprd14.prod.outlook.com/
[1] https://github.com/skiffos/u-boot/commit/3bb93519563146419aa06e8d21394089163302b6
This is for a few Risc-v boards based on D1.
Tested-by: Christian Stewart <christian@paral.in>
Thanks & best,
Christian Stewart
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] riscv: Fix build against binutils 2.38
2022-03-09 6:31 ` Leo Liang
2022-03-10 8:03 ` Alexandre Ghiti
@ 2022-10-01 23:24 ` Heinrich Schuchardt
2022-10-01 23:57 ` Tom Rini
1 sibling, 1 reply; 24+ messages in thread
From: Heinrich Schuchardt @ 2022-10-01 23:24 UTC (permalink / raw)
To: Leo Liang, Alexandre Ghiti
Cc: Rick Chen, Aurelien Jarno, u-boot, bmeng.cn, sjg, trini
On 3/9/22 07:31, Leo Liang wrote:
> Hi Alex,
> On Thu, Mar 03, 2022 at 11:06:18AM +0000, Leo Liang wrote:
>> Hi Alex,
>> On Tue, Mar 01, 2022 at 03:21:56AM +0000, Leo Liang wrote:
>>> Hi Alex,
>>> On Mon, Feb 21, 2022 at 05:42:41PM +0100, Alexandre Ghiti wrote:
>>>> On Sat, Feb 19, 2022 at 9:52 AM Leo Liang <ycliang@andestech.com> wrote:
>>>>>
>>>>> Hi Alex,
>>>>> On Thu, Feb 17, 2022 at 11:28:46AM +0100, Alexandre Ghiti wrote:
>>>>>> Hi Leo,
>>>>>>
>>>>>> On Thu, Feb 17, 2022 at 10:25 AM Leo Liang <ycliang@andestech.com> wrote:
>>>>>>>
>>>>>>> Hi Alexandre,
>>>>>>> On Fri, Jan 28, 2022 at 02:47:13PM +0100, Alexandre Ghiti wrote:
>>>>>>>> The following description is copied from the equivalent patch for the
>>>>>>>> Linux Kernel proposed by Aurelien Jarno:
>>>>>>>>
>>>>>>>> From version 2.38, binutils default to ISA spec version 20191213. This
>>>>>>>> means that the csr read/write (csrr*/csrw*) instructions and fence.i
>>>>>>>> instruction has separated from the `I` extension, become two standalone
>>>>>>>> extensions: Zicsr and Zifencei. As the kernel uses those instruction,
>>>>>>>> this causes the following build failure:
>>>>>>>>
>>>>>>>> arch/riscv/cpu/mtrap.S: Assembler messages:
>>>>>>>> arch/riscv/cpu/mtrap.S:65: Error: unrecognized opcode `csrr a0,scause'
>>>>>>>> arch/riscv/cpu/mtrap.S:66: Error: unrecognized opcode `csrr a1,sepc'
>>>>>>>> arch/riscv/cpu/mtrap.S:67: Error: unrecognized opcode `csrr a2,stval'
>>>>>>>> arch/riscv/cpu/mtrap.S:70: Error: unrecognized opcode `csrw sepc,a0'
>>>>>>>>
>>>>>>>> Signed-off-by: Alexandre Ghiti <alexandre.ghiti@canonical.com>
>>>>>>>> ---
>>>>>>>> arch/riscv/Makefile | 11 ++++++++++-
>>>>>>>> 1 file changed, 10 insertions(+), 1 deletion(-)
>>>>>>>
>>>>>>> This patch seems to fail CI somehow.
>>>>>>> (https://source.denx.de/u-boot/custodians/u-boot-riscv/-/pipelines/11004)
>>>>>>>
>>>>>>> Could you take a look at it ?
>>>>>>
>>>>>> I have just tried on master (commit ab8903a24db1) and it failed for
>>>>>> the same reason, so this is not related to this patch. Nevertheless,
>>>>>> I'll try to bisect the problem :)
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Alex
>>>>>>
>>>>>
>>>>> Thanks for putting the effort into it!
>>>>>
>>>>> AFAIK, this patch does nothing related to the error message "undefined reference to `__ashldi3'" from the failed CI.
>>>>>
>>>>> Nonetheless, I have tried a few times myself,
>>>>> and found that CI could pass with ab8903a24db1 but cannot pass with this patch on my side.
>>>>> https://source.denx.de/u-boot/custodians/u-boot-riscv/-/commits/staging
>>>>> https://source.denx.de/u-boot/custodians/u-boot-riscv/-/pipelines
>>>>>
>>>>
>>>> To me it is an issue with the toolchain: libgcc is missing those
>>>> symbols. If I use an Ubuntu toolchain, it fails no matter which commit
>>>> I am on (I tested as far as v2021.10). But if I use a toolchain from
>>>> https://mirrors.edge.kernel.org/pub/tools/crosstool/files/bin/x86_64/,
>>>> it works fine.
>>>>
>>>> What I don't understand is how you manage to have different build
>>>> results with the same docker image: can you confirm that you use the
>>>> same toolchains in the following builds?
>>>>
>>>> https://source.denx.de/u-boot/custodians/u-boot-riscv/-/jobs/393701
>>>> https://source.denx.de/u-boot/custodians/u-boot-riscv/-/jobs/393783
>>>>
>>>
>>> Sorry for the late reply.
>>> I have checked the toolchain version of these two builds,
>>> they are using the same toolchain[1] from Tom's docker image on docker hub[2].
>>>
>>> Also the fail is reproducible using this docker image with the following commands:
>>>
>>> leo@host sudo docker run -it --name leo-test trini/u-boot-gitlab-ci-runner:focal-20220113-03Feb2022 /bin/bash
>>> uboot@356268d27bf0:~$ git clone https://source.denx.de/u-boot/custodians/u-boot-riscv.git && cd u-boot-riscv
>>> uboot@356268d27bf0:~/u-boot-riscv$ git checkout staging
>>> uboot@356268d27bf0:~/u-boot-riscv$ export PATH=/opt/gcc-11.1.0-nolibc/riscv64-linux/bin:$PATH
>>> uboot@356268d27bf0:~/u-boot-riscv$ export CROSS_COMPILE=riscv64-linux-
>>> uboot@356268d27bf0:~/u-boot-riscv$ make qemu-riscv32_spl_defconfig
>>> uboot@356268d27bf0:~/u-boot-riscv$ make -j`nproc` V=1
>>>
>>> ...
>>>
>>> riscv64-linux-ld.bfd -m elf32lriscv --gc-sections -static -pie -Bstatic --no-dynamic-linker -z notext --build-id=none -Ttext 0x81200000 -o u-boot -T u-boot.lds arch/riscv/cpu/start.o --whole-archive arch/riscv/cpu/built-in.o arch/riscv/cpu/generic/built-in.o arch/riscv/lib/built-in.o board/emulation/common/built-in.o board/emulation/qemu-riscv/built-in.o boot/built-in.o cmd/built-in.o common/built-in.o disk/built-in.o drivers/built-in.o drivers/usb/cdns3/built-in.o drivers/usb/common/built-in.o drivers/usb/dwc3/built-in.o drivers/usb/emul/built-in.o drivers/usb/eth/built-in.o drivers/usb/host/built-in.o drivers/usb/mtu3/built-in.o drivers/usb/musb-new/built-in.o drivers/usb/musb/built-in.o drivers/usb/phy/built-in.o drivers/usb/ulpi/built-in.o env/built-in.o fs/built-in.o lib/built-in.o net/built-in.o --no-whole-archive -L /opt/gcc-11.1.0-nolibc/riscv64-linux/bin/../lib/gcc/riscv64-linux/11.1.0 -lgcc -Map u-boot.map; true
>>> riscv64-linux-ld.bfd: drivers/virtio/virtio-uclass.o: in function `virtio_uclass_child_pre_probe':
>>> /home/uboot/u-boot-riscv/drivers/virtio/virtio-uclass.c:339: undefined reference to `__lshrdi3'
>>> riscv64-linux-ld.bfd: /home/uboot/u-boot-riscv/drivers/virtio/virtio-uclass.c:311: undefined reference to `__ashldi3'
>>> riscv64-linux-ld.bfd: /home/uboot/u-boot-riscv/drivers/virtio/virtio-uclass.c:310: undefined reference to `__ashldi3'
>>> riscv64-linux-ld.bfd: drivers/nvme/nvme.o: in function `nvme_blk_rw':
>>> /home/uboot/u-boot-riscv/drivers/nvme/nvme.c:776: undefined reference to `__lshrdi3'
>>> riscv64-linux-ld.bfd: fs/ext4/ext4_common.o: in function `ext4fs_get_extent_block':
>>> /home/uboot/u-boot-riscv/fs/ext4/ext4_common.c:1560: undefined reference to `__ashldi3'
>>> riscv64-linux-ld.bfd: fs/ext4/dev.o: in function `ext4fs_set_blk_dev':
>>> /home/uboot/u-boot-riscv/fs/ext4/dev.c:46: undefined reference to `__lshrdi3'
>>> riscv64-linux-ld.bfd: lib/display_options.o: in function `print_size':
>>> /home/uboot/u-boot-riscv/lib/display_options.c:103: undefined reference to `__lshrdi3'
>>> riscv64-linux-ld.bfd: /home/uboot/u-boot-riscv/lib/display_options.c:102: undefined reference to `__ashldi3'
>>> riscv64-linux-ld.bfd: /home/uboot/u-boot-riscv/lib/display_options.c:95: undefined reference to `__ashldi3'
>>> riscv64-linux-ld.bfd: /home/uboot/u-boot-riscv/lib/display_options.c:124: undefined reference to `__lshrdi3'
>>> riscv64-linux-ld.bfd: lib/vsprintf.o: in function `number':
>>> /home/uboot/u-boot-riscv/lib/vsprintf.c:213: undefined reference to `__lshrdi3'
>>> make: *** [Makefile:1800: u-boot] Error 1
>>>
>>> Furthermore, Using the same container and perform the identical build commands listed above on master branch produce no error.
>>>
>>> What seems a bit odd is that when testing qemu-riscv32_spl,
>>> buildman still uses 64 bit toolchain for the build.
>>> I am not sure what the effect of "riscv64-linux-ld.bfd -m elf32lriscv" is.
>>>
>>> Do you have any thoughts ?
>>>
>>> [1] https://mirrors.edge.kernel.org/pub/tools/crosstool/files/bin/x86_64/11.1.0/x86_64-gcc-11.1.0-nolibc-riscv64-linux.tar.xz
>>> [2] https://hub.docker.com/layers/trini/u-boot-gitlab-ci-runner/focal-20220113-03Feb2022/images/sha256-b1cddec69526015c550ac8e528114c976ccd1a0e75676328c4f81b834e06b2b3?context=explore
>>>
>>> Best regards,
>>> Leo
>>>
>>
>> I re-ran again with buildman's verbose option (./tools/buildman/buildman -o /tmp/qemu-riscv32_spl/ -w -E -W -e -V -v --board qemu-riscv32_spl)
>> and found that the failed command is as below:
>>
>> riscv64-linux-ld.bfd -m elf32lriscv --gc-sections -static -pie -Bstatic --no-dynamic-linker -z notext --build-id=none -Ttext 0x81200000 -o u-boot -T u-boot.lds arch/riscv/cpu/start.o --whole-archive arch/riscv/cpu/built-in.o arch/riscv/cpu/generic/built-in.o arch/riscv/lib/built-in.o board/emulation/common/built-in.o board/emulation/qemu-riscv/built-in.o boot/built-in.o cmd/built-in.o common/built-in.o disk/built-in.o drivers/built-in.o drivers/usb/cdns3/built-in.o drivers/usb/common/built-in.o drivers/usb/dwc3/built-in.o drivers/usb/emul/built-in.o drivers/usb/eth/built-in.o drivers/usb/host/built-in.o drivers/usb/mtu3/built-in.o drivers/usb/musb-new/built-in.o drivers/usb/musb/built-in.o drivers/usb/phy/built-in.o drivers/usb/ulpi/built-in.o env/built-in.o fs/built-in.o lib/built-in.o net/built-in.o --no-whole-archive -L /opt/gcc-11.1.0-nolibc/riscv64-linux/bin/../lib/gcc/riscv64-linux/11.1.0 -lgcc -Map u-boot.map; true
>> ^^^^^^^^^^^^^^^^^^^^^^
>>
>> The reason for this to fail is due to the wrong search path for libgcc.
>> The above command uses "-L /opt/gcc-11.1.0-nolibc/riscv64-linux/bin/../lib/gcc/riscv64-linux/11.1.0",
>> where it should be "-L /opt/gcc-11.1.0-nolibc/riscv64-linux/bin/../lib/gcc/riscv64-linux/11.1.0/lib32/ilp32[d]".
>>
>> This search path is generated from Makefile:865 `PLATFORM_LIBGCC := -L $(shell dirname `$(CC) $(c_flags) -print-libgcc-file-name`) -lgcc`.
>>
>> I'll try to find out how buildman executes the make process.
>>
>> ```
>> $ ./tools/buildman/buildman -o /tmp/qemu-riscv32_spl/ -w -E -W -e -V -v --board qemu-riscv32_spl
>> $ cat /tmp/qemu-riscv32_spl/log | grep u-boot.map
>> riscv64-linux-ld.bfd -m elf32lriscv --gc-sections -static -pie -Bstatic --no-dynamic-linker -z notext --build-id=none -Ttext 0x81200000 -o u-boot -T u-boot.lds arch/riscv/cpu/start.o --whole-archive arch/riscv/cpu/built-in.o arch/riscv/cpu/generic/built-in.o arch/riscv/lib/built-in.o board/emulation/common/built-in.o board/emulation/qemu-riscv/built-in.o boot/built-in.o cmd/built-in.o common/built-in.o disk/built-in.o drivers/built-in.o drivers/usb/cdns3/built-in.o drivers/usb/common/built-in.o drivers/usb/dwc3/built-in.o drivers/usb/emul/built-in.o drivers/usb/eth/built-in.o drivers/usb/host/built-in.o drivers/usb/mtu3/built-in.o drivers/usb/musb-new/built-in.o drivers/usb/musb/built-in.o drivers/usb/phy/built-in.o drivers/usb/ulpi/built-in.o env/built-in.o fs/built-in.o lib/built-in.o net/built-in.o --no-whole-archive -L /opt/gcc-11.1.0-nolibc/riscv64-linux/bin/../lib/gcc/riscv64-linux/11.1.0 -lgcc -Map u-boot.map; true
>> ```
>>
>
> This patch looks valid, it's the CI process which causes the error to occur.
>
> The command "dirname $(riscv64-linux-gcc -march=rv32imac -mabi=ilp32 -print-libgcc-filename)" gives
> different result from "dirname $(riscv64-linux-gcc -march=rv32imac_zicsr_zifencei -mabi=ilp32 -print-libgcc-filename)".
>
> The former gives "/opt/gcc-11.1.0-nolibc/riscv64-linux/bin/../lib/gcc/riscv64-linux/11.1.0/lib32/ilp32"
> while the latter gives "/opt/gcc-11.1.0-nolibc/riscv64-linux/bin/../lib/gcc/riscv64-linux/11.1.0".
>
> The symbol __ashldi3 and __lshrdi3 only exist in libgcc.a under /opt/gcc-11.1.0-nolibc/riscv64-linux/bin/../lib/gcc/riscv64-linux/11.1.0/lib32/ilp32,
> so linker search path have to be set to it to link successfully.
>
> The multilib setting does not cover zifencei and zicsr, so we get a default multilib path from -print-libgcc-file-name, and thus run into error like this.
>
> We should be able to fix this by using 32 bit toolchain in the CI process for 32 bit platform/configuration.
>
> Any thoughts or comments ?
In our Docker container command
tools/buildman/buildman -o build -w -E -W -e --board qemu-riscv32_spl
leads to build/toolchain with content
gcc /opt/gcc-11.1.0-nolibc/riscv64-linux/bin/riscv64-linux-gcc
path /opt/gcc-11.1.0-nolibc/riscv64-linux/bin
cross riscv64-linux-
arch riscv64
When compiling qemu-riscv32_defconfig with Alexandre's patch and
export
CROSS_COMPILE=/opt/gcc-11.1.0-nolibc/riscv64-linux/bin/riscv64-linux-
I see undefined reference to `__ashldi3'.
With
export
CROSS_COMPILE=/opt/gcc-11.1.0-nolibc/riscv32-linux/bin/riscv32-linux-
it works correctly.
So first thing to do is to fix the Docker container to install the
riscv32 toolchain.
Next we have to tell binman to use (installing the tool chain is not
enough).
Best regards
Heinrich
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] riscv: Fix build against binutils 2.38
2022-10-01 23:24 ` Heinrich Schuchardt
@ 2022-10-01 23:57 ` Tom Rini
2022-10-02 1:52 ` Heinrich Schuchardt
0 siblings, 1 reply; 24+ messages in thread
From: Tom Rini @ 2022-10-01 23:57 UTC (permalink / raw)
To: Heinrich Schuchardt
Cc: Leo Liang, Alexandre Ghiti, Rick Chen, Aurelien Jarno, u-boot,
bmeng.cn, sjg
[-- Attachment #1: Type: text/plain, Size: 13113 bytes --]
On Sun, Oct 02, 2022 at 01:24:08AM +0200, Heinrich Schuchardt wrote:
> On 3/9/22 07:31, Leo Liang wrote:
> > Hi Alex,
> > On Thu, Mar 03, 2022 at 11:06:18AM +0000, Leo Liang wrote:
> > > Hi Alex,
> > > On Tue, Mar 01, 2022 at 03:21:56AM +0000, Leo Liang wrote:
> > > > Hi Alex,
> > > > On Mon, Feb 21, 2022 at 05:42:41PM +0100, Alexandre Ghiti wrote:
> > > > > On Sat, Feb 19, 2022 at 9:52 AM Leo Liang <ycliang@andestech.com> wrote:
> > > > > >
> > > > > > Hi Alex,
> > > > > > On Thu, Feb 17, 2022 at 11:28:46AM +0100, Alexandre Ghiti wrote:
> > > > > > > Hi Leo,
> > > > > > >
> > > > > > > On Thu, Feb 17, 2022 at 10:25 AM Leo Liang <ycliang@andestech.com> wrote:
> > > > > > > >
> > > > > > > > Hi Alexandre,
> > > > > > > > On Fri, Jan 28, 2022 at 02:47:13PM +0100, Alexandre Ghiti wrote:
> > > > > > > > > The following description is copied from the equivalent patch for the
> > > > > > > > > Linux Kernel proposed by Aurelien Jarno:
> > > > > > > > >
> > > > > > > > > From version 2.38, binutils default to ISA spec version 20191213. This
> > > > > > > > > means that the csr read/write (csrr*/csrw*) instructions and fence.i
> > > > > > > > > instruction has separated from the `I` extension, become two standalone
> > > > > > > > > extensions: Zicsr and Zifencei. As the kernel uses those instruction,
> > > > > > > > > this causes the following build failure:
> > > > > > > > >
> > > > > > > > > arch/riscv/cpu/mtrap.S: Assembler messages:
> > > > > > > > > arch/riscv/cpu/mtrap.S:65: Error: unrecognized opcode `csrr a0,scause'
> > > > > > > > > arch/riscv/cpu/mtrap.S:66: Error: unrecognized opcode `csrr a1,sepc'
> > > > > > > > > arch/riscv/cpu/mtrap.S:67: Error: unrecognized opcode `csrr a2,stval'
> > > > > > > > > arch/riscv/cpu/mtrap.S:70: Error: unrecognized opcode `csrw sepc,a0'
> > > > > > > > >
> > > > > > > > > Signed-off-by: Alexandre Ghiti <alexandre.ghiti@canonical.com>
> > > > > > > > > ---
> > > > > > > > > arch/riscv/Makefile | 11 ++++++++++-
> > > > > > > > > 1 file changed, 10 insertions(+), 1 deletion(-)
> > > > > > > >
> > > > > > > > This patch seems to fail CI somehow.
> > > > > > > > (https://source.denx.de/u-boot/custodians/u-boot-riscv/-/pipelines/11004)
> > > > > > > >
> > > > > > > > Could you take a look at it ?
> > > > > > >
> > > > > > > I have just tried on master (commit ab8903a24db1) and it failed for
> > > > > > > the same reason, so this is not related to this patch. Nevertheless,
> > > > > > > I'll try to bisect the problem :)
> > > > > > >
> > > > > > > Thanks,
> > > > > > >
> > > > > > > Alex
> > > > > > >
> > > > > >
> > > > > > Thanks for putting the effort into it!
> > > > > >
> > > > > > AFAIK, this patch does nothing related to the error message "undefined reference to `__ashldi3'" from the failed CI.
> > > > > >
> > > > > > Nonetheless, I have tried a few times myself,
> > > > > > and found that CI could pass with ab8903a24db1 but cannot pass with this patch on my side.
> > > > > > https://source.denx.de/u-boot/custodians/u-boot-riscv/-/commits/staging
> > > > > > https://source.denx.de/u-boot/custodians/u-boot-riscv/-/pipelines
> > > > > >
> > > > >
> > > > > To me it is an issue with the toolchain: libgcc is missing those
> > > > > symbols. If I use an Ubuntu toolchain, it fails no matter which commit
> > > > > I am on (I tested as far as v2021.10). But if I use a toolchain from
> > > > > https://mirrors.edge.kernel.org/pub/tools/crosstool/files/bin/x86_64/,
> > > > > it works fine.
> > > > >
> > > > > What I don't understand is how you manage to have different build
> > > > > results with the same docker image: can you confirm that you use the
> > > > > same toolchains in the following builds?
> > > > >
> > > > > https://source.denx.de/u-boot/custodians/u-boot-riscv/-/jobs/393701
> > > > > https://source.denx.de/u-boot/custodians/u-boot-riscv/-/jobs/393783
> > > > >
> > > >
> > > > Sorry for the late reply.
> > > > I have checked the toolchain version of these two builds,
> > > > they are using the same toolchain[1] from Tom's docker image on docker hub[2].
> > > >
> > > > Also the fail is reproducible using this docker image with the following commands:
> > > >
> > > > leo@host sudo docker run -it --name leo-test trini/u-boot-gitlab-ci-runner:focal-20220113-03Feb2022 /bin/bash
> > > > uboot@356268d27bf0:~$ git clone https://source.denx.de/u-boot/custodians/u-boot-riscv.git && cd u-boot-riscv
> > > > uboot@356268d27bf0:~/u-boot-riscv$ git checkout staging
> > > > uboot@356268d27bf0:~/u-boot-riscv$ export PATH=/opt/gcc-11.1.0-nolibc/riscv64-linux/bin:$PATH
> > > > uboot@356268d27bf0:~/u-boot-riscv$ export CROSS_COMPILE=riscv64-linux-
> > > > uboot@356268d27bf0:~/u-boot-riscv$ make qemu-riscv32_spl_defconfig
> > > > uboot@356268d27bf0:~/u-boot-riscv$ make -j`nproc` V=1
> > > >
> > > > ...
> > > >
> > > > riscv64-linux-ld.bfd -m elf32lriscv --gc-sections -static -pie -Bstatic --no-dynamic-linker -z notext --build-id=none -Ttext 0x81200000 -o u-boot -T u-boot.lds arch/riscv/cpu/start.o --whole-archive arch/riscv/cpu/built-in.o arch/riscv/cpu/generic/built-in.o arch/riscv/lib/built-in.o board/emulation/common/built-in.o board/emulation/qemu-riscv/built-in.o boot/built-in.o cmd/built-in.o common/built-in.o disk/built-in.o drivers/built-in.o drivers/usb/cdns3/built-in.o drivers/usb/common/built-in.o drivers/usb/dwc3/built-in.o drivers/usb/emul/built-in.o drivers/usb/eth/built-in.o drivers/usb/host/built-in.o drivers/usb/mtu3/built-in.o drivers/usb/musb-new/built-in.o drivers/usb/musb/built-in.o drivers/usb/phy/built-in.o drivers/usb/ulpi/built-in.o env/built-in.o fs/built-in.o lib/built-in.o net/built-in.o --no-whole-archive -L /opt/gcc-11.1.0-nolibc/riscv64-linux/bin/../lib/gcc/riscv64-linux/11.1.0 -lgcc -Map u-boot.map; true
> > > > riscv64-linux-ld.bfd: drivers/virtio/virtio-uclass.o: in function `virtio_uclass_child_pre_probe':
> > > > /home/uboot/u-boot-riscv/drivers/virtio/virtio-uclass.c:339: undefined reference to `__lshrdi3'
> > > > riscv64-linux-ld.bfd: /home/uboot/u-boot-riscv/drivers/virtio/virtio-uclass.c:311: undefined reference to `__ashldi3'
> > > > riscv64-linux-ld.bfd: /home/uboot/u-boot-riscv/drivers/virtio/virtio-uclass.c:310: undefined reference to `__ashldi3'
> > > > riscv64-linux-ld.bfd: drivers/nvme/nvme.o: in function `nvme_blk_rw':
> > > > /home/uboot/u-boot-riscv/drivers/nvme/nvme.c:776: undefined reference to `__lshrdi3'
> > > > riscv64-linux-ld.bfd: fs/ext4/ext4_common.o: in function `ext4fs_get_extent_block':
> > > > /home/uboot/u-boot-riscv/fs/ext4/ext4_common.c:1560: undefined reference to `__ashldi3'
> > > > riscv64-linux-ld.bfd: fs/ext4/dev.o: in function `ext4fs_set_blk_dev':
> > > > /home/uboot/u-boot-riscv/fs/ext4/dev.c:46: undefined reference to `__lshrdi3'
> > > > riscv64-linux-ld.bfd: lib/display_options.o: in function `print_size':
> > > > /home/uboot/u-boot-riscv/lib/display_options.c:103: undefined reference to `__lshrdi3'
> > > > riscv64-linux-ld.bfd: /home/uboot/u-boot-riscv/lib/display_options.c:102: undefined reference to `__ashldi3'
> > > > riscv64-linux-ld.bfd: /home/uboot/u-boot-riscv/lib/display_options.c:95: undefined reference to `__ashldi3'
> > > > riscv64-linux-ld.bfd: /home/uboot/u-boot-riscv/lib/display_options.c:124: undefined reference to `__lshrdi3'
> > > > riscv64-linux-ld.bfd: lib/vsprintf.o: in function `number':
> > > > /home/uboot/u-boot-riscv/lib/vsprintf.c:213: undefined reference to `__lshrdi3'
> > > > make: *** [Makefile:1800: u-boot] Error 1
> > > >
> > > > Furthermore, Using the same container and perform the identical build commands listed above on master branch produce no error.
> > > >
> > > > What seems a bit odd is that when testing qemu-riscv32_spl,
> > > > buildman still uses 64 bit toolchain for the build.
> > > > I am not sure what the effect of "riscv64-linux-ld.bfd -m elf32lriscv" is.
> > > >
> > > > Do you have any thoughts ?
> > > >
> > > > [1] https://mirrors.edge.kernel.org/pub/tools/crosstool/files/bin/x86_64/11.1.0/x86_64-gcc-11.1.0-nolibc-riscv64-linux.tar.xz
> > > > [2] https://hub.docker.com/layers/trini/u-boot-gitlab-ci-runner/focal-20220113-03Feb2022/images/sha256-b1cddec69526015c550ac8e528114c976ccd1a0e75676328c4f81b834e06b2b3?context=explore
> > > >
> > > > Best regards,
> > > > Leo
> > > >
> > >
> > > I re-ran again with buildman's verbose option (./tools/buildman/buildman -o /tmp/qemu-riscv32_spl/ -w -E -W -e -V -v --board qemu-riscv32_spl)
> > > and found that the failed command is as below:
> > >
> > > riscv64-linux-ld.bfd -m elf32lriscv --gc-sections -static -pie -Bstatic --no-dynamic-linker -z notext --build-id=none -Ttext 0x81200000 -o u-boot -T u-boot.lds arch/riscv/cpu/start.o --whole-archive arch/riscv/cpu/built-in.o arch/riscv/cpu/generic/built-in.o arch/riscv/lib/built-in.o board/emulation/common/built-in.o board/emulation/qemu-riscv/built-in.o boot/built-in.o cmd/built-in.o common/built-in.o disk/built-in.o drivers/built-in.o drivers/usb/cdns3/built-in.o drivers/usb/common/built-in.o drivers/usb/dwc3/built-in.o drivers/usb/emul/built-in.o drivers/usb/eth/built-in.o drivers/usb/host/built-in.o drivers/usb/mtu3/built-in.o drivers/usb/musb-new/built-in.o drivers/usb/musb/built-in.o drivers/usb/phy/built-in.o drivers/usb/ulpi/built-in.o env/built-in.o fs/built-in.o lib/built-in.o net/built-in.o --no-whole-archive -L /opt/gcc-11.1.0-nolibc/riscv64-linux/bin/../lib/gcc/riscv64-linux/11.1.0 -lgcc -Map u-boot.map; true
> > > ^^^^^^^^^^^^^^^^^^^^^^
> > >
> > > The reason for this to fail is due to the wrong search path for libgcc.
> > > The above command uses "-L /opt/gcc-11.1.0-nolibc/riscv64-linux/bin/../lib/gcc/riscv64-linux/11.1.0",
> > > where it should be "-L /opt/gcc-11.1.0-nolibc/riscv64-linux/bin/../lib/gcc/riscv64-linux/11.1.0/lib32/ilp32[d]".
> > >
> > > This search path is generated from Makefile:865 `PLATFORM_LIBGCC := -L $(shell dirname `$(CC) $(c_flags) -print-libgcc-file-name`) -lgcc`.
> > >
> > > I'll try to find out how buildman executes the make process.
> > >
> > > ```
> > > $ ./tools/buildman/buildman -o /tmp/qemu-riscv32_spl/ -w -E -W -e -V -v --board qemu-riscv32_spl
> > > $ cat /tmp/qemu-riscv32_spl/log | grep u-boot.map
> > > riscv64-linux-ld.bfd -m elf32lriscv --gc-sections -static -pie -Bstatic --no-dynamic-linker -z notext --build-id=none -Ttext 0x81200000 -o u-boot -T u-boot.lds arch/riscv/cpu/start.o --whole-archive arch/riscv/cpu/built-in.o arch/riscv/cpu/generic/built-in.o arch/riscv/lib/built-in.o board/emulation/common/built-in.o board/emulation/qemu-riscv/built-in.o boot/built-in.o cmd/built-in.o common/built-in.o disk/built-in.o drivers/built-in.o drivers/usb/cdns3/built-in.o drivers/usb/common/built-in.o drivers/usb/dwc3/built-in.o drivers/usb/emul/built-in.o drivers/usb/eth/built-in.o drivers/usb/host/built-in.o drivers/usb/mtu3/built-in.o drivers/usb/musb-new/built-in.o drivers/usb/musb/built-in.o drivers/usb/phy/built-in.o drivers/usb/ulpi/built-in.o env/built-in.o fs/built-in.o lib/built-in.o net/built-in.o --no-whole-archive -L /opt/gcc-11.1.0-nolibc/riscv64-linux/bin/../lib/gcc/riscv64-linux/11.1.0 -lgcc -Map u-boot.map; true
> > > ```
> > >
> >
> > This patch looks valid, it's the CI process which causes the error to occur.
> >
> > The command "dirname $(riscv64-linux-gcc -march=rv32imac -mabi=ilp32 -print-libgcc-filename)" gives
> > different result from "dirname $(riscv64-linux-gcc -march=rv32imac_zicsr_zifencei -mabi=ilp32 -print-libgcc-filename)".
> >
> > The former gives "/opt/gcc-11.1.0-nolibc/riscv64-linux/bin/../lib/gcc/riscv64-linux/11.1.0/lib32/ilp32"
> > while the latter gives "/opt/gcc-11.1.0-nolibc/riscv64-linux/bin/../lib/gcc/riscv64-linux/11.1.0".
> >
> > The symbol __ashldi3 and __lshrdi3 only exist in libgcc.a under /opt/gcc-11.1.0-nolibc/riscv64-linux/bin/../lib/gcc/riscv64-linux/11.1.0/lib32/ilp32,
> > so linker search path have to be set to it to link successfully.
> >
> > The multilib setting does not cover zifencei and zicsr, so we get a default multilib path from -print-libgcc-file-name, and thus run into error like this.
> >
> > We should be able to fix this by using 32 bit toolchain in the CI process for 32 bit platform/configuration.
> >
> > Any thoughts or comments ?
>
> In our Docker container command
>
> tools/buildman/buildman -o build -w -E -W -e --board qemu-riscv32_spl
>
> leads to build/toolchain with content
>
> gcc /opt/gcc-11.1.0-nolibc/riscv64-linux/bin/riscv64-linux-gcc
> path /opt/gcc-11.1.0-nolibc/riscv64-linux/bin
> cross riscv64-linux-
> arch riscv64
>
> When compiling qemu-riscv32_defconfig with Alexandre's patch and
>
> export
> CROSS_COMPILE=/opt/gcc-11.1.0-nolibc/riscv64-linux/bin/riscv64-linux-
>
> I see undefined reference to `__ashldi3'.
Another reason to port the generic *di3 option from modern Linux kernel.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] riscv: Fix build against binutils 2.38
2022-10-01 23:57 ` Tom Rini
@ 2022-10-02 1:52 ` Heinrich Schuchardt
2022-10-02 17:16 ` Tom Rini
0 siblings, 1 reply; 24+ messages in thread
From: Heinrich Schuchardt @ 2022-10-02 1:52 UTC (permalink / raw)
To: Tom Rini
Cc: Leo Liang, Alexandre Ghiti, Rick Chen, Aurelien Jarno, u-boot,
bmeng.cn, sjg
On 10/2/22 01:57, Tom Rini wrote:
>>> Any thoughts or comments ?
>> In our Docker container command
>>
>> tools/buildman/buildman -o build -w -E -W -e --board qemu-riscv32_spl
>>
>> leads to build/toolchain with content
>>
>> gcc /opt/gcc-11.1.0-nolibc/riscv64-linux/bin/riscv64-linux-gcc
>> path /opt/gcc-11.1.0-nolibc/riscv64-linux/bin
>> cross riscv64-linux-
>> arch riscv64
>>
>> When compiling qemu-riscv32_defconfig with Alexandre's patch and
>>
>> export
>> CROSS_COMPILE=/opt/gcc-11.1.0-nolibc/riscv64-linux/bin/riscv64-linux-
>>
>> I see undefined reference to `__ashldi3'.
> Another reason to port the generic *di3 option from modern Linux kernel.
Why should we use a 64bit toolchain for 32bit RISC-V when a 32bit
toolchain is available?
Fixing the Docker container and buildman seems to be the logical way
forward.
Cf.
https://source.denx.de/u-boot/custodians/u-boot-efi/-/commits/riscv
https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/13657
Best regards
Heinrich
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] riscv: Fix build against binutils 2.38
2022-10-02 1:52 ` Heinrich Schuchardt
@ 2022-10-02 17:16 ` Tom Rini
2022-10-02 17:25 ` Tom Rini
0 siblings, 1 reply; 24+ messages in thread
From: Tom Rini @ 2022-10-02 17:16 UTC (permalink / raw)
To: Heinrich Schuchardt
Cc: Leo Liang, Alexandre Ghiti, Rick Chen, Aurelien Jarno, u-boot,
bmeng.cn, sjg
[-- Attachment #1: Type: text/plain, Size: 1369 bytes --]
On Sun, Oct 02, 2022 at 03:52:00AM +0200, Heinrich Schuchardt wrote:
>
>
> On 10/2/22 01:57, Tom Rini wrote:
> > > > Any thoughts or comments ?
> > > In our Docker container command
> > >
> > > tools/buildman/buildman -o build -w -E -W -e --board qemu-riscv32_spl
> > >
> > > leads to build/toolchain with content
> > >
> > > gcc /opt/gcc-11.1.0-nolibc/riscv64-linux/bin/riscv64-linux-gcc
> > > path /opt/gcc-11.1.0-nolibc/riscv64-linux/bin
> > > cross riscv64-linux-
> > > arch riscv64
> > >
> > > When compiling qemu-riscv32_defconfig with Alexandre's patch and
> > >
> > > export
> > > CROSS_COMPILE=/opt/gcc-11.1.0-nolibc/riscv64-linux/bin/riscv64-linux-
> > >
> > > I see undefined reference to `__ashldi3'.
> > Another reason to port the generic *di3 option from modern Linux kernel.
>
> Why should we use a 64bit toolchain for 32bit RISC-V when a 32bit toolchain
> is available?
>
> Fixing the Docker container and buildman seems to be the logical way
> forward.
>
> Cf.
> https://source.denx.de/u-boot/custodians/u-boot-efi/-/commits/riscv
> https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/13657
Because it's also yet another example of the problems we have because we
haven't ported that functionality back, which improves on the state of
what's in our tree today wrt "libgcc".
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] riscv: Fix build against binutils 2.38
2022-10-02 17:16 ` Tom Rini
@ 2022-10-02 17:25 ` Tom Rini
0 siblings, 0 replies; 24+ messages in thread
From: Tom Rini @ 2022-10-02 17:25 UTC (permalink / raw)
To: Heinrich Schuchardt
Cc: Leo Liang, Alexandre Ghiti, Rick Chen, Aurelien Jarno, u-boot,
bmeng.cn, sjg
[-- Attachment #1: Type: text/plain, Size: 1650 bytes --]
On Sun, Oct 02, 2022 at 01:16:33PM -0400, Tom Rini wrote:
> On Sun, Oct 02, 2022 at 03:52:00AM +0200, Heinrich Schuchardt wrote:
> >
> >
> > On 10/2/22 01:57, Tom Rini wrote:
> > > > > Any thoughts or comments ?
> > > > In our Docker container command
> > > >
> > > > tools/buildman/buildman -o build -w -E -W -e --board qemu-riscv32_spl
> > > >
> > > > leads to build/toolchain with content
> > > >
> > > > gcc /opt/gcc-11.1.0-nolibc/riscv64-linux/bin/riscv64-linux-gcc
> > > > path /opt/gcc-11.1.0-nolibc/riscv64-linux/bin
> > > > cross riscv64-linux-
> > > > arch riscv64
> > > >
> > > > When compiling qemu-riscv32_defconfig with Alexandre's patch and
> > > >
> > > > export
> > > > CROSS_COMPILE=/opt/gcc-11.1.0-nolibc/riscv64-linux/bin/riscv64-linux-
> > > >
> > > > I see undefined reference to `__ashldi3'.
> > > Another reason to port the generic *di3 option from modern Linux kernel.
> >
> > Why should we use a 64bit toolchain for 32bit RISC-V when a 32bit toolchain
> > is available?
> >
> > Fixing the Docker container and buildman seems to be the logical way
> > forward.
> >
> > Cf.
> > https://source.denx.de/u-boot/custodians/u-boot-efi/-/commits/riscv
> > https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/13657
>
> Because it's also yet another example of the problems we have because we
> haven't ported that functionality back, which improves on the state of
> what's in our tree today wrt "libgcc".
Which is not to say I disagree with v3 of your series, this just
reminded me of problems we have that I dug in to last week for other
reasons.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2022-10-02 17:25 UTC | newest]
Thread overview: 24+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-01-28 13:47 [PATCH] riscv: Fix build against binutils 2.38 Alexandre Ghiti
2022-01-28 14:15 ` Bin Meng
2022-01-28 18:03 ` Heinrich Schuchardt
2022-01-28 18:19 ` Aurelien Jarno
2022-01-28 18:28 ` Aurelien Jarno
2022-01-28 18:22 ` Heinrich Schuchardt
2022-02-17 9:24 ` Leo Liang
2022-02-17 10:28 ` Alexandre Ghiti
2022-02-19 8:51 ` Leo Liang
2022-02-21 16:42 ` Alexandre Ghiti
2022-03-01 3:21 ` Leo Liang
2022-03-03 11:06 ` Leo Liang
2022-03-09 6:31 ` Leo Liang
2022-03-10 8:03 ` Alexandre Ghiti
2022-04-07 9:12 ` Leo Liang
2022-04-12 9:14 ` Alexandre Ghiti
2022-04-13 1:49 ` Leo Liang
2022-10-01 23:24 ` Heinrich Schuchardt
2022-10-01 23:57 ` Tom Rini
2022-10-02 1:52 ` Heinrich Schuchardt
2022-10-02 17:16 ` Tom Rini
2022-10-02 17:25 ` Tom Rini
2022-06-23 13:40 ` Heiko Stübner
2022-08-30 20:28 ` Christian Stewart
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.