Building loongarch64 toolchain

Building loongarch64 toolchain

[Guenter Roeck]

Hi,

I have been trying to build a toolchain for loongarch64 using gcc 12.1.0 and
binutils 2.38. Unfortunately, the resulting toolchain doesn't work for me.
Tracking down the problem, it turns out that gcc passes -mabi=lp64d to the
assembler, but the assembler only supports -mabi=lp64.

Where can I find guidance on how to build a working toolchain ? Using the
available toolchain binaries is not an option.

Thanks,
Guenter

Re: Building loongarch64 toolchain

[Huacai Chen]

Hi, Xuerui,

On Thu, Jun 30, 2022 at 10:06 PM Guenter Roeck <linux@roeck-us.net> wrote:
>
> Hi,
>
> I have been trying to build a toolchain for loongarch64 using gcc 12.1.0 and
> binutils 2.38. Unfortunately, the resulting toolchain doesn't work for me.
> Tracking down the problem, it turns out that gcc passes -mabi=lp64d to the
> assembler, but the assembler only supports -mabi=lp64.
>
> Where can I find guidance on how to build a working toolchain ? Using the
> available toolchain binaries is not an option.
Could you please give some guidance?

Huacai
>
> Thanks,
> Guenter
>

Re: Building loongarch64 toolchain

[Guenter Roeck]

On 6/30/22 19:14, Huacai Chen wrote:
> Hi, Xuerui,
> 
> On Thu, Jun 30, 2022 at 10:06 PM Guenter Roeck <linux@roeck-us.net> wrote:
>>
>> Hi,
>>
>> I have been trying to build a toolchain for loongarch64 using gcc 12.1.0 and
>> binutils 2.38. Unfortunately, the resulting toolchain doesn't work for me.
>> Tracking down the problem, it turns out that gcc passes -mabi=lp64d to the
>> assembler, but the assembler only supports -mabi=lp64.
>>
>> Where can I find guidance on how to build a working toolchain ? Using the
>> available toolchain binaries is not an option.
> Could you please give some guidance?
> 

I ended up hacking binutils to accept all lp64 mabi variants.

--- binutils-2.38.orig/gas/config/tc-loongarch.c	2022-01-22 04:14:08.000000000 -0800
+++ binutils-2.38/gas/config/tc-loongarch.c	2022-06-30 07:41:29.545038901 -0700
@@ -142,7 +142,8 @@
    switch (c)
      {
      case OPTION_ABI:
-      if (strcasecmp (arg, "lp64") == 0)
+      if (!strcasecmp (arg, "lp64") || !strcasecmp (arg, "lp64d") ||
+          !strcasecmp (arg, "lp64s") || !strcasecmp (arg, "lp64f"))
  	{
  	  LARCH_opts.ase_abi |= EF_LOONGARCH_ABI_LP64;
  	  LARCH_opts.ase_ilp32 = 1;

With that, I am able to compile loongarch:defconfig. I'd still like
to understand the problem and avoid the hack, though.

Thanks,
Guenter

Re: Building loongarch64 toolchain

[WANG Xuerui]

Hi,

On 7/1/22 14:39, Guenter Roeck wrote:
> On 6/30/22 19:14, Huacai Chen wrote:
>> Hi, Xuerui,
>>
>> On Thu, Jun 30, 2022 at 10:06 PM Guenter Roeck <linux@roeck-us.net> 
>> wrote:
>>>
>>> Hi,
>>>
>>> I have been trying to build a toolchain for loongarch64 using gcc 
>>> 12.1.0 and
>>> binutils 2.38. Unfortunately, the resulting toolchain doesn't work 
>>> for me.
>>> Tracking down the problem, it turns out that gcc passes -mabi=lp64d 
>>> to the
>>> assembler, but the assembler only supports -mabi=lp64.
>>>
>>> Where can I find guidance on how to build a working toolchain ? 
>>> Using the
>>> available toolchain binaries is not an option.
>> Could you please give some guidance?
>>
>
> I ended up hacking binutils to accept all lp64 mabi variants.
>
> --- binutils-2.38.orig/gas/config/tc-loongarch.c    2022-01-22 
> 04:14:08.000000000 -0800
> +++ binutils-2.38/gas/config/tc-loongarch.c    2022-06-30 
> 07:41:29.545038901 -0700
> @@ -142,7 +142,8 @@
>    switch (c)
>      {
>      case OPTION_ABI:
> -      if (strcasecmp (arg, "lp64") == 0)
> +      if (!strcasecmp (arg, "lp64") || !strcasecmp (arg, "lp64d") ||
> +          !strcasecmp (arg, "lp64s") || !strcasecmp (arg, "lp64f"))
>      {
>        LARCH_opts.ase_abi |= EF_LOONGARCH_ABI_LP64;
>        LARCH_opts.ase_ilp32 = 1;
>
> With that, I am able to compile loongarch:defconfig. I'd still like
> to understand the problem and avoid the hack, though.

This is due to an incompatible change to the LoongArch toolchain 
convention spec (the first version was like [1], got criticized mainly 
by me, then morphed into the final take [2], all discussion was in 
Chinese though), after the initial port went public and got accepted by 
binutils upstream. The binutils trunk has already been updated; in 
particular, you want at least [3] for compatibility with gcc.

BTW, you could use the Gentoo toolchain for easy experimentation if 
that's acceptable for you. (I maintain the Gentoo/LoongArch port so I 
know that toolchain is working for most commonly encountered software. 
It's probably carrying more downstream patches than some of you would 
prefer, although I don't find that to be a problem so far.)

[1]: https://github.com/loongson/LoongArch-Documentation/pull/23
[2]: https://github.com/loongson/LoongArch-Documentation/pull/24
[3]: 
https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=3b14682a432e61c756ec9ad0b5bf5f8136e2cdce

-- 
WANG "xen0n" Xuerui

Linux/LoongArch mailing list: https://lore.kernel.org/loongarch/

Re: Building loongarch64 toolchain

[Guenter Roeck]

On Sat, Jul 02, 2022 at 12:37:21AM +0800, WANG Xuerui wrote:
> Hi,
> 
> On 7/1/22 14:39, Guenter Roeck wrote:
> > On 6/30/22 19:14, Huacai Chen wrote:
> > > Hi, Xuerui,
> > > 
> > > On Thu, Jun 30, 2022 at 10:06 PM Guenter Roeck <linux@roeck-us.net>
> > > wrote:
> > > > 
> > > > Hi,
> > > > 
> > > > I have been trying to build a toolchain for loongarch64 using
> > > > gcc 12.1.0 and
> > > > binutils 2.38. Unfortunately, the resulting toolchain doesn't
> > > > work for me.
> > > > Tracking down the problem, it turns out that gcc passes
> > > > -mabi=lp64d to the
> > > > assembler, but the assembler only supports -mabi=lp64.
> > > > 
> > > > Where can I find guidance on how to build a working toolchain ?
> > > > Using the
> > > > available toolchain binaries is not an option.
> > > Could you please give some guidance?
> > > 
> > 
> > I ended up hacking binutils to accept all lp64 mabi variants.
> > 
> > --- binutils-2.38.orig/gas/config/tc-loongarch.c    2022-01-22
> > 04:14:08.000000000 -0800
> > +++ binutils-2.38/gas/config/tc-loongarch.c    2022-06-30
> > 07:41:29.545038901 -0700
> > @@ -142,7 +142,8 @@
> >    switch (c)
> >      {
> >      case OPTION_ABI:
> > -      if (strcasecmp (arg, "lp64") == 0)
> > +      if (!strcasecmp (arg, "lp64") || !strcasecmp (arg, "lp64d") ||
> > +          !strcasecmp (arg, "lp64s") || !strcasecmp (arg, "lp64f"))
> >      {
> >        LARCH_opts.ase_abi |= EF_LOONGARCH_ABI_LP64;
> >        LARCH_opts.ase_ilp32 = 1;
> > 
> > With that, I am able to compile loongarch:defconfig. I'd still like
> > to understand the problem and avoid the hack, though.
> 
> This is due to an incompatible change to the LoongArch toolchain convention
> spec (the first version was like [1], got criticized mainly by me, then
> morphed into the final take [2], all discussion was in Chinese though),
> after the initial port went public and got accepted by binutils upstream.
> The binutils trunk has already been updated; in particular, you want at
> least [3] for compatibility with gcc.
> 
Thanks a lot for the explanation. Unfortunately, [3] does not apply on top
of binutils 2.38, so I asssume that there are other loongarch related
changes.

> BTW, you could use the Gentoo toolchain for easy experimentation if that's
> acceptable for you. (I maintain the Gentoo/LoongArch port so I know that
> toolchain is working for most commonly encountered software. It's probably
> carrying more downstream patches than some of you would prefer, although I
> don't find that to be a problem so far.)
> 

At this point I am just trying to compile the Linux kernel. The next step
would be create a root file system and to boot that kernel in qemu.
I'll leave that for later when I find an example of how to do that
to make sure that I don't waste my time playing around with qemu.
Until then, I think I'll just stick with my hack (and hopefully the
next version of binutils should work).

On a related note, in addition to the Linux kernel patches I just posted,
allmodconfig doesn't build because __cmpxchg and __xchg do not support
8-bit and 16-bit operations. Is there a plan to fix this ?

Thanks,
Guenter

> [1]: https://github.com/loongson/LoongArch-Documentation/pull/23
> [2]: https://github.com/loongson/LoongArch-Documentation/pull/24
> [3]: https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=3b14682a432e61c756ec9ad0b5bf5f8136e2cdce
> 
> -- 
> WANG "xen0n" Xuerui
> 
> Linux/LoongArch mailing list: https://lore.kernel.org/loongarch/
> 

Re: Building loongarch64 toolchain

[WANG Xuerui]

On 7/2/22 02:34, Guenter Roeck wrote:
> On Sat, Jul 02, 2022 at 12:37:21AM +0800, WANG Xuerui wrote:
>> Hi,
>>
>> On 7/1/22 14:39, Guenter Roeck wrote:
>>> On 6/30/22 19:14, Huacai Chen wrote:
>>>> Hi, Xuerui,
>>>>
>>>> On Thu, Jun 30, 2022 at 10:06 PM Guenter Roeck <linux@roeck-us.net>
>>>> wrote:
>>>>> Hi,
>>>>>
>>>>> I have been trying to build a toolchain for loongarch64 using
>>>>> gcc 12.1.0 and
>>>>> binutils 2.38. Unfortunately, the resulting toolchain doesn't
>>>>> work for me.
>>>>> Tracking down the problem, it turns out that gcc passes
>>>>> -mabi=lp64d to the
>>>>> assembler, but the assembler only supports -mabi=lp64.
>>>>>
>>>>> Where can I find guidance on how to build a working toolchain ?
>>>>> Using the
>>>>> available toolchain binaries is not an option.
>>>> Could you please give some guidance?
>>>>
>>> I ended up hacking binutils to accept all lp64 mabi variants.
>>>
>>> --- binutils-2.38.orig/gas/config/tc-loongarch.c    2022-01-22
>>> 04:14:08.000000000 -0800
>>> +++ binutils-2.38/gas/config/tc-loongarch.c    2022-06-30
>>> 07:41:29.545038901 -0700
>>> @@ -142,7 +142,8 @@
>>>     switch (c)
>>>       {
>>>       case OPTION_ABI:
>>> -      if (strcasecmp (arg, "lp64") == 0)
>>> +      if (!strcasecmp (arg, "lp64") || !strcasecmp (arg, "lp64d") ||
>>> +          !strcasecmp (arg, "lp64s") || !strcasecmp (arg, "lp64f"))
>>>       {
>>>         LARCH_opts.ase_abi |= EF_LOONGARCH_ABI_LP64;
>>>         LARCH_opts.ase_ilp32 = 1;
>>>
>>> With that, I am able to compile loongarch:defconfig. I'd still like
>>> to understand the problem and avoid the hack, though.
>> This is due to an incompatible change to the LoongArch toolchain convention
>> spec (the first version was like [1], got criticized mainly by me, then
>> morphed into the final take [2], all discussion was in Chinese though),
>> after the initial port went public and got accepted by binutils upstream.
>> The binutils trunk has already been updated; in particular, you want at
>> least [3] for compatibility with gcc.
>>
> Thanks a lot for the explanation. Unfortunately, [3] does not apply on top
> of binutils 2.38, so I asssume that there are other loongarch related
> changes.
I think it's due to commit 748594bc07f3 ("LoongArch: Use functions 
instead of magic numbers.") being the prerequisite.  I personally use 
either the Gentoo toolchain (for normal/casual use) or the trunk version 
(for development) anyway...
>
>> BTW, you could use the Gentoo toolchain for easy experimentation if that's
>> acceptable for you. (I maintain the Gentoo/LoongArch port so I know that
>> toolchain is working for most commonly encountered software. It's probably
>> carrying more downstream patches than some of you would prefer, although I
>> don't find that to be a problem so far.)
>>
> At this point I am just trying to compile the Linux kernel. The next step
> would be create a root file system and to boot that kernel in qemu.
> I'll leave that for later when I find an example of how to do that
> to make sure that I don't waste my time playing around with qemu.
> Until then, I think I'll just stick with my hack (and hopefully the
> next version of binutils should work).

Yeah the current QEMU trunk is known not to work for usable system 
emulation. This is being worked on but frankly I don't expect much 
progress before the 7.1 freeze. In the meantime only the pre-built 
binary at [1] is able to boot the EFI stub kernel (the bits are still 
under review at [2] obviously).

[1]: 
https://github.com/yangxiaojuan-loongson/qemu-binary/tree/main/binary-0613
[2]: 
https://lore.kernel.org/loongarch/20220617145754.582056-1-chenhuacai@loongson.cn/T/#u

>
> On a related note, in addition to the Linux kernel patches I just posted,
> allmodconfig doesn't build because __cmpxchg and __xchg do not support
> 8-bit and 16-bit operations. Is there a plan to fix this ?

I think this is being tackled at [3]. Might take a while before it's 
gonna land though, as the architecture lacks native sub-word atomics and 
such things are hard to get right.

[3]: 
https://lore.kernel.org/loongarch/20220623044752.2074066-1-chenhuacai@loongson.cn/

>
> Thanks,
> Guenter
>
>> [1]: https://github.com/loongson/LoongArch-Documentation/pull/23
>> [2]: https://github.com/loongson/LoongArch-Documentation/pull/24
>> [3]: https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=3b14682a432e61c756ec9ad0b5bf5f8136e2cdce
>>
>> -- 
>> WANG "xen0n" Xuerui
>>
>> Linux/LoongArch mailing list: https://lore.kernel.org/loongarch/
>>
-- 
WANG "xen0n" Xuerui

Linux/LoongArch mailing list: https://lore.kernel.org/loongarch/

Re: Building loongarch64 toolchain

[Xi Ruoyao]

On Sat, 2022-07-02 at 02:51 +0800, WANG Xuerui wrote:
> On 7/2/22 02:34, Guenter Roeck wrote:

> I think it's due to commit 748594bc07f3 ("LoongArch: Use functions 
> instead of magic numbers.") being the prerequisite.  I personally use 
> either the Gentoo toolchain (for normal/casual use) or the trunk version 
> (for development) anyway...
> > 
> > > BTW, you could use the Gentoo toolchain for easy experimentation if that's
> > > acceptable for you. (I maintain the Gentoo/LoongArch port so I know that
> > > toolchain is working for most commonly encountered software. It's probably
> > > carrying more downstream patches than some of you would prefer, although I
> > > don't find that to be a problem so far.)

In my build I apply every non-GDB LoongArch changes in binutils-gdb.git
master branch for 2.38.  Some of them are needed to keep the binutils
test result clean (and I don't want to spend too much time finding out
"which is really necessary").

> > 
> > At this point I am just trying to compile the Linux kernel. The next step
> > would be create a root file system and to boot that kernel in qemu.
> > I'll leave that for later when I find an example of how to do that
> > to make sure that I don't waste my time playing around with qemu.
> > Until then, I think I'll just stick with my hack (and hopefully the
> > next version of binutils should work).

BTW recently we also fixed a severe GCC issue for LoongArch:

https://gcc.gnu.org/r12-8520

I'm not sure if this issue will cause miscompilation of the kernel or
"some parts" of the kernel.
> > 

-- 
Xi Ruoyao <xry111@xry111.site>
School of Aerospace Science and Technology, Xidian University