Bug#1023486: Re: Bug#1023486: Re: Bug#1023486: Please add loong64 support to dpkg
Hi,Guillem > I assume anything not matching exactly values within OBJABI_MASK > would not be linkable either. If I'm reading the binutils source > correctly it seems to confirm this, although the comment there reads > to be negated: > > /* Disallow linking different ABIs. */ > /* Only check relocation version. >The obj_v0 is compatible with obj_v1. */ > > So shouldn't the latter be s/compatible/incompatible/? > > Also is the port going to be ABI v1? OBJABI is used to determine the version of the obj file to be linked. For binutils versions below 2.40, as generates OBJABI = obj_v0, and ld can only link to the obj_v0. For binutils versions 2.40 and above, as generates OBJABI = obj_v1, and ld can link any obj files of obj_v0 and obj_v1. The Loongarch code of version 2.40 has been submitted to the binutils upstream, and version 2.40 has not been released. Loongarch ELF ABI specification： https://github.com/loongson/LoongArch-Documentation/blob/main/docs/LoongArch-ELF-ABI-EN.adoc#e_flags-identifies-abi-type-and-version thanks, Dandan Zhang 本邮件及其附件含有龙芯中科的商业秘密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制或散发）本邮件及其附件中的信息。如果您错收本邮件，请您立即电话或邮件通知发件人并删除本邮件。 This email and its attachments contain confidential information from Loongson Technology , which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this email in error, please notify the sender by phone or email immediately and delete it.
Bug#1023486: Re: Bug#1023486: Please add loong64 support to dpkg
On Mon, 2022-11-14 at 18:01:26 +0800, 张丹丹 wrote: > > I think the part that was missing, which was asked on the list, and a > > rather important part of this! :) Is the ABI this conforms to. > > > > I'm attaching a patch that updates the test suite so that it passes, > > and adds what I think (but I don't know as I didn't check deeper) might > > change the ABI for built objects, which ties into the ABI this > > architecture is intended to conform to. > > > > I guess the main question is whether objects with these different > > EF_LOONGARCH_* flags can be mixed when linking or they are ABI > > incompatible, as the code in the patch now assume. > > 1、The value of ELF_FLAGS_LOONGARCH_* flags (you provided) conform to the > loongarch ABI standard. > 2、After confirmation, the following three ELF_FLAG_LOONGARCH_* can not be > mixed when linking，Because of different ABIs do not allow linking, otherwise > an > error will occur. As follows, >ELF_FLAG_LOONGARCH_SOFT_FLOAT => 0x0001, // soft float >ELF_FLAG_LOONGARCH_SINGLE_FLOAT => 0x0002, // single float >ELF_FLAG_LOONGARCH_DOUBLE_FLOAT => 0x0003, // double float I assume anything not matching exactly values within OBJABI_MASK would not be linkable either. If I'm reading the binutils source correctly it seems to confirm this, although the comment there reads to be negated: /* Disallow linking different ABIs. */ /* Only check relocation version. The obj_v0 is compatible with obj_v1. */ So shouldn't the latter be s/compatible/incompatible/? Also is the port going to be ABI v1? Thanks, Guillem
Bug#1023486: Re: Bug#1023486: Please add loong64 support to dpkg
Dear Guillem, > I think the part that was missing, which was asked on the list, and a > rather important part of this! :) Is the ABI this conforms to. > > I'm attaching a patch that updates the test suite so that it passes, > and adds what I think (but I don't know as I didn't check deeper) might > change the ABI for built objects, which ties into the ABI this > architecture is intended to conform to. > > I guess the main question is whether objects with these different > EF_LOONGARCH_* flags can be mixed when linking or they are ABI > incompatible, as the code in the patch now assume. 1、The value of ELF_FLAGS_LOONGARCH_* flags (you provided) conform to the loongarch ABI standard. 2、After confirmation, the following three ELF_FLAG_LOONGARCH_* can not be mixed when linking，Because of different ABIs do not allow linking, otherwise an error will occur. As follows, ELF_FLAG_LOONGARCH_SOFT_FLOAT => 0x0001, // soft float ELF_FLAG_LOONGARCH_SINGLE_FLOAT => 0x0002, // single float ELF_FLAG_LOONGARCH_DOUBLE_FLOAT => 0x0003, // double float thanks, Dandan Zhang > -原始邮件- > 发件人: "Guillem Jover" > 发送时间:2022-11-11 19:51:54 (星期五) > 收件人: "张丹丹" , 1023...@bugs.debian.org > 抄送: > 主题: Re: Bug#1023486: Please add loong64 support to dpkg > > Hi! > > On Sat, 2022-11-05 at 18:08:03 +0800, 张丹丹 wrote: > > Package: dpkg > > Version: 1.21.10 > > Severity: wishlist > > Tags: patch > > User: debian-de...@lists.debian.org > > Usertags: loongarch64 > > > According to the result of disscussion from > > debian-d...@lists.debian.org(https://lists.debian.org/debian-dpkg/2022/11/msg1.html), > > guil...@debian.org, hel...@subdivi.de, *@loongson.cn and so on. > > Dpkg architecture of loong64 just determine the name of the software > > packages. > > Should add loong64 architecture to dpkg package? > > > > - Add support for loongarch64 CPU. > > Here is a simple patch to dpkg for the loongarch64. > > Please download from attachment. > > > > - Have an official GNU triplet in the GNU config project. > > https://git.savannah.gnu.org/cgit/config.git/commit/?id=c8ddc8472f8efcadafc1ef53ca1d863415fddd5f > > > > - GNU binutils, gcc, and the respective libc project have merged by > > upstream. > > Binutils: > > https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob_plain;f=binutils/NEWS;hb=refs/heads/binutils-2_39-branch > > Gcc: https://gcc.gnu.org/gcc-12/changes.html > > Glibc: https://sourceware.org/pipermail/libc-alpha/2022-August/141193.html > > > > > > - Please tell me if I've missed something. > > I think the part that was missing, which was asked on the list, and a > rather important part of this! :) Is the ABI this conforms to. > > I'm attaching a patch that updates the test suite so that it passes, > and adds what I think (but I don't know as I didn't check deeper) might > change the ABI for built objects, which ties into the ABI this > architecture is intended to conform to. > > I guess the main question is whether objects with these different > EF_LOONGARCH_* flags can be mixed when linking or they are ABI > incompatible, as the code in the patch now assume. > > Thanks, > Guillem 本邮件及其附件含有龙芯中科的商业秘密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制或散发）本邮件及其附件中的信息。如果您错收本邮件，请您立即电话或邮件通知发件人并删除本邮件。 This email and its attachments contain confidential information from Loongson Technology , which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this email in error, please notify the sender by phone or email immediately and delete it. From bd0462298d5cf833ab47b0124ca470d0e156d902 Mon Sep 17 00:00:00 2001 From: Guillem Jover Date: Fri, 11 Nov 2022 12:43:38 +0100 Subject: [PATCH] arch: Add support for loong64 CPU MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit This is based on the LoongArch 64-bit little-endian hard-float ISA. Closes: #1023486 Based-on-patch-by: å¼ ä¸¹ä¸¹ --- data/cputable | 1 + scripts/Dpkg/Shlibs/Objdump.pm | 9 + scripts/t/Dpkg_Arch.t | 4 ++-- 3 files changed, 12 insertions(+), 2 deletions(-) diff --git a/data/cputable b/data/cputable index 172cea3f5..7b1ee2c58 100644 --- a/data/cputable +++ b/data/cputable @@ -26,6 +26,7 @@ arm arm arm.* 32 little arm64 aarch64 aarch64 64 little avr32 avr32 avr32 32 big hppa hppa hppa.* 32 big +loong64 loongarch64 loon
Bug#1023486: Please add loong64 support to dpkg
Hi!
On Sat, 2022-11-05 at 18:08:03 +0800, 张丹丹 wrote:
> Package: dpkg
> Version: 1.21.10
> Severity: wishlist
> Tags: patch
> User: debian-de...@lists.debian.org
> Usertags: loongarch64
> According to the result of disscussion from
> debian-d...@lists.debian.org(https://lists.debian.org/debian-dpkg/2022/11/msg1.html),
> guil...@debian.org, hel...@subdivi.de, *@loongson.cn and so on.
> Dpkg architecture of loong64 just determine the name of the software packages.
> Should add loong64 architecture to dpkg package?
>
> - Add support for loongarch64 CPU.
> Here is a simple patch to dpkg for the loongarch64.
> Please download from attachment.
>
> - Have an official GNU triplet in the GNU config project.
> https://git.savannah.gnu.org/cgit/config.git/commit/?id=c8ddc8472f8efcadafc1ef53ca1d863415fddd5f
>
> - GNU binutils, gcc, and the respective libc project have merged by upstream.
> Binutils:
> https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob_plain;f=binutils/NEWS;hb=refs/heads/binutils-2_39-branch
> Gcc: https://gcc.gnu.org/gcc-12/changes.html
> Glibc: https://sourceware.org/pipermail/libc-alpha/2022-August/141193.html
>
>
> - Please tell me if I've missed something.
I think the part that was missing, which was asked on the list, and a
rather important part of this! :) Is the ABI this conforms to.
I'm attaching a patch that updates the test suite so that it passes,
and adds what I think (but I don't know as I didn't check deeper) might
change the ABI for built objects, which ties into the ABI this
architecture is intended to conform to.
I guess the main question is whether objects with these different
EF_LOONGARCH_* flags can be mixed when linking or they are ABI
incompatible, as the code in the patch now assume.
Thanks,
Guillem
From bd0462298d5cf833ab47b0124ca470d0e156d902 Mon Sep 17 00:00:00 2001
From: Guillem Jover
Date: Fri, 11 Nov 2022 12:43:38 +0100
Subject: [PATCH] arch: Add support for loong64 CPU
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
This is based on the LoongArch 64-bit little-endian hard-float ISA.
Closes: #1023486
Based-on-patch-by: 张丹丹
---
data/cputable | 1 +
scripts/Dpkg/Shlibs/Objdump.pm | 9 +
scripts/t/Dpkg_Arch.t | 4 ++--
3 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/data/cputable b/data/cputable
index 172cea3f5..7b1ee2c58 100644
--- a/data/cputable
+++ b/data/cputable
@@ -26,6 +26,7 @@ arm arm arm.* 32 little
arm64 aarch64 aarch64 64 little
avr32 avr32 avr32 32 big
hppa hppa hppa.* 32 big
+loong64 loongarch64 loongarch64 64 little
i386 i686 (i[34567]86|pentium) 32 little
ia64 ia64 ia64 64 little
m32r m32r m32r 32 big
diff --git a/scripts/Dpkg/Shlibs/Objdump.pm b/scripts/Dpkg/Shlibs/Objdump.pm
index baeb8bb5c..9deedb4b4 100644
--- a/scripts/Dpkg/Shlibs/Objdump.pm
+++ b/scripts/Dpkg/Shlibs/Objdump.pm
@@ -101,6 +101,7 @@ use constant {
ELF_MACH_XTENSA => 94,
ELF_MACH_MICROBLAZE => 189,
ELF_MACH_ARCV2 => 195,
+ELF_MACH_LOONGARCH => 258,
ELF_MACH_AVR_OLD=> 0x1057,
ELF_MACH_OR1K_OLD => 0x8472,
ELF_MACH_ALPHA => 0x9026,
@@ -125,6 +126,13 @@ use constant {
ELF_FLAG_IA64_ABI64 => 0x0010,
+ELF_FLAG_LOONGARCH_SOFT_FLOAT => 0x0001,
+ELF_FLAG_LOONGARCH_SINGLE_FLOAT => 0x0002,
+ELF_FLAG_LOONGARCH_DOUBLE_FLOAT => 0x0003,
+ELF_FLAG_LOONGARCH_ABI_MASK => 0x0007,
+ELF_FLAG_LOONGARCH_OBJABI_V1=> 0x0040,
+ELF_FLAG_LOONGARCH_OBJABI_MASK => 0x00c0,
+
ELF_FLAG_MIPS_ABI2 => 0x0020,
ELF_FLAG_MIPS_32BIT => 0x0100,
ELF_FLAG_MIPS_FP64 => 0x0200,
@@ -158,6 +166,7 @@ my %elf_mach_map = (
# behavior, and we do not drop dependencies.
my %elf_flags_mask = (
ELF_MACH_IA64() => ELF_FLAG_IA64_ABI64,
+ELF_MACH_LOONGARCH() => ELF_FLAG_LOONGARCH_ABI_MASK | ELF_FLAG_LOONGARCH_OBJABI_MASK,
ELF_MACH_MIPS() => ELF_FLAG_MIPS_ABI_MASK | ELF_FLAG_MIPS_ABI2,
ELF_MACH_PPC64()=> ELF_FLAG_PPC64_ABI64,
);
diff --git a/scripts/t/Dpkg_Arch.t b/scripts/t/Dpkg_Arch.t
index 012f67c63..59855dfa4 100644
--- a/scripts/t/Dpkg_Arch.t
+++ b/scripts/t/Dpkg_Arch.t
@@ -16,7 +16,7 @@
use strict;
use warnings;
-use Test::More tests => 18407;
+use Test::More tests => 18900;
use_ok('Dpkg::Arch', qw(debarch_to_debtuple debarch_to_multiarch
debarch_eq debarch_is debarch_is_wildcard
@@ -28,7 +28,7 @@ use_ok('Dpkg::Arch', qw(debarch_to_debtuple debarch_to_multiarch
get_host_gnu_type
get_valid_arches));
-my $KNOWN_ARCHES_TOTAL = 554;
+my $KNOWN_ARCHES_TOTAL = 569;
my @valid_arches = get_valid_arches();
sub get_valid_wildcards
--
2.38.1
Bug#1023486: Please add loong64 support to dpkg
On Sat, Nov 05, 2022 at 06:08:03PM +0800, 张丹丹 wrote: Package: dpkg Version: 1.21.10 Severity: wishlist Tags: patch User: debian-de...@lists.debian.org Usertags: loongarch64 Do we want to insist on "loongarch64" while the Debian arch name is "loong64" instead? As people are going to refer to this port as something like "Debian loong64" in the coming days, I guess bug reports would come in with "loong64" tags and I'm not sure an additional "loongarch64" tag would help.
Bug#1023486: Please add loong64 support to dpkg
On Sat, Nov 05, 2022 at 06:08:03PM +0800, 张丹丹 wrote: > - Add support for loongarch64 CPU. Thank you for filing this much better bug. It is now properly formatted, has good metadata and a useful usertag. Please be consistent in continuing to use this usertag for further related bugs on any Debian package. Reviewed-by: Helmut Grohne Please do merge it with the other two bugs you created earlier though. Please be patient about this. However simple this patch may look, it usually takes significant time to make it appear in dpkg. Guillem, please try merging it before the bookworm release. I think this can go in after the toolchain freeze still. Helmut
Bug#1023486: Please add loong64 support to dpkg
Package: dpkg Version: 1.21.10 Severity: wishlist Tags: patch User: debian-de...@lists.debian.org Usertags: loongarch64 According to the result of disscussion from debian-d...@lists.debian.org(https://lists.debian.org/debian-dpkg/2022/11/msg1.html), guil...@debian.org, hel...@subdivi.de, *@loongson.cn and so on. Dpkg architecture of loong64 just determine the name of the software packages. Should add loong64 architecture to dpkg package? - Add support for loongarch64 CPU. Here is a simple patch to dpkg for the loongarch64. Please download from attachment. - Have an official GNU triplet in the GNU config project. https://git.savannah.gnu.org/cgit/config.git/commit/?id=c8ddc8472f8efcadafc1ef53ca1d863415fddd5f - GNU binutils, gcc, and the respective libc project have merged by upstream. Binutils: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob_plain;f=binutils/NEWS;hb=refs/heads/binutils-2_39-branch Gcc: https://gcc.gnu.org/gcc-12/changes.html Glibc: https://sourceware.org/pipermail/libc-alpha/2022-August/141193.html - Please tell me if I've missed something. Dandan Zhang dpkg-1.21.10-loongarch64-support.patch Description: Binary data
