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=-4.6 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 10542 invoked from network); 20 Nov 2023 06:12:25 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 20 Nov 2023 06:12:25 -0000 Received: (qmail 25959 invoked by uid 550); 20 Nov 2023 06:12:20 -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 25927 invoked from network); 20 Nov 2023 06:12:19 -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> From: Hongliang Wang Message-ID: <2a8d55b0-add3-4d90-1119-4e5c28b6626e@loongson.cn> Date: Mon, 20 Nov 2023 14:11:56 +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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-CM-TRANSID:AQAAf8AxH92t+FplBkxHAA--.27676S3 X-CM-SenderInfo: pzdqwxxrqjzxhdqjqz5rrqw2lrqou0/ X-Coremail-Antispam: 1Uk129KBj93XoWxtrWxtF47WrWUGw1ktr4fWFX_yoW7Zw4fpr ZrCF4YkFWkJrnrG3Z7tw1rXrsrtwsrGry2qF15K34xZr90vF1Ikr18KrsruF48Xw4rCw10 vrW8ta47XF1DAagCm3ZEXasCq-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] add loongarch64 port v9. 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 >> >