From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=MAILING_LIST_MULTI, NICE_REPLY_A,RCVD_IN_MSPIKE_H2 autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 7217 invoked from network); 11 Apr 2023 10:00:46 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 11 Apr 2023 10:00:46 -0000 Received: (qmail 20446 invoked by uid 550); 11 Apr 2023 10:00:43 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 20402 invoked from network); 11 Apr 2023 10:00:42 -0000 To: Rich Felker , musl@lists.openwall.com References: <20230129170407.GL4163@brightrain.aerifal.cx> <7c77f6d5-7f42-f3a9-af81-99a251780d19@loongson.cn> <20230216231336.GW4163@brightrain.aerifal.cx> <2775a5e6-1fc0-e542-47ea-e90170053654@loongson.cn> <00d245b2-c0b5-9978-7f7b-9d5aa5df6137@loongson.cn> <20230403133523.GG3630668@port70.net> <20230403144248.GE4163@brightrain.aerifal.cx> <20230403154435.GH3630668@port70.net> <20230404170635.GJ3630668@port70.net> From: =?UTF-8?B?546L5rSq5Lqu?= Message-ID: <1f54e72c-afde-4dd4-5f89-994a9ea16868@loongson.cn> Date: Tue, 11 Apr 2023 18:00:25 +0800 User-Agent: Mozilla/5.0 (X11; Linux mips64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <20230404170635.GJ3630668@port70.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-CM-TRANSID:AQAAf8Axlry5LzVkg0AeAA--.30403S3 X-CM-SenderInfo: pzdqwxxrqjzxhdqjqz5rrqw2lrqou0/ X-Coremail-Antispam: 1Uk129KBjvJXoWxXw1DJrW7WF1DWr47KryDZFb_yoW5Zw13pF WjkF18CrsrJFnayw1qka4jvr1Ykw4kJr1jkasYk34IkFy3tFykWry0vr4akF98Zr4kWrnF yr47KFyUuayYqrDanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUj1kv1TuYvTs0mT0YCTnIWj qI5I8CrVACY4xI64kE6c02F40Ex7xfYxn0WfASr-VFAUDa7-sFnT9fnUUIcSsGvfJTRUUU bx8YFVCjjxCrM7AC8VAFwI0_Jr0_Gr1l1xkIjI8I6I8E6xAIw20EY4v20xvaj40_Wr0E3s 1l1IIY67AEw4v_Jr0_Jr4l8cAvFVAK0II2c7xJM28CjxkF64kEwVA0rcxSw2x7M28EF7xv wVC0I7IYx2IY67AKxVWUJVWUCwA2z4x0Y4vE2Ix0cI8IcVCY1x0267AKxVWUJVW8JwA2z4 x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x0267AKxVW0oVCq3wAS0I0E 0xvYzxvE52x082IY62kv0487Mc804VCY07AIYIkI8VC2zVCFFI0UMc02F40EFcxC0VAKzV Aqx4xG6I80ewAv7VC0I7IYx2IY67AKxVWUGVWUXwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S 6xCaFVCjc4AY6r1j6r4UM4x0Y48IcVAKI48JMxk0xIA0c2IEe2xFo4CEbIxvr21l42xK82 IYc2Ij64vIr41l4I8I3I0E4IkC6x0Yz7v_Jr0_Gr1lx2IqxVAqx4xG67AKxVWUJVWUGwC2 0s026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r1Y6r17MIIYrxkI7VAKI48JMI IF0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6xkF7I0E14v26r1j6r4UMIIF 0xvE42xK8VAvwI8IcIk0rVWUJVWUCwCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E87 Iv6xkF7I0E14v26r1j6r4UYxBIdaVFxhVjvjDU0xZFpf9x07UWHqcUUUUU= Subject: Re: [musl] add loongarch64 port v6. 在 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: >>> 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?