From: Rich Felker <dalias@libc.org>
To: 王洪亮 <wanghongliang@loongson.cn>
Cc: musl@lists.openwall.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: <777071eb-d8c3-eb04-fef4-4f54d6016e8f@loongson.cn>
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 \
--to=dalias@libc.org \
--cc=musl@lists.openwall.com \
--cc=wanghongliang@loongson.cn \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public 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).