Re: [musl] add loongarch64 port v6.

[王洪亮 <wanghongliang@loongson.cn>]

在 2023/4/5 上午1:06, Szabolcs Nagy 写道:
> * 王洪亮 <wanghongliang@loongson.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?