From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by sourceware.org (Postfix) with ESMTPS id C6F9A3858D37 for ; Thu, 18 Apr 2024 10:28:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C6F9A3858D37 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=linux.ibm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linux.ibm.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org C6F9A3858D37 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=148.163.156.1 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1713436084; cv=none; b=o7cRkjs7+Vav0o0tI9NO7i43e3cW0mtcaIq/DjKuTbCMs5vhLr7j3tbg2YtvfdSwRJBFsb/r5BiTtGmwTqTNzm8VcowvtfvrcxCJghXN0XtxAukik4zuvVxYpvRRvBGTd6cYZQFQa5a+QFR3mFKtKrO17DV42+8688c7svlfXwU= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1713436084; c=relaxed/simple; bh=wyyhuuDEwy96CgPNeDFj7NKnZjMRguYq2pAFEfyL01o=; h=DKIM-Signature:Message-ID:Date:Subject:To:From:MIME-Version; b=a0UTm4Lam1XwNqUi6szJqEqBYhqL2nyJ7iqHFQdEms1iKQ+j0MT9yN/mZmkO0nR5iRSpgatDYeS4ITV2pmI8y8HeyqfbZ4WRgoidwa1JpxXuVuBPSZKpkx4Z4gE42CvECX793g8bU656ZXzbSiSWzmJW24AePmMrsSetOtr5dkY= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from pps.filterd (m0353728.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 43IA38KV003391; Thu, 18 Apr 2024 10:27:59 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=message-id : date : subject : to : cc : references : from : in-reply-to : content-type : content-transfer-encoding : mime-version; s=pp1; bh=RhQet+N0+R7jIgGG+6IoSPlwX8GjocwMK4iRkIDRu/E=; b=ZoIW4AMRyEyLiDD+1fZ8cZAFUo+TtPOWopyLnz9Psx1FDyqZgJR8+atMbapkoadkah+w QR0WoYlZNIZZmOWjKYO2cKQzl9n+gyX5YpgYATxpXhDcmJMWnBWmLLrxDpypzpvVGwMQ ghvcmuKLE5+cgWs+5MKFJLWIjo0u8Epe8mT+sOthf/fOqorhzVeuU0i0Mmg9pgorp61K X7FY5N1/+15uOl1wcydxZY9FE46AGppYr3WTPyf/uP8Ne49rP4QXvtGo8+iVF85Q7gnK OIyvV94UtPEJDLZZur1OhZoMIdTMR7FmjDoYV/sPveShSCPyBc/WTxcmBuZT+UtWTmU1 Lg== Received: from ppma12.dal12v.mail.ibm.com (dc.9e.1632.ip4.static.sl-reverse.com [50.22.158.220]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3xk1dnr1gg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 18 Apr 2024 10:27:58 +0000 Received: from pps.filterd (ppma12.dal12v.mail.ibm.com [127.0.0.1]) by ppma12.dal12v.mail.ibm.com (8.17.1.19/8.17.1.19) with ESMTP id 43I7onGD018206; Thu, 18 Apr 2024 10:27:57 GMT Received: from smtprelay04.fra02v.mail.ibm.com ([9.218.2.228]) by ppma12.dal12v.mail.ibm.com (PPS) with ESMTPS id 3xg4ctj9cg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 18 Apr 2024 10:27:57 +0000 Received: from smtpav03.fra02v.mail.ibm.com (smtpav03.fra02v.mail.ibm.com [10.20.54.102]) by smtprelay04.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 43IARqlE33882660 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 18 Apr 2024 10:27:54 GMT Received: from smtpav03.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 420242004B; Thu, 18 Apr 2024 10:27:52 +0000 (GMT) Received: from smtpav03.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 2919220040; Thu, 18 Apr 2024 10:27:52 +0000 (GMT) Received: from [9.155.201.79] (unknown [9.155.201.79]) by smtpav03.fra02v.mail.ibm.com (Postfix) with ESMTP; Thu, 18 Apr 2024 10:27:52 +0000 (GMT) Message-ID: Date: Thu, 18 Apr 2024 12:27:51 +0200 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 10/15] gas: Skip SFrame FDE if FP without RA on stack To: Indu Bhagat Cc: Andreas Krebbel , binutils@sourceware.org References: <20240412144718.4191286-1-jremus@linux.ibm.com> <20240412144718.4191286-11-jremus@linux.ibm.com> <35d18b75-5509-4aae-9e5b-408382010573@linux.ibm.com> <9bbfb6a8-c83c-484c-922b-cef90603f663@oracle.com> From: Jens Remus Content-Language: en-US Organization: IBM Deutschland Research & Development GmbH In-Reply-To: <9bbfb6a8-c83c-484c-922b-cef90603f663@oracle.com> Content-Type: text/plain; charset=UTF-8; format=flowed X-TM-AS-GCONF: 00 X-Proofpoint-GUID: qoO_9-dBdT_cYMZ8Zr6On7_u9WrjZYMh X-Proofpoint-ORIG-GUID: qoO_9-dBdT_cYMZ8Zr6On7_u9WrjZYMh Content-Transfer-Encoding: 8bit X-Proofpoint-UnRewURL: 0 URL was un-rewritten MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.272,Aquarius:18.0.1011,Hydra:6.0.619,FMLib:17.11.176.26 definitions=2024-04-18_08,2024-04-17_01,2023-05-22_02 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxscore=0 priorityscore=1501 bulkscore=0 mlxlogscore=999 impostorscore=0 adultscore=0 spamscore=0 malwarescore=0 suspectscore=0 lowpriorityscore=0 clxscore=1015 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2404010000 definitions=main-2404180074 X-Spam-Status: No, score=-9.8 required=5.0 tests=BAYES_00,BODY_8BITS,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,GIT_PATCH_0,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Am 18.04.2024 um 01:56 schrieb Indu Bhagat: > On 4/16/24 06:14, Jens Remus wrote: >> Hello Indu, >> >> Am 12.04.2024 um 16:47 schrieb Jens Remus: >>> The SFrame format cannot represent the frame pointer (FP) being saved >>> on the stack without the return address (RA) also being saved on the >>> stack, if RA tracking is used. >> >> [...] >> >>> diff --git a/gas/gen-sframe.c b/gas/gen-sframe.c >>> index a3b6f75cfe85..87be3eb05ad2 100644 >>> --- a/gas/gen-sframe.c >>> +++ b/gas/gen-sframe.c >>> @@ -1439,6 +1439,25 @@ sframe_do_fde (struct sframe_xlate_ctx >>> *xlate_ctx, >>>       = get_dw_fde_end_addrS (xlate_ctx->dw_fde); >>>       } >>> +#ifdef SFRAME_FRE_RA_TRACKING >>> +  if (sframe_ra_tracking_p ()) >>> +    { >>> +      struct sframe_row_entry *fre; >>> + >>> +      /* Iterate over the scratchpad FREs and validate them.  */ >>> +      for (fre = xlate_ctx->first_fre; fre; fre = fre->next) >>> +    { >>> +      /* SFrame format cannot represent FP on stack without RA on >>> stack.  */ >>> +      if (fre->ra_loc != SFRAME_FRE_ELEM_LOC_STACK >>> +          && fre->bp_loc == SFRAME_FRE_ELEM_LOC_STACK) >>> +        { >>> +          as_warn (_("skipping SFrame FDE due to FP without RA on >>> stack")); >>> +          return SFRAME_XLATE_ERR_NOTREPRESENTED; >>> +        } >>> +    } >>> +    } >>> +#endif /* SFRAME_FRE_RA_TRACKING  */ >>> + >>>     return SFRAME_XLATE_OK; >>>   } >> >> I noticed that above new warning is erroneously emitted when >> assembling the following CFI directive sequence with option "-alh" (to >> output a listing of the assembly; probably any "-a[...]") on a SFrame >> enabled target, that uses FP and RA tracking. >> >> .cfi_offset , >> .cfi_offset , >> >> The reason is that with listings enabled there is an additional DWARF >> DW_CFA_advance_loc CFI instruction (with a zero advance) between both >> DW_CFA_offset instructions, that the DWARF .eh_frame generator is able >> to process correctly, but causes the .sframe generator to choke. >> >> Additionally with this patch reverted "bad" SFrame information is >> generated (see example below), where there are multiple SFrame FREs >> for the same PC start address. >> Note that the FP-tracking information erroneously being displayed in >> the RA-tracking column, is why I introduced this new warning message. >> I will send two alternative patches how to potentially resolve that soon. >> >> $ cat test_fpra_min.s >>          .cfi_sections .sframe, .eh_frame >>          .cfi_startproc >>          stmg    %r11,%r15,88(%r15) >>          .cfi_rel_offset 11, 88 >>          .cfi_rel_offset 14, 112 >>          la      %r11,0 >>          la      %r14,0 >> .Lreturn: >>          lmg     %r11,%r15,88(%r15) >>          .cfi_restore 14 >>          .cfi_restore 11 >>          br      %r14 >>          .cfi_endproc >> >> $ ojbdump --sframe test_fpra_without-alh.o >> ... >>    Function Index : >> >>      func idx [0]: pc = 0x0, size = 22 bytes >>      STARTPC         CFA       FP        RA >>      0000000000000000  sp+160    u         u >>      0000000000000006  sp+160    c-72      c-48 >>      0000000000000014  sp+160    u         u >> >> $ objdump --sframe test_fpra_with_alh.o >> ... >>    Function Index : >> >>      func idx [0]: pc = 0x0, size = 22 bytes >>      STARTPC         CFA       FP        RA >>      0000000000000000  sp+160    u         u >>      0000000000000006  sp+160    u         c-72 >>      0000000000000006  sp+160    c-72      c-48 >>      0000000000000014  sp+160    u         c-72 >>      0000000000000014  sp+160    u         u >> >> Note that the outputs of "objdump -Wf" and "objdump -WF" are identical >> in both cases (with and without option "-alh"). >> >> Debugging of the SFrame processing of the DWARF CFI instructions shows >> that with option "-a" there are additional DW_CFA_advance_loc: >> >> DW_CFA_def_cfa: reg=15 offset=160 >> DW_CFA_advance_loc: lab1=L0, lab2=L0 >> DW_CFA_offset: reg=11 offset=-72 >> DW_CFA_advance_loc: lab1=L0, lab2=L0   <-- only with -a >> DW_CFA_offset: reg=14 offset=-48 >> DW_CFA_advance_loc: lab1=L0, lab2=L0 >> DW_CFA_restore: reg=14 >> DW_CFA_advance_loc: lab1=L0, lab2=L0   <-- only with -a >> DW_CFA_restore: reg=11 >> >> Debugging of the CFI directive processing in gas/dw2gencfi.c shows the >> following: >> >> - With option "-a" cfi_add_advance_loc() is invoked more often in >> dot_cfi() due to the condition (symbol_get_frag >> (frchain_now->frch_cfi_data->last_address) != frag_now) evaluating to >> true. >> >> - output_cfi_insn() of case DW_CFA_advance_loc enters the condition >> (symbol_get_frag (to) == symbol_get_frag (from)) without option "-a" >> and enters the else condition with option "-a". The else path has an >> interesting comment that suggests that there is logic to relax an >> advance by zero at a later stage: >> >> "... Call frag_grow with the sum of room needed by frag_more and >> frag_var to preallocate space ensuring that the DW_CFA_advance_loc4 is >> in the fixed part of the rs_cfa frag, so that the relax machinery can >> remove the advance_loc should it advance by zero." >> >> I don't have a clue how to resolve this potential issue in the SFrame >> generation. I could not figure out how to detect the advance of zero >> in the SFrame processing of DW_CFA_advance_loc, so that it could be >> treated special. >> I can open a ticket in the Sourceware Bugzilla, if you agree that this >> is an issue. >> > > Hi Jens, > > Confirming that its reproducible and that this is an issue in the > existing implementation.  Please go ahead and create a bugzilla. > > Thanks Hello Indu, thanks for confirming! Opened: https://sourceware.org/bugzilla/show_bug.cgi?id=31654 Regards, Jens -- Jens Remus Linux on Z Development (D3303) and z/VSE Support +49-7031-16-1128 Office jremus@de.ibm.com IBM IBM Deutschland Research & Development GmbH; Vorsitzender des Aufsichtsrats: Wolfgang Wendt; Geschäftsführung: David Faller; Sitz der Gesellschaft: Böblingen; Registergericht: Amtsgericht Stuttgart, HRB 243294 IBM Data Privacy Statement: https://www.ibm.com/privacy/