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 3615 invoked from network); 24 May 2022 12:32:16 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 24 May 2022 12:32:16 -0000 Received: (qmail 32722 invoked by uid 550); 24 May 2022 12:32:14 -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 32666 invoked from network); 24 May 2022 12:32:13 -0000 Date: Tue, 24 May 2022 08:32:01 -0400 From: Rich Felker To: =?utf-8?B?546L5rSq5Lqu?= Cc: musl@lists.openwall.com Message-ID: <20220524123201.GU7074@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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <777071eb-d8c3-eb04-fef4-4f54d6016e8f@loongson.cn> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] add loongarch64 port v3 On Tue, May 24, 2022 at 05:08:21PM +0800, 王洪亮 wrote: > > 在 2022/5/21 下午4:22, Markus Wichmann 写道: > >>>I'm also not clear on how > >>>specifying the alignment here helps since any object created in a way > >>>that the alignment would affect cannot have the FAM present. > >>> > >>the __aligned__(16)  here used to save 128bit vector later. > >But it has no effect, right? The array member is offset an integer > >multiple of sixteen bytes from the start of the structure, so it is > >already aligned with respect to that, and the declaration adds no > >further padding (and if it did, common style in both Linux and musl is > >to explicate the padding). And the pointer to the structure comes from > >the kernel. > > if no __aligned__(16),the struct sigcontext is 8 bytes align,even if > the extcontext[] 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. Rich