From: 王洪亮 <wanghongliang@loongson.cn>
To: musl@lists.openwall.com
Subject: Re: [musl] add loongarch64 port v3
Date: Wed, 25 May 2022 18:08:23 +0800 [thread overview]
Message-ID: <4978b83d-871a-e8ca-ab4b-6dec73f34075@loongson.cn> (raw)
In-Reply-To: <20220524123201.GU7074@brightrain.aerifal.cx>
在 2022/5/24 下午8:32, Rich Felker 写道:
> 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.
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_handler
is inconsistent with kernel pushing it onto the stack in a signal frame.
so I understand the __attribute__((__aligned__(16))) is necessary in musl.
src/thread/pthread_cancel.c
static void cancel_handler(int sig, siginfo_t *si, void *ctx)
{
pthread_t self = __pthread_self();
ucontext_t *uc = ctx;
uintptr_t pc = uc->uc_mcontext.MC_PC;
...
}
musl/arch/loongarch64/bits/signal.h:
typedef unsigned long greg_t, gregset_t[32];
typedef struct sigcontext {
unsigned long pc;
gregset_t gregs;
unsigned int flags;
unsigned long extcontext[];
}mcontext_t;
linux/arch/loongarch/include/uapi/asm/sigcontext.h:
struct sigcontext {
__u64 sc_pc;
__u64 sc_regs[32];
__u32 sc_flags;
__u64 sc_extcontext[0] __attribute__((__aligned__(16)));
};
>
> Rich
next prev parent reply other threads:[~2022-05-25 10:08 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
2022-05-25 10:08 ` 王洪亮 [this message]
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=4978b83d-871a-e8ca-ab4b-6dec73f34075@loongson.cn \
--to=wanghongliang@loongson.cn \
--cc=musl@lists.openwall.com \
/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).