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 28459 invoked from network); 29 May 2022 06:34:17 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 29 May 2022 06:34:17 -0000 Received: (qmail 3117 invoked by uid 550); 29 May 2022 06:34:15 -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 3079 invoked from network); 29 May 2022 06:34:14 -0000 Date: Sun, 29 May 2022 08:34:02 +0200 From: Szabolcs Nagy To: =?utf-8?B?546L5rSq5Lqu?= Cc: musl@lists.openwall.com Message-ID: <20220529063402.GS1320090@port70.net> Mail-Followup-To: =?utf-8?B?546L5rSq5Lqu?= , 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> <07a1976c-2872-0e69-5602-7f5f055ef5ff@loongson.cn> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <07a1976c-2872-0e69-5602-7f5f055ef5ff@loongson.cn> Subject: Re: [musl] add loongarch64 port v3 * =E7=8E=8B=E6=B4=AA=E4=BA=AE [2022-05-26 11:07= :42 +0800]: > =E5=9C=A8 2022/5/25 =E4=B8=8B=E5=8D=888:32, Rich Felker =E5=86=99=E9=81= =93: > > On Wed, May 25, 2022 at 06:08:23PM +0800, =E7=8E=8B=E6=B4=AA=E4=BA=AE w= rote: > > > =E5=9C=A8 2022/5/24 =E4=B8=8B=E5=8D=888:32, Rich Felker =E5=86=99=E9= =81=93: > > > > What we've been trying to say is that there are several cases, none= of > > > > which seem to need it: > > > >=20 > > > > 1. You create an object with declared type struct sigcontext. In th= is > > > > 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. > > > >=20 > > > > 2. You malloc storage for the object with space for the flexible ar= ray > > > > member. In this case the allocation has alignment max_align_t a= nd > > > > 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? it is specified in iso c11. malloc aligns at least to this alignment. >=20 > TYPEDEF struct { long long __ll; long double __ld; } max_align_t; >=20 > I understand if FAM is not specified alignment,FAM is aligned according to > its type size,why is max_align_t? > > > >=20 > > > > 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 g= ave > > > > 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_han= dler > > > is inconsistent with kernel pushing it onto the stack in a signal fra= me. > > > so I understand the __attribute__((__aligned__(16))) is necessary in = musl. > > >=20 > > > src/thread/pthread_cancel.c > > >=20 > > > static void cancel_handler(int sig, siginfo_t *si, void *ctx) > > > { > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 pthread_t self =3D __pthr= ead_self(); > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ucontext_t *uc =3D ctx; > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 uintptr_t pc =3D uc->uc_m= context.MC_PC; > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ... > > > } > > >=20 > > > musl/arch/loongarch64/bits/signal.h: > > >=20 > > > typedef unsigned long greg_t, gregset_t[32]; > > > typedef struct sigcontext { > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 unsigned long pc; > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 gregset_t gregs; > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 unsigned int flags; > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 unsigned long extcontext[= ]; > > > }mcontext_t; > > >=20 > > > linux/arch/loongarch/include/uapi/asm/sigcontext.h: > > >=20 > > > struct sigcontext { > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 __u64=C2=A0=C2=A0 sc_pc; > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 __u64=C2=A0=C2=A0 sc_regs= [32]; > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 __u32=C2=A0=C2=A0 sc_flag= s; > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 __u64=C2=A0=C2=A0 sc_extc= ontext[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. >=20 > 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? the aligned attribute is not standard (iso c11 has _Alignas instead). the kernel does not care, but libc headers must work with all compilers and c language parsing tools, so if we can specify a struct with the same abi that the kernel wants but in a standard conform way, then we should do it that way. stating the padding explicitly is useful anyway when the exact layout of a type matters. it is not just about declaring the type but documenting the abi.