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.5 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 19220 invoked from network); 26 May 2022 03:07:59 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 26 May 2022 03:07:59 -0000 Received: (qmail 13431 invoked by uid 550); 26 May 2022 03:07:56 -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 13396 invoked from network); 26 May 2022 03:07:55 -0000 To: musl@lists.openwall.com References: <20220516142704.GR7074@brightrain.aerifal.cx> <5fe467cd-4b68-2841-8aae-c485e7570267@loongson.cn> <20220521082246.GA20105@voyager> <777071eb-d8c3-eb04-fef4-4f54d6016e8f@loongson.cn> <20220524123201.GU7074@brightrain.aerifal.cx> <4978b83d-871a-e8ca-ab4b-6dec73f34075@loongson.cn> <20220525123211.GV7074@brightrain.aerifal.cx> From: =?UTF-8?B?546L5rSq5Lqu?= Message-ID: <07a1976c-2872-0e69-5602-7f5f055ef5ff@loongson.cn> Date: Thu, 26 May 2022 11:07:42 +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: <20220525123211.GV7074@brightrain.aerifal.cx> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-CM-TRANSID:AQAAf9BxWeT+7o5ihgwCAA--.5335S3 X-Coremail-Antispam: 1UD129KBjvJXoWxCry5uF4UuFWktw4furyDJrb_yoW5CFWUpF yvka4vyFWUGFnYkw1qya40qry5Zw48G34UKr93Ga47AryDXFs2gF4UWF4j9FyDXw48WF1j vryUKFy3uFWrtrJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUvSb7Iv0xC_Kw4lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Xr0_Ar1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Cr0_Gr1UM28EF7xvwVC2z280aVAFwI0_Gr1j6F4UJwA2z4x0Y4 vEx4A2jsIEc7CjxVAFwI0_Cr1j6rxdM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVAC Y4xI64kE6c02F40Ex7xfMcIj6xIIjxv20xvE14v26r1j6r18McIj6I8E87Iv67AKxVWUJV W8JwAm72CE4IkC6x0Yz7v_Jr0_Gr1lF7xvr2IY64vIr41lc7I2V7IY0VAS07AlzVAYIcxG 8wCY02Avz4vE14v_Gr4l42xK82IYc2Ij64vIr41l4I8I3I0E4IkC6x0Yz7v_Jr0_Gr1lx2 IqxVAqx4xG67AKxVWUJVWUGwC20s026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v2 6r1j6r15MIIYrxkI7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2 IY6xkF7I0E14v26r1j6r4UMIIF0xvE42xK8VAvwI8IcIk0rVWrZr1j6s0DMIIF0xvEx4A2 jsIE14v26r1j6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Jr0_GrUvcSsGvfC2KfnxnUUI43 ZEXa7IU5NJ57UUUUU== X-CM-SenderInfo: pzdqwxxrqjzxhdqjqz5rrqw2lrqou0/ Subject: Re: [musl] add loongarch64 port v3 在 2022/5/25 下午8:32, Rich Felker 写道: > On Wed, May 25, 2022 at 06:08:23PM +0800, 王洪亮 wrote: >> 在 2022/5/24 下午8:32, Rich Felker 写道: >>> What we've been trying to say is that there are several cases, none of >>> which seem to need it: >>> >>> 1. You create an object with declared type struct sigcontext. In this >>> case, the flexible array member at the end is not present at all >>> (because that's how C works) which means there's no extended >>> context which needs additional alignment and probably also means >>> this is not a usable way of creating sigcontext structs. >>> >>> 2. You malloc storage for the object with space for the flexible array >>> member. In this case the allocation has alignment max_align_t and >>> everything is fine. I don't understand what is alignment max_align_t? I found the max_align_t definition in musl,is this it? TYPEDEF struct { long long __ll; long double __ld; } max_align_t; I understand if FAM is not specified alignment,FAM is aligned according to its type size,why is max_align_t? >>> >>> 3. You get the object from the kernel pushing it onto the stack in a >>> signal frame. This is probably actually the only case the type is >>> usable in, and of course it has whatever alignment the kernel gave >>> it. >> Specify the __attribute__((__aligned__(16))) in musl,is used to be >> consistent with kernel.if I removed the __attribute__((__aligned__(16))), >> there is a libc-test fail in pthread_cancel.exe.the reason is that the >> offset of uc->uc_mcontext from the start of uc obtained in cancel_handler >> is inconsistent with kernel pushing it onto the stack in a signal frame. >> so I understand the __attribute__((__aligned__(16))) is necessary in musl. >> >> src/thread/pthread_cancel.c >> >> static void cancel_handler(int sig, siginfo_t *si, void *ctx) >> { >>         pthread_t self = __pthread_self(); >>         ucontext_t *uc = ctx; >>         uintptr_t pc = uc->uc_mcontext.MC_PC; >>          ... >> } >> >> musl/arch/loongarch64/bits/signal.h: >> >> typedef unsigned long greg_t, gregset_t[32]; >> typedef struct sigcontext { >>         unsigned long pc; >>         gregset_t gregs; >>         unsigned int flags; >>         unsigned long extcontext[]; >> }mcontext_t; >> >> linux/arch/loongarch/include/uapi/asm/sigcontext.h: >> >> struct sigcontext { >>         __u64   sc_pc; >>         __u64   sc_regs[32]; >>         __u32   sc_flags; >>         __u64   sc_extcontext[0] __attribute__((__aligned__(16))); >> }; > This is because ucontext_t is defined without explicit padding before > uc_mcontext. Add "long __uc_pad;" or similar before it so that the > offset is explicitly what it's supposed to be rather than a > consequence ot overalignment. Add "long __uc_pad;" before uc_mcontext can resolve offset error, why it is better than sc_extcontext[] __attribute__((__aligned__(16)))? isn't it more direct to be consistent with kernel? > Rich