From: 王洪亮 <firstname.lastname@example.org>
To: Szabolcs Nagy <email@example.com>, Rich Felker <firstname.lastname@example.org>,
Subject: Re: [musl] add loongarch64 port v6.
Date: Wed, 12 Apr 2023 10:21:00 +0800 [thread overview]
Message-ID: <email@example.com> (raw)
在 2023/4/5 上午1:06, Szabolcs Nagy 写道:
> * 王洪亮 <firstname.lastname@example.org> [2023-04-04 17:46:36 +0800]:
>> 在 2023/4/3 下午11:44, Szabolcs Nagy 写道:
>>> i was asking because of this glibc patch:
>>> i dont understand that change (loongarch is in glibc since 2.36 release).
>> Based on the v6 patch,I Modified the member names of struct sigcontext to
>> consistency with kernel and glibc. As shown in
> (1) if _XOPEN_SOURCE && !_GNU_SOURCE && !_BSD_SOURCE mcontext_t fields
> need not be accessible and must be in the impl reserved namespace
> (no glibc or linux api compat requirement, only posix namespace req).
> (2) otherwise musl mcontext_t fields must match glibc.
> (ucontext and mcontext_t must use the same api across libcs).
> i think it does not matter if the fields are different from the linux
> uapi sigcontext fields. glibc used to include linux asm/sigcontext.h
> to define mcontext_t so the fields were the same, but that polluted
> the namespace and got fixed a while ago:
> since then mcontext_t is not the same as struct sigcontext, but
> even before that they should not have been used interchangably
> in c apis (the c abi must match though).
> so i would not change the glibc code to match linux. and update the
> musl patch to match current glibc api. the only wart i see is that
> all targets currently have an uc_flags field in ucontext, loongarch
> has an __uc_flags, but i think that's fine if there is no portable
> use of this field. you may want to look into that, but it can be
> fixed with a #define uc_flags __uc_flags if needed.
> the glibc loongarch maintainers can break their api (and c++ abi) if
> they wish to make it consistent with linux uapi, but i don't think
> that's very useful. i'd wait for the glibc patch to be resolved and
> fix musl patches accordingly. the v6 patches currently violate both
> (1) and (2) requirements.
I received a email return notification, I send it again.
I'm waiting for the final modification of glibc, and fix the member name
of mcontext accordingly. I will also fix the problem about violate both
(1) and (2) requirements.
I would like to mention again about the zero-length arrays of mcontext:
1.In musl, it is extcontext in struct mcontext.
2.In kernel, it is sc_extcontext __attribute__((__aligned__(16)))
in struct sigcontext.
3.In glibc, it is __extcontext __attribute__((__aligned__(16)))
in struct mcontext.
Currently, we use __extcontext instead of __extcontext, and fill
the long __uc_pad before ucontext.uc_mcontext to achieve the 16 alignment
of ucontext.uc_mcontext in musl.From the base of ucontext, we can ensure
that the ucontext.uc_mcontext is 16 alignment throuth the fill of __uc_pad,
but struct mcontext itself (not ucontext.uc_mcontext, only mcontext) cannot
ensure 16 alignment in musl.From this point, it is inconsistent between musl
and kernel(glibc is consistent with kernel.).I worry that this may have
compatibility risks in the future.
So I want to ask if we could use the __attribute__((__aligned__(16)))
to describe extcontext instead of the __uc_pad in musl?
next prev parent reply other threads:[~2023-04-12 2:21 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-03 8:15 [musl] add loongarch64 port v5 王洪亮
2022-09-06 1:51 ` [musl] " 王洪亮
2022-09-06 5:12 ` WANG Xuerui
2022-10-08 1:44 ` 王洪亮
2022-10-12 8:22 ` [musl] " WANG Xuerui
2022-11-15 7:17 ` [musl] add loongarch64 port v6 王洪亮
2022-12-19 6:32 ` 王洪亮
2023-01-09 9:46 ` 王洪亮
2023-01-29 1:15 ` 王洪亮
2023-01-29 8:52 ` Ariadne Conill
2023-01-29 17:04 ` Rich Felker
2023-01-30 1:27 ` 王洪亮
2023-02-16 23:13 ` Rich Felker
2023-02-17 7:06 ` 王洪亮
2023-03-17 8:41 ` 王洪亮
2023-04-03 13:35 ` Szabolcs Nagy
2023-04-03 14:42 ` Rich Felker
2023-04-03 15:44 ` Szabolcs Nagy
2023-04-04 9:46 ` 王洪亮
2023-04-04 17:06 ` Szabolcs Nagy
2023-04-11 10:00 ` 王洪亮
2023-04-12 2:21 ` 王洪亮 [this message]
2022-10-12 18:20 ` [musl] add loongarch64 port v5 Rich Felker
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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
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).