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.3 required=5.0 tests=MAILING_LIST_MULTI, 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 20785 invoked from network); 25 May 2022 12:32:31 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 25 May 2022 12:32:31 -0000 Received: (qmail 22085 invoked by uid 550); 25 May 2022 12:32:28 -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 22011 invoked from network); 25 May 2022 12:32:27 -0000 Date: Wed, 25 May 2022 08:32:12 -0400 From: Rich Felker To: =?utf-8?B?546L5rSq5Lqu?= Cc: musl@lists.openwall.com Message-ID: <20220525123211.GV7074@brightrain.aerifal.cx> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4978b83d-871a-e8ca-ab4b-6dec73f34075@loongson.cn> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] add loongarch64 port v3 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. > > > >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. Rich