From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-5.1 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,NICE_REPLY_A,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL,T_SCC_BODY_TEXT_LINE,URIBL_SBL_A autolearn=ham autolearn_force=no version=3.4.4 Received: from second.openwall.net (second.openwall.net [193.110.157.125]) by inbox.vuxu.org (Postfix) with SMTP id 6D4CF2483B for ; Mon, 29 Jan 2024 02:26:47 +0100 (CET) Received: (qmail 9293 invoked by uid 550); 29 Jan 2024 01:24:24 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 9250 invoked from network); 29 Jan 2024 01:24:24 -0000 From: Hongliang Wang To: musl@lists.openwall.com References: <99d954ca-faee-2cac-97af-7fc2ecdb9a89@loongson.cn> <65857ef7-0ef8-d3c8-d6d8-ea577b99e793@loongson.cn> <20230920131619.GA1427497@port70.net> <9dd23cf9-9795-0704-3a83-085ad9e6054a@loongson.cn> <3838b2d6-8330-33b5-fd87-8af3404a29dc@loongson.cn> <1f1d2528-ae86-46ea-64b1-c5b3ddb1709b@loongson.cn> <7b59ddc0-67ab-4ffa-e083-3e5086dd5de3@loongson.cn> <7aad7a07-9762-3d62-a8c2-4cdf860a7dcb@loongson.cn> <20231116161056.GZ4163@brightrain.aerifal.cx> <65fe2213-9846-6624-f852-f16b401ceba2@loongson.cn> <20231117172552.GA4163@brightrain.aerifal.cx> <2a8d55b0-add3-4d90-1119-4e5c28b6626e@loongson.cn> <03605726-4d36-6b2c-0f79-ec7bce08451a@loongson.cn> Message-ID: Date: Mon, 29 Jan 2024 09:26:21 +0800 User-Agent: Mozilla/5.0 (X11; Linux loongarch64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <03605726-4d36-6b2c-0f79-ec7bce08451a@loongson.cn> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-CM-TRANSID:AQAAf8CxPs+7_rZlbgokAA--.13464S3 X-CM-SenderInfo: pzdqwxxrqjzxhdqjqz5rrqw2lrqou0/ X-Coremail-Antispam: 1Uk129KBj93XoW3GFy5Ww1xXFW7tw17Xw48Zrc_yoWxuw1fpF W7CF1YkF4UJr17Gw1xtw1rXr45tw47G34jqr15KryxCr90vF17Kr18tr4DuF1kXw4rGw10 vry8t3W7XF1DAagCm3ZEXasCq-sJn29KB7ZKAUJUUUUU529EdanIXcx71UUUUU7KY7ZEXa sCq-sGcSsGvfJ36c02F40EFcxC0VAKzVAqx4xG6I80ewCIccxYrVCFb4Uv73VFW2AGmfu7 bjvjm3AaLaJ3UjIYCTnIWjp_UUUYT7kC6x804xWl14x267AKxVWUJVW8JwAFc2x0x2IEx4 CE42xK8VAvwI8IcIk0rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2ocxC64kIII0Yj41l84x0 c7CEw4AK67xGY2AK021l84ACjcxK6xIIjxv20xvE14v26r1j6r1xM28EF7xvwVC0I7IYx2 IY6xkF7I0E14v26r1j6r4UM28EF7xvwVC2z280aVAFwI0_Gr0_Cr1l84ACjcxK6I8E87Iv 6xkF7I0E14v26r4j6r4UJwAS0I0E0xvYzxvE52x082IY62kv0487Mc804VCY07AIYIkI8V C2zVCFFI0UMc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0I7IYx2IY67AKxVWUJVWUGwAv 7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4UM4x0Y48IcVAKI48JMxk0xI A0c2IEe2xFo4CEbIxvr21l42xK82IYc2Ij64vIr41l4I8I3I0E4IkC6x0Yz7v_Jr0_Gr1l x2IqxVAqx4xG67AKxVWUJVWUGwC20s026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14 v26r1j6r15MIIYY7kG6xAYrwCIc40Y0x0EwIxGrwCI42IY6xIIjxv20xvE14v26r1j6r1x MIIF0xvE2Ix0cI8IcVCY1x0267AKxVWUJVW8JwCI42IY6xAIw20EY4v20xvaj40_Jr0_JF 4lIxAIcVC2z280aVAFwI0_Jr0_Gr1lIxAIcVC2z280aVCY1x0267AKxVWUJVW8JbIYCTnI WIevJa73UjIFyTuYvjxUyTUqUUUUU Subject: Re: [musl] add loongarch64 port v8. Hi, Rich I'm sorry to ask again about the progress of the LoongArch64 patch. The Alpine support LoongArch porting has stopped and waiting for musl for a long time. see alpine TSC: https://gitlab.alpinelinux.org/alpine/tsc/-/issues/72 So we would like to ask about the approximate time and plan for patch merge? Is it possible to be merged in the near future? Thank you very much. Regards, Hongliang Wang 在 2023/12/8 下午4:23, Hongliang Wang 写道: > Hi, Rich > > I'm sorry to trouble you again. we know that you are taking the > time to review the code for Loongarch port. because there are > multiple applications rely on musl, and recently many people ask > us about the progress of musl support LoongArch, they are waiting > for it for next work. > > So we would like to make bold to ask you about the approximate time > and plan for merge Loongarch port? > > Thank you very much. > > Regards, > Hongliang Wang > > 在 2023/11/20 下午2:11, Hongliang Wang 写道: >> Hi, Rich >> >> The patch for modify musl dynamic linker has been merged to gcc, >> and also backported to gcc-12 and gcc-13. >> >> The 0001-add-loongarch64-port-v8.patch is still as the latest patch. >> >> Thank you very much. >> >> Hongliang Wang. >> >> >> 在 2023/11/18 下午12:19, Jingyun Hua 写道: >>> Hi,Rich >>> >>> I'm sorry for wasting everyone's time with my suggestion about the wrong >>> dynamic connector name, and thank you for always taking the time to >>> review the code for the musl LoongArch port. >>> >>> I carefully looked at the musl code and documentation again, LoongArch >>> should follow the musl style and use naming consistent with other archs >>> naming. >>> >>> and I saw that gcc also submitted a modification for this: >>> https://gcc.gnu.org/pipermail/gcc-patches/2023-November/637113.html >>> >>> This may be a good solution. After waiting for the modifications of gcc >>> to be merged, we can add "-sp" to __loongarch_single_float based on the >>> musl v8 patch, and at the same time, gcc will backport the >>> modifications to gcc-12 and gcc-13. >>> >>> Thank you very much. >>> >>> Regards, >>> Jingyun Hua >>> >>> On 11/18/23 1:25 AM, Rich Felker wrote: >>>> On Fri, Nov 17, 2023 at 03:20:58PM +0800, Hongliang Wang wrote: >>>>> >>>>> >>>>> 在 2023/11/17 上午12:10, Rich Felker 写道: >>>>>> On Thu, Nov 16, 2023 at 10:54:44AM +0800, Hongliang Wang wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Thank you for your suggestion, I have modified the dynamic linker >>>>>>> name according to the basic ABI types are specified in the ABI >>>>>>> document of the LoongArch, and post >>>>>>> 0001-add-loongarch64-port-v9.patch, >>>>>>> as shown in the attachment. >>>>>>> >>>>>>> Based on 0001-add-loongarch64-port-v8.patch,the modifications for >>>>>>> 0001-add-loongarch64-port-v9.patch are as follows: >>>>>>> >>>>>>> --- >>>>>>>   arch/loongarch64/reloc.h | 10 ++++++---- >>>>>>>   configure                |  4 +++- >>>>>>>   2 files changed, 9 insertions(+), 5 deletions(-) >>>>>>> >>>>>>> diff --git a/arch/loongarch64/reloc.h b/arch/loongarch64/reloc.h >>>>>>> index a4482b48..6907de8e 100644 >>>>>>> --- a/arch/loongarch64/reloc.h >>>>>>> +++ b/arch/loongarch64/reloc.h >>>>>>> @@ -1,7 +1,9 @@ >>>>>>> -#ifdef __loongarch_soft_float >>>>>>> -#define FP_SUFFIX "-sf" >>>>>>> -#else >>>>>>> -#define FP_SUFFIX "" >>>>>>> +#if defined __loongarch_double_float >>>>>>> +#define FP_SUFFIX "-lp64d" >>>>>>> +#elif defined __loongarch_single_float >>>>>>> +#define FP_SUFFIX "-lp64f" >>>>>>> +#elif defined __loongarch_soft_float >>>>>>> +#define FP_SUFFIX "-lp64s" >>>>>>>   #endif >>>>>>> >>>>>>>   #define LDSO_ARCH "loongarch64"  FP_SUFFIX >>>>>>> diff --git a/configure b/configure >>>>>>> index 55d179f1..93b06287 100755 >>>>>>> --- a/configure >>>>>>> +++ b/configure >>>>>>> @@ -673,7 +673,9 @@ trycppif __AARCH64EB__ "$t" && >>>>>>> SUBARCH=${SUBARCH}_be >>>>>>>   fi >>>>>>> >>>>>>>   if test "$ARCH" = "loongarch64" ; then >>>>>>> -trycppif __loongarch_soft_float "$t" && SUBARCH=${SUBARCH}-sf >>>>>>> +trycppif __loongarch_double_float "$t" && SUBARCH=${SUBARCH}-lp64d >>>>>>> +trycppif __loongarch_single_float "$t" && SUBARCH=${SUBARCH}-lp64f >>>>>>> +trycppif __loongarch_soft_float "$t" && SUBARCH=${SUBARCH}-lp64s >>>>>>>   printf "checking whether compiler support FCSRs... " >>>>>>>   echo "__asm__(\"movfcsr2gr \$t0,\$fcsr0\");" > "$tmpc" >>>>>>>   if $CC -c -o /dev/null "$tmpc" >/dev/null 2>&1 ; then >>>>>>> -- >>>>>>> >>>>>>> Please review again, and point them out if any questions need to be >>>>>>> modified, thanks. >>>>>> >>>>>> Why are you changing the ABI name for the existing one to something >>>>>> different rather than just adding the missing ones, and doing it with >>>>>> a name that's less descriptive ("-sf" is widely recognized as a >>>>>> softfloat suffix, -lp64s not so much) and adding a redundant "lp64" >>>>>> part to each one that does not seem to be part of distinguishing the >>>>>> float ABI? >>>>>> >>>>>> Rich >>>>>> >>>>> We change the ABI name based on the LoongArch ELF ABI specification, >>>>> which can be seen: >>>>> https://loongson.github.io/LoongArch-Documentation/LoongArch-ELF-ABI-EN.html >>>>> >>>>> (Table 7. Base ABI Types.) >>>>> The specification defines lp64d, lp64s, lp64f: >>>>> lp64d indicates uses 64-bit FPRs, d indicates double float. >>>>> lp64s indicates uses 32-bit FPRs, s indicates single float. >>>>> lp64f indicates uses no FPRs,  f indicates soft float. >>>>> >>>>> The specification does not define sf, so I removed it. >>>>> The define in musl is also consistent with gcc. >>>> >>>> Please use naming consistent with what we do for other archs in musl >>>> for a proposal to be included in musl. This means: >>>> >>>> - Subarch should be empty for the default (I assume that means >>>>    hardware floating point with full double precision) ABI that you >>>>    expect most Linux-compatible systems to be using. >>>> >>>> - Don't include extraneous stuff like "lp64" that's universal to the >>>>    architecture in the subarch name. There isn't a need to align these >>>>    names with anything outside of musl. >>>> >>>> Please stick with what has already been approved, with changes >>>> well-motivated -- in this case, that means just proposing a name for >>>> the single-precision subarch. My preference would be to use "-sp" like >>>> we did for riscv64. >>>> >>>> The reason this has taken so long to get merged is that *every* time I >>>> set aside some time to apply it, there are new gratuitous changes, >>>> many of which seem to be motivated by style musl does not follow. I'd >>>> like to merge precisely what I reviewed last time, with the gratuitous >>>> changes I found reverted, plus the new subarch/ldso name for single >>>> precision. Does this sound good? >>>> >>>> Rich >>>> >>>