From: Rich Felker <email@example.com> To: 王洪亮 <firstname.lastname@example.org> Cc: email@example.com Subject: Re: [musl] add loongarch64 port v3 Date: Tue, 24 May 2022 08:32:01 -0400 [thread overview] Message-ID: <20220524123201.GU7074@brightrain.aerifal.cx> (raw) In-Reply-To: <firstname.lastname@example.org> 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
next prev parent reply other threads:[~2022-05-24 12:32 UTC|newest] Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-05-05 3:21 王洪亮 2022-05-09 1:34 ` [musl] " 王洪亮 2022-05-11 13:37 ` Rich Felker 2022-05-11 16:08 ` Arnd Bergmann 2022-05-16 14:27 ` [musl] " Rich Felker 2022-05-21 6:38 ` 王洪亮 2022-05-21 8:22 ` Markus Wichmann 2022-05-24 9:08 ` 王洪亮 2022-05-24 12:32 ` Rich Felker [this message] 2022-05-25 10:08 ` 王洪亮 2022-05-25 12:32 ` Rich Felker 2022-05-26 3:07 ` 王洪亮 2022-05-29 6:34 ` Szabolcs Nagy
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20220524123201.GU7074@brightrain.aerifal.cx \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: [musl] add loongarch64 port v3' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Code repositories for project(s) associated with this inbox: https://git.vuxu.org/mirror/musl/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).