From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-5.2 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,NICE_REPLY_A,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: from second.openwall.net (second.openwall.net [193.110.157.125]) by inbox.vuxu.org (Postfix) with SMTP id AB82723F17 for ; Tue, 30 Jan 2024 08:35:56 +0100 (CET) Received: (qmail 21685 invoked by uid 550); 30 Jan 2024 07:33:30 -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 21632 invoked from network); 30 Jan 2024 07:33:29 -0000 To: Rich Felker , musl@lists.openwall.com References: <20240125174353.GW22081@brightrain.aerifal.cx> <20240129164702.GR4163@brightrain.aerifal.cx> From: Hongliang Wang Message-ID: Date: Tue, 30 Jan 2024 15:35:33 +0800 User-Agent: Mozilla/5.0 (X11; Linux loongarch64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <20240129164702.GR4163@brightrain.aerifal.cx> Content-Type: multipart/mixed; boundary="------------2E06E3131F5F68A1A8C91B1F" Content-Language: en-US X-CM-TRANSID:AQAAf8Cxbs3EprhlDJQnAA--.21399S3 X-CM-SenderInfo: pzdqwxxrqjzxhdqjqz5rrqw2lrqou0/ X-Coremail-Antispam: 1Uk129KBj93XoWxCr18Xr1Dtr4fKFyDJr1rZrc_yoWrJw4kpF WFvayrKrW8Jw1vy3s0gw1UXF10kryF9FWrWa93Ka4j9F15WFnYvr1fGr4a9FW5J3yvka1Y vrW0934UuFZ8ZFcCm3ZEXasCq-sJn29KB7ZKAUJUUUU8529EdanIXcx71UUUUU7KY7ZEXa sCq-sGcSsGvfJ3Ic02F40EFcxC0VAKzVAqx4xG6I80ebIjqfuFe4nvWSU5nxnvy29KBjDU 0xBIdaVrnRJUUUBCb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I20VC2zVCF04k26cxKx2 IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48v e4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Gr0_Xr1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI 0_Gr0_Cr1l84ACjcxK6I8E87Iv67AKxVW8Jr0_Cr1UM28EF7xvwVC2z280aVCY1x0267AK xVW8Jr0_Cr1UM2vj62AExVA0xI801c8C04v26x02cVCv0xWle2I262IYc4CY6c8Ij28IcV AaY2xG8wASzI0EjI02j7AqF2xKxwAqjxCEc2xF0cIa020Ex4CE44I27wAqx4xG64xvF2IE w4CE5I8CrVC2j2WlYx0E2Ix0cI8IcVAFwI0_Jr0_Jr4lYx0Ex4A2jsIE14v26r1j6r4UMc vjeVCFs4IE7xkEbVWUJVW8JwACjcxG0xvEwIxGrwCYjI0SjxkI62AI1cAE67vIY487MxAI w28IcxkI7VAKI48JMxC20s026xCaFVCjc4AY6r1j6r4UMI8I3I0E5I8CrVAFwI0_Jr0_Jr 4lx2IqxVCjr7xvwVAFwI0_JrI_JrWlx4CE17CEb7AF67AKxVWUXVWUAwCIc40Y0x0EwIxG rwCI42IY6xIIjxv20xvE14v26r1j6r1xMIIF0xvE2Ix0cI8IcVCY1x0267AKxVWUJVW8Jw CI42IY6xAIw20EY4v20xvaj40_Jr0_JF4lIxAIcVC2z280aVAFwI0_Jr0_Gr1lIxAIcVC2 z280aVCY1x0267AKxVWUJVW8JbIYCTnIWIevJa73UjIFyTuYvjxU1J5rUUUUU Subject: Re: [musl] loongarch64 merge This is a multi-part message in MIME format. --------------2E06E3131F5F68A1A8C91B1F Content-Type: text/plain; charset=gbk; format=flowed Content-Transfer-Encoding: 8bit ÔÚ 2024/1/30 ÉÏÎç12:47, Rich Felker дµÀ: > On Thu, Jan 25, 2024 at 12:43:54PM -0500, Rich Felker wrote: >> I'm going through where everything was left on this topic and >> preparing a patch for merge. This message/thread is to document what >> I'm actually doing vs the various submitted versions of the patch >> since v5/v6 where the major review took place. >> >> >> Subsequent changes I'm reverting: >> >> - De-optimization of __get_tp. No motivation for removing the >> potentially in-place $tp was provided, and we generally use the >> arch's tp in-place unless there's a compiler bug to be worked >> around. See powerpc{,64} for an example where it's used, or1k where >> we have a probably-obsolete workaround for ancient clang being >> broken. >> >> - unsigned -> unsigned int, etc. >> >> - Gratuitous whitespace changes in headers that obscure the fact that >> a header is a complete duplicate that could eventually be shared >> between archs (e.g. bits/float.h, bits/posix.h) or just obscure >> what differs from other archs when running diff. >> >> >> Fixes from previous review that were overlooked: >> >> - Removing SA_RESTORER -- its presence defined as 0 produces wrong >> sigaction ABI. >> >> >> Additions: >> >> - Adding the reloc.h/configure case for single-only float. >> >> - The new member names for mcontext_t are all in reserved namespace, >> so there's no reason to have a separate namespace-clean version of >> mcontext_t, and I'm removing the latter. >> >> - Public member uc_flags with no __, macro for compat with any >> existing software using the __-prefixed name. >> >> >> Still TODO: >> >> I don't think I ever reviewed the apparent rewrite of sigsetjmp and >> possibly some other asm that changed between v5 and v8. I'm about to >> start looking at that and will follow up. > > OK, sigsetjmp appears to have been non-working in v5 (it failed to > save the argument anywhere, so attempted it use it after it was > clobbered in the code path after calling setjmp). > > v8 fixes this and seems like it should work, but I don't understand > the offsets used. > > The loongarch64 __jmp_buf has 23 slots, but only appears to use 21 of > them, with sigsetjmp storing its extra data in the last 2 unused > slots. The contract here is supposed to be that the entirety of > __jmp_buf belongs to setjmp/longjmp, with sigsetjmp using the extra > space in the full jmp_buf/sigjmp_buf type with signal mask and lots of > extra space. > > Were these slots added just for sigsetjmp? If so, that was an ABI > mistake, but I don't think it warrants a late change; it's probably > better to just leave them there as extensibility. Yes, the purpose of the last 2 slots of __jmp_buf just used for sigsetjmp to storing its extra data. Now leave them there as extensibility is OK. Hongliang Wang > > Either way, I think sigsetjmp should be modified not to rely on > storage in space that setjmp is entitled to be able to modify, i.e. it > should be using offsets 184 and 184+16, not 168 and 176. > > Rich > I understand. I attached a patch to fix this issue. please review it. diff --git a/src/signal/loongarch64/sigsetjmp.s b/src/signal/loongarch64/sigsetjmp.s index 992ab1a4..9c0e3ae2 100644 --- a/src/signal/loongarch64/sigsetjmp.s +++ b/src/signal/loongarch64/sigsetjmp.s @@ -5,8 +5,8 @@ sigsetjmp: __sigsetjmp: beq $a1, $zero, 1f - st.d $ra, $a0, 168 - st.d $s0, $a0, 176 + st.d $ra, $a0, 184 + st.d $s0, $a0, 200 #184+8+8 move $s0, $a0 la.global $t0, setjmp @@ -14,8 +14,8 @@ __sigsetjmp: move $a1, $a0 # Return from 'setjmp' or 'longjmp' move $a0, $s0 - ld.d $ra, $a0, 168 - ld.d $s0, $a0, 176 + ld.d $ra, $a0, 184 + ld.d $s0, $a0, 200 #184+8+8 .hidden __sigsetjmp_tail la.global $t0, __sigsetjmp_tail (END) Hongliang Wang --------------2E06E3131F5F68A1A8C91B1F Content-Type: text/x-patch; charset=UTF-8; name="0001-loongarch64-fix-the-incorrect-offset-of__jmp_buf-use.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename*0="0001-loongarch64-fix-the-incorrect-offset-of__jmp_buf-use.pa"; filename*1="tch" >From 762a21eb0e1addf508cdb3ab2e3c109400734452 Mon Sep 17 00:00:00 2001 From: wanghongliang Date: Tue, 30 Jan 2024 06:51:56 +0800 Subject: [PATCH] loongarch64:fix the incorrect offset of__jmp_buf used in sigsetjmp. Signed-off-by: wanghongliang --- src/signal/loongarch64/sigsetjmp.s | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/signal/loongarch64/sigsetjmp.s b/src/signal/loongarch64/sigsetjmp.s index 992ab1a4..9c0e3ae2 100644 --- a/src/signal/loongarch64/sigsetjmp.s +++ b/src/signal/loongarch64/sigsetjmp.s @@ -5,8 +5,8 @@ sigsetjmp: __sigsetjmp: beq $a1, $zero, 1f - st.d $ra, $a0, 168 - st.d $s0, $a0, 176 + st.d $ra, $a0, 184 + st.d $s0, $a0, 200 #184+8+8 move $s0, $a0 la.global $t0, setjmp @@ -14,8 +14,8 @@ __sigsetjmp: move $a1, $a0 # Return from 'setjmp' or 'longjmp' move $a0, $s0 - ld.d $ra, $a0, 168 - ld.d $s0, $a0, 176 + ld.d $ra, $a0, 184 + ld.d $s0, $a0, 200 #184+8+8 .hidden __sigsetjmp_tail la.global $t0, __sigsetjmp_tail -- 2.37.1 --------------2E06E3131F5F68A1A8C91B1F--