[PATCH] riscv: Fix build against binutils 2.38

Alexandre Ghiti alexandre.ghiti at canonical.com
Mon Feb 21 17:42:41 CET 2022


On Sat, Feb 19, 2022 at 9:52 AM Leo Liang <ycliang at 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 at 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 at 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


More information about the U-Boot mailing list