[PATCH] LoongArch: Modify some member names in mcontext_t and ucontext_t structs to align them with the kernel.

caiyinyu caiyinyu@loongson.cn
Mon Apr 3 09:41:28 GMT 2023


在 2023/4/3 下午5:25, Xi Ruoyao 写道:
> On Mon, 2023-04-03 at 17:18 +0800, caiyinyu wrote:
>> 在 2023/4/3 下午4:56, Xi Ruoyao 写道:
>>> On Fri, 2023-03-31 at 11:52 +0800, caiyinyu wrote:
>>>
>>> /* snip */
>>>
>>>> Your plan caused fails in glibc conform tests.
>>> Let me try something...
>>>
>>>> We wanted to inform you that we are aware that the proposed
>>>> modification[1] will affect the public API. However, since
>>>> LoongArch
>>>> Musl has not yet been released
>>> Then why not change the Musl instead?  It's not released so you
>>> won't
>>> break existing code.
>> This is also a viable solution, but we want to take advantage of the
>> early development
>>
>> stage to standardize the member names of mcontext_t/sigcontext in musl
>> and glibc2.36/37...
>>
>> to match those in the kernel in order to get rid of historical
>> baggage,
>>
>> as mentioned in the previous email.
> Give me several hours trying to make the anonymous union work.  I see
> similar things in other ports' mcontext_t definition so I guess I can
> make it work...
>
> And please don't change Glibc 2.36/37.  The reason is:
>
> If some downstream work decides get rid of historical things, the
> maintainer can just say "Glibc < 2.38 is not supported".
>
> Or they can use #if __GLIBC_PREREQ (2, 38) to support both releases if
> they want to support both old and new releases.
>
> But by backporting the change into 2.36 or 37, there will be no trivial
> way to support both "old" definition and "new" definition because there
> is no #ifdef can distinguish "patched" 2.37 and "unpatched" 2.37.  And
> you cannot tell distro maintainers to update there Glibc headers in
> /usr/include because doing so is *very* dangerous.

OK, thanks a lot.



More information about the Libc-alpha mailing list