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 0E8323858D35 for ; Tue, 16 Apr 2024 13:14:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 0E8323858D35 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 0E8323858D35 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=1713273263; cv=none; b=IhgyETK/gWlmb+JJYnQpbZ+m4/Qh0+1DvLh9iLXeFE6ZQ+YDnfmdRFxtXujPz3hsukFXhQGoVpkU78I3CnFtJswPAsjrFgR30eONCN6QdIaL0TnpBQNICeSeJdQR11B3TGBN6kp12o9wcz4R7Hb4VTUmBDWDg+Ul2imV10wQv4E= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1713273263; c=relaxed/simple; bh=5QvgM3bwi0txf9Tai1ZmVtMf9iOJDPTfdXaw3XecqNo=; h=DKIM-Signature:Message-ID:Date:Subject:To:From:MIME-Version; b=EvWF3uiykiSxsjtk5S3EoRxf17WLuQjMEgDSwZzT6Kx9bfNktvQhgwGZagQ02caBSr6arCQrnFmc2WPT8e3zsTZCYQw7lSRUgv6wtn1gemLRBafDoB13VBotXxZdCy6nKY6plWteGxzpug51Az+PMlOs11uGFgNohRG61+SxFmQ= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from pps.filterd (m0353729.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 43GDCmnY023213; Tue, 16 Apr 2024 13:14:18 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=MLAu8XriBfYpGtHNyw0BcOYsp/R/oTinFbQk4gxWxBE=; b=Py4yWcuMLFwayj6PQCzNlyVwCaUz1iL6jS4rNMbGkCnycHBPIQUGeukFjKrKB7Buz9W3 MIgUXY8fR7pOkrt+10A3NJM+rnD+N2HB8n5JLepgYOfmbLOSs2Un/VsodgVi3a0240L4 qR8B2hiSDC+BCiYW0cRzyiGXQCMwRSzy3KpkxV7GzEzEmU0B2ndfb7XYuoFOwwrn4DR3 XAr9IGNtxxyWCfA8PWzeUdzShMpI/qVnCqK/hsKFYhzSnK7VZLDNdoNeALoH6CWbyvBk UVyJE0rXJdNa+i5XZJ9oe+R3OA6FKOCwlPCsiGPrNxOXwI4LcF4OMS7DQXzYYlATgoYq iA== Received: from ppma13.dal12v.mail.ibm.com (dd.9e.1632.ip4.static.sl-reverse.com [50.22.158.221]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3xht0s0058-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 16 Apr 2024 13:14:17 +0000 Received: from pps.filterd (ppma13.dal12v.mail.ibm.com [127.0.0.1]) by ppma13.dal12v.mail.ibm.com (8.17.1.19/8.17.1.19) with ESMTP id 43GASXUM021375; Tue, 16 Apr 2024 13:14:16 GMT Received: from smtprelay03.fra02v.mail.ibm.com ([9.218.2.224]) by ppma13.dal12v.mail.ibm.com (PPS) with ESMTPS id 3xg6kkdutk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 16 Apr 2024 13:14:16 +0000 Received: from smtpav05.fra02v.mail.ibm.com (smtpav05.fra02v.mail.ibm.com [10.20.54.104]) by smtprelay03.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 43GDEAjk40108422 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 16 Apr 2024 13:14:12 GMT Received: from smtpav05.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 87E252004D; Tue, 16 Apr 2024 13:14:10 +0000 (GMT) Received: from smtpav05.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 4031D2004B; Tue, 16 Apr 2024 13:14:10 +0000 (GMT) Received: from [9.179.9.38] (unknown [9.179.9.38]) by smtpav05.fra02v.mail.ibm.com (Postfix) with ESMTP; Tue, 16 Apr 2024 13:14:10 +0000 (GMT) Message-ID: <35d18b75-5509-4aae-9e5b-408382010573@linux.ibm.com> Date: Tue, 16 Apr 2024 15:14:09 +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> From: Jens Remus Content-Language: en-US Organization: IBM Deutschland Research & Development GmbH In-Reply-To: <20240412144718.4191286-11-jremus@linux.ibm.com> Content-Type: text/plain; charset=UTF-8; format=flowed X-TM-AS-GCONF: 00 X-Proofpoint-GUID: PiXNxi50ggqrTQVjoKsAJ20R-lwQeMCH X-Proofpoint-ORIG-GUID: PiXNxi50ggqrTQVjoKsAJ20R-lwQeMCH 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-16_09,2024-04-16_01,2023-05-22_02 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 lowpriorityscore=0 bulkscore=0 clxscore=1015 impostorscore=0 phishscore=0 suspectscore=0 mlxscore=0 adultscore=0 malwarescore=0 priorityscore=1501 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2404010000 definitions=main-2404160080 X-Spam-Status: No, score=-12.6 required=5.0 tests=BAYES_00,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: 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. Thanks and 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/