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.8 required=5.0 tests=MAILING_LIST_MULTI, NICE_REPLY_A,RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 25257 invoked from network); 19 Jul 2023 06:55:52 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 19 Jul 2023 06:55:52 -0000 Received: (qmail 1370 invoked by uid 550); 19 Jul 2023 06:55:48 -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 1329 invoked from network); 19 Jul 2023 06:55:47 -0000 From: Hongliang Wang To: musl@lists.openwall.com References: <20230418093844.GP3630668@port70.net> <0fd19586-376c-14ec-a50b-8c561f9f82f2@loongson.cn> <72a1a5d1-6f57-9a12-7775-84e1ff2c1df2@loongson.cn> <64955faf-c213-34bf-c7e2-691064da51f9@loongson.cn> Message-ID: <968652d9-3780-0843-908e-f21bc93b6ee1@loongson.cn> Date: Wed, 19 Jul 2023 14:55:31 +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: <64955faf-c213-34bf-c7e2-691064da51f9@loongson.cn> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-CM-TRANSID:AQAAf8AxX8_jiLdkZG00AA--.12682S3 X-CM-SenderInfo: pzdqwxxrqjzxhdqjqz5rrqw2lrqou0/ X-Coremail-Antispam: 1Uk129KBj93XoWxWryDWw48Ar15uryxXryrAFc_yoWrJw4rpF 1vka48CrW5JF18Jr1jvw15Zr9xKry8J3WUWry3Ja47XrWDtFn2gryUXF1q9Fn8Jr48WF1U Zr1Utr17uF1UJrXCm3ZEXasCq-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 v7. Hi Rich, I asked about the current situation of 0001-add-loongarch64-port-v7.patch in mailing list some times, but I haven't received any response from you. We very hope that LoongArch can be supported in musl as soon as possible and used by more people. So we urgently want to know the current review progress of this patch and what else do we need to do? Thank you for your attention, We're looking forward to your early reply. Best wishes, Hongliang Wang 在 2023/6/25 上午11:43, Hongliang Wang 写道: > > Friendly ping. > > 在 2023/6/1 下午8:44, wanghongliang 写道: >> Hi,Rich >> >> Is there anything else that needs to be modified in >> 0001-add-loongarch64-port-v7.patch? >> >> Looking forward to your reply. >> >> >> 在 2023/5/10 上午11:36, 王洪亮 写道: >>> Hi, Rich >>> >>> Is there anything else that needs to be modified in >>> 0001-add-loongarch64-port-v7.patch? >>> >>> >>> 在 2023/4/18 下午7:32, 王洪亮 写道: >>>> >>>> 在 2023/4/18 下午5:38, Szabolcs Nagy 写道: >>>>> * 王洪亮 [2023-04-18 09:28:49 +0800]: >>>>>> +++ b/arch/loongarch64/bits/signal.h >>>>>> @@ -6,14 +6,27 @@ >>>>>>   #define SIGSTKSZ    16384 >>>>>>   #endif >>>>>> >>>>>> +#if defined(_GNU_SOURCE) || defined(_BSD_SOURCE) >>>>>>   typedef unsigned long greg_t, gregset_t[32]; >>>>>> >>>>>> -typedef struct sigcontext { >>>>>> +struct sigcontext { >>>>>>       unsigned long sc_pc; >>>>>> -    gregset_t     sc_regs; >>>>>> -    unsigned int  sc_flags; >>>>>> -    unsigned long sc_extcontext[]; >>>>>> +    unsigned long sc_regs[32]; >>>>>> +    unsigned int sc_flags; >>>>>> +    unsigned long sc_extcontext[] __attribute__((__aligned__(16))); >>>>>> +}; >>>>> this looks good. (i don't know if this is really >>>>> needed in signal.h, but other targets have it too) >>>>> >>>>>> + >>>>>> +typedef struct { >>>>>> +    unsigned long __pc; >>>>>> +    unsigned long __gregs[32]; >>>>>> +    unsigned int __flags; >>>>>> +    unsigned long __extcontext[] __attribute__((__aligned__(16))); >>>>>>   } mcontext_t; >>>>> i would use the same struct tag as glibc so >>>>> >>>>> typedef struct mcontext_t { ... >>>>> >>>>> (we don't need c++ abi compat with glibc, but >>>>> it's nicer to be consistent) >>>>> >>>>>> +#else >>>>>> +typedef struct { >>>>>> +    unsigned long __space[34]; >>>>>> +} mcontext_t; >>>>> i would add the aligned attribute here. >>>>> >>>>> (it's more important to match the kernel layout than to >>>>> avoid c extensions in standard mode: loongarch c compilers >>>>> will all support the aligned attribute in system headers) >>>> I understand there is no need for me to submit modifications, >>>> you help me modify it directly,right? >>>>>> +#endif >>>>>> >>>>>>   struct sigaltstack { >>>>>>       void   *ss_sp; >>>>>> @@ -23,11 +36,10 @@ struct sigaltstack { >>>>>> >>>>>>   typedef struct __ucontext >>>>>>   { >>>>>> -    unsigned long      uc_flags; >>>>>> +    unsigned long      __uc_flags; >>>>>>       struct __ucontext  *uc_link; >>>>>>       stack_t            uc_stack; >>>>>>       sigset_t           uc_sigmask; >>>>>> -    long               __uc_pad; >>>>>>       mcontext_t         uc_mcontext; >>>>>>   } ucontext_t; >>>>> looks good. >>>>> >>>>> (the only issue is if some code uses uc_flags in an >>>>> arch independent way. i don't know if there is any >>>>> use for it on linux. but we can fix that later on >>>>> both glibc and musl side if it comes up.)