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=-3.4 required=5.0 tests=MAILING_LIST_MULTI, NICE_REPLY_A,RCVD_IN_DNSWL_MED,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 30391 invoked from network); 25 Jun 2023 03:43:47 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 25 Jun 2023 03:43:47 -0000 Received: (qmail 13323 invoked by uid 550); 25 Jun 2023 03:43:42 -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 12265 invoked from network); 25 Jun 2023 03:43:42 -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> Message-ID: <64955faf-c213-34bf-c7e2-691064da51f9@loongson.cn> Date: Sun, 25 Jun 2023 11:43:26 +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: <72a1a5d1-6f57-9a12-7775-84e1ff2c1df2@loongson.cn> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-CM-TRANSID:AQAAf8Ax98zet5dk3i8GAA--.9391S3 X-CM-SenderInfo: pzdqwxxrqjzxhdqjqz5rrqw2lrqou0/ X-Coremail-Antispam: 1Uk129KBj93XoWxur1xCFyftFW8CFWxZw13GFX_yoW5CFWkpF 1vka48CrW5JF1rJr1jvw15Zr9xKr18J3WUWry3Ja42qrZrtFn2gFy7XFn09rn8Jr48WF1U Zr1Utrnrur1fJFXCm3ZEXasCq-sJn29KB7ZKAUJUUUUU529EdanIXcx71UUUUU7KY7ZEXa sCq-sGcSsGvfJ3Ic02F40EFcxC0VAKzVAqx4xG6I80ebIjqfuFe4nvWSU5nxnvy29KBjDU 0xBIdaVrnRJUUUvFb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I20VC2zVCF04k26cxKx2 IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48v e4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Jr0_JF4l84ACjcxK6xIIjxv20xvEc7CjxVAFwI 0_Jr0_Gr1l84ACjcxK6I8E87Iv67AKxVWxJVW8Jr1l84ACjcxK6I8E87Iv6xkF7I0E14v2 6r4UJVWxJr1le2I262IYc4CY6c8Ij28IcVAaY2xG8wAqjxCEc2xF0cIa020Ex4CE44I27w Aqx4xG64xvF2IEw4CE5I8CrVC2j2WlYx0E2Ix0cI8IcVAFwI0_Jr0_Jr4lYx0Ex4A2jsIE 14v26r1j6r4UMcvjeVCFs4IE7xkEbVWUJVW8JwACjcxG0xvEwIxGrwCYjI0SjxkI62AI1c AE67vIY487MxAIw28IcxkI7VAKI48JMxC20s026xCaFVCjc4AY6r1j6r4UMI8I3I0E5I8C rVAFwI0_Jr0_Jr4lx2IqxVCjr7xvwVAFwI0_JrI_JrWlx4CE17CEb7AF67AKxVWUJVWUXw CIc40Y0x0EwIxGrwCI42IY6xIIjxv20xvE14v26r1j6r1xMIIF0xvE2Ix0cI8IcVCY1x02 67AKxVWUJVW8JwCI42IY6xAIw20EY4v20xvaj40_Jr0_JF4lIxAIcVC2z280aVAFwI0_Jr 0_Gr1lIxAIcVC2z280aVCY1x0267AKxVWUJVW8JbIYCTnIWIevJa73UjIFyTuYvjxUzsqW UUUUU Subject: Re: [musl] add loongarch64 port v7. 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.)