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=-1.6 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL, T_SCC_BODY_TEXT_LINE,URIBL_BLACK autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 32564 invoked from network); 8 Dec 2023 08:24:14 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 8 Dec 2023 08:24:14 -0000 Received: (qmail 12167 invoked by uid 550); 8 Dec 2023 08:24:02 -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 12129 invoked from network); 8 Dec 2023 08:24:01 -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> Message-ID: <03605726-4d36-6b2c-0f79-ec7bce08451a@loongson.cn> Date: Fri, 8 Dec 2023 16:23:45 +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: <2a8d55b0-add3-4d90-1119-4e5c28b6626e@loongson.cn> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-CM-TRANSID:AQAAf8CxP92S0nJlf0JYAA--.480S3 X-CM-SenderInfo: pzdqwxxrqjzxhdqjqz5rrqw2lrqou0/ X-Coremail-Antispam: 1Uk129KBj93XoW3XryUWryxCF1rXw1xAFy3ZFc_yoWxXF1rpF W7CF1YkF48JrnrG3Wxtw1rXr45tw47G342qr15KryxZr90vF1xKr18tr4DuF18Xws5Cw10 vrW8ta47XF1qyagCm3ZEXasCq-sJn29KB7ZKAUJUUUUU529EdanIXcx71UUUUU7KY7ZEXa sCq-sGcSsGvfJ3Ic02F40EFcxC0VAKzVAqx4xG6I80ebIjqfuFe4nvWSU5nxnvy29KBjDU 0xBIdaVrnRJUUUv2b4IE77IF4wAFF20E14v26r1j6r4UM7CY07I20VC2zVCF04k26cxKx2 IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48v e4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_JFI_Gr1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI 0_Jr0_Gr1l84ACjcxK6I8E87Iv67AKxVW8Jr0_Cr1UM28EF7xvwVC2z280aVCY1x0267AK xVW8Jr0_Cr1UM2AIxVAIcxkEcVAq07x20xvEncxIr21l57IF6xkI12xvs2x26I8E6xACxx 1l5I8CrVACY4xI64kE6c02F40Ex7xfMcIj6xIIjxv20xvE14v26r1j6r18McIj6I8E87Iv 67AKxVWUJVW8JwAm72CE4IkC6x0Yz7v_Jr0_Gr1lF7xvr2IY64vIr41lc7I2V7IY0VAS07 AlzVAYIcxG8wCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkEbVWUJVW8JwC20s026c02 F40E14v26r1j6r18MI8I3I0E7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_Jr0_Jr ylIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI42IY6xIIjxv20xvEc7Cj xVAFwI0_Jr0_Gr1lIxAIcVCF04k26cxKx2IYs7xG6r1j6r1xMIIF0xvEx4A2jsIE14v26r 1j6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Jr0_GrUvcSsGvfC2KfnxnUUI43ZEXa7IU1CP fJUUUUU== Subject: [musl] Re:[musl] add loongarch64 port v8. 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 >>> >>