From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-5.3 required=5.0 tests=MAILING_LIST_MULTI, NICE_REPLY_A,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 2617 invoked from network); 18 Dec 2023 18:12:25 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 18 Dec 2023 18:12:25 -0000 Received: (qmail 3799 invoked by uid 550); 18 Dec 2023 07:44:32 -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 3767 invoked from network); 18 Dec 2023 07:44:31 -0000 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> From: Jingyun Hua Message-ID: Date: Mon, 18 Dec 2023 15:44:42 +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:AQAAf8Cx3+Fs+H9lZdMJAA--.46877S3 X-CM-SenderInfo: xkxdyxpqj130o6or00hjvr0hdfq/1tbiAQAJDWV-rC0FwwABsZ X-Coremail-Antispam: 1Uk129KBj93XoWxKF4rKFyDKrWfGF4kuw48GrX_yoWxuFyxpr W7CF1YkF4UJr17Gw1xtw1rXr45tw17G34UXr15Kryxurn0vF17Kr18tr4DuF1kXw4rCw10 vry8tw17XF1UAacCm3ZEXasCq-sJn29KB7ZKAUJUUUUU529EdanIXcx71UUUUU7KY7ZEXa sCq-sGcSsGvfJ3Ic02F40EFcxC0VAKzVAqx4xG6I80ebIjqfuFe4nvWSU5nxnvy29KBjDU 0xBIdaVrnRJUUUv2b4IE77IF4wAFF20E14v26r1j6r4UM7CY07I20VC2zVCF04k26cxKx2 IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48v e4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Jr0_JF4l84ACjcxK6xIIjxv20xvEc7CjxVAFwI 0_Jr0_Gr1l84ACjcxK6I8E87Iv67AKxVW8Jr0_Cr1UM28EF7xvwVC2z280aVCY1x0267AK xVW8Jr0_Cr1UM2AIxVAIcxkEcVAq07x20xvEncxIr21l57IF6xkI12xvs2x26I8E6xACxx 1l5I8CrVACY4xI64kE6c02F40Ex7xfMcIj6xIIjxv20xvE14v26r1j6r18McIj6I8E87Iv 67AKxVWUJVW8JwAm72CE4IkC6x0Yz7v_Jr0_Gr1lF7xvr2IY64vIr41lc7I2V7IY0VAS07 AlzVAYIcxG8wCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkEbVWUJVW8JwC20s026c02 F40E14v26r1j6r18MI8I3I0E7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_Jr0_Jr ylIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI42IY6xIIjxv20xvEc7Cj xVAFwI0_Jr0_Gr1lIxAIcVCF04k26cxKx2IYs7xG6r1j6r1xMIIF0xvEx4A2jsIE14v26r 1j6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Jr0_GrUvcSsGvfC2KfnxnUUI43ZEXa7IU1CP fJUUUUU== Subject: Re: [musl] Re:[musl] add loongarch64 port v8. Hi, I had to ask again about the progress of the LoongArch64 patch, as I have been working on adding LoongArch64 support to Alpine Linux recently, see： https://gitlab.alpinelinux.org/alpine/tsc/-/issues/72 Currently, we are waiting for the LoongArch64 patch to be merged to musl, and then continue the upstream porting of Alpine Linux. Thanks! Regards, Jingyun Hua On 12/8/23 4:23 PM, Hongliang Wang wrote: > 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 >>>> >>> -- Jingyun Hua