[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 11 Apr 2023 18:00:25 +0800
From: 王洪亮 <wanghongliang@...ngson.cn>
To: Rich Felker <dalias@...c.org>, musl@...ts.openwall.com
Subject: Re: add loongarch64 port v6.
在 2023/4/5 上午1:06, Szabolcs Nagy 写道:
> * 王洪亮 <wanghongliang@...ngson.cn> [2023-04-04 17:46:36 +0800]:
>> 在 2023/4/3 下午11:44, Szabolcs Nagy 写道:
>>> i was asking because of this glibc patch:
>>> https://sourceware.org/pipermail/libc-alpha/2023-April/146897.html
>>>
>>> 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:
> https://sourceware.org/bugzilla/show_bug.cgi?id=21457
> 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.
Hi,
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[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?
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
