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,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 27794 invoked from network); 1 Jun 2023 12:44:36 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 1 Jun 2023 12:44:36 -0000 Received: (qmail 30604 invoked by uid 550); 1 Jun 2023 12: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 30565 invoked from network); 1 Jun 2023 12:44:31 -0000 From: wanghongliang To: musl@lists.openwall.com References: <20230418093844.GP3630668@port70.net> <0fd19586-376c-14ec-a50b-8c561f9f82f2@loongson.cn> Message-ID: <72a1a5d1-6f57-9a12-7775-84e1ff2c1df2@loongson.cn> Date: Thu, 1 Jun 2023 20:44:13 +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:AQAAf8Dx_7OdknhkIkKEAA--.18100S3 X-CM-SenderInfo: pzdqwxxrqjzxhdqjqz5rrqw2lrqou0/ X-Coremail-Antispam: 1Uk129KBjvJXoWxCw1ktFyDJF47tF1furW3Wrg_yoW5AryDpF 1vkay8CrW5JFn5Aryjvw1Yvr9xKr18J3ZrWry3Ja4IqrZrtFn2gFy7XFn09Fn8Jr48WF1U Zr1Utrnrur4fJFJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUj1kv1TuYvTs0mT0YCTnIWj qI5I8CrVACY4xI64kE6c02F40Ex7xfYxn0WfASr-VFAUDa7-sFnT9fnUUIcSsGvfJTRUUU bxAYFVCjjxCrM7AC8VAFwI0_Jr0_Gr1l1xkIjI8I6I8E6xAIw20EY4v20xvaj40_Wr0E3s 1l1IIY67AEw4v_Jr0_Jr4l8cAvFVAK0II2c7xJM28CjxkF64kEwVA0rcxSw2x7M28EF7xv wVC0I7IYx2IY67AKxVWUCVW8JwA2z4x0Y4vE2Ix0cI8IcVCY1x0267AKxVWUJVW8JwA2z4 x0Y4vEx4A2jsIE14v26r4UJVWxJr1l84ACjcxK6I8E87Iv6xkF7I0E14v26F4UJVW0owAS 0I0E0xvYzxvE52x082IY62kv0487Mc804VCY07AIYIkI8VC2zVCFFI0UMc02F40EFcxC0V AKzVAqx4xG6I80ewAv7VC0I7IYx2IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr1l Ox8S6xCaFVCjc4AY6r1j6r4UM4x0Y48IcVAKI48JMxk0xIA0c2IEe2xFo4CEbIxvr21l42 xK82IYc2Ij64vIr41l4I8I3I0E4IkC6x0Yz7v_Jr0_Gr1lx2IqxVAqx4xG67AKxVWUJVWU GwC20s026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r1j6r15MIIYrxkI7VAKI4 8JMIIF0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6xkF7I0E14v26r1j6r4U MIIF0xvE42xK8VAvwI8IcIk0rVWUJVWUCwCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I 8E87Iv6xkF7I0E14v26r1j6r4UYxBIdaVFxhVjvjDU0xZFpf9x07UE-erUUUUU= Subject: Re: [musl] add loongarch64 port v7. 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.)