From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS3215 2.6.0.0/16 X-Spam-Status: No, score=-5.3 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI,NICE_REPLY_A, RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [IPv6:2620:52:3:1:0:246e:9693:128c]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id E3A131F9FC for ; Thu, 4 Nov 2021 22:38:42 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 2E7413857809 for ; Thu, 4 Nov 2021 22:38:41 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 2E7413857809 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1636065521; bh=zMKeF0wXnDcgfP3DOOcQKxhWjfcPpfKOfKxdtCXqx0I=; h=Date:Subject:To:References:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=vYca0qTAb6UfGqqriBa9GP8a/LCYb2FgyxMBiftToqlrqh6lXhnlcAK1sLUOdc1t5 YmZUkR15G7DreJRk5+667gpnJOWQ9uG2a+wtODl47/e5fn5GtyjNCGQ8rp1ce+gPdY giJASDXr4Th6ddxFBRecdyIrBkFnTt87nd/4RkEQ= Received: from mx0a-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by sourceware.org (Postfix) with ESMTPS id 8E8F63857C70 for ; Thu, 4 Nov 2021 22:36:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 8E8F63857C70 Received: from pps.filterd (m0098420.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.1.2/8.16.1.2) with SMTP id 1A4MSMoL007232 for ; Thu, 4 Nov 2021 22:36:45 GMT Received: from ppma01wdc.us.ibm.com (fd.55.37a9.ip4.static.sl-reverse.com [169.55.85.253]) by mx0b-001b2d01.pphosted.com with ESMTP id 3c4njckh5d-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 04 Nov 2021 22:36:44 +0000 Received: from pps.filterd (ppma01wdc.us.ibm.com [127.0.0.1]) by ppma01wdc.us.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 1A4MJI52015198 for ; Thu, 4 Nov 2021 22:36:44 GMT Received: from b01cxnp22034.gho.pok.ibm.com (b01cxnp22034.gho.pok.ibm.com [9.57.198.24]) by ppma01wdc.us.ibm.com with ESMTP id 3c0wpcbqn2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 04 Nov 2021 22:36:44 +0000 Received: from b01ledav004.gho.pok.ibm.com (b01ledav004.gho.pok.ibm.com [9.57.199.109]) by b01cxnp22034.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 1A4MahPp44499230 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 4 Nov 2021 22:36:43 GMT Received: from b01ledav004.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 45A501120A0; Thu, 4 Nov 2021 22:36:43 +0000 (GMT) Received: from b01ledav004.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 10AF8112097; Thu, 4 Nov 2021 22:36:43 +0000 (GMT) Received: from [9.160.131.71] (unknown [9.160.131.71]) by b01ledav004.gho.pok.ibm.com (Postfix) with ESMTP; Thu, 4 Nov 2021 22:36:42 +0000 (GMT) Message-ID: Date: Thu, 4 Nov 2021 17:36:42 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.2.0 Subject: Re: [PATCH] powerpc64[le]: Fix CFI for assembly templated syscalls [BZ #28532] Content-Language: en-US To: Matheus Castanho References: <20211103142222.23948-1-msc@linux.ibm.com> <4b3eb1fb-6931-102b-01e3-aeb166f7b105@linux.ibm.com> <87h7ct9o57.fsf@linux.ibm.com> In-Reply-To: <87h7ct9o57.fsf@linux.ibm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: cNAz8QGT3F-41owreDZHCqS5Kf1Brho_ X-Proofpoint-GUID: cNAz8QGT3F-41owreDZHCqS5Kf1Brho_ X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.790,Hydra:6.0.425,FMLib:17.0.607.475 definitions=2021-11-04_07,2021-11-03_01,2020-04-07_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 adultscore=0 spamscore=0 clxscore=1015 mlxscore=0 mlxlogscore=999 priorityscore=1501 lowpriorityscore=0 phishscore=0 suspectscore=0 bulkscore=0 malwarescore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2110150000 definitions=main-2111040088 X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Paul E Murphy via Libc-alpha Reply-To: Paul E Murphy Cc: libc-alpha@sourceware.org Errors-To: libc-alpha-bounces+e=80x24.org@sourceware.org Sender: "Libc-alpha" On 11/3/21 11:41 AM, Matheus Castanho wrote: > > Paul E Murphy writes: > >> On 11/3/21 9:22 AM, Matheus Castanho via Libc-alpha wrote: >>> Syscalls based on the assembly templates are missing CFI for r31, which gets >>> clobbered when scv is used, and info for LR is inaccurate, placed in the wrong >>> LOC and not using the proper offset. These are fixed by this commit. >>> After this change: >>> $ readelf -wF libc.so.6 | grep 0004b9d4.. -A 7 && objdump --disassemble=kill >>> libc.so.6 >>> 00004a48 0000000000000020 00004a4c FDE cie=00000000 pc=000000000004b9d4..000000000004ba3c >>> LOC CFA r31 ra >>> 000000000004b9d4 r1+0 u u >>> 000000000004b9e4 r1+48 u u >>> 000000000004b9e8 r1+48 c-16 u >>> 000000000004b9fc r1+48 c-16 c-32 >>> 000000000004ba08 r1+48 c-16 >>> 000000000004ba18 r1+48 u >>> 000000000004ba1c r1+0 u >>> libc.so.6: file format elf64-powerpcle >>> Disassembly of section .text: >>> 000000000004b9d4 : >>> 4b9d4: 1f 00 4c 3c addis r2,r12,31 >>> 4b9d8: 2c c3 42 38 addi r2,r2,-15572 >>> 4b9dc: 25 00 00 38 li r0,37 >>> 4b9e0: d1 ff 21 f8 stdu r1,-48(r1) >>> 4b9e4: 20 00 e1 fb std r31,32(r1) >>> 4b9e8: 98 8f ed eb ld r31,-28776(r13) >>> 4b9ec: 10 00 ff 77 andis. r31,r31,16 >>> 4b9f0: 1c 00 82 41 beq 4ba0c >>> 4b9f4: a6 02 28 7d mflr r9 >>> 4b9f8: 10 00 21 f9 std r9,16(r1) >>> 4b9fc: 01 00 00 44 scv 0 >>> 4ba00: 10 00 21 e9 ld r9,16(r1) >>> 4ba04: a6 03 28 7d mtlr r9 >>> 4ba08: 08 00 00 48 b 4ba10 >>> 4ba0c: 02 00 00 44 sc >>> 4ba10: 00 00 bf 2e cmpdi cr5,r31,0 >>> 4ba14: 20 00 e1 eb ld r31,32(r1) >>> 4ba18: 30 00 21 38 addi r1,r1,48 >>> 4ba1c: 18 00 96 41 beq cr5,4ba34 >>> 4ba20: 01 f0 20 39 li r9,-4095 >>> 4ba24: 40 48 23 7c cmpld r3,r9 >>> 4ba28: 20 00 e0 4d bltlr+ >>> 4ba2c: d0 00 63 7c neg r3,r3 >>> 4ba30: 08 00 00 48 b 4ba38 >>> 4ba34: 20 00 e3 4c bnslr+ >>> 4ba38: c8 32 fe 4b b 2ed00 <__syscall_error> >>> ... >>> 4ba44: 40 20 0c 00 .long 0xc2040 >>> 4ba48: 68 00 00 00 .long 0x68 >>> 4ba4c: 06 00 5f 5f rlwnm r31,r26,r0,0,3 >>> 4ba50: 6b 69 6c 6c xoris r12,r3,26987 >>> --- >>> sysdeps/powerpc/powerpc64/sysdep.h | 6 ++++-- >>> 1 file changed, 4 insertions(+), 2 deletions(-) >>> diff --git a/sysdeps/powerpc/powerpc64/sysdep.h >>> b/sysdeps/powerpc/powerpc64/sysdep.h >>> index 589f7c8d18..beb477d57b 100644 >>> --- a/sysdeps/powerpc/powerpc64/sysdep.h >>> +++ b/sysdeps/powerpc/powerpc64/sysdep.h >>> @@ -275,12 +275,14 @@ LT_LABELSUFFIX(name,_name_end): ; \ >>> /* Allocate frame and save register */ >>> #define NVOLREG_SAVE \ >>> stdu r1,-SCV_FRAME_SIZE(r1); \ >>> + cfi_adjust_cfa_offset(SCV_FRAME_SIZE); \ >>> std r31,SCV_FRAME_NVOLREG_SAVE(r1); \ >>> - cfi_adjust_cfa_offset(SCV_FRAME_SIZE); >>> + cfi_offset(r31,-(SCV_FRAME_SIZE-SCV_FRAME_NVOLREG_SAVE)); >>> OK. This (and similarly the case below) seem a little obfuscated for >> computing stack save slots. I wonder if a distinct macro like >> SCV_FRAME_R31_SAVE_SLOT (and similar SCV_FRAME_CALLER_LR_SAVE_SLOT >> below) would make this code more approachable for those less familiar with ppc64 >> abis. >> > > But those kind of already exist: FRAME_LR_SAVE and > SCV_FRAME_NVOLREG_SAVE, but these two values are relative to the > top-most frame, so we need some math to get the values relative to the > CFA. > > Wouldn't adding 2 more macros with similar meanings (but with different > references) make things even more complicated? After refreshing my understanding of CFI. I agree with you. > >>> /* Restore register and destroy frame */ >>> #define NVOLREG_RESTORE \ >>> ld r31,SCV_FRAME_NVOLREG_SAVE(r1); \ >>> + cfi_restore(r31); \ >>> addi r1,r1,SCV_FRAME_SIZE; \ >>> cfi_adjust_cfa_offset(-SCV_FRAME_SIZE); >>> @@ -332,7 +334,7 @@ LT_LABELSUFFIX(name,_name_end): ; \ >>> #define DO_CALL_SCV \ >>> mflr r9; \ >>> std r9,FRAME_LR_SAVE(r1); \ >>> - cfi_offset(lr,FRAME_LR_SAVE); \ >>> + cfi_offset(lr,-(SCV_FRAME_SIZE-FRAME_LR_SAVE)) > .machine "push"; \ I suspect this change is highlighting a bug in the asm. We should be saving lr to the caller frame's lr slot, not the callee's. >>> .machine "power9"; \ >>> scv 0; \ >>> > > > -- > Matheus Castanho >