mailing list of musl libc
 help / color / mirror / code / Atom feed
From: 王洪亮 <>
To: Rich Felker <>,
Subject: Re: [musl] add loongarch64 port v6.
Date: Tue, 11 Apr 2023 18:00:25 +0800	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

在 2023/4/5 上午1:06, Szabolcs Nagy 写道:
> * 王洪亮 <> [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
>> maintain
>> 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'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) 

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[0] __attribute__((__aligned__(16))) in 
struct sigcontext.

3.In glibc, it is  __extcontext[0] __attribute__((__aligned__(16))) in 
struct mcontext.

Currently, we use __extcontext[] instead of __extcontext[0], 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?

  reply	other threads:[~2023-04-11 10:00 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                                 ` 王洪亮 [this message]
2023-04-12  2:21                                 ` 王洪亮
2022-10-12 18:20 ` [musl] add loongarch64 port v5 Rich Felker

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:

* 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).