Date: Tue, 24 May 2022 08:32:01 -0400 From: Rich Felker <dalias@...c.org> To: 王洪亮 <wanghongliang@...ngson.cn> Cc: musl@...ts.openwall.com Subject: Re: 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
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.